6 ms·

Boring Languages Are Underrated (2015)

75 points by panic 5y ago

majkinetor 5y ago
To be pedantic, Calibre is written mostly in Python, not in Java.
- ncmncm 5y ago
  BTW: Why is Python not a boring language? Serious question. Related: What makes C++ a boring language?
  - breckenedge 5y ago
    It is boring now. At some point c++ and Java were exciting and revolutionary. The basic premise holds, choose technology that has widespread adoption and, to be really effective, that you’re already familiar with.
    - ncmncm 5y ago
      Java, like Go, was specifically designed from inception not to be even a little bit exciting or revolutionary. That was their whole value proposition. If they ever excited somebody, that would be purely accidental, possibly indicating a miscalibration.
      - breckenedge 5y ago
        You’re talking about the design of the language. I’m talking about the adoption of the language. C++ was also intended to be very boring, very easy to teach.
        ncmncm 5y ago
        False. C++ was designed as a tool for engineering large systems. Even in its earliest versions, it supported a revolutionary feature, the destructor, for resource management, since adopted as fundamental to Rust. It originated useful suppport for compile-time generic programming (at a time when Ada failed to deliver); also lately gaining support in Rust. Except for a quiet period from 1998 to 2011, it has consistently extended the library of techniques now usable for mainstream production systems.
    - jcelerier 5y ago
      > It is boring now. Nah
