I disagree with a lot of what Stroustrup says, but I do like one comment from him (paraphrasing from memory):
There are two kinds of technologies, the ones everyone hates and the ones that no one uses.
Any useful technology is going to have to make a load of compromises to be useful. I consider it a good rule of thumb that, if you couldn’t sit down and write a few thousand words about all of the things you hate about a technology, you probably don’t understand it well enough to recommend it.
I’ve come to dislike that comment, and would put it in the same category as “everything is a tradeoff”. It’s a thought-terminating cliche that’s used to fend off criticism and avoid introspection.
There are such a thing as bad engineering decisions. Not everything was made with perfect information, implemented flawlessly to spec, with optimal allocation of resources. In fact many decisions are made on the bases of all kinds of biases, including personal preferences, limited knowledge, unclear goals, a bunch of gut feeling, etc.
And even a technology with good engineering decisions can turn a lot worse over time, e.g. when fundamental assumptions change.
I agree with you, but I’d like to defend the phrase “everything is a tradeoff” please!
To me, the natural corollary is that you should decide which set of tradeoffs are best for you.
All of the things you said are true but you can avoid a lot of pitfalls by being aware of what you are optimising for, what you are giving up, and why that might be appropriate in a given situation.
you should decide which set of tradeoffs are best for you.
(neo)Confucianism teaches that solutions don’t exist, rather just sets of trade offs. E.g. you can choose to have your current problem, or the problem which will occur if “solve” it.
What’s your background with Confucianism? I would say it’s fairly optimistic about human perfectibility. It’s maybe not utopian, but a sage king can rightly order the empire with the Mandate of Heaven at least. Or do you mean more contemporary Confucian inspired thought not classical (c300BCE) or neo (c1000CE)?
Neoconfucianism (in Chinese, study of “li”) synthesized it with Daoism and Buddhism (the 3 teachings). Wu wei is an important aspect of that li (logos, natural law) channeling the Zhuangzi’s pessimism. Yangmingzi riffs on this, believing in random action (experimenting?) but not consciously planning/acting towards plans. You’re to understand the trade offs etc. and map the different ways destiny may flow, but not act on them. Original Confucianism had a more limited focus (family first) which Zhang Zai extended, by treating everything as a bigger family, allowing Confucian approaches to apply to other domains.
One 4 character parable/idiom (which means “blessing in disguise”) has:
lose horse - poor
horse comes back with horse friends - richer
break leg - bad
don’t get drafted - good
background
Wing-tsit Chan and Lin Yutang made great translations and discussions on the history of ideas in Chinese thought. Though I may read Chen Chun, it’s really through their lenses as my Chinese isn’t yet up to snuff.
Okay. I wasn’t sure if by “neo” you meant like Daniel Bell’s New Confucianism.
I would say Wang Yangming is pretty optimistic about solutions. He’s against theoretical contemplation, but for the unity of knowledge and conduct, so ISTM the idea is you solve problems by acting intuitively. I’m sure if pressed he would acknowledge there are some tradeoffs, but I don’t see him as having a very pessimistic view or emphasizing the tradeoffs versus emphasizing perfecting your knowledge-conduct.
Thank you, I dug into this a bit deeper. I believe you are right and I have been misunderstanding some aspect of will./intention, which I struggle to articulate. Laozi and everything later building on it do seem to focus on (attempts to) control backfiring. I’m not sure if my pick-tradeoffs-lens is a productive innovation or missing the point. (How broadly/narrowly should we apply things?)
I’m also tired of hearing “everything is a trade-off” for that reason. I definitely like the phrase “thought-terminating cliche”.
It’s also not true. “Everything is a trade-off” implies that everything is already Pareto-optimal, which is crazy. Lots of things are worse than they could be without making any compromises. It even feels arrogant to say that anything is any kind of “optimal”.
There are such a thing as bad engineering decisions.
Of course, I think people mostly mean that there are bad approaches, but no perfect ones. (Or, more mathematically, the “better than” relation is often partial.)
Both sides phrases are inportant and meaningful, yes people can overuse them, and people can also fail to understand that “changing this behavior to be ‘sensible’” also is a trade off as changing behaviour can break existing stuff.
We can look at all sorts of things where the “trade off” being made is not obvious:
lack of safety in C/C++: yay performance! Downside: global performance cost due to myriad mitigations in software (aslr, hardened allocators, …) and hardware (pointer auth, mte, cheri, …) cost performance (power and speed) for everything
myriad weird bits of JS - mean lots of edge cases in the language, though in practice the more absurd cases aren’t hit and basic changes to style choices mitigate most of the remainder, so the cost of removing the behavior is unbounded and leaving it there has little practical cost
removing “print” statements from Python 3: made the language more “consistent” but imo was one of the largest contributors to just how long the 2->3 migration took, but was also entirely unnecessary from a practical point of view as a print statement is in practice distinguishable from a call
At the end of the day you might disagree with my framing/opinion of the trade offs being made, but they’re still trade offs, because trade offs are a fundamental part of every design decision you can ever make.
There’s nothing thought terminating about “everything is a trade off”, claiming that it is is itself thought terminating: it implies a belief that the decisions being made are not a trade off and that a decision is either right or wrong. That mentality leads to inflexibility, and arguably incorrect choices because it results in a design choices that don’t consider the trade offs being made.
“changing this behavior to be ‘sensible’” also is a trade off as changing behaviour can break existing stuff.
But what about the time when the decisions were actually made? What technical, calculated trade-offs did JS make when implementing its numerous inconsistencies, that are collectively seen as design failures?
claiming that it is is itself thought terminating: it implies a belief that the decisions being made are not a trade off and that a decision is either right or wrong
I definitely think some decisions can be right or wrong.
But what about the time when the decisions were actually made? What technical, calculated trade-offs did JS make when implementing its numerous inconsistencies, that are collectively seen as design failures?
The key tradeoff made in the development of JavaScript was to spend only a week and a half on it, sacrificing coherent design and conceptual integrity in exchange for a time-to-market advantage.
This isn’t really true. The initial prototype was made in 10 days but there were a lot of breaking changes up to Javascript 1.0 which was released a year later. Still a fairly short time frame for a new language but not exactly ten days.
At least there the weird quirks would’ve (hopefully) gotten fixed as bugs, because it has an actual language spec. OTOH, it might also have begotten generations of Scheme-haters and parenthophobes, or Microsoft’s Visual Basicscript would’ve taken off and we’d all be using that instead. Not sure what’s worse…
But what about the time when the decisions were actually made? What technical, calculated trade-offs did JS make when implementing its numerous inconsistencies, that are collectively seen as design failures?
Some behaviors are not the result of “decisions”, they’re just happenstance of someone writing code at the time without considering the trade offs because at the time they did not recognize that they were making a decision that had trade offs.
You’re saying there are numerous inconsistencies that were implemented, but that assumes that the inconsistencies were implemented, rather than an unexpected interaction of reasonable behaviors, without knowing the exact examples you’re thinking of I can’t speak to anything.
I definitely think some decisions can be right or wrong.
With the benefit of hindsight, or with a different view of the trade offs. Do you have examples of things where the decision was objectively wrong and not just a result of the weight of trade offs changing over time, such that the trade offs made in the past would not be made now?
A good example that happens all the time in the small is doing redundant work, mostly because you’re not aware it’s happening. Cloning data structures too often, verifying invariants multiple times, etc. I’ve seen a lot of cases where redundancies could be avoided with zero downside, if the author had paid more attention.
This makes me think how beautiful it is that crypto developers have managed to make NFT’s into not only something everyone hates but something nobody uses, at the same time
I consider it a good rule of thumb that, if you couldn’t sit down and write a few thousand words about all of the things you hate about a technology, you probably don’t understand it well enough to recommend it.
As a core element of good critical thinking, one should hypothetically be able to write such a criticism about anything they are a fan of. In fact, I encourage everyone to try this out as often as possible and push through the discomfort.
Notice I used the dreaded word “fan” there- which is the point of this comment: There should be a key distinction between someone who is a “fan” of a technology based on a critical evaluation of its pros and cons and someone who is a “fan” of a technology based on a relatively rosy assessment of its pros and a relatively blind assessment of its cons.
I think the OP blogger is really complaining about the latter. And, all other things being equal, I believe a developer using a technology chosen via critical assessment by a fan will always lead to superior work relative to a technology chosen via critical assessment by a non-fan. The fan, for example, will be motivated to know and understand things like the niche micro-optimizations to use that don’t make the code less readable (I’m thinking of, for example, the “for” construct in Elixir), and will likely use designs that align closer to the semantics of that particular language’s design than to languages in general.
One of the reasons I left Ruby and went to Elixir is that the “list of valid and impactful criticisms” I could come up with was simply shorter (and significantly so) with Elixir. (Perhaps I should blogpost a critical assessment of both.) And yes, I went from being a “fan” of Ruby to a “fan” of Elixir, but I can also rattle Elixir’s faults off the top of my head (slowish math, can’t compile to static binary, complex deployment, depends on BEAM VM/Erlang, still a bit “niche”, functional semantics more difficult to adopt for new developers, wonky language server in VSCode, no typing (although that’s about to change somewhat), not as easy to introspect language features as Ruby, etc.)
The other point I’d like to make is that even though “everything is a compromise,” there are certainly locally-optimal maxima with the more correct level of abstraction and the more correct design decisions. Otherwise we should all just code in Brainfuck because of its simple instruction set or in assembly because of its speed.
I think the distinction would be that I wouldn’t really call you a “fan” of Ruby or Elixir if you’re making these considered decisions, weighing the trade-offs, and considering whether they’re appropriate more-or-less dispassionately. You can certainly like languages, but I think if you call someone a “fan” of something, there’s an implication of a sort of blind loyalty. By analogy to sports fans, where a fan always supports their team, no matter who they’re up against, a fan of a particular technology is someone who always supports their particular technology, rails against those who criticize it, and hurls vitriol against “opponents” of their tool of choice.
Alright. Interesting distinction/clarification that gave me an idea.
So, in thinking of my Apple “fandom” that has been pretty consistent since I was 12 in 1984 when my family was simultaneously the last one in the neighborhood to get a family computer and the first ones to get a Mac (128k) and I was absolutely fucking enthralled in a way I cannot describe… which persisted through the near-death of 1997 and beyond into the iPod and iPhone era…
I think it has to do with “love”, frankly. If you “love” something, you see it through thick and thin, you stick around through difficulties, and you often (in particular if you contribute directly to the good quality of the thing, or the quality of its use, or its “evangelism”, or its community) literally believe the thing into a better version of itself over time.
The “likers”, in essence, value things based on the past and current objective value while the “lovers” (the fans) value things based on the perceived intrinsic and future value.
And the latter is quite irrational and thus indefensible and yet is the fundamental instrument of value creation.
But can also lead to failure. As we all know. The things the “likers” use are less risky.
One factor is that many software development projects are much closer to bike sheds than to skyscrapers. If someone is a fan of, say, geodesic domes (as in, believes that their current and/or future value is underrated), there is no reason not to try that in constructing a bike shed — it’s unlikely that whatever the builder is a fan of will completely fail to work for the intended purpose. The best outcome is that the technology will be proved viable or they will find ways to improve it.
If people set out to build a skyscraper from the start, then sure, they must carefully evaluate everything and reject unacceptable tradeoffs.
When people build a social network for students of a single college using a bikeshed-level technology stack because that’s what allowed them to build it quickly on zero budget and then start scaling it to millions users, it’s not the same problem as “started building a skyscraper from plywood”.
OTOH, no sane architect or engineer would expand a bikeshed into a skyscraper by continuing with the same materials and techniques. They’d probably trash the bikeshed and start pouring a foundation, for starters…
Exactly. When managers or VCs demand that a bikeshed is to be expanded into a skyscraper using the same materials, it’s not an engineering problem. Well, when engineers choose to do that, it definitely is. But a lot of the time, that’s not what happens.
Thank you! The “critical thinking” aspect is I think muddied by the article by setting up an ingroup/outgroup dichotomy with engineers on one side and fans on the other.
It’s normal to be a fan of something while also being fully aware of its trade-offs. Plus, sometimes an organization’s inertia needs the extra energetic push of advocacy (e.g. from a fanatic) to transition from a “good enough / nobody got fired for buying IBM” mentality into a better local optimum.
The mindset of “everything is a trade-off” is true but can also turn into a crutch and you end up avoiding thinking critically because oh well it’s just some trade-offs I can’t be bothered to fully understand.
“Engineers” and “fans” don’t look at the same trade-offs with different-colored glasses, they actually see different sets of trade-offs.
if you couldn’t sit down and write a few thousand words about all of the things you hate about a technology, you probably don’t understand it well enough to recommend it.
I would add: you should also be able to defend the options you didn’t choose. If someone can give a big list of reasons why Go is better than Rust, yet they still recommend Rust for this project, I’m a lot more likely to trust them.
There are two kinds of technologies, the ones everyone hates and the ones that no one uses.
This is true. I remember people hating Java, C++ and XML. Today I more often meet people hating Python, Rust and YAML. Sometimes it is the same people. Older technologies are well established and the hatred has run out. People have got used to it and take it for what it is. Hyped technologies raise false hopes and unrealistic expectations, which then lead to disappointment and hate.
A few years ago, I would have completely agreed. Today, I mostly agree but with some nuance.
I agree that you need objectivity about technology whether you like it or dislike it, but you should still be allowed to like or dislike technology based on subjective criteria and even to pick them for projects based on those, provided the choice is not too far from the “optimal option”. Moreover I think you can sometimes have more success doing that than with a purely rational approach.
but you should still be allowed to like or dislike technology based on subjective criteria
Right; the article compares C’s speed to Python, and it’s true that it would be faster written in C, but on the other hand maybe using C for that project would make your entire team miserable and increase team attrition.
Strong agree here. Most “engineering” decisions in programming are made at least in part on aesthetic bases; the point is to recognize that tendency, not eliminate it.
Not sure I agree with the editorialized title, but the original is also not very good.
I take mild offense of one sentence:
I have seen projects die because their first engineers chose the language they were fans of, even when a calm and sober assessment of the technology should have revealed from day one that it was not an appropriate choice
As if “the engineers”, no matter how senior, are always, or just usually the decision makers, or at least have free enough reign to make a good decision. Depending on your employer or customer, in my experience you can usually choose between at most 3-4 technologies because that’s what is there, or “we’re an X shop” or whatever.
Are you saying that the OP is a liar for saying they’ve seen projects die for that reason? That they’re making it up? How do you know?
But if your point is “I haven’t seen that happen,” then you can’t really take offense with their sentence. You and they just have different experiences.
Personally, I (an engineer) have several times decided on what language to use in a project. For the newsreader UI in Safari (c.2007) my partner and I decided to use Lua as a templating engine to generate HTML because it’s dynamic and well suited to that task and the interpreter is tiny. At Couchbase I reluctantly went back to C++ to implement the core code of Couchbase Lite because it was the best option for fast cross-platform code. (Ironically I was So Over C++ before then, but am now a semi-fan.)
Your response is weirdly, emotionally loaded, and I believe you’re reading something the OP didn’t write (strawman). I think they were merely pointing out that your decisions as an engineer aren’t allowed to be anything you want no matter how well it solves the problem technically because your employer ultimately decides for you in many cases.
But that’s not what the OP said. They just said they’d seen this situation happen. Not sure how you can take offense at that unless you don’t actually believe it happens.
If @wink meant they take offense that engineers usually don’t get to choose, that’s something different and not at all the same as taking offense at the OP’s statement.
Yeah I’m not sure how you would go to calling someone a liar when I merely pointed out that the piece (imho) leaves out a whole chunk of decision factors.
JFTR, I am mostly annoyed (and lightly, at that) at the situation, not the author
Developers can also make bad technology choices independent of management or customer interference
I think the point of the “liar” comment is you’re adding a lot of assumptions to what was written in the original post. The situation that you’re annoyed about definitely happens, no question, but based on what was written here we have no way to know what the OP experienced
If you feel offended or annoyed by what the OP wrote, I’d consider whether you are yourself in a bad work situation where you don’t have enough input or control over technical choices
Yes, and I did not say they are wrong. Probably it was badly phrased if two people misunderstood it, but I find the case I described to be more common than the one described in the post. Also “the engineers” I (maybe mis)read as “the implementing team” and not the architect and/or CTO, although they probably are engineers too.
But I can spell it out again: Yes, it has happened that engineers have made the wrong choice, I am not disagreeing, my point was merely an addition that I find to be just as likely to happen.
I though I specified that this has been the case many times, in many orgs, over many years, so maybe it’s a general problem and not my last job (as I just switched).
Yes, but even engineers building robots aren’t robots themselves. Psychological factors are huge for ourselves, our co-workers and our customers. “Calmly evaluating” isn’t that easy, even if you think you’re only possessed of pure Vulcan logic, you’re reflecting all kinds of influences and biases.
“Being a fan” is just a more obvious manifestation of that, not even necessarily an estimate of the strength of the bias.
A prerequisite for this is trying a bunch of technologies. Without doing so, you only have other people’s testimony to rely on when comparing known technology X to unknown technology Y. Those writers will often be biased themselves, or will try to compare a technology they know really well to others they don’t know well at all, resulting in a false signal which can then creep into the decision process of anyone wanting to choose between X and Y.
For example, I used PHP back in the mid-2000s for a few years for personal projects, and have used Python for many years professionally up until now. So I can only compare PHP to Python with three massive caveats: I don’t remember my experience with PHP very well any more, I was pretty junior when using PHP, and both languages have changed a lot since then.
Very true. But you should probably not be selecting an unknown technology for a high-stakes project. This also means that if you don’t have a lot of experience with other technologies, you’ll end up selecting a “technically” suboptimal technology, but if you are very skilled at the suboptimal technology, for you it might be actually be the optimal choice for the project.
Of course, the curmudgeon who succeeds you will then start whining about it, even though they wouldn’t be inheriting the project in the first place if it hadn’t been successful.
On the other hand, I’ve also seen “senior” engineers who thought PHP was the best language ever (“because it has such nice array handling”), and when asked further, said they didn’t have any serious experience with other languages. That’s the other extreme.
I guess it just means that one should keep trying out new things, but on lower stakes projects or smaller projects where a rewrite wouldn’t take too long. But then, “shiny new thing burnout” is also definitely a thing.
Ideally speaking? Sure. But historically ? I can’t help but think back to the AC/DC stuff of the late 1800s.
Besides, fan is kind of ambiguous; these days, it informally means something like “mild supporter”, but the word can be weasel’d to mean more narrowly “extreme crusader” to suit &c.
I’m not real convinced by the Walter Sobchak calmer-than-you-are (& sober-er, too) 20/10 hindsight eagle-eyed type attitude, but I don’t really disagree, either. Some things just don’t work, as built.
This aligns well with my thoughts. I would describe myself as a fan of Python because it fitted me like a glove when I discovered it in 90s and was the first (also only) language where I wrote code of some length that worked correctly the first time before I became experienced in it.
However, my use of Python does not form part of my identity. There’s plenty of what I’m not fond of, but it remains one of my favorite tools with attachment that is not purely rational.
Somewhat off-topic I do feel world would be in better place if peoples identities would be formed around cores as small as possible.
They are also, of course, not dispassionate Vulcans who get every assessment perfectly rationally correct at all times, trivially proved by how much even relatively rational engineers can disagree with each other.
They should be. The bar for being an engineer has been lowered to unreasonable extremes. Competent engineers in control of they craft do make rational assessments correctly. And often times at the very least, understand each other views’ advantages and disadvantages.
Or course, in a world where the coolest language is the one with a the coolest looking mascot or with the best conferences with the best parties…. What can we expect in terms of engineering?
Or course, in a world where the coolest language is the one with a the coolest looking mascot or with the best conferences with the best parties…. What can we expect in terms of engineering?
I’ve heard all kinds of flimsy rationales for why people like or use certain languages, but none of these has ever been one of them.
But engineers are humans and Vulcans aren’t real, that’s the point. It’s not about lowering the bar, it’s that people are coming to situations with different contexts and that often there isn’t one correct answer, but trade-offs whose relative weights are to a degree subjective enough that reasonable people will differ.
I really really hate JavaScript. It’s ugly as hell, with all kinds of bad decisions made right at the start. But at least it doesn’t have significant whitespace, or limit what you can write in 1 line.
In practice, you can write things in JavaScript about as quickly as you can in Python. The breadth and depth of libraries of pre-canned solutions in the ecosystem is at least comparable.
Multiple companies have collectively spent billions of dollars making JavaScript run fast – something similar to C with gcc/llvm’s default optimisation level (the optimisation you get if you forget to specify optimisation). Many many times faster than Python.
Node lets you use JavaScript in your scripts and on your severs in exactly the same way as Python. It’s not just in the browser.
Why do people use Python not JavaScript? The JS trade-off seems sooo much better.
Funny, I dislike both languages but dislike JavaScript a lot more than Python even though I agree with you about JavaScript’s expressiveness beating Python’s. For me the main reason is that Python feels more solid - there are no weird implicit type conversions and it has proper integers (even bignums) and no node_modules/npm hell (yes, you have pip/pyenv/poetry/whetever hell but it’s not as bad and you wouldn’t typically have as deep a dependency tree). I also have felt the pain of using Webpack and Babel, to which my only response can be “never again”.
Nowadays, it’s less painful but before with Node.js you’d end up with callback hell as well. Then you got promises, and then async (which Python also adopted, IMO a mistake).
So for me, as a non-fan of both, the trade-off is the other way around.
The breadth and depth of libraries of pre-canned solutions in the ecosystem is at least comparable.
I’d personally agree on the libraries that matter. Funny enough, a colleague who was a JavaScript fan famously said Python’s library ecosystem was “a wasteland”.
I disagree with a lot of what Stroustrup says, but I do like one comment from him (paraphrasing from memory):
Any useful technology is going to have to make a load of compromises to be useful. I consider it a good rule of thumb that, if you couldn’t sit down and write a few thousand words about all of the things you hate about a technology, you probably don’t understand it well enough to recommend it.
I’ve come to dislike that comment, and would put it in the same category as “everything is a tradeoff”. It’s a thought-terminating cliche that’s used to fend off criticism and avoid introspection.
There are such a thing as bad engineering decisions. Not everything was made with perfect information, implemented flawlessly to spec, with optimal allocation of resources. In fact many decisions are made on the bases of all kinds of biases, including personal preferences, limited knowledge, unclear goals, a bunch of gut feeling, etc.
And even a technology with good engineering decisions can turn a lot worse over time, e.g. when fundamental assumptions change.
I agree with you, but I’d like to defend the phrase “everything is a tradeoff” please!
To me, the natural corollary is that you should decide which set of tradeoffs are best for you.
All of the things you said are true but you can avoid a lot of pitfalls by being aware of what you are optimising for, what you are giving up, and why that might be appropriate in a given situation.
You said it already
That is better than “everything is a tradeoff” and makes the pithy statement less pithy and more actionable.
(neo)Confucianism teaches that solutions don’t exist, rather just sets of trade offs. E.g. you can choose to have your current problem, or the problem which will occur if “solve” it.
What’s your background with Confucianism? I would say it’s fairly optimistic about human perfectibility. It’s maybe not utopian, but a sage king can rightly order the empire with the Mandate of Heaven at least. Or do you mean more contemporary Confucian inspired thought not classical (c300BCE) or neo (c1000CE)?
Neoconfucianism (in Chinese, study of “li”) synthesized it with Daoism and Buddhism (the 3 teachings). Wu wei is an important aspect of that li (logos, natural law) channeling the Zhuangzi’s pessimism. Yangmingzi riffs on this, believing in random action (experimenting?) but not consciously planning/acting towards plans. You’re to understand the trade offs etc. and map the different ways destiny may flow, but not act on them. Original Confucianism had a more limited focus (family first) which Zhang Zai extended, by treating everything as a bigger family, allowing Confucian approaches to apply to other domains.
One 4 character parable/idiom (which means “blessing in disguise”) has:
Wing-tsit Chan and Lin Yutang made great translations and discussions on the history of ideas in Chinese thought. Though I may read Chen Chun, it’s really through their lenses as my Chinese isn’t yet up to snuff.
Okay. I wasn’t sure if by “neo” you meant like Daniel Bell’s New Confucianism.
I would say Wang Yangming is pretty optimistic about solutions. He’s against theoretical contemplation, but for the unity of knowledge and conduct, so ISTM the idea is you solve problems by acting intuitively. I’m sure if pressed he would acknowledge there are some tradeoffs, but I don’t see him as having a very pessimistic view or emphasizing the tradeoffs versus emphasizing perfecting your knowledge-conduct.
Thank you, I dug into this a bit deeper. I believe you are right and I have been misunderstanding some aspect of will./intention, which I struggle to articulate. Laozi and everything later building on it do seem to focus on (attempts to) control backfiring. I’m not sure if my pick-tradeoffs-lens is a productive innovation or missing the point. (How broadly/narrowly should we apply things?)
I’m also tired of hearing “everything is a trade-off” for that reason. I definitely like the phrase “thought-terminating cliche”.
It’s also not true. “Everything is a trade-off” implies that everything is already Pareto-optimal, which is crazy. Lots of things are worse than they could be without making any compromises. It even feels arrogant to say that anything is any kind of “optimal”.
That was exactly my point, thanks for nailing it concisely.
that pareto-optimality explanation site is fantastic
Of course, I think people mostly mean that there are bad approaches, but no perfect ones. (Or, more mathematically, the “better than” relation is often partial.)
Both sides phrases are inportant and meaningful, yes people can overuse them, and people can also fail to understand that “changing this behavior to be ‘sensible’” also is a trade off as changing behaviour can break existing stuff.
We can look at all sorts of things where the “trade off” being made is not obvious:
lack of safety in C/C++: yay performance! Downside: global performance cost due to myriad mitigations in software (aslr, hardened allocators, …) and hardware (pointer auth, mte, cheri, …) cost performance (power and speed) for everything
myriad weird bits of JS - mean lots of edge cases in the language, though in practice the more absurd cases aren’t hit and basic changes to style choices mitigate most of the remainder, so the cost of removing the behavior is unbounded and leaving it there has little practical cost
removing “print” statements from Python 3: made the language more “consistent” but imo was one of the largest contributors to just how long the 2->3 migration took, but was also entirely unnecessary from a practical point of view as a print statement is in practice distinguishable from a call
At the end of the day you might disagree with my framing/opinion of the trade offs being made, but they’re still trade offs, because trade offs are a fundamental part of every design decision you can ever make.
There’s nothing thought terminating about “everything is a trade off”, claiming that it is is itself thought terminating: it implies a belief that the decisions being made are not a trade off and that a decision is either right or wrong. That mentality leads to inflexibility, and arguably incorrect choices because it results in a design choices that don’t consider the trade offs being made.
But what about the time when the decisions were actually made? What technical, calculated trade-offs did JS make when implementing its numerous inconsistencies, that are collectively seen as design failures?
I definitely think some decisions can be right or wrong.
The key tradeoff made in the development of JavaScript was to spend only a week and a half on it, sacrificing coherent design and conceptual integrity in exchange for a time-to-market advantage.
This isn’t really true. The initial prototype was made in 10 days but there were a lot of breaking changes up to Javascript 1.0 which was released a year later. Still a fairly short time frame for a new language but not exactly ten days.
I often wonder what development would be like now if Brendan Eich had said “no, I can’t complete it in that time, just embed Python”.
I don’t think Python even had booleans at that point. IMHO the contemporary embedding language would have been Tcl, of all things!
The starting point was Scheme, so that would probably have been the default choice if not implementing something custom.
At least there the weird quirks would’ve (hopefully) gotten fixed as bugs, because it has an actual language spec. OTOH, it might also have begotten generations of Scheme-haters and parenthophobes, or Microsoft’s Visual Basicscript would’ve taken off and we’d all be using that instead. Not sure what’s worse…
When was Microsoft adding VBScript to IE?
I’m not sure there’s an actual trade-off there. Don’t you think it’s possible to come up with a more coherent design in that timeframe?
Unlikely given the specific constraints Eich was operating under at the time.
Some behaviors are not the result of “decisions”, they’re just happenstance of someone writing code at the time without considering the trade offs because at the time they did not recognize that they were making a decision that had trade offs.
You’re saying there are numerous inconsistencies that were implemented, but that assumes that the inconsistencies were implemented, rather than an unexpected interaction of reasonable behaviors, without knowing the exact examples you’re thinking of I can’t speak to anything.
With the benefit of hindsight, or with a different view of the trade offs. Do you have examples of things where the decision was objectively wrong and not just a result of the weight of trade offs changing over time, such that the trade offs made in the past would not be made now?
A good example that happens all the time in the small is doing redundant work, mostly because you’re not aware it’s happening. Cloning data structures too often, verifying invariants multiple times, etc. I’ve seen a lot of cases where redundancies could be avoided with zero downside, if the author had paid more attention.
This makes me think how beautiful it is that crypto developers have managed to make NFT’s into not only something everyone hates but something nobody uses, at the same time
The quote you refer to is: “There are only two kinds of programming languages: those people always bitch about and those nobody uses.”
Another good one is “For new features, people insist on LOUD explicit syntax. For established features, people want terse notation.”
I’ve never heard this one before! It’s really good.
Here’s the primary source on that one: https://www.thefeedbackloop.xyz/stroustrups-rule-and-layering-over-time/
Looks like there’s some sort of error though. I’m on my phone so I’m not getting great diagnostics hah.
As a core element of good critical thinking, one should hypothetically be able to write such a criticism about anything they are a fan of. In fact, I encourage everyone to try this out as often as possible and push through the discomfort.
Notice I used the dreaded word “fan” there- which is the point of this comment: There should be a key distinction between someone who is a “fan” of a technology based on a critical evaluation of its pros and cons and someone who is a “fan” of a technology based on a relatively rosy assessment of its pros and a relatively blind assessment of its cons.
I think the OP blogger is really complaining about the latter. And, all other things being equal, I believe a developer using a technology chosen via critical assessment by a fan will always lead to superior work relative to a technology chosen via critical assessment by a non-fan. The fan, for example, will be motivated to know and understand things like the niche micro-optimizations to use that don’t make the code less readable (I’m thinking of, for example, the “for” construct in Elixir), and will likely use designs that align closer to the semantics of that particular language’s design than to languages in general.
One of the reasons I left Ruby and went to Elixir is that the “list of valid and impactful criticisms” I could come up with was simply shorter (and significantly so) with Elixir. (Perhaps I should blogpost a critical assessment of both.) And yes, I went from being a “fan” of Ruby to a “fan” of Elixir, but I can also rattle Elixir’s faults off the top of my head (slowish math, can’t compile to static binary, complex deployment, depends on BEAM VM/Erlang, still a bit “niche”, functional semantics more difficult to adopt for new developers, wonky language server in VSCode, no typing (although that’s about to change somewhat), not as easy to introspect language features as Ruby, etc.)
The other point I’d like to make is that even though “everything is a compromise,” there are certainly locally-optimal maxima with the more correct level of abstraction and the more correct design decisions. Otherwise we should all just code in Brainfuck because of its simple instruction set or in assembly because of its speed.
I think the distinction would be that I wouldn’t really call you a “fan” of Ruby or Elixir if you’re making these considered decisions, weighing the trade-offs, and considering whether they’re appropriate more-or-less dispassionately. You can certainly like languages, but I think if you call someone a “fan” of something, there’s an implication of a sort of blind loyalty. By analogy to sports fans, where a fan always supports their team, no matter who they’re up against, a fan of a particular technology is someone who always supports their particular technology, rails against those who criticize it, and hurls vitriol against “opponents” of their tool of choice.
Alright. Interesting distinction/clarification that gave me an idea.
So, in thinking of my Apple “fandom” that has been pretty consistent since I was 12 in 1984 when my family was simultaneously the last one in the neighborhood to get a family computer and the first ones to get a Mac (128k) and I was absolutely fucking enthralled in a way I cannot describe… which persisted through the near-death of 1997 and beyond into the iPod and iPhone era…
I think it has to do with “love”, frankly. If you “love” something, you see it through thick and thin, you stick around through difficulties, and you often (in particular if you contribute directly to the good quality of the thing, or the quality of its use, or its “evangelism”, or its community) literally believe the thing into a better version of itself over time.
The “likers”, in essence, value things based on the past and current objective value while the “lovers” (the fans) value things based on the perceived intrinsic and future value.
And the latter is quite irrational and thus indefensible and yet is the fundamental instrument of value creation.
But can also lead to failure. As we all know. The things the “likers” use are less risky.
Does this distinction make sense?
One factor is that many software development projects are much closer to bike sheds than to skyscrapers. If someone is a fan of, say, geodesic domes (as in, believes that their current and/or future value is underrated), there is no reason not to try that in constructing a bike shed — it’s unlikely that whatever the builder is a fan of will completely fail to work for the intended purpose. The best outcome is that the technology will be proved viable or they will find ways to improve it.
If people set out to build a skyscraper from the start, then sure, they must carefully evaluate everything and reject unacceptable tradeoffs.
When people build a social network for students of a single college using a bikeshed-level technology stack because that’s what allowed them to build it quickly on zero budget and then start scaling it to millions users, it’s not the same problem as “started building a skyscraper from plywood”.
OTOH, no sane architect or engineer would expand a bikeshed into a skyscraper by continuing with the same materials and techniques. They’d probably trash the bikeshed and start pouring a foundation, for starters…
Exactly. When managers or VCs demand that a bikeshed is to be expanded into a skyscraper using the same materials, it’s not an engineering problem. Well, when engineers choose to do that, it definitely is. But a lot of the time, that’s not what happens.
Thank you! The “critical thinking” aspect is I think muddied by the article by setting up an ingroup/outgroup dichotomy with engineers on one side and fans on the other.
It’s normal to be a fan of something while also being fully aware of its trade-offs. Plus, sometimes an organization’s inertia needs the extra energetic push of advocacy (e.g. from a fanatic) to transition from a “good enough / nobody got fired for buying IBM” mentality into a better local optimum.
The mindset of “everything is a trade-off” is true but can also turn into a crutch and you end up avoiding thinking critically because oh well it’s just some trade-offs I can’t be bothered to fully understand.
“Engineers” and “fans” don’t look at the same trade-offs with different-colored glasses, they actually see different sets of trade-offs.
I would add: you should also be able to defend the options you didn’t choose. If someone can give a big list of reasons why Go is better than Rust, yet they still recommend Rust for this project, I’m a lot more likely to trust them.
This is true. I remember people hating Java, C++ and XML. Today I more often meet people hating Python, Rust and YAML. Sometimes it is the same people. Older technologies are well established and the hatred has run out. People have got used to it and take it for what it is. Hyped technologies raise false hopes and unrealistic expectations, which then lead to disappointment and hate.
A few years ago, I would have completely agreed. Today, I mostly agree but with some nuance.
I agree that you need objectivity about technology whether you like it or dislike it, but you should still be allowed to like or dislike technology based on subjective criteria and even to pick them for projects based on those, provided the choice is not too far from the “optimal option”. Moreover I think you can sometimes have more success doing that than with a purely rational approach.
Right; the article compares C’s speed to Python, and it’s true that it would be faster written in C, but on the other hand maybe using C for that project would make your entire team miserable and increase team attrition.
Strong agree here. Most “engineering” decisions in programming are made at least in part on aesthetic bases; the point is to recognize that tendency, not eliminate it.
Not sure I agree with the editorialized title, but the original is also not very good.
I take mild offense of one sentence:
As if “the engineers”, no matter how senior, are always, or just usually the decision makers, or at least have free enough reign to make a good decision. Depending on your employer or customer, in my experience you can usually choose between at most 3-4 technologies because that’s what is there, or “we’re an X shop” or whatever.
Are you saying that the OP is a liar for saying they’ve seen projects die for that reason? That they’re making it up? How do you know?
But if your point is “I haven’t seen that happen,” then you can’t really take offense with their sentence. You and they just have different experiences.
Personally, I (an engineer) have several times decided on what language to use in a project. For the newsreader UI in Safari (c.2007) my partner and I decided to use Lua as a templating engine to generate HTML because it’s dynamic and well suited to that task and the interpreter is tiny. At Couchbase I reluctantly went back to C++ to implement the core code of Couchbase Lite because it was the best option for fast cross-platform code. (Ironically I was So Over C++ before then, but am now a semi-fan.)
Your response is weirdly, emotionally loaded, and I believe you’re reading something the OP didn’t write (strawman). I think they were merely pointing out that your decisions as an engineer aren’t allowed to be anything you want no matter how well it solves the problem technically because your employer ultimately decides for you in many cases.
But that’s not what the OP said. They just said they’d seen this situation happen. Not sure how you can take offense at that unless you don’t actually believe it happens.
If @wink meant they take offense that engineers usually don’t get to choose, that’s something different and not at all the same as taking offense at the OP’s statement.
Yeah I’m not sure how you would go to calling someone a liar when I merely pointed out that the piece (imho) leaves out a whole chunk of decision factors.
JFTR, I am mostly annoyed (and lightly, at that) at the situation, not the author
Developers can also make bad technology choices independent of management or customer interference
I think the point of the “liar” comment is you’re adding a lot of assumptions to what was written in the original post. The situation that you’re annoyed about definitely happens, no question, but based on what was written here we have no way to know what the OP experienced
If you feel offended or annoyed by what the OP wrote, I’d consider whether you are yourself in a bad work situation where you don’t have enough input or control over technical choices
Yes, and I did not say they are wrong. Probably it was badly phrased if two people misunderstood it, but I find the case I described to be more common than the one described in the post. Also “the engineers” I (maybe mis)read as “the implementing team” and not the architect and/or CTO, although they probably are engineers too.
But I can spell it out again: Yes, it has happened that engineers have made the wrong choice, I am not disagreeing, my point was merely an addition that I find to be just as likely to happen.
I though I specified that this has been the case many times, in many orgs, over many years, so maybe it’s a general problem and not my last job (as I just switched).
Yes, but even engineers building robots aren’t robots themselves. Psychological factors are huge for ourselves, our co-workers and our customers. “Calmly evaluating” isn’t that easy, even if you think you’re only possessed of pure Vulcan logic, you’re reflecting all kinds of influences and biases.
“Being a fan” is just a more obvious manifestation of that, not even necessarily an estimate of the strength of the bias.
A prerequisite for this is trying a bunch of technologies. Without doing so, you only have other people’s testimony to rely on when comparing known technology X to unknown technology Y. Those writers will often be biased themselves, or will try to compare a technology they know really well to others they don’t know well at all, resulting in a false signal which can then creep into the decision process of anyone wanting to choose between X and Y.
For example, I used PHP back in the mid-2000s for a few years for personal projects, and have used Python for many years professionally up until now. So I can only compare PHP to Python with three massive caveats: I don’t remember my experience with PHP very well any more, I was pretty junior when using PHP, and both languages have changed a lot since then.
Very true. But you should probably not be selecting an unknown technology for a high-stakes project. This also means that if you don’t have a lot of experience with other technologies, you’ll end up selecting a “technically” suboptimal technology, but if you are very skilled at the suboptimal technology, for you it might be actually be the optimal choice for the project.
Of course, the curmudgeon who succeeds you will then start whining about it, even though they wouldn’t be inheriting the project in the first place if it hadn’t been successful.
On the other hand, I’ve also seen “senior” engineers who thought PHP was the best language ever (“because it has such nice array handling”), and when asked further, said they didn’t have any serious experience with other languages. That’s the other extreme.
I guess it just means that one should keep trying out new things, but on lower stakes projects or smaller projects where a rewrite wouldn’t take too long. But then, “shiny new thing burnout” is also definitely a thing.
Ideally speaking? Sure. But historically ? I can’t help but think back to the AC/DC stuff of the late 1800s.
Besides,
fanis kind of ambiguous; these days, it informally means something like “mild supporter”, but the word can be weasel’d to mean more narrowly “extreme crusader” to suit &c.I’m not real convinced by the Walter Sobchak calmer-than-you-are (& sober-er, too) 20/10 hindsight eagle-eyed type attitude, but I don’t really disagree, either. Some things just don’t work, as built.
This aligns well with my thoughts. I would describe myself as a fan of Python because it fitted me like a glove when I discovered it in 90s and was the first (also only) language where I wrote code of some length that worked correctly the first time before I became experienced in it.
However, my use of Python does not form part of my identity. There’s plenty of what I’m not fond of, but it remains one of my favorite tools with attachment that is not purely rational.
Somewhat off-topic I do feel world would be in better place if peoples identities would be formed around cores as small as possible.
They should be. The bar for being an engineer has been lowered to unreasonable extremes. Competent engineers in control of they craft do make rational assessments correctly. And often times at the very least, understand each other views’ advantages and disadvantages.
Or course, in a world where the coolest language is the one with a the coolest looking mascot or with the best conferences with the best parties…. What can we expect in terms of engineering?
Agreed. The word fan comes from fanatic.
I’ve heard all kinds of flimsy rationales for why people like or use certain languages, but none of these has ever been one of them.
But engineers are humans and Vulcans aren’t real, that’s the point. It’s not about lowering the bar, it’s that people are coming to situations with different contexts and that often there isn’t one correct answer, but trade-offs whose relative weights are to a degree subjective enough that reasonable people will differ.
I really really hate JavaScript. It’s ugly as hell, with all kinds of bad decisions made right at the start. But at least it doesn’t have significant whitespace, or limit what you can write in 1 line.
In practice, you can write things in JavaScript about as quickly as you can in Python. The breadth and depth of libraries of pre-canned solutions in the ecosystem is at least comparable.
Multiple companies have collectively spent billions of dollars making JavaScript run fast – something similar to C with gcc/llvm’s default optimisation level (the optimisation you get if you forget to specify optimisation). Many many times faster than Python.
Node lets you use JavaScript in your scripts and on your severs in exactly the same way as Python. It’s not just in the browser.
Why do people use Python not JavaScript? The JS trade-off seems sooo much better.
Funny, I dislike both languages but dislike JavaScript a lot more than Python even though I agree with you about JavaScript’s expressiveness beating Python’s. For me the main reason is that Python feels more solid - there are no weird implicit type conversions and it has proper integers (even bignums) and no
node_modules/npm hell (yes, you have pip/pyenv/poetry/whetever hell but it’s not as bad and you wouldn’t typically have as deep a dependency tree). I also have felt the pain of using Webpack and Babel, to which my only response can be “never again”.Nowadays, it’s less painful but before with Node.js you’d end up with callback hell as well. Then you got promises, and then async (which Python also adopted, IMO a mistake).
So for me, as a non-fan of both, the trade-off is the other way around.
I’d personally agree on the libraries that matter. Funny enough, a colleague who was a JavaScript fan famously said Python’s library ecosystem was “a wasteland”.