5 ms·

Wouldn't it by nice to have a language where the project owners said "you know what, I think we're done, just bug fixes now".

jcelerier 5y ago
feel free to use QBASIC
daniel-thompson 5y ago
Not a language in the way you mean, but TeX did this a while back.
JeanMeche 5y ago
Yeah, for a dying language.
- badsectoracula 5y ago
  A language's surroundings can still be improved, the documentation can still be improved, new tools can still be made, new libraries can still be written, etc. And at the end if the language is inadequate for something then simply use something else that fits better, there is no reason to force all languages be gigantic kitchensinks.
  - twblalock 5y ago
    On the other hand, it is a lot of work to build your product in one language, which you then outgrow, which forces you to switch to another language. I've seen this happen many times, particularly with projects that started out in Python. Eventually the codebase and teams get too big, and managing a large codebase in a language with Python's type system becomes very cumbersome. Type annotations were a reaction to that, and adding them to the language has probably enabled a lot of teams to continue using Python. Off the top of my head, other examples of good changes include NIO and better concurrency primitives/lambda syntax in Java, generics in Go, and async/await in several other languages. All of those solved pain points for developers that might have otherwise been solved by switching languages. Why does this matter? First of all, it's a lot of work to rewrite products in different languages. Also, while it sounds attractive to pick the right language for the task every time, in practice it is difficult to run a coherent engineering organization if every product or team uses a different language -- it's hard to build good shared libraries and app frameworks for every language in use, and if someone leaves the company it can be hard to transfer their projects to other engineers. Most of the time, as an engineering org matures it eventually settles on a few "blessed" languages, invests in good frameworks for them, and requires all the teams to use them. Out of necessity, those tend to be the "kitchen sink" variety.
    - badsectoracula 5y ago
      This is about why you may want a kitchensink language, which can be fine depending on the case and a criterion for choosing it as "the right language" (or skipping a language) for your case but it isn't really about making all languages kitchensink languages. The comment above implied that languages which'd try to avoid becoming kitchensink languages would be dying languages - as if these are the only outcomes.
      - pjmlp 5y ago
        People miss that programing languages are no different from any kind of software products, and software products without new releases hardly survive.
loeg 5y ago
Mid-2000s versions of C and C++ come close, but I think the new features since then are largely worth having.
- KptMarchewa 5y ago
  C++ was just tied in "C++0x" debacle for over a decade, only delivered when they cut tons of stuff.
tsimionescu 5y ago
Common Lisp is like this. There is a standard, but no changes have been done since then. On the other hand, it also shows some of the disadvantages - for example, there is no multi-threading support of any kind in the Common Lisp standard, because this was not a common feature at the time the standard was created; neither is there Unicode support. Of course there are libraries that implement these things, even portably (and this being CL, the difference between library and core langauge is minimal), but it's still a point some hold against it.
frou_dh 5y ago
That's Standard ML. Coming at you live straight outta '97
chubot 5y ago
Rich Hickey talked about this in his History of Clojure presentation and paper. https://news.ycombinator.com/item?id=27782864 https://news.ycombinator.com/item?id=27782864 It's definitely an unusual approach for authors to consider software "done", and Clojure apparently gets close to it (?) Not surprisingly, that kind of stance also generates controversy ... you can't win :)
maximilianroos 5y ago
COBOL awaits you!
- sblom 5y ago
  Still being revised in standards committees: https://en.wikipedia.org/wiki/COBOL#COBOL_2014 https://en.wikipedia.org/wiki/COBOL#COBOL_2014
twic 5y ago
awk?
yifanl 5y ago
Elixir announced something to that effect in 2019. > As mentioned earlier, releases was the last planned feature for Elixir. We don’t have any major user-facing feature in the works nor planned. I know for certain some will consider this fact the most excing part of this announcement! [0] [0] https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-released/ https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas...
travisgriggs 5y ago
Elixir feels largely this way to me. Though I'm on the fence, that they end run around the pressure to evolve, by just inventing new DSLs via gobs of macro magic for some of the newer stuff. Whereas a language like Swift keeps leaning on the compiler to respond to evolving demands.