dsizzle 5y ago
Where does Joel Spolsky pick on boring languages? I went looking for this and could only find him defending the use of Java/.NET https://www.joelonsoftware.com/2006/09/01/language-wars/ https://www.joelonsoftware.com/2006/09/01/language-wars/. Of course that's an old article. (Incidentally the first result of my search was this very article.)
- dnautics 5y ago
  He missed the mark too, throwing shade on RoR; today almost everyone on this site depends on a mission critical RoR app (GitHub) that has scaled just fine (I'm aware parts of GitHub are no longer ruby)
  - civilized 5y ago
    Well, technically, the Git part of GitHub is written in C.
    - dnautics 5y ago
      Yep, but not many are setting up standalone git servers and most people are wholly dependent on the web UI for some nontrivial organizational or personal git management. Either that, or they're using gitlab. Which is also RoR (iirc)
      - swiley 5y ago
        There’s nothing to set up if you don’t need a GUI and are already running httpd/sshd.
        dnautics 5y ago
        Yep. And people generally don't do it. Because they want things the gui. Is this even a serious argument?
  - bdcravens 5y ago
    It wasn't terribly inaccurate. "for Serious Business Stuff you really must recognize that there just isn’t a lot of experience in the world building big mission critical web systems in Ruby on Rails" - in 2006 was true "I’m really not sure that you won’t hit scaling problems" - Twitter's issues scaling Rails are well known "that’s not a safe choice for at least another year or six" - For many that was true. For example, prior to Bundler (released in 2010), managing dependencies was hairy. "you’ll be buying 5 times as many boxes as the .NET guy down the hall" - Easy to throw resources at a problem now, but pre-cloud, that required some serious capex, so it wasn't a problem you take lightly. DHH himself has acknowledged Rails needs more resources, as they aren't optimizing for that problem: "Don’t get me wrong, though. I love speed. I especially love free and cheap speed. It’s just that I’m not willing to trade things that are of real, enduring value to get more of a nice-to-have once we’ve long since reached Good Enough. Things like programmer happiness, the eloquence of Ruby, and the productivity of Rails." (https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-years/ https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-...) (FWIW, I'm 100% Team Rails these days, but I do think Spolsky's assessment at the time was valid)
ncmncm 5y ago
Apparently the only published way to contact Dan Luu is via a twitter account. So, additional notable C++ uses: - Gdb - SpaceX real-time flight control - All fintech (besides FPGAs) - Fuschia OS Gdb and Gcc are interesting as wholly successful drama-free transitions from C.
- wk_end 5y ago
  "All" fintech? Not remotely true. Lots of fintech is written in C#, Java, Haskell, Ocaml, and more.
  - ncmncm 5y ago
    It is possible to find isolated instances of fintech in other languages.
  - codesections 5y ago
    With "more" notably including Q and other array languages — pretty much as far from "boring" as you can get
- boulos 5y ago
  Dan's email address is his name @ gmail.com [1]. [1] https://mobile.twitter.com/danluu/status/934880279772258304 https://mobile.twitter.com/danluu/status/934880279772258304
- moonchild 5y ago
  > All fintech Not all. Source: personal experience.
- sho 5y ago
  > All fintech Outside of HFT and matching engines at big exchanges exactly what do you think is in C++? Because I don't think what you said is remotely true. C++, if used at all, would be reserved for the smallest, fastest spinning cog, everything else (95%+) in a more human-scalable tech stack.
  - 5y ago
fiddlerwoaroof 5y ago
The footnote about Sapir-Whorf slightly misses the point, I think: I found learning Haskell useful because it made it impossible to write programs the way I was used to on Python. So, I _had_ to learn to think in the paradigm it uses. I’ve mostly written Java and JS/TS for pay, but I now have experience with a whole new way of designing programs that is relatively useful.
sgeisenh 5y ago
I would like the definition of "boring". Most of my day job is spent reading C++ (I write some, too) and it is more terrifying than boring. Understanding when certain errors can (and do) occur and when to optimize for performance over readability is really, really hard. I believe that Rust, Go and TypeScript have gained a lot of popularity because they are boring to read. Even OCaml has gained a ton of popularity because it is boring to read. C, C++, python and JavaScript: not boring to read, you constantly need to be on your toes.
- Jtsummers 5y ago
  It's partially covered in the first link on the page: https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology. A specific quality described there would be languages that have fewer unknown unknowns, a lack of surprises. C, C++, Java (the three he picks) have relatively few surprises. Either by virtue of design (here I'd say both C and Java) or total industry experience with the language (C++, C, Java). Ubiquity might be another consideration. A lot of other languages could probably be added to the list on that criteria. Another would be how common it is, especially for a particular domain. In my field (embedded, safety critical, real-time) it would seem like Rust would be a great choice, but it's not common and there are both technical and logistical hurdles preventing its use (for fielding, at least, for proofs of concept it's viable and that could lead to its use in fielded systems later). I'm constrained to C, C++, and maybe Ada. Fortran has been phased out, but would've been one of the boring languages for this domain up to about 20 years ago (for a new project).
  - nielsbot 5y ago
    Not really what you meant, but I personally have never found C++ programming to be without surprises of some sort: easy to make mistakes which are hard to find, having to agree on which C++ features/paradigms to adopt in your codebase, willy-nilly exceptions, constant appearance of new language features, etc.
  - smackeyacky 5y ago
    I think C++ is full of surprises, especially inersection of where macros and class templates collide. I don't think I ever saw more surprising behaviour from a language than c++, although most of the horrible surprises were cfront related and I hope they are gone now.
vp8989 5y ago
I used to think this until I really took the time to dig into Rust. Rust has completely snapped me out of this depressing, "pragmatist" learned helplessness that people seem so keen to try to cram down everyone's throats these days.
- ravenstine 5y ago
  Could you elaborate a bit? I'm curious precisely what you mean, though I can make some guesses.
  - vp8989 5y ago
    Elaborate on what? Rust or the pragmatism stuff?
    - ravenstine 5y ago
      The "pragmatism" mainly, although I'd also be interested in how Rust specifically doesn't cause learned helplessness.
      - vp8989 5y ago
        It's become very trendy these days to be hyper-pragmatic and dismiss attempts to push forward new big ideas or programming languages as frivolous. "Shut up and give me another 500 lines of PHP, we have (made up) deadlines to meet!"
        ravenstine 5y ago
        Oh oh, yes! 100%
- ashtonkem 5y ago
  I thought that too until I tried to recreate a web API I run at work in rust. Turns out that the language is far less important than having really great libraries. I’ll re-evaluate rust when things like resilience4j and micrometer exist for it.
