3 ms·

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 opposit

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.

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.