Comment by kqr | Hacker News Reader

Comment by kqr | Hacker News Reader

Parent Full thread

The points on the fluff in particular resonate with me because idespite being a fairly good software engineer, I would say it was only recently I truly started seeing past the fluff.

However, typing this out, I realise I would have said the same thing 10 years ago, and 5 years ago, and I probably will again another 5 years from now.

I think the truth is that we're always missing the forest for all the trees -- only at increasing levels of abstraction: at first, everything is foreign, then syntax becomes fluff, then APIs become fluff, then patterns, then languages, then compilers, then ... I look forward to learning what the next level of fluff will be.

> The majority of the stuff being released every day is just a rehash of the same ideas. Truly revolutionary stuff only happens every few years.

Maybe not even that often. I can recommend Old Is the New New by Kevlin Henney for a good, historical perspective on how little actually changes sometimes: https://youtube.com/watch?v=AbgsfeGvg3E

Edit: now this was more interesting than I anticipated. What is the next level of fluff? Concurrency? Advanced data structures? Phrasing problems for SMT solvers? Probabilistic modeling?

Or are the things I picture as fluff just specific techniques, because the next level of fluff is so meta I wouldn't even recognise it now?

> then languages

Perhaps a slight digression, but: I think there are very few people who can really say they can 'see through' the difference between languages.

C++, Erlang, Prolog, and Haskell, are very different languages, all the way from the shallow matter of syntax, through the type system, and even down to the fundamental model of computation. When I hear someone say If you learn to program in one language, it's easy to learn another, I assume that person doesn't know much about programming.

> If you learn to program in one language, it's easy to learn another, I assume that person doesn't know much about programming.

This is flat out wrong.

If you know Python, it'll be easier to learn Rust than having to learn Rust from zero. Engineering is about problem solving and formulating solutions with algorithms and data structures. If you don't know what those are yet, it'll take much longer to learn.

Learning one of anything makes learning the next one easier. Programming languages, spoken languages, musical instruments, sports cars, martial arts, sports, weapons, drawing, etc. Your brain builds a rich scaffold you can hang new concepts from.

> If you know Python, it'll be easier to learn Rust than having to learn Rust from zero.

> Learning one of anything makes learning the next one easier

Agreed, but I put easy, not easier. I suspect we really agree on all points.

If you know C#, it's easy to learn Java, as most the concepts are shared, and even the syntax is very similar. When someone says If you learn to program in one language, it's easy to learn another, it betrays that they don't understand that some languages are similar, but some are very different and have unavoidable learning curves.

C++ is a good example. Learning C++ is not easy, no matter what your background knowledge of other concepts and languages. It's a huge language, in which nothing is simple. Even the build model is a minefield. Having a solid understanding of imperative programming and OOP (from knowing Java, say) is certainly an important head-start. I wouldn't recommend C++ as someone's first programming language. There's still an enormous amount to learn about C++ specifically, no matter your background knowledge.

It’s also worth noting that projects are rarely contained within the bounds of a programming language.

If you’re building a web app, what’re language you use will still come down to HTML/css. You’ll also probably be using SQL, which is also unlikely to change.

But there’s the other side to that. If you’re graphics programming, OpenGL provides the same features regardless of language. The OS APIs are broadly the same - the steps to set up a TCP listener don’t change with the language.

The APIs for all these may be subtlety different between languages, but not significantly. It’s a case of translation rather than relearning, and although I can’t speak for anyone else I find that translation quite painless.

Learning Python before Haskell also made learning Haskell significantly harder for me, because I kept trying to write Python in Haskell

Sure, but it will still be a while before you aren't just writing Python in Rust.

It’s still easier than if you had never previously written an if statement. If there weren’t a lot of differences between languages then we wouldn’t have so many languages, but that doesn’t mean that there are not a lot of concepts that are used widely across many languages.

However the more languages you know and the more they're spread across different paradigms the shallower the learning curve will be for any language one wants to pick up.

Be fair to the original comment, which referenced people saying something about learning a language, and it making learning any others easy, not about learning many languages, and it making learning any others easier.

Writing Python in Rust unlike say writing C++ in Rust, might actually be a desirable thing. Put it this way, It will be a while before you are writing Rust like Python.

I'm one of those people, but there's more nuance than that to it. I've learned about 20 different languages to some degree, from Python to brainfuck to Elixir currently. When I learn a new language, I go to the source material, so for elixir I used the tutorials at the elixir home page and their API documentation. I read the tutorials, writing each line of code into my editor, running each, modifying it to see how it works, etc. Then, everytime the tutorial links to or mentions an API, I'll go read that documentation page in full and experimenting. Then I'll make some projects with that language, look at how the more experienced Elixir (or whatever) developers code by exploring their repos, etc.

After doing that 10+ times, it becomes easier to see the patterns in languages, and easier to understand how their underlying structure will affect how you have to code. There's only so many ways to write a compiler or interpreter, and if you know how they work and you know that your language is, for example, optimized for tail recursion, then you get your experience from other similar languages as a bonus.