MeinBlutIstBlau 5y ago
.NET is definitely not boring. I've seen some absurd things you can do in C# that still confuse me.
ghosss 5y ago
I think boring languages (apparently C, C++, and Java) are rated well enough. They are fine for software that is working okay, and is too expensive to rewrite in a language without the footgun that is “null”. But starting a new project in them is borderline malpractice for a lead engineer at this point. Please use a language that, if nothing else, statically prevents the “billion dollar mistake”. Rust, replacing C/C++, or Java in some cases (not Android apps), and Kotlin, replacing Java, seem like winners. They are pretty boring in the end, and prevent programmers from making the mistakes that programmers consistently make. Swift also qualifies, if you happen to be writing an iOS app.
- rightbyte 5y ago
  If don't get where the hate for null comes from. It is a free runtime assertion that invalid objects are not used. The problem arises when invalid pointers are not null ...
  - kentm 5y ago
    It's not so much that null is used but that every reference type is nullable in practice for languages that have it. Languages "without null" specifically mark certain variables as optional (same as nullable), so you're able to know that a given value is either always non-null or nullable (requires null check). In terms of checks for null vs checks against an option type for data, there's some ergonomic improvements for languages with good option support, but it's mostly the same. The real benefit is that not everything is null, and if it is nullable then its explicitly called out.
    - zapzupnz 5y ago
      Agree. It's not null that's the issue. Null can be fine, especially in a union type like Some|None (which in most languages is a type called Optional). It's mainly to do with languages that couldn't signify that some value could be null so you'd be forever doing defensive nullity checks. Developers get lazy or forgetful and miss out those checks when they need to be there; without language support, the compiler has no reason to assume that's a problem and lets code go ahead with unexpected behaviour. The ergonomics of a language that can tell you this value may be null, check for that" or one that provides syntactic shorthand — and that the compiler complains when you aren't treating those nullable values safely — is where the magic happens. Turning nulls into optionals is all in the name of helping the reader AND the writer. (And I know I basically repeated what kentm said :-) but it's a message worth repeating!)
MathMonkeyMan 5y ago
Boring languages have lots of loops and things that are required to have names.
voidhorse 5y ago
The more programming languages I use the less I care about this or that particular language and the more I think it comes down to the atomic level of good or bad features that are often available across different languages. For example, I was writing some vimscript earlier today. Vimscript supports var-args in functions: bad idea. Dynamic type systems: generally a bad idea. Mixing declarative and imperative code: bad. Fancy comments/docstring systems (javadoc, python test): bad. Complicated type system features (e.g. dependent types): not necessarily bad but often unnecessary. Type casting: sometimes necessary but bad. Optional function arguments/arguments with default values: convenient but bad… Basically any semantic element that increases the cognitive demand placed on the reader should be avoided. Circling back to varargs, they might be convenient when I’m writing a function initially, but they give readers no information, and it’s not uncommon at all that I have to go back and examine the precise details of how exactly I was using this or that vararg again. Essentially, the more I program the more I think it’s best to use the simplest features possible and avoid anything fancy unless absolutely necessary, even when the fancy stuff is terser. This is part of what makes c, go, standard ml, scheme (even though I just knocked dynamic types) some of the best languages imo. Sure they are missing a lot of great writer-oriented features that programmers tend to drool over, but their absence is actually what makes these languages better.
- avindroth 5y ago
  Just to add some nuance: simplicity might be a boon for someone/company/industry working with multiple languages, but if you live in the, say, Java world, complexity may pay off for the native residents. For instance, natural languages develop all sorts of intricacies that are inconvenient for the learners, but expressive for the native residents. If the frequency of language usage is high, features of previously medium-level complexity become simpler and more “chunked”, due to how many times you have seen them (e.g. decorators in Python). So to Python residents, decorators are simple.