jcelerier 5y ago

feel free to use QBASIC

daniel-thompson 5y ago

Not a language in the way you mean, but TeX did this a while back.

JeanMeche 5y ago

Yeah, for a dying language.

badsectoracula 5y ago
A language's surroundings can still be improved, the documentation can still be improved, new tools can still be made, new libraries can still be written, etc. And at the end if the language is inadequate for something then simply use something else that fits better, there is no reason to force all languages be gigantic kitchensinks.
- twblalock 5y ago
  On the other hand, it is a lot of work to build your product in one language, which you then outgrow, which forces you to switch to another language. I've seen this happen many times, particularly with projects that started out in Python. Eventually the codebase and teams get too big, and managing a large codebase in a language with Python's type system becomes very cumbersome. Type annotations were a reaction to that, and adding them to the language has probably enabled a lot of teams to continue using Python. Off the top of my head, other examples of good changes include NIO and better concurrency primitives/lambda syntax in Java, generics in Go, and async/await in several other languages. All of those solved pain points for developers that might have otherwise been solved by switching languages. Why does this matter? First of all, it's a lot of work to rewrite products in different languages. Also, while it sounds attractive to pick the right language for the task every time, in practice it is difficult to run a coherent engineering organization if every product or team uses a different language -- it's hard to build good shared libraries and app frameworks for every language in use, and if someone leaves the company it can be hard to transfer their projects to other engineers. Most of the time, as an engineering org matures it eventually settles on a few "blessed" languages, invests in good frameworks for them, and requires all the teams to use them. Out of necessity, those tend to be the "kitchen sink" variety.
  - badsectoracula 5y ago
    This is about why you may want a kitchensink language, which can be fine depending on the case and a criterion for choosing it as "the right language" (or skipping a language) for your case but it isn't really about making all languages kitchensink languages. The comment above implied that languages which'd try to avoid becoming kitchensink languages would be dying languages - as if these are the only outcomes.
    - pjmlp 5y ago
      People miss that programing languages are no different from any kind of software products, and software products without new releases hardly survive.

loeg 5y ago

Mid-2000s versions of C and C++ come close, but I think the new features since then are largely worth having.

KptMarchewa 5y ago
C++ was just tied in "C++0x" debacle for over a decade, only delivered when they cut tons of stuff.

tsimionescu 5y ago

Common Lisp is like this. There is a standard, but no changes have been done since then. On the other hand, it also shows some of the disadvantages - for example, there is no multi-threading support of any kind in the Common Lisp standard, because this was not a common feature at the time the standard was created; neither is there Unicode support. Of course there are libraries that implement these things, even portably (and this being CL, the difference between library and core langauge is minimal), but it's still a point some hold against it.

frou_dh 5y ago

That's Standard ML. Coming at you live straight outta '97

chubot 5y ago

Rich Hickey talked about this in his History of Clojure presentation and paper. https://news.ycombinator.com/item?id=27782864 https://news.ycombinator.com/item?id=27782864 It's definitely an unusual approach for authors to consider software "done", and Clojure apparently gets close to it (?) Not surprisingly, that kind of stance also generates controversy ... you can't win :)

maximilianroos 5y ago

COBOL awaits you!

sblom 5y ago
Still being revised in standards committees: https://en.wikipedia.org/wiki/COBOL#COBOL_2014 https://en.wikipedia.org/wiki/COBOL#COBOL_2014

twic 5y ago

awk?

yifanl 5y ago

Elixir announced something to that effect in 2019. > As mentioned earlier, releases was the last planned feature for Elixir. We don’t have any major user-facing feature in the works nor planned. I know for certain some will consider this fact the most excing part of this announcement! [0] [0] https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-released/ https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas...

travisgriggs 5y ago

Elixir feels largely this way to me. Though I'm on the fence, that they end run around the pressure to evolve, by just inventing new DSLs via gobs of macro magic for some of the newer stuff. Whereas a language like Swift keeps leaning on the compiler to respond to evolving demands.