Learning yet another new language for the sake of just knowing another language? Not particularly.

There's an incredible amount of churn in the web languages/frameworks arena. A few years ago it seemed like every week another PHP "MVC" framework was released with exactly the same features as the last one, but with claims that it was faster, more robust, more extensible, and so on. At one point the "big players" were CakePHP and CodeIgniter. Now they seem to be Symfony and Laravel, but feature-wise there doesn't seem to be a huge amount of difference to how your application is structured in these particular frameworks.

Now the churn seems to have shifted away from PHP to JS and JS build systems, and lo and behold we have Imba, "a new programming language for the web".

Sometimes these tools offer clear advantages, other times not so. But often the lifespan on these seems to be less than a year. Everyone is excited about Backbone for six months, until Ember comes out and now no one talks about Backbone. But then Angular comes out and no-one talks about Ember. Investing time in learning any new tool can feel like a huge waste of time when there's a high chance that said tool will disappear a year or so down the line.

Moving this away from the land of web, a new language should at the very least offer a new perspective on something, for example Rust's approach to memory management is intriguing enough for it to potentially be worthwhile.

I like learning new skills and techniques. A language with a different syntax and some sugar-coating that is fundamentally the same as something I already know isn't that.

But maybe I'm just bitter ;)

I do like learning new languages, but there's a certain amount of fatigue in this particular space, given the pace of announcements and limited time. There's a worry that one could spend all one's available time for learning new things and have learned nothing of value in two years.

For this to be of value, it has to provide at least one of four things:

1. Becoming a widely-adopted system (like node.js)

2. Strong influence on widely-adopted systems (like Elm)

3. Insights that influence one personally (like most any lisp)

4. More fun than alternative things one could be playing with

Even Elm is far from widely adopted, though I agree it has really captured people's attention

The widely adopted example was node.js; Elm was my example of a system that has had strong influence on widely adopted systems (like React/Redux).

I like learning new languages that are of VALUE to learn: to quote Alan Perlis: " A language that doesn't affect the way you think about programming, is not worth knowing."

Imba doesn't seem to do anything new, just add some new syntax that seems similar to coffeescript.

If you want to make a new language, good on you, but don't trumpet it as the next big thing, that's a revolution, unless it's doing something new, or at least has a different idea about how to do it. Failing all that, at least have it be good for getting stuff done fast. This is the "perl approach."

I think existing programmers sometimes forget that there's more people who /will/ program than who /do/ program. They have existing biases: towards extra tokens, separation of concerns by separating technologies rather than components, and other newer concepts that they legitimately do find strange.

People making programming languages are much better suited by targeting non-programmers: existing devs are often simply not their audience.

"People making programming languages are much better suited by targeting non-programmers: existing devs are often simply not their audience."

In this case I'd argue it would be better for non-programmers to learn JavaScript before a language which compiles to it.

I agree with that: these languages often don't have devtools, so they have to look at the compiled output to fix bugs. This makes for an unpleasant learning experinece.

Once these tools fix the DevTools situation they'll be a lot more useful.

Imba is still lacking when it comes to devtools, but it does have full support for source mapping, and the sublime text plugin includes inline error messages from the compiler.

I get a little confused when people say they "compile" x scripting language into y scripting language.

Are you trying to be snarky or are you actually confused? Check out the wikipedia article on Transpilers for info on source to source compilers.

I know. Not trying to be snarky at all. Why don't people call stuff by it's names??? Transpiling, not compiling.

Maybe it looks like I'm nitpicking... If it got across like that, sorry. Not my intention at all.

What would you call it other than "compiling"?

Transpiling, as said above. Or maybe transpiling is compiling. I think I'll get out of it more confused than going in.

I like to view transpiling as a specialization of compiling. Even if you try to make the distinction between high-level input -> low-level output, in the end it feels like the language matters much less than how the generated code is designed. Most "transpilers" end up using the bare minimum number of features for the target language and staying constrained to a pretty low-level part of that language. For example, languages that transpile to JavaScript tend to target asm.js, which really doesn't look anything like the JavaScript that real people write. Getting bogged down in naming differences when the overall process is pretty much identical is just ignoring the big picture in my mind.

Because 10 years of experience is not the same thing as one year of experience repeated 10 times.

I could not agree more! To me it seems that most of what is happening today is an exhausting chase by some developers to fill their CV / Resume with the latest buzz word technology, resulting in a shallow understanding of deep fundamental concepts and years of experience on a CV that means absolutely nothing.

As a college senior, this has been my problem—constant context switching to "keep updated". It really is a problem. My resolution for this year is to just focus and get good at at most two languages and their ecosystems.

I only learn something new if I have a reason to. I may learn PHP in the near future because my company is migrating to Magento from Rails.

I actively try to avoid learning when pursuing side projects. With side projects, the idea is to explore a domain rather than tools. My current side project, a productivity / accounting app, requires no new knowledge, and I want to keep it that way.

I am very skeptical that, after a certain level of proficiency, that significant time spent in other programming paradigms makes you better all around. I went through HtDP several years ago, and thought it was wonderful, but I don't program that way now. I do not TDD everything, or even most things, even though I know how to do it and why you would want to. You take the best parts of everything you come across, and throw away what you don't like.

The longer I code, the more I default to the tried-and-true. Everything else just seems counter-productive.

I am also cautious about learning new technologies and very carefully select what I actually learn.

Using proven techniques and tools makes experienced people more productive even if their raw mental abilities decline with age.

Learning and testing new technologies is expensive and most of the time leads nowhere.

I have a limited amount of give a sh. There's just way too many javascript/web frameworks being put out for me to give a sh about all of them.

Because 98% is bullshit. Get very interested, have fun, learn, prototype, things look fine, then after start use seriously and depend on makes you so much pain and problem. Then have to fix, and patch and in the end: always remove. After you have this experience many times you will also very critical and have high expectation/requirement, then you will come to HN and reply negatively.