chillpenguin 5y ago
He mentions other things are more effective for leveling up (other things besides learning new languages). What are some of those things beyond "domain knowledge"? Some things I can think of: databases, architecture, unix tools. What else do people recommend doing to become a better programmer? I'll admit I've fallen for the "learn esoteric languages" trap for a large part of my journey as a programmer.
nwmcsween 5y ago
Boring languages don't have to eschew interesting concepts. The problem languages have is balancing abstraction without gaining state and losing performance. Ideally programming would consist of multiple small languages focused on specific abstractions (types, concurrency, functions, etc)
ksec 5y ago
>When I talk to new programmers, they're often pretty influenced by this They call it evangelist.
Zababa 5y ago
> A question I have is, why is online discussion about this topic so one-sided while the discussions I've had in real life are so oppositely one-sided. Of course, neither people who are loud on the internet nor people I personally know are representative samples of programmers, but I still find it interesting. Programming languages are a kind of pyramid scheme. If you get more people into the community, you have more chances of using it at your day job, more libraries will be developed, more people will work on the language itself, more people will promote it and do cool stuff with it. Popularity brings even more popularity. And popularity is usually the most important feature of a programming language. Edit: as mentionned by ashtonkem, the proper term would be "network effect" and not "pyramid scheme".
- ashtonkem 5y ago
  The proper term for this is “network effect”. Pyramid schemes only make sense if you’re remunerated in some way based on the number of people you directly and indirectly bring to the language.
  - Zababa 5y ago
    > Pyramid schemes only make sense if you’re remunerated in some way based on the number of people you directly and indirectly bring to the language. But you are remunarated in a way. If your pet language become really popular, you don't have to choose between using it for less pay or not using it for more pay. That's either more pay or more happiness compared to the previous choice. There will also be more libraries, better tooling, better everything in general that will make you gain a lot of time. Also, people that follow you will also be "trapped" in the language as they will have invested in it. If they want to make their investment better, one of the thing you can do it again, bring other people to the language. Another thing is that if you're someone very important in a small language, and that language gets big, you become someone very important, period. Again, an incentive to bring people into it.
    - ashtonkem 5y ago
      You benefit from the popularity of the language, not specifically from the people you bring in. In a real pyramid scheme all the people you bring in (and the people they bring in) pay you directly. Nobody else in the scheme helps you, and they may in fact be competing with you for new recruits. You’re also obligated to pass some (or most) of the benefits you receive on to the person who recruited you. With the above hypothetical, you benefit from more programmers in your language regardless of how they got there, even if someone else “recruits” them, or they were there before you got there.

75 points by panic 5y ago

majkinetor 5y ago

To be pedantic, Calibre is written mostly in Python, not in Java.

ncmncm 5y ago
BTW: Why is Python not a boring language? Serious question. Related: What makes C++ a boring language?
- breckenedge 5y ago
  It is boring now. At some point c++ and Java were exciting and revolutionary. The basic premise holds, choose technology that has widespread adoption and, to be really effective, that you’re already familiar with.
  - ncmncm 5y ago
    Java, like Go, was specifically designed from inception not to be even a little bit exciting or revolutionary. That was their whole value proposition. If they ever excited somebody, that would be purely accidental, possibly indicating a miscalibration.
    - breckenedge 5y ago
      You’re talking about the design of the language. I’m talking about the adoption of the language. C++ was also intended to be very boring, very easy to teach.
      - ncmncm 5y ago
        False. C++ was designed as a tool for engineering large systems. Even in its earliest versions, it supported a revolutionary feature, the destructor, for resource management, since adopted as fundamental to Rust. It originated useful suppport for compile-time generic programming (at a time when Ada failed to deliver); also lately gaining support in Rust. Except for a quiet period from 1998 to 2011, it has consistently extended the library of techniques now usable for mainstream production systems.
  - jcelerier 5y ago
    > It is boring now. Nah

dsizzle 5y ago

Where does Joel Spolsky pick on boring languages? I went looking for this and could only find him defending the use of Java/.NET https://www.joelonsoftware.com/2006/09/01/language-wars/ https://www.joelonsoftware.com/2006/09/01/language-wars/. Of course that's an old article. (Incidentally the first result of my search was this very article.)

