5 ms·

It is a mysterious thing how the influencers of various kind in software engineering, have to jump from something new to something new. Even if the "new" new ha

It is a mysterious thing how the influencers of various kind in software engineering, have to jump from something new to something new. Even if the "new" new has been created a long time ago. Using old systems is in no way fashionable. Everyone wants the latest whatnot on their resume to be more attractive for future job opportunities. We are forever stuck in a fast fashion web. I like to think about typed vs non typed langauges For a long time they both existed in relativ harmony (much more so than emacs vs vi). Then it became the THE THING to use non typed langues. In part because "having to write the type in the code was far too much work". We got young software developers who had never used a type langauge but who had joined the "church of non typed". Skipping ahead, some influencer discovers typed languages and how it solves many problems. What about that. Choices are good. We can make informed choices as to what tool makes the most sense in the context of what we are trying to solve. (and its fit with the team and the legacy code etc)

anilakar 2y ago
Kubernetes is great. Legacy bash and cron is hip and cool again just because you can wrap stuff in a k8s cronjob.
cultofmetatron 2y ago
> Even if the "new" new has been created a long time ago. laughs in common lisp
- tartoran 2y ago
  (+ ha ha ha ha)
wruza 2y ago
Having lived through all that I think it’s worth reminding that old typed languages were no match to modern ones. I’m not talking about arcane envs here, only about practical and widely used. People didn’t really go just “untyped”. Untyped simply was quicker in becoming easier to use and less screwed than the old. Or you may even view it as paving the road. Typed slowly catched up with the same quality under new names. This nuance is easy to miss, but set the cut off date to 2005 and recollect what your “options” were again. They weren’t that shiny.
- actionfromafar 2y ago
  Basically Java, right? C++ was mostly gnarly, especially considering the tools available to most people. There were cool languages but the tooling was not cool. GHC...
  - pjmlp 2y ago
    C++ Builder and Delphi were definitly cool.
- pjmlp 2y ago
  Quicker only when not using IDEs, which some folks apparently failed to learn while hipping scritping languages. Also some of the coolness of today's typed languages were already available in those days, I had ML languages, during early 1990's on my degree. ML for the Working Programmer was published in 1991.
- chikere232 2y ago
  I remember a lot of praise for duck "typing" as if it was an innovation, and claims you should just write unit tests to catch type errors. People kept glossing over the fact that writing typed code would be so much easier than writing untyped code with sufficient manual tests to catch type errors, because no one did the last bit. Things just broke runtime instead.
  - pjc50 2y ago
    Yes, this always struck me as completely bananas. Types are a vastly superior form of test for certain conditions. Duck typing with type inference would be nice but seems to be completely esoteric. You could have both the flexibility of being able to write "func(arg)" without having to specify the type, and the constraint that if you call arg.foo() in your function the compiler should enforce that you actually have a foo method on arg. (special side-eye to the people materializing methods and properties all over the place at runtime. This seems to have been a rails/python thing that is gradually going out of fashion.)
  - sgarland 2y ago
nejsjsjsbsb 2y ago
Is that Alfonzo Church of the untyped lambda calculus?
- cjfd 2y ago
  Yes, however his brother Alonzo did not mind the typed lambda calculus all that much.
InDubioProRubio 2y ago
Its also part of the economic cycle- centralized architectures thrive in a monopolistic oligarchy - and would quickly fall out of fashion after some trustbusting.
froh 2y ago
Is it so mysterious, though? isn't it "simply" the thesis - antithesis - synthesis cycle? and this cycle needs time, years, decades sometimes. OO starts in the 1970s. C++ comes 1985, Java 1995 (while smalltalk was born 1972) Hoare talks about CSP in 1978. golang mainlined it 2009. SQL started in 1970s and reached first consensus in the 1980s. or take the evolution from sgml->xml->json w/ json-schema... concepts need time to mature. and merging concepts (like duck typing and static type analysis in python) in addition needs both base concepts to be mature enough first. and likewise, at a personal level, brains need time to absorb the concepts. So of course "younglings" only know part of the world. And on the other hand mature technologies often have evolved their idiosyncracies, their "warts", and they sometimes paint themselves into some corner. C++ with ABI stability; perl with sigils; Java with "Java only" and a poor JNI and "xml xml xml"; UML with "graphical language"; many languages with no syntax baseline marker "this is a C++-95 file" or "this is a python 2 file", freezing syntax... So imho it's not simply a mysterious urge for the shiny, new stuff, but a mixed bag of overwhelm (I'll rather start something new before I dig through all that's here) and deliberate decisions (I do know what I'm talking about and X, and Y can't be "simply evolved" into Z, so I start Z).
- TeMPOraL 2y ago
  I feel the main reason this cycle still needs those decades to loop back again is that the world underwent its digital revolution during current iteration. We can't do synthesis without breaking everything, so we instead spawn sub-cycles on top - and then most of those end up frozen mid-way for the same reason, and we spawn sub-cycles on top of them, and so on. That's why our systems look like geological layers - XML at the bottom, JSON in the middle, and at the top JSON w/ schemas, plus a little Cambrian explosion of alternatives forming its anthitesis... and looking at it, SGML starts looking sexy again. And sure enough, you can actually use it today - but guess how? That's right, via an npm packge[0]. Wonder if we ever get a chance to actually pull all the accumulated layers of cruft back - to go through synthesis, complete the cycle and create a more reasonable base layer for the future. -- [0] - https://sgmljs.net/docs/producing-html-tutorial/producing-html-tutorial.html https://sgmljs.net/docs/producing-html-tutorial/producing-ht... / https://sgmljs.net/ https://sgmljs.net/
