6 ms·

But in one sense, there are no languages with unique powers. Ultimately all languages are instructions for a CPU. The language can make you ‘feel’ smart as an i

But in one sense, there are no languages with unique powers. Ultimately all languages are instructions for a CPU. The language can make you ‘feel’ smart as an individual or ‘be’ smart by allowing a large group of people to accomplish something that couldn’t be achieved by a single person. My hypothesis is that languages that are good at making the individual feel smart have proven to be less effective at allowing a large group of programmers to collaborate.

namaria 5y ago
Being clever alone or in a group can be different things and valuable in different situations.
- aserafini 5y ago
  Sure, but the article is rather disparaging to the engineer spending their life in the so called ‘mainstream’ 99.5% of languages, implying their work is in someway less ‘smart’ than those exploring the 0.5%. I am offering a counterpoint that instead, some ‘smart’ engineers have concluded that boring programming languages are the way to get big things done.
smackeyacky 5y ago
This was certainly my experience with Smalltalk in the 1990s. The "good" programmers oustripped the departmental guys so quickly we ended up with two factions in the one company and libraries of code only the gurus understood. It killed the code re-use stats and resulted in a lot of duplicated work.
- jim-jim-jim 5y ago
  I think that scenario speaks to the importance of training, regular knowledge sharing sessions, pair programming, and the like. I've found myself in the opposite situation, where the team refuses to use a language feature that will make life significantly easier out of consideration for some hypothetical clueless graduate. Addressing a skill gap technically seems a bit short sighted compared to addressing it culturally. Especially because most weird language features don't actually require you to be smart to understand them; they're just unfamiliar.
  - smackeyacky 5y ago
    I've been thinking about this a bit, and something like Smalltalk is just completely alien if you came from a C or a Cobol background. The Cobol guys were used to using a rich, transaction based environment and the C guys were used to rolling their own everything. When they hit Smalltalk and the "if" statement looks like...wtf the boolean does the work? Or even better, one of the gurus decided that the best way to solve the "how do I get my database connection information" was to give the users a class that deliberately threw an exception they were meant to catch at the top of the chain of execution. In this case, the guru wrote a class that threw a "#doesNotUnderstand" which can be caught, re-injected with the appropriate object, and the program can continue. It quite simply was too much for some guys to get their heads around. It probably wasn't the best way to use an exception either, but occasionally when I'm working with .NET I really wish I could catch some of those, re-inject the expected bit of data and have my program continue it's merry way. One of the modes of working in Smalltalk is to deliberately write something half finished, so when the #doesNotUnderstand gets thrown, you can edit the code during while debugging, accept it, and continue the program. If it takes a long time to reproduce a bug in a C# program, you're stuck with going through all the motions to get back to where the bug exists, but in Smalltalk you could simply fill in the bit of broken code, continue and it would work from then on. Again - hard to change the habits of a lifetime and I'm not sure that as a long term development environment it's very healthy (you might fix an instance of the bug, but did you fix all the possible combinations of it?) Still, when you're in a Smalltalk groove it feels like walking a high wire and performing magic.
goatlover 5y ago
Except that some languages let you take full advantage of the hardware and some don’t. For example the ability to parallelize code, or write a device driver.
- aserafini 5y ago
  Yes that’s true. Also some don’t even run in a browser for example.

namaria 5y ago

Being clever alone or in a group can be different things and valuable in different situations.

aserafini 5y ago
Sure, but the article is rather disparaging to the engineer spending their life in the so called ‘mainstream’ 99.5% of languages, implying their work is in someway less ‘smart’ than those exploring the 0.5%. I am offering a counterpoint that instead, some ‘smart’ engineers have concluded that boring programming languages are the way to get big things done.

smackeyacky 5y ago

This was certainly my experience with Smalltalk in the 1990s. The "good" programmers oustripped the departmental guys so quickly we ended up with two factions in the one company and libraries of code only the gurus understood. It killed the code re-use stats and resulted in a lot of duplicated work.

jim-jim-jim 5y ago
I think that scenario speaks to the importance of training, regular knowledge sharing sessions, pair programming, and the like. I've found myself in the opposite situation, where the team refuses to use a language feature that will make life significantly easier out of consideration for some hypothetical clueless graduate. Addressing a skill gap technically seems a bit short sighted compared to addressing it culturally. Especially because most weird language features don't actually require you to be smart to understand them; they're just unfamiliar.
- smackeyacky 5y ago
  I've been thinking about this a bit, and something like Smalltalk is just completely alien if you came from a C or a Cobol background. The Cobol guys were used to using a rich, transaction based environment and the C guys were used to rolling their own everything. When they hit Smalltalk and the "if" statement looks like...wtf the boolean does the work? Or even better, one of the gurus decided that the best way to solve the "how do I get my database connection information" was to give the users a class that deliberately threw an exception they were meant to catch at the top of the chain of execution. In this case, the guru wrote a class that threw a "#doesNotUnderstand" which can be caught, re-injected with the appropriate object, and the program can continue. It quite simply was too much for some guys to get their heads around. It probably wasn't the best way to use an exception either, but occasionally when I'm working with .NET I really wish I could catch some of those, re-inject the expected bit of data and have my program continue it's merry way. One of the modes of working in Smalltalk is to deliberately write something half finished, so when the #doesNotUnderstand gets thrown, you can edit the code during while debugging, accept it, and continue the program. If it takes a long time to reproduce a bug in a C# program, you're stuck with going through all the motions to get back to where the bug exists, but in Smalltalk you could simply fill in the bit of broken code, continue and it would work from then on. Again - hard to change the habits of a lifetime and I'm not sure that as a long term development environment it's very healthy (you might fix an instance of the bug, but did you fix all the possible combinations of it?) Still, when you're in a Smalltalk groove it feels like walking a high wire and performing magic.

goatlover 5y ago

Except that some languages let you take full advantage of the hardware and some don’t. For example the ability to parallelize code, or write a device driver.

aserafini 5y ago
Yes that’s true. Also some don’t even run in a browser for example.