dnautics 5y ago
He missed the mark too, throwing shade on RoR; today almost everyone on this site depends on a mission critical RoR app (GitHub) that has scaled just fine (I'm aware parts of GitHub are no longer ruby)
- civilized 5y ago
  Well, technically, the Git part of GitHub is written in C.
  - dnautics 5y ago
    Yep, but not many are setting up standalone git servers and most people are wholly dependent on the web UI for some nontrivial organizational or personal git management. Either that, or they're using gitlab. Which is also RoR (iirc)
    - swiley 5y ago
      There’s nothing to set up if you don’t need a GUI and are already running httpd/sshd.
      - dnautics 5y ago
        Yep. And people generally don't do it. Because they want things the gui. Is this even a serious argument?
- bdcravens 5y ago
  It wasn't terribly inaccurate. "for Serious Business Stuff you really must recognize that there just isn’t a lot of experience in the world building big mission critical web systems in Ruby on Rails" - in 2006 was true "I’m really not sure that you won’t hit scaling problems" - Twitter's issues scaling Rails are well known "that’s not a safe choice for at least another year or six" - For many that was true. For example, prior to Bundler (released in 2010), managing dependencies was hairy. "you’ll be buying 5 times as many boxes as the .NET guy down the hall" - Easy to throw resources at a problem now, but pre-cloud, that required some serious capex, so it wasn't a problem you take lightly. DHH himself has acknowledged Rails needs more resources, as they aren't optimizing for that problem: "Don’t get me wrong, though. I love speed. I especially love free and cheap speed. It’s just that I’m not willing to trade things that are of real, enduring value to get more of a nice-to-have once we’ve long since reached Good Enough. Things like programmer happiness, the eloquence of Ruby, and the productivity of Rails." (https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-years/ https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-...) (FWIW, I'm 100% Team Rails these days, but I do think Spolsky's assessment at the time was valid)

ncmncm 5y ago

Apparently the only published way to contact Dan Luu is via a twitter account. So, additional notable C++ uses: - Gdb - SpaceX real-time flight control - All fintech (besides FPGAs) - Fuschia OS Gdb and Gcc are interesting as wholly successful drama-free transitions from C.

wk_end 5y ago
"All" fintech? Not remotely true. Lots of fintech is written in C#, Java, Haskell, Ocaml, and more.
- ncmncm 5y ago
  It is possible to find isolated instances of fintech in other languages.
- codesections 5y ago
  With "more" notably including Q and other array languages — pretty much as far from "boring" as you can get
boulos 5y ago
Dan's email address is his name @ gmail.com [1]. [1] https://mobile.twitter.com/danluu/status/934880279772258304 https://mobile.twitter.com/danluu/status/934880279772258304
moonchild 5y ago
> All fintech Not all. Source: personal experience.
sho 5y ago
> All fintech Outside of HFT and matching engines at big exchanges exactly what do you think is in C++? Because I don't think what you said is remotely true. C++, if used at all, would be reserved for the smallest, fastest spinning cog, everything else (95%+) in a more human-scalable tech stack.
- 5y ago

fiddlerwoaroof 5y ago

The footnote about Sapir-Whorf slightly misses the point, I think: I found learning Haskell useful because it made it impossible to write programs the way I was used to on Python. So, I _had_ to learn to think in the paradigm it uses. I’ve mostly written Java and JS/TS for pay, but I now have experience with a whole new way of designing programs that is relatively useful.

sgeisenh 5y ago

I would like the definition of "boring". Most of my day job is spent reading C++ (I write some, too) and it is more terrifying than boring. Understanding when certain errors can (and do) occur and when to optimize for performance over readability is really, really hard. I believe that Rust, Go and TypeScript have gained a lot of popularity because they are boring to read. Even OCaml has gained a ton of popularity because it is boring to read. C, C++, python and JavaScript: not boring to read, you constantly need to be on your toes.

Jtsummers 5y ago
It's partially covered in the first link on the page: https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology. A specific quality described there would be languages that have fewer unknown unknowns, a lack of surprises. C, C++, Java (the three he picks) have relatively few surprises. Either by virtue of design (here I'd say both C and Java) or total industry experience with the language (C++, C, Java). Ubiquity might be another consideration. A lot of other languages could probably be added to the list on that criteria. Another would be how common it is, especially for a particular domain. In my field (embedded, safety critical, real-time) it would seem like Rust would be a great choice, but it's not common and there are both technical and logistical hurdles preventing its use (for fielding, at least, for proofs of concept it's viable and that could lead to its use in fielded systems later). I'm constrained to C, C++, and maybe Ada. Fortran has been phased out, but would've been one of the boring languages for this domain up to about 20 years ago (for a new project).
- nielsbot 5y ago
  Not really what you meant, but I personally have never found C++ programming to be without surprises of some sort: easy to make mistakes which are hard to find, having to agree on which C++ features/paradigms to adopt in your codebase, willy-nilly exceptions, constant appearance of new language features, etc.
