5 ms·

This article gets posted a lot, but I find it a little unsatisfying. I think it’s because it’s pretty vague about what “boring” means exactly, so it’s the kind

by fnfjfk 3y ago

This article gets posted a lot, but I find it a little unsatisfying. I think it’s because it’s pretty vague about what “boring” means exactly, so it’s the kind of statement most can agree with, without it actually being a very strong statement. It’s not wrong per se, don’t choose some technology posted for the first time yesterday. But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs, which Kotlin would have caught at compile-time. Or if you choose C++ over Rust, same general idea. The specific languages it calls out are Python and PHP, which IMO are bug-prone languages with serious performance/efficiency implications. Some semblance of safety needs to be bolted on separately, and at large scale they will cost your company $$$ vs. a more performance-friendly language (the latter doesn’t matter so much if you are a tiny startup with no users yet). I would say more important is “write boring code”, and it is easier to write boring to-the-point code in modern languages without implicit null references, with sum types for modeling mutually-exclusive data, and with as many other common pitfalls statically eliminated as is possible.

kyawzazaw 3y ago
> But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs, which Kotlin would have caught at compile-time. Or if you choose C++ over Rust, same general idea. But isn't the point that if you run into this much issue for the initial choice, you are now ready to use an innovation token and switch to a different one? > Some semblance of safety needs to be bolted on separately, and at large scale they will cost your company $$$ vs. a more performance-friendly language (the latter doesn’t matter so much if you are a tiny startup with no users yet). At that point with all the financial resources, they can consider to rewrite/migrate. Thus, at the start, chose boring technology. Even at a big company, retraining or hiring people proficient in Rust will probably cost more than continuing to use C++ codebase and people.
- hgomersall 3y ago
  Interestingly enough, the concern in the early stages is actually not at all about hiring people, it's about personal motivation and technology fit. We dropped C for Rust in a systems language context and technologically it was a fantastic choice. I guess some of the benefits of a language switch could have been realised with C++, but since my proficiency with C++ was a few small incremental changes relative to C, I was going to have to learn a lot in either case. Rust held far more appeal and in hindsight has helped us provided fantastic stability in our software whilst developing very rapidly.
  - kyawzazaw 3y ago
    > Interestingly enough, the concern in the early stages is actually not at all about hiring people, it's about personal motivation and technology fit. Is this in regards to running a startup? In that case, I have little to add. But my initial understanding would be, the startup needs to be able to reach product market-fit as quickly as possible. Which is where using a boring technology (to the founders/founding team) would reduce distractions/unknowns. > but since my proficiency with C++ was a few small incremental changes relative to C, I was going to have to learn a lot in either case. Isn't this premise aligned with the philosophy written in the article? 1. You needed to learn something new (so no longer boring, and prime for innovation token) 2. You needed to use something different for a systems language context (innovation token time)
