4 ms·

But a meta-smart engineer that wants to maximise real world impact through a software project would realise that not all ‘smart’ people agree about what smart ‘

But a meta-smart engineer that wants to maximise real world impact through a software project would realise that not all ‘smart’ people agree about what smart ‘IS’. So for engineering efforts that require large amounts of people to contribute, a more restrictive, less flexible language can yield better overall productivity by expanding the pool of potential contributors and reducing friction arising from pointless differences and ‘smart’ programming (like macros). In other words, removing ‘smart’ programming features like macros probably turns out to be (weirdly) smart in the real world.

jstx1 5y ago
Go is one of my favorite languages exactly for the reason you describe - it focuses on getting things done and it scales to collaborating with many people. At the same time I enjoy tinkering with different new languages every once in a while and I think that's what the article talks about. There's a place for experimenting and trying out new things, that doesn't mean that you need to rewrite everything in Haskell.
- kaba0 5y ago
  But not having enough abstraction is also problematic and Go does cross that line for me at least. Eg. on my current CRUD app, we use Spring’s aspects to implement some permission checking before specific HTTP requests. The alternative - copying a function call to each place - would be much more bug prone, a change in one will not be propagated, etc. While it may not be the best example, there are many similar cases where I feel that less abstraction would just make it unmaintainable.
  - pphysch 5y ago
    No need to embed function calls everywhere. The integration of authorization middleware should only be as complicated as your routing: mux.Handle("/", middlewareOne(middlewareTwo(finalHandler))) https://www.alexedwards.net/blog/making-and-using-middleware https://www.alexedwards.net/blog/making-and-using-middleware
arketyp 5y ago
Smart here is used as an indicator of a language with unique powers. So it's more about what the engineer can do to expand his own mind, to get new perspectives.
- aserafini 5y ago
  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
ozim 5y ago
There are different types of problems to be solved. There are "business as usual" problems, so gluing libraries, CRUD's. Where having junior level code is by far most efficient because you probably have to face multiple issues. Ones like employee rotation, lots of business requests where it is by far better to have code duplication and some tweaks in copy pasted code so it stays simple and don't introduce wrong abstractions. Even generic types as in C# I would consider mostly bad idea to use for those. Other type would be libraries or frameworks where you definitely cannot afford "copy/paste/change". I would hope that people working on libraries or frameworks stick to what they write for at least 5 years and hope they could be life long supporters. For those people and types of projects you want some smart features like generic types so that they can simply do their job. I cannot think of a framework that would not use quite complex ideas to achieve what it should be. Of course there are many more like hardware programming, operating systems and the ones that PG pointed as 0.5% of developers work like really hard/weird problems one cannot solve by simply making CRUD. I have pointed only at things that are in my line of work. Unfortunately there is a lot of people who should be delivering things as in CRUD/glue/junior so the first category. Where what THEY think they should be doing is some kind of framework/libraries work. Because they think that it will make business "future proof" and "that is what professional developers should do", while wasting resources. Of course doing CRUD/glue in an easy way that can be understood by juniors and fast is important and highly valuable in itself. But I think a lot of people don't understand value of it.
- aserafini 5y ago
  IMO the greatest achievement of collaborative programming so far is Linux. Not a CRUD application written by Junior developers. And it is written in C, which I assume is not one of PG’s blessed ‘weird’ languages that supposedly superior programmers are using.
  - AnimalMuppet 5y ago
    Here's what I could write in C that I couldn't in (most) other languages: unsigned short *reg = (unsigned short*)0xFFFF1014; *reg = 0x1027; If you have memory-mapped I/O (like the 68000-style architectures did), this lets you take a hardware register at a known address, and write any bit pattern you wanted to it. For embedded hardware, this meant that the hardware was right there, ready to work with. Sure, you can crash your program if there isn't the hardware you expect at 0xFFFF1014. Sure, you can use this exact approach to trash memory anywhere in your program image. But it lets you easily do things that are not easily done in most other languages.

jstx1 5y ago

Go is one of my favorite languages exactly for the reason you describe - it focuses on getting things done and it scales to collaborating with many people. At the same time I enjoy tinkering with different new languages every once in a while and I think that's what the article talks about. There's a place for experimenting and trying out new things, that doesn't mean that you need to rewrite everything in Haskell.

kaba0 5y ago
But not having enough abstraction is also problematic and Go does cross that line for me at least. Eg. on my current CRUD app, we use Spring’s aspects to implement some permission checking before specific HTTP requests. The alternative - copying a function call to each place - would be much more bug prone, a change in one will not be propagated, etc. While it may not be the best example, there are many similar cases where I feel that less abstraction would just make it unmaintainable.
- pphysch 5y ago
  No need to embed function calls everywhere. The integration of authorization middleware should only be as complicated as your routing: mux.Handle("/", middlewareOne(middlewareTwo(finalHandler))) https://www.alexedwards.net/blog/making-and-using-middleware https://www.alexedwards.net/blog/making-and-using-middleware

arketyp 5y ago

Smart here is used as an indicator of a language with unique powers. So it's more about what the engineer can do to expand his own mind, to get new perspectives.

aserafini 5y ago
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

ozim 5y ago

There are different types of problems to be solved. There are "business as usual" problems, so gluing libraries, CRUD's. Where having junior level code is by far most efficient because you probably have to face multiple issues. Ones like employee rotation, lots of business requests where it is by far better to have code duplication and some tweaks in copy pasted code so it stays simple and don't introduce wrong abstractions. Even generic types as in C# I would consider mostly bad idea to use for those. Other type would be libraries or frameworks where you definitely cannot afford "copy/paste/change". I would hope that people working on libraries or frameworks stick to what they write for at least 5 years and hope they could be life long supporters. For those people and types of projects you want some smart features like generic types so that they can simply do their job. I cannot think of a framework that would not use quite complex ideas to achieve what it should be. Of course there are many more like hardware programming, operating systems and the ones that PG pointed as 0.5% of developers work like really hard/weird problems one cannot solve by simply making CRUD. I have pointed only at things that are in my line of work. Unfortunately there is a lot of people who should be delivering things as in CRUD/glue/junior so the first category. Where what THEY think they should be doing is some kind of framework/libraries work. Because they think that it will make business "future proof" and "that is what professional developers should do", while wasting resources. Of course doing CRUD/glue in an easy way that can be understood by juniors and fast is important and highly valuable in itself. But I think a lot of people don't understand value of it.

aserafini 5y ago
IMO the greatest achievement of collaborative programming so far is Linux. Not a CRUD application written by Junior developers. And it is written in C, which I assume is not one of PG’s blessed ‘weird’ languages that supposedly superior programmers are using.
- AnimalMuppet 5y ago
  Here's what I could write in C that I couldn't in (most) other languages: unsigned short *reg = (unsigned short*)0xFFFF1014; *reg = 0x1027; If you have memory-mapped I/O (like the 68000-style architectures did), this lets you take a hardware register at a known address, and write any bit pattern you wanted to it. For embedded hardware, this meant that the hardware was right there, ready to work with. Sure, you can crash your program if there isn't the hardware you expect at 0xFFFF1014. Sure, you can use this exact approach to trash memory anywhere in your program image. But it lets you easily do things that are not easily done in most other languages.