- smackeyacky 5y ago
  I think C++ is full of surprises, especially inersection of where macros and class templates collide. I don't think I ever saw more surprising behaviour from a language than c++, although most of the horrible surprises were cfront related and I hope they are gone now.

vp8989 5y ago

I used to think this until I really took the time to dig into Rust. Rust has completely snapped me out of this depressing, "pragmatist" learned helplessness that people seem so keen to try to cram down everyone's throats these days.

ravenstine 5y ago
Could you elaborate a bit? I'm curious precisely what you mean, though I can make some guesses.
- vp8989 5y ago
  Elaborate on what? Rust or the pragmatism stuff?
  - ravenstine 5y ago
    The "pragmatism" mainly, although I'd also be interested in how Rust specifically doesn't cause learned helplessness.
    - vp8989 5y ago
      It's become very trendy these days to be hyper-pragmatic and dismiss attempts to push forward new big ideas or programming languages as frivolous. "Shut up and give me another 500 lines of PHP, we have (made up) deadlines to meet!"
      - ravenstine 5y ago
        Oh oh, yes! 100%
ashtonkem 5y ago
I thought that too until I tried to recreate a web API I run at work in rust. Turns out that the language is far less important than having really great libraries. I’ll re-evaluate rust when things like resilience4j and micrometer exist for it.

MeinBlutIstBlau 5y ago

.NET is definitely not boring. I've seen some absurd things you can do in C# that still confuse me.

ghosss 5y ago

I think boring languages (apparently C, C++, and Java) are rated well enough. They are fine for software that is working okay, and is too expensive to rewrite in a language without the footgun that is “null”. But starting a new project in them is borderline malpractice for a lead engineer at this point. Please use a language that, if nothing else, statically prevents the “billion dollar mistake”. Rust, replacing C/C++, or Java in some cases (not Android apps), and Kotlin, replacing Java, seem like winners. They are pretty boring in the end, and prevent programmers from making the mistakes that programmers consistently make. Swift also qualifies, if you happen to be writing an iOS app.

rightbyte 5y ago
If don't get where the hate for null comes from. It is a free runtime assertion that invalid objects are not used. The problem arises when invalid pointers are not null ...
- kentm 5y ago
  It's not so much that null is used but that every reference type is nullable in practice for languages that have it. Languages "without null" specifically mark certain variables as optional (same as nullable), so you're able to know that a given value is either always non-null or nullable (requires null check). In terms of checks for null vs checks against an option type for data, there's some ergonomic improvements for languages with good option support, but it's mostly the same. The real benefit is that not everything is null, and if it is nullable then its explicitly called out.
  - zapzupnz 5y ago
    Agree. It's not null that's the issue. Null can be fine, especially in a union type like Some|None (which in most languages is a type called Optional). It's mainly to do with languages that couldn't signify that some value could be null so you'd be forever doing defensive nullity checks. Developers get lazy or forgetful and miss out those checks when they need to be there; without language support, the compiler has no reason to assume that's a problem and lets code go ahead with unexpected behaviour. The ergonomics of a language that can tell you this value may be null, check for that" or one that provides syntactic shorthand — and that the compiler complains when you aren't treating those nullable values safely — is where the magic happens. Turning nulls into optionals is all in the name of helping the reader AND the writer. (And I know I basically repeated what kentm said :-) but it's a message worth repeating!)

MathMonkeyMan 5y ago

Boring languages have lots of loops and things that are required to have names.

voidhorse 5y ago

