Not to be the perpetual Luddite, but I hate how much programming languages change. I don’t particularly like go as a language (good board game though), but the minimal changes over time starts to feel really correct.
I don't think the issue is that languages change per se - it's that they borrow features from other languages, that people ask "can we have $feature from $language please?"
in JS (and years before that, PHP), one example was object-oriented programming / classes, except in both JS and PHP it was never implemented fully, with JS not even having access modifiers for a long time. JS didn't need classes and the implementation is lacking, but someone decided it should be added.
Likewise, Java had functional programming bolted on; they never extended the base List types with functional modifiers, so now you have to transform or wrap your List in a Stream to make it work with Java's attempts at functional programming. Personally, I think if you want to do FP or FP-style coding on the JVM, you should rewrite things in Scala. You can write Scala and Java side-by-side.
Same with JS, you want JS but with types? You can have Typescript. I wish they did the same with JS-with-classes, just write a new language that compiles to JS instead of bolt classes onto the JS standard.
My second love was LISP. I love me some functional programming.
But I greatly dislike multi-paradigm programming languages. Mostly because I've worked with other programmers.
Borrowing features (idioms) from other languages is great. Pattern matching is nice. For Java, I'm looking forward to (interpolated) string templates and implicit classes. Destructuring would be nice too.
--
But for the love of Larry, where are intrinsic regex expressions?
Path expressions?
Most of our work is data processing.
Input -> munging -> output.
Meaning cutting and pasting strings.
So I mostly want new features related to string and data processing.
--
The evergreen fetish (kink) with arcana like type systems, monads, and metaprogramming is just so besides the point. That's what Lambda the Ultimate and HN are for.
For "commercial" languages, just give me tools for work.
Fussing with novel languages is for my hobby projects.
> I wish they did the same with JS-with-classes, just write a new language that compiles to JS instead of bolt classes onto the JS standard.
I think the classes were a good thing. Better would have been to change the OO model entirely, but if you're going to have one and can't change it, nice to at least have some sugar to make it usable. IDK if it's better elsewhere, but prototypal OO was pretty clearly a miss-step for Javascript, and sugar to make the OO system usable and less-obtuse (while making it easier to ignore the parts that should basically never be used, which parts amount to all the distinctive things about prototypal OO) is a decent move.
> Same with JS, you want JS but with types? You can have Typescript. I wish they did the same with JS-with-classes, just write a new language that compiles to JS instead of bolt classes onto the JS standard.
Wow, relevant username for this take, as you'd end up with an eldritch creature as soon as people tried to bolt these DSLs together into their opinionated bags of features, and a meta-language landscape that resembles the already fragmented frontend landscape of today
To be fair, now that almost all professionally-written passes through a rewriting compiler, Javascript actually has evolved to a ecosystem that _can_ handle rapid (non-breaking) changes to a language spec.
I'd also argue that the majority of these changes are to the standard library (new methods on String, Array, RegExp, etc). Not really core language changes. I don't know how often the go libs update but surely faster than the language spec?
They're likely referring to Babel and TypeScript. In short, it doesn't matter what you're writing as long as your transpiler has the right `target` so it works in older browsers/engines too.
There are popular JavaScript tools that nearly everyone uses, that reimplement Lisp poorly by source-to-source compiling stuff written against the latest new hotness spec into something that can be run by some old-and-busted JavaScript runtime (e.g., in browsers).
I'm more annoyed that the direction of change is mostly converging. Maybe that's a good thing, but it seems every language needs to add every popular feature of other languages until it's possible to code any language as any other language except in incompatible syntax.
In the case of TypeScript, we have the base JavaScript, template literals, and the type system all playing this game in the same file. Three systems trying to out feature each other. Tagged template literals, template literal types, etc.
Template literal types (a) have nothing to do with tagged template literals, and (b) are a game-changing feature, allowing you to write compile-time string parsers.
It’s a cutesy thing that basically always comes with a “don’t actually do/use this!” disclaimer. The thing that’s actually good about template literal types is that they allow for modeling a whole class of real world JS that wasn’t possible otherwise. That is and always has been the fundamental goal of TS.
Go helped me realize that how much you like a language can partially be a function of how you try to use it.
I used Go wrong for years. Once I stopped doing dumb stuff with it (especially with the type system), it got a lot more pleasant. I don’t think I’d design it the same way, but I’m quite a bit happier using it now.
It’s kind of like using a hammer to drive a screw. The problem isn’t the screw or the hammer. Go seems to be a hammer-screw situation for a lot of people, but there really is a happy path.
Not saying this because I think you’re unaware — mostly thinking out loud because I used to feel like Go needed new features and your comment reminded me of this. I also like the relative stability of Go now, though. It has a great foundational toolset and good design overall, so to its credit, it hasn’t really needed to change so much. I only thought it did because I used it wrong.
The C99 changes were pretty radical, but couldn't be broadly used until around 2016 when the Microsoft compiler finally caught up and started to implement the most important C99 features.
in JS (and years before that, PHP), one example was object-oriented programming / classes, except in both JS and PHP it was never implemented fully, with JS not even having access modifiers for a long time. JS didn't need classes and the implementation is lacking, but someone decided it should be added.
Likewise, Java had functional programming bolted on; they never extended the base List types with functional modifiers, so now you have to transform or wrap your List in a Stream to make it work with Java's attempts at functional programming. Personally, I think if you want to do FP or FP-style coding on the JVM, you should rewrite things in Scala. You can write Scala and Java side-by-side.
Same with JS, you want JS but with types? You can have Typescript. I wish they did the same with JS-with-classes, just write a new language that compiles to JS instead of bolt classes onto the JS standard.