eitland 3y ago
> But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs You are also choosing -to let your team choose their own IDE - easy to debug - frameworks that works out of the box - and continue to work regardless of Kotlin versions (since one doesn't use Kotlin) - to no have to deal with a number of "interesting" ways to write code I like Kotlin. But it is more nuanced than some people would like to have us believe. Personally I think I have spent far more time over the last three or four years hand holding Kotlin and cleaning up "clean code" than I have saved by less NPEs.
- a_imho 3y ago
  Agreed, also, imo boring implies that failure modes are well understood or at least documented and have a bigger community to rely on when you eventually hit them.
philosophywaves 3y ago
I think the reason it resonates with people is that a common failure mode in technology is picking the wrong tech for the problem, and this often happens because engineers like to learn and pick things they are unfamiliar with so that they get that buzz. Most of the value in this article can be boiled down to telling engineers to not make tech decisions based on the brainy feelgoods. It's like telling people to eat their vegetables. Boring, straightforward advice, but a good path to a healthier body.
jpgvm 3y ago
Eh, I would argue Kotlin is solidly boring right alongside Java now. It's still "mostly" Java if you are using it in the same places you can use Java. I'm with you generally though. Yes choose boring tools, JVM, PostgreSQL, etc. But also write boring code using boring architectures deployed on boring platforms.
- dukeyukey 3y ago
  Definitely. The only real downside to going with Kotlin nowadays is hiring developers; it's reasonably easy to find Java developers who want to try Kotlin, but hard to hire people experienced in Kotlin.
8n4vidtmkvmk 3y ago
Choosing a language before you even have an app matters. Changing the language your app is already written in or tacking on a microservice so you can use a 2nd language.... not such a good idea. I chose php 8 years ago because I already knew it. Would I write my app in a different language today if I could? Probably. Should I do that now, when I have very few bugs (basically none of which are related to my language choice) and no performance issues? Probably not. Have I been tempted because shiny? Yes. Delivering actual value to customers is what matters and there hasn't been anything I couldn't solve with a bit more PHP. Rewriting the whole app would probably kill my business.
deleted 3y ago
[deleted]
randomdata 3y ago
> But if you make the choice of Java (boring) over Kotlin (shiny new) New doesn't mean exciting. Programming languages are boring – even new ones. If you see a programming language attracting a lot of excitement, beware, but otherwise whatever you're comfortable with will be fine.
pharmakom 3y ago
Kotlin counts as boring now (imo)
crabbone 3y ago
Concentrating on NPEs and stuff like sum times is misunderstanding the problems with software quality to the point of misunderstanding the magnitude of impact of different flaws. Working tightly with QA for over ten years by now, I can assure you that NPEs are exceptionally rare in bug reports filed by QA. No matter if that's a common problem in the language the application is written in (eg. Java or C++) or virtually nonexistent (eg. Kotlin or Haskell). Here are some examples of more common bugs: * Misunderstanding of the desired functionality (eg. giving admin permissions to regular users). * Not being able to predict all valid input forms (eg. user names with accented characters). * Forgetting to handle errors coming from multiple levels below the immediate level that's being worked with (eg. dealing with SSL-related problems in HTTP client / server communication). * Simply forgetting to implement some uncommon bit of functionality (usually related to cleanups, deletion etc.) ---- Currently in-use programming languages have roughly the same ability to deal with these, as I call them, "macro-problems" of programs. All of them are equally ill-equipped and unprepared for them. Tightening the type system or chasing after nulls is working at a resolution that's too fine. At this resolution programmers usually still have a good chance of figuring out the problems without the aid of types or similar automation.
- JambalayaJim 3y ago
  NPE safety and sum times deal with issues that developers face on the day to day, long before the product ever gets used by end users in the first place. NPE issues are also very very difficult to chase down.
  - crabbone 3y ago
    I'm talking about QA, not end-users. "very very difficult" on what scale? How many "verys" before it gets really hard? Again, the proof is in the pudding. You take a language that doesn't make any special efforts to protect against nulls (eg. Java), and you take Kotlin that does, and the difference in the number of problems associated with NPEs is barely noticeable. Perhaps some automation offered by Kotlin for dealing with NPEs makes developers' experience more pleasant / easier, but the Java side just isn't hard enough to make this a substantial benefit. And, just to not be misunderstood: I'm not saying that automation in how to deal with missing values is bad, not at all! It's good. But, strategically, there are much bigger problems / juicier targets than NPEs. If you compare this to health, then NPEs are a headache, while misunderstood requirements are a cancer. It's great if you can treat both, but if you have limited resources, then cancer gets a priority treatment.

by fnfjfk 3y ago

kyawzazaw 3y ago

> But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs, which Kotlin would have caught at compile-time. Or if you choose C++ over Rust, same general idea. But isn't the point that if you run into this much issue for the initial choice, you are now ready to use an innovation token and switch to a different one? > Some semblance of safety needs to be bolted on separately, and at large scale they will cost your company $$$ vs. a more performance-friendly language (the latter doesn’t matter so much if you are a tiny startup with no users yet). At that point with all the financial resources, they can consider to rewrite/migrate. Thus, at the start, chose boring technology. Even at a big company, retraining or hiring people proficient in Rust will probably cost more than continuing to use C++ codebase and people.

hgomersall 3y ago
Interestingly enough, the concern in the early stages is actually not at all about hiring people, it's about personal motivation and technology fit. We dropped C for Rust in a systems language context and technologically it was a fantastic choice. I guess some of the benefits of a language switch could have been realised with C++, but since my proficiency with C++ was a few small incremental changes relative to C, I was going to have to learn a lot in either case. Rust held far more appeal and in hindsight has helped us provided fantastic stability in our software whilst developing very rapidly.
- kyawzazaw 3y ago
  > Interestingly enough, the concern in the early stages is actually not at all about hiring people, it's about personal motivation and technology fit. Is this in regards to running a startup? In that case, I have little to add. But my initial understanding would be, the startup needs to be able to reach product market-fit as quickly as possible. Which is where using a boring technology (to the founders/founding team) would reduce distractions/unknowns. > but since my proficiency with C++ was a few small incremental changes relative to C, I was going to have to learn a lot in either case. Isn't this premise aligned with the philosophy written in the article? 1. You needed to learn something new (so no longer boring, and prime for innovation token) 2. You needed to use something different for a systems language context (innovation token time)

eitland 3y ago

> But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs You are also choosing -to let your team choose their own IDE - easy to debug - frameworks that works out of the box - and continue to work regardless of Kotlin versions (since one doesn't use Kotlin) - to no have to deal with a number of "interesting" ways to write code I like Kotlin. But it is more nuanced than some people would like to have us believe. Personally I think I have spent far more time over the last three or four years hand holding Kotlin and cleaning up "clean code" than I have saved by less NPEs.

a_imho 3y ago
Agreed, also, imo boring implies that failure modes are well understood or at least documented and have a bigger community to rely on when you eventually hit them.

philosophywaves 3y ago

I think the reason it resonates with people is that a common failure mode in technology is picking the wrong tech for the problem, and this often happens because engineers like to learn and pick things they are unfamiliar with so that they get that buzz. Most of the value in this article can be boiled down to telling engineers to not make tech decisions based on the brainy feelgoods. It's like telling people to eat their vegetables. Boring, straightforward advice, but a good path to a healthier body.

jpgvm 3y ago

Eh, I would argue Kotlin is solidly boring right alongside Java now. It's still "mostly" Java if you are using it in the same places you can use Java. I'm with you generally though. Yes choose boring tools, JVM, PostgreSQL, etc. But also write boring code using boring architectures deployed on boring platforms.

dukeyukey 3y ago
Definitely. The only real downside to going with Kotlin nowadays is hiring developers; it's reasonably easy to find Java developers who want to try Kotlin, but hard to hire people experienced in Kotlin.

8n4vidtmkvmk 3y ago

Choosing a language before you even have an app matters. Changing the language your app is already written in or tacking on a microservice so you can use a 2nd language.... not such a good idea. I chose php 8 years ago because I already knew it. Would I write my app in a different language today if I could? Probably. Should I do that now, when I have very few bugs (basically none of which are related to my language choice) and no performance issues? Probably not. Have I been tempted because shiny? Yes. Delivering actual value to customers is what matters and there hasn't been anything I couldn't solve with a bit more PHP. Rewriting the whole app would probably kill my business.

deleted 3y ago

[deleted]

randomdata 3y ago

> But if you make the choice of Java (boring) over Kotlin (shiny new) New doesn't mean exciting. Programming languages are boring – even new ones. If you see a programming language attracting a lot of excitement, beware, but otherwise whatever you're comfortable with will be fine.

pharmakom 3y ago

Kotlin counts as boring now (imo)

crabbone 3y ago

Concentrating on NPEs and stuff like sum times is misunderstanding the problems with software quality to the point of misunderstanding the magnitude of impact of different flaws. Working tightly with QA for over ten years by now, I can assure you that NPEs are exceptionally rare in bug reports filed by QA. No matter if that's a common problem in the language the application is written in (eg. Java or C++) or virtually nonexistent (eg. Kotlin or Haskell). Here are some examples of more common bugs: * Misunderstanding of the desired functionality (eg. giving admin permissions to regular users). * Not being able to predict all valid input forms (eg. user names with accented characters). * Forgetting to handle errors coming from multiple levels below the immediate level that's being worked with (eg. dealing with SSL-related problems in HTTP client / server communication). * Simply forgetting to implement some uncommon bit of functionality (usually related to cleanups, deletion etc.) ---- Currently in-use programming languages have roughly the same ability to deal with these, as I call them, "macro-problems" of programs. All of them are equally ill-equipped and unprepared for them. Tightening the type system or chasing after nulls is working at a resolution that's too fine. At this resolution programmers usually still have a good chance of figuring out the problems without the aid of types or similar automation.

JambalayaJim 3y ago
NPE safety and sum times deal with issues that developers face on the day to day, long before the product ever gets used by end users in the first place. NPE issues are also very very difficult to chase down.
- crabbone 3y ago
  I'm talking about QA, not end-users. "very very difficult" on what scale? How many "verys" before it gets really hard? Again, the proof is in the pudding. You take a language that doesn't make any special efforts to protect against nulls (eg. Java), and you take Kotlin that does, and the difference in the number of problems associated with NPEs is barely noticeable. Perhaps some automation offered by Kotlin for dealing with NPEs makes developers' experience more pleasant / easier, but the Java side just isn't hard enough to make this a substantial benefit. And, just to not be misunderstood: I'm not saying that automation in how to deal with missing values is bad, not at all! It's good. But, strategically, there are much bigger problems / juicier targets than NPEs. If you compare this to health, then NPEs are a headache, while misunderstood requirements are a cancer. It's great if you can treat both, but if you have limited resources, then cancer gets a priority treatment.