The more programming languages I use the less I care about this or that particular language and the more I think it comes down to the atomic level of good or bad features that are often available across different languages. For example, I was writing some vimscript earlier today. Vimscript supports var-args in functions: bad idea. Dynamic type systems: generally a bad idea. Mixing declarative and imperative code: bad. Fancy comments/docstring systems (javadoc, python test): bad. Complicated type system features (e.g. dependent types): not necessarily bad but often unnecessary. Type casting: sometimes necessary but bad. Optional function arguments/arguments with default values: convenient but bad… Basically any semantic element that increases the cognitive demand placed on the reader should be avoided. Circling back to varargs, they might be convenient when I’m writing a function initially, but they give readers no information, and it’s not uncommon at all that I have to go back and examine the precise details of how exactly I was using this or that vararg again. Essentially, the more I program the more I think it’s best to use the simplest features possible and avoid anything fancy unless absolutely necessary, even when the fancy stuff is terser. This is part of what makes c, go, standard ml, scheme (even though I just knocked dynamic types) some of the best languages imo. Sure they are missing a lot of great writer-oriented features that programmers tend to drool over, but their absence is actually what makes these languages better.

avindroth 5y ago
Just to add some nuance: simplicity might be a boon for someone/company/industry working with multiple languages, but if you live in the, say, Java world, complexity may pay off for the native residents. For instance, natural languages develop all sorts of intricacies that are inconvenient for the learners, but expressive for the native residents. If the frequency of language usage is high, features of previously medium-level complexity become simpler and more “chunked”, due to how many times you have seen them (e.g. decorators in Python). So to Python residents, decorators are simple.

chillpenguin 5y ago

He mentions other things are more effective for leveling up (other things besides learning new languages). What are some of those things beyond "domain knowledge"? Some things I can think of: databases, architecture, unix tools. What else do people recommend doing to become a better programmer? I'll admit I've fallen for the "learn esoteric languages" trap for a large part of my journey as a programmer.

nwmcsween 5y ago

Boring languages don't have to eschew interesting concepts. The problem languages have is balancing abstraction without gaining state and losing performance. Ideally programming would consist of multiple small languages focused on specific abstractions (types, concurrency, functions, etc)

ksec 5y ago

>When I talk to new programmers, they're often pretty influenced by this They call it evangelist.

Zababa 5y ago

> A question I have is, why is online discussion about this topic so one-sided while the discussions I've had in real life are so oppositely one-sided. Of course, neither people who are loud on the internet nor people I personally know are representative samples of programmers, but I still find it interesting. Programming languages are a kind of pyramid scheme. If you get more people into the community, you have more chances of using it at your day job, more libraries will be developed, more people will work on the language itself, more people will promote it and do cool stuff with it. Popularity brings even more popularity. And popularity is usually the most important feature of a programming language. Edit: as mentionned by ashtonkem, the proper term would be "network effect" and not "pyramid scheme".

ashtonkem 5y ago
The proper term for this is “network effect”. Pyramid schemes only make sense if you’re remunerated in some way based on the number of people you directly and indirectly bring to the language.
- Zababa 5y ago
  > Pyramid schemes only make sense if you’re remunerated in some way based on the number of people you directly and indirectly bring to the language. But you are remunarated in a way. If your pet language become really popular, you don't have to choose between using it for less pay or not using it for more pay. That's either more pay or more happiness compared to the previous choice. There will also be more libraries, better tooling, better everything in general that will make you gain a lot of time. Also, people that follow you will also be "trapped" in the language as they will have invested in it. If they want to make their investment better, one of the thing you can do it again, bring other people to the language. Another thing is that if you're someone very important in a small language, and that language gets big, you become someone very important, period. Again, an incentive to bring people into it.
  - ashtonkem 5y ago
    You benefit from the popularity of the language, not specifically from the people you bring in. In a real pyramid scheme all the people you bring in (and the people they bring in) pay you directly. Nobody else in the scheme helps you, and they may in fact be competing with you for new recruits. You’re also obligated to pass some (or most) of the benefits you receive on to the person who recruited you. With the above hypothetical, you benefit from more programmers in your language regardless of how they got there, even if someone else “recruits” them, or they were there before you got there.