4 ms·

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

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.

bryanlarsen 4y ago
The changes aren't breaking. Javascript from the 90's still works.
packetlost 4y ago
C doesn't seem to have substantially changed in 20+ years.
- flohofwoe 4y ago
  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.
  - kevin_thibedeau 4y ago
    C11 provides a lot of useful goodies too. I don't relish the idea of writing C89 and giving up all the improvements.
- RobotToaster 4y ago
  C23 adds support for type inference.
- kahrl 4y ago
  It has.
djtriptych 4y ago
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?
- avgcorrection 4y ago
  > To be fair, now that almost all professionally-written passes through a rewriting compiler, What?
  - HeavyFeather 4y ago
    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.
  - bitwize 4y ago
    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). In fact this is how TypeScript is implemented.
    - Dylan16807 4y ago
      A pass to strip some type annotations isn't a poor reimplementation of Lisp, jeez. I know the quote you're referring to but you're stretching a mile to get there.
  - djtriptych 4y ago
    To add the above - I also meant to write "Professionally-written Javascript" in case it was the grammar that threw you off. Sorry!
    - avgcorrection 4y ago
      Thanks. :) Wasn’t able to fill in the dropped word.
Cthulhu_ 4y ago
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.
- specialist 4y ago
  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.
  - mLuby 4y ago
    What does "intrinsic regex" mean?
    - specialist 4y ago
dayvid 4y ago
If it's any consolation, the guy from nomadlist is building AI businesses with jQuery and PHP: https://twitter.com/levelsio/status/1633422349012992007 https://twitter.com/levelsio/status/1633422349012992007
- wiseowise 4y ago
  How does it work, though?
svachalek 4y ago
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.
- AprilArcus 4y ago
  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.
  - Aeolun 4y ago
    > allowing you to write compile-time string parsers I’m not entirely sure this is a good thing. But it’s certainly convenient in some instances.
    - rcfox 4y ago
      I, for one, love that my ORM can statically check my SQL statements.
    - eyelidlessness 4y ago
      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.
steve_adams_86 4y ago
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.

bryanlarsen 4y ago

The changes aren't breaking. Javascript from the 90's still works.

packetlost 4y ago

C doesn't seem to have substantially changed in 20+ years.

flohofwoe 4y ago
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.
- kevin_thibedeau 4y ago
  C11 provides a lot of useful goodies too. I don't relish the idea of writing C89 and giving up all the improvements.
RobotToaster 4y ago
C23 adds support for type inference.
kahrl 4y ago
It has.

djtriptych 4y ago

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?

avgcorrection 4y ago
> To be fair, now that almost all professionally-written passes through a rewriting compiler, What?
- HeavyFeather 4y ago
  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.
- bitwize 4y ago
  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). In fact this is how TypeScript is implemented.
  - Dylan16807 4y ago
    A pass to strip some type annotations isn't a poor reimplementation of Lisp, jeez. I know the quote you're referring to but you're stretching a mile to get there.
- djtriptych 4y ago
  To add the above - I also meant to write "Professionally-written Javascript" in case it was the grammar that threw you off. Sorry!
  - avgcorrection 4y ago
    Thanks. :) Wasn’t able to fill in the dropped word.

Cthulhu_ 4y ago

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.

specialist 4y ago
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.
- mLuby 4y ago
  What does "intrinsic regex" mean?
  - specialist 4y ago

dayvid 4y ago

If it's any consolation, the guy from nomadlist is building AI businesses with jQuery and PHP: https://twitter.com/levelsio/status/1633422349012992007 https://twitter.com/levelsio/status/1633422349012992007

wiseowise 4y ago
How does it work, though?

svachalek 4y ago

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.

AprilArcus 4y ago
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.
- Aeolun 4y ago
  > allowing you to write compile-time string parsers I’m not entirely sure this is a good thing. But it’s certainly convenient in some instances.
  - rcfox 4y ago
    I, for one, love that my ORM can statically check my SQL statements.
  - eyelidlessness 4y ago
    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.

steve_adams_86 4y ago

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.