gonzo41 2y ago
The biggest sin IMO is the language devs who decide to "bring in types" to previously untyped langs. Dropped spaghetti everywhere.

anilakar 2y ago

Kubernetes is great. Legacy bash and cron is hip and cool again just because you can wrap stuff in a k8s cronjob.

cultofmetatron 2y ago

> Even if the "new" new has been created a long time ago. laughs in common lisp

tartoran 2y ago
(+ ha ha ha ha)

wruza 2y ago

Having lived through all that I think it’s worth reminding that old typed languages were no match to modern ones. I’m not talking about arcane envs here, only about practical and widely used. People didn’t really go just “untyped”. Untyped simply was quicker in becoming easier to use and less screwed than the old. Or you may even view it as paving the road. Typed slowly catched up with the same quality under new names. This nuance is easy to miss, but set the cut off date to 2005 and recollect what your “options” were again. They weren’t that shiny.

actionfromafar 2y ago
Basically Java, right? C++ was mostly gnarly, especially considering the tools available to most people. There were cool languages but the tooling was not cool. GHC...
- pjmlp 2y ago
  C++ Builder and Delphi were definitly cool.
pjmlp 2y ago
Quicker only when not using IDEs, which some folks apparently failed to learn while hipping scritping languages. Also some of the coolness of today's typed languages were already available in those days, I had ML languages, during early 1990's on my degree. ML for the Working Programmer was published in 1991.
chikere232 2y ago
I remember a lot of praise for duck "typing" as if it was an innovation, and claims you should just write unit tests to catch type errors. People kept glossing over the fact that writing typed code would be so much easier than writing untyped code with sufficient manual tests to catch type errors, because no one did the last bit. Things just broke runtime instead.
- pjc50 2y ago
  Yes, this always struck me as completely bananas. Types are a vastly superior form of test for certain conditions. Duck typing with type inference would be nice but seems to be completely esoteric. You could have both the flexibility of being able to write "func(arg)" without having to specify the type, and the constraint that if you call arg.foo() in your function the compiler should enforce that you actually have a foo method on arg. (special side-eye to the people materializing methods and properties all over the place at runtime. This seems to have been a rails/python thing that is gradually going out of fashion.)
- sgarland 2y ago

nejsjsjsbsb 2y ago

Is that Alfonzo Church of the untyped lambda calculus?

cjfd 2y ago
Yes, however his brother Alonzo did not mind the typed lambda calculus all that much.

InDubioProRubio 2y ago

Its also part of the economic cycle- centralized architectures thrive in a monopolistic oligarchy - and would quickly fall out of fashion after some trustbusting.

froh 2y ago

Is it so mysterious, though? isn't it "simply" the thesis - antithesis - synthesis cycle? and this cycle needs time, years, decades sometimes. OO starts in the 1970s. C++ comes 1985, Java 1995 (while smalltalk was born 1972) Hoare talks about CSP in 1978. golang mainlined it 2009. SQL started in 1970s and reached first consensus in the 1980s. or take the evolution from sgml->xml->json w/ json-schema... concepts need time to mature. and merging concepts (like duck typing and static type analysis in python) in addition needs both base concepts to be mature enough first. and likewise, at a personal level, brains need time to absorb the concepts. So of course "younglings" only know part of the world. And on the other hand mature technologies often have evolved their idiosyncracies, their "warts", and they sometimes paint themselves into some corner. C++ with ABI stability; perl with sigils; Java with "Java only" and a poor JNI and "xml xml xml"; UML with "graphical language"; many languages with no syntax baseline marker "this is a C++-95 file" or "this is a python 2 file", freezing syntax... So imho it's not simply a mysterious urge for the shiny, new stuff, but a mixed bag of overwhelm (I'll rather start something new before I dig through all that's here) and deliberate decisions (I do know what I'm talking about and X, and Y can't be "simply evolved" into Z, so I start Z).

TeMPOraL 2y ago
I feel the main reason this cycle still needs those decades to loop back again is that the world underwent its digital revolution during current iteration. We can't do synthesis without breaking everything, so we instead spawn sub-cycles on top - and then most of those end up frozen mid-way for the same reason, and we spawn sub-cycles on top of them, and so on. That's why our systems look like geological layers - XML at the bottom, JSON in the middle, and at the top JSON w/ schemas, plus a little Cambrian explosion of alternatives forming its anthitesis... and looking at it, SGML starts looking sexy again. And sure enough, you can actually use it today - but guess how? That's right, via an npm packge[0]. Wonder if we ever get a chance to actually pull all the accumulated layers of cruft back - to go through synthesis, complete the cycle and create a more reasonable base layer for the future. -- [0] - https://sgmljs.net/docs/producing-html-tutorial/producing-html-tutorial.html https://sgmljs.net/docs/producing-html-tutorial/producing-ht... / https://sgmljs.net/ https://sgmljs.net/

gonzo41 2y ago

The biggest sin IMO is the language devs who decide to "bring in types" to previously untyped langs. Dropped spaghetti everywhere.