Why?
Why?
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 ;)
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
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."
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.
Once these tools fix the DevTools situation they'll be a lot more useful.
Maybe it looks like I'm nitpicking... If it got across like that, sorry. Not my intention at all.
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.
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.