I see your point if you're saying, on a surface level, that, "you know one, you know them all," is wrong, but if you dig deeper I think you'll see that, for the experienced (as in: someone who's been around a while) developer, you kinda can say that, with some reservations.

I think anyone can do the same thing, it just takes a decade or more to get there. I'm kinda dumb, too, so if I can do it, anyone can.

I'm with you on this - I don't know so many languages but have studied a wide range, and am fluent in several programming and human languages.

What I've found that is that once you learn more than one language with different paradigms, it becomes easier to learn another one with a similar or another different paradigm.

As you pointed out, there are only so many ways a language can be designed/structured, and becoming multilingual means getting familiar with the shared (and implicit) models and operations underlying all languages.

Your 2nd paragraph says what I meant to say, but much more sussinctly. Thank you.

Well, as someone who has taught different languages as first, second and third languages to students and young pupils I would say it becomes easier. Not easy in an absolute sense. It still requires effort.

I would however agree with you that those who say "it's easy to learn another" in an absolute way has usually only considered languages from the same group so far.

I also agree with this. Some people treats languages like forks. It's just a fork why pick another it will do just fine right? Well languages are more like artist tools I think. Of course you can draw a perfect horse with pen/pastel/charcoals as in writing really good i.e Chat Server with Java/Erlang, but each of them has different taste, feeling, community. Picking a language is pretty different than picking a fork. And those all the way Javascript / Java lovers feels like 0.7/0.5 mechanical pencil users that tries draw everything with that. How about trying a brush? (Maybe I shouldn't have pushed this analogy this far)

No offense to, my fork lover friends.

Or they program different things than you do. In data science for example it's not a big deal to jump across Matlab, Python, Julia, Lua etc.

If you know Java, you'll not take very long to be productive in another JVM language or in C#.

Yes, deep specialized expertise will take time. Also, switching across paradigms or levels (C -> Prolog or Python -> assembly) will take much longer. But that's not what people usually have in mind when they say switching languages is easy. It's usually the domain that takes longer to learn.

> If you learn to program in one language, it's easy to learn another.

That's often the case: many people who think that don't really use the strengths of the languages they use.

On the other hand, I've written a basic lambda calculus parser for fun and gone on to write (non-distributable, if I care about people) software using it, also for fun; I've written idiomatic, well-formed code in BASIC, C, Perl, Ruby, Scheme, Standard ML, and a wide range of other things; and I've basically added features by removing code. At some point, even if you know what you're doing, there comes a point where, kinda-sorta, it becomes easy to learn others.

It just takes a lot more than learning only one language to get to that point. Whether the person who first coined that comment about learning languages meant it as a simplification of a wise concept or was a blubdev who never really figured out the significant differences between programming languages is a question I'd like to see answered definitively, based on knowledge of the individual rather than guesses.

They might not mean "easy" in the same way you mean. I sometimes find myself saying "easy" when what I mean is something more like "approachable" or "without many ambiguous roadblocks". I very much believe it is "easy" in that way to learn new programming languages. It is still hard work, requiring lots of reading and trial and error and plenty of failure, but it doesn't have that same experience of complete stuckness as the first time learning to program.

But I wouldn't say it is "easy" after learning one language. It definitely takes two or three, with step-changes each time you learn a language in a different paradigm than you have before.

I would expand that to "If you learn to program in one language, it's easy to learn another within the same paradigm".

If you know Python, Ruby or PHP will be pretty easy for you to pick up. You might have some difficulties with Haskell and Lisp.

I'd add that spending some time to play with the languages that are hard or different will pay dividends down the road.

Learning some Haskell was probably the most worthwhile time I have spent learning a language because it forced me to fundamentally reevaluate how I think about programming. Now I don't use Haskell at work, and likely never will; but, years later, the techniques I learned from it I still apply daily when I write C, Python, JS or whatever. It made my code far cleaner.

Whenever a newish programmer has asked me what language they should learn next I always say prolog. I fully expect them to never touch the language afterwards, but writing prolog was a truly a mind opening experience. More so than learning functional programming imo.

I feel this same way about Clojure, I won't likely ever use it professionally, but it's made me a better programmer having learned it.

I routinely write in no less than 4 languages for work... comfortably in all of them. Each certainly have their own nuances but the skills translate and made learning the others easier. At worst I (have had to and do) sometimes look up syntax or end up using a design that's less than optimal for that languadge, but that still works.

I absolutely agree with you. Being able to call languages fluff comes from me having tried to build real applications with C, Python, Prolog, Erlang, Haskell, Ada, POSIX shell, AWK, Common Lisp, Perl, R, and so on.

Crucially, I don't just think of languages as different syntax for Java.

I've been having this experience recently. I used to be a voracious reader of programming books. But for a long time starting, gosh, maybe over 5 years ago, I just couldn't get excited to read them anymore. Just recently I thoroughly enjoyed reading Designing Data Intensive Applications, and I have just started Streaming Systems, which I'm also enjoying a lot. I think this idea of fluff at different levels of abstraction explains it: I used to enjoy reading books about programming languages and frameworks, but at some point it just felt like fluff and I could no longer get through it. But there are books about techniques for solving particular classes of problem (in the case of my recent reading: data processing) which don't feel like fluff to me. But maybe they will eventually, and maybe you're already further on this continuum and would find these books fluffy as well. I'll definitely be thinking about this fluff at different levels of abstraction model and checking my self-education against it as I go now!

Not sure how to write this. I am hoping the next level of fluff to be removed will be implementing concrete algorithms in procedural or functional style in day to day coding. Instead we should be leveraging other programs (such as SMT solvers, but not limited to those) to produce a suitable implementations of solutions. That is, we should try to focus more on specifications, in one form or another.

So much of the software I work with could plausibly have been written by a machine instead.

Reply on news.ycombinator.com