4 ms·

I strongly disagree. Software engineering has changed dramatically over the past 20 years. Choosing a non-mainstream uses an innovation token on something tha

I strongly disagree. Software engineering has changed dramatically over the past 20 years. Choosing a non-mainstream uses an innovation token on something that does not contribute business value. That’s a huge red flag. Software engineering is now a team sport. Future maintainability and readability is now orders of magnitude more important than nifty tricks when writing the code. See http://boringtechnology.club/ http://boringtechnology.club/

_pmf_ 5y ago
> Future maintainability and readability is now orders of magnitude more important than nifty tricks when writing the code. Explain npm, then.
metagame 5y ago
Software engineering has always been a team sport, even though we've known since The Mythical Man Month that throwing more programmers at a problem just slows the work down. Choosing a non-mainstream language can absolutely contribute business value. For example, toy or tool, making your creation extensible adds value. Multiple businesses have spawned from this, and Lisp and Lua are prime candidates of non-mainstream languages that billion dollar companies have decided to choose to build substantial portions of their products around so that users could extend. Even someone who doesn't know AutoLISP can look at an AutoLISP script from decades ago and get it within an hour. For another example, after being scolded for using Unicode to write my overstrikes, I wanted to see how difficult it would be to extend Arc's markdown to add DHTML overstrikes (DHTML and Unicode both have their own ways of doing them). This wasn't hard, despite not being intensely familiar with Arc and pg's programming style being relatively off-beat (Arc is essentially sillyScheme, and he takes full advantage of writing things and defining them later, which is normally easy to cope with but part of the design philosophy of Arc was to minimize syntax, so it sometimes takes longer than you would see in a less holistically-cultivated Scheme). I checked (def markdown ... ) and figured out how to add to it pretty quickly.
deleted 5y ago
[deleted]
dkarl 5y ago
> Software engineering is now a team sport. "Now" meaning since the 1960s (and probably before)? > See http://boringtechnology.club/ http://boringtechnology.club/ There are plenty of "weird" (in the sense of the parent comment) "boring" (in the sense of the essay you linked [1]) languages out there. Common Lisp and Erlang spring to mind. They are old technologies, and their capabilities and failure modes are well-understood. Maybe not by me and you and the average programmer off the street, but after decades of use, the knowledge is available. There's also an argument to be had about how much you should value the personal familiarity your team and the people you hire have with the technology. Certainly there's a cost to using unfamiliar technology, and there's a trade-off when choosing between an old, battle-tested, highly capable, but unfamiliar technology and something that is less capable but nearer to hand. [1] "the capabilities of these things are well understood. But more importantly, their failure modes are well understood" https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology

_pmf_ 5y ago

> Future maintainability and readability is now orders of magnitude more important than nifty tricks when writing the code. Explain npm, then.

metagame 5y ago

Software engineering has always been a team sport, even though we've known since The Mythical Man Month that throwing more programmers at a problem just slows the work down. Choosing a non-mainstream language can absolutely contribute business value. For example, toy or tool, making your creation extensible adds value. Multiple businesses have spawned from this, and Lisp and Lua are prime candidates of non-mainstream languages that billion dollar companies have decided to choose to build substantial portions of their products around so that users could extend. Even someone who doesn't know AutoLISP can look at an AutoLISP script from decades ago and get it within an hour. For another example, after being scolded for using Unicode to write my overstrikes, I wanted to see how difficult it would be to extend Arc's markdown to add DHTML overstrikes (DHTML and Unicode both have their own ways of doing them). This wasn't hard, despite not being intensely familiar with Arc and pg's programming style being relatively off-beat (Arc is essentially sillyScheme, and he takes full advantage of writing things and defining them later, which is normally easy to cope with but part of the design philosophy of Arc was to minimize syntax, so it sometimes takes longer than you would see in a less holistically-cultivated Scheme). I checked (def markdown ... ) and figured out how to add to it pretty quickly.

deleted 5y ago

[deleted]

dkarl 5y ago

> Software engineering is now a team sport. "Now" meaning since the 1960s (and probably before)? > See http://boringtechnology.club/ http://boringtechnology.club/ There are plenty of "weird" (in the sense of the parent comment) "boring" (in the sense of the essay you linked [1]) languages out there. Common Lisp and Erlang spring to mind. They are old technologies, and their capabilities and failure modes are well-understood. Maybe not by me and you and the average programmer off the street, but after decades of use, the knowledge is available. There's also an argument to be had about how much you should value the personal familiarity your team and the people you hire have with the technology. Certainly there's a cost to using unfamiliar technology, and there's a trade-off when choosing between an old, battle-tested, highly capable, but unfamiliar technology and something that is less capable but nearer to hand. [1] "the capabilities of these things are well understood. But more importantly, their failure modes are well understood" https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology