Completely agree, having worked with engineers and scientists for a large part of my career.
Programming is still in this goofy phase as a profession/industry where lots of practitioners interpret suffering and complexity and difficulty as signals of underlying quality.
There are still large numbers of programmers who see advances in human-computer interaction and tools as basically childish, because what matters to them is the feeling of machismo they get while programming, rather than whether their efforts make their users more successful.
See the pushback against IDEs (as you said), syntax highlighting (“syntax highlighting is for children”), Rust (“_I_ know how to manage memory, everyone else is an idiot who needs to git gud”), types generally (“_I_ don’t make type errors”). Even high level languages and garbage collection were met with similar derision when they were going mainstream. There are so many examples of this throughout the history of programming.
If something is hard to do, or resulted in something impressively complex rather than something underwhelmingly simple, it must be good.
Basically, we’re still a very immature profession and it’ll take time before we shed the “the most important thing about programming is that I get to be a wizard” stuff. The users care that the bridge doesn’t fall down when they drive over it. The users don’t care whether designing the bridge made me feel powerful and wizardly because I used a crayon rather than Solidworks.
Basically all text editors now do syntax highlighting, I have not heard any one say they avoid syntax high-lighting. I personally avoid the usual auto complete interface style and stick with the emacs default of explicitly requesting the editor to completion at point, not because it can't do it or that I am being macho but because I find it distracting and find it obscures code I often want to look at.
I hate with passion GUI's that stop be copying text and other crack that modern IDE's often do.
I don't avoid modern features at all and actively use pretty much all of them. If something like and IDE works for you that's great. But their is not some deep psychological need I am fulfilling, other then using tools that have less friction for me.
Additionally the post is about haskell a very high level language with the type system being the main feature, this persons choice in emacs is clearly different to the type that shun type systems and GC. Additionally I do not actually think the types that shun GC and shun type systems intersect as much as you make out, the types that shun GC are performance obsessed kinds of people in which type systems can improve performance significantly and those that shun type systems are (a dying breed) tend to be those who like scripting languages and hacking something together quickly. Most people recognize that both have their place I think.
Maybe the example of a carpenter who has a set of trusted tools and might like or a chefs set of knives, if we really need to look at other professions and measure are self against them. I think if you ask people why they use text editors (or IDE's) they will give their own valid reasons for each.
Ok I stand corrected, Rob Pike is no fool, I agree the comment seems flippant and a little silly, I guess theirs a few people who shun syntax highlighting.
tonksy also has some interesting opinions on syntax highlighting - not necessarily against highlighting, but taking a more minimalist stance against how highlighting is typically done: https://tonsky.me/blog/syntax-highlighting/
> One of the basic rules of thumb in typography is that, when writing a piece of text, you should choose one typeface and stick to it. Likewise, a splash of colour may grab the reader's attention, but it will inevitably decrease the legibility of the text. The natural flow of the text is broken, and it takes more brain effort to piece together the individual letters into words and semantics. Cognitively, the reading process becomes slightly less automatic and slightly more conscious; leaving less room in the conscious part of the mind for actually understanding the text.
Right, but... are you reading code in a way in which you need to preserve the “natural flow”? Personally I read a program (made up of discrete chunks of syntax that do things) much differently than a novel, or any piece of natural language in which you’d care about the typography.
I think that's an incredibly ignorant and hostile read, frankly. It's a manifold of human behaviors manifesting as something you're painting with a large brush. In the largest stroke, if you have any empathy and a competent theory of mind, you understand it's simple identity protectionism. People attach their identities to their methodologies and tools, and are generally close-minded. I like to think of it like an energy saving trait hardwired into the human mind, even if it's a little bit annoying.
The behavior also isn't unique to programming at all. You can observe it in the various engineering fields. As a single example, in civil engineering you have the conflict between allowable stress design or load and resistance factor design. You even see the behavior in fields like medicine. Different doctors have different views on different methodologies, treatments, etc.
Ascribing it to the "youth" of programming as a field is strange, not just because of its observability in older professions, but because the things you're complaining about are things that emerged as the field got more mature.
I think there's a serious self-flagellation problem some programmers have for themselves after being talked down to by other fields that you're exemplifying here. There's nothing particularly unique about the social dynamics of programming.
I have literally seen this firsthand enough to consider it repeatable. I am not making up characters for effect. I have seen and worked with people who didn’t want to write tests because they thought it made them appear weak. I have seen people say they use Ruby because they “don’t want a compiler holding their hand” as if a compiler diminished them personally (I have nothing against Ruby specifically).
Programming is a young field compared to basically all the others. It is immature. It is undergoing massive change quickly. It does have an immature, barely developed theory of practice. This has weird effects, just like how other disciplines had weird quirks when they were young too. What was young medicine like?
I have a great deal of empathy and respect for programmers. Same for engineers and doctors. None are infallible. Doesn’t change my read that our (programming) culture could be better than it is in specific ways, which could result in better decision making in the aggregate.
As for your last point, I agree! I’ve worked too closely with them for there to be any mystique left. I don’t want programming to become civil engineering or medicine but I think we can learn things from how they think about quality and systems. They’ve had more practice at it.
I know I've seen enough people online proudly declare their hatred of IDEs and how real men code in text editors often enough to notice it as a pattern.
No, it's a competing ecosystem, even though both are built on Apache Arrow, and their dataframe APIs might look similar on the surface.
DataFusion is being used as a building block for a growing number of databases and data processing engines in Rust, as it offers the necessary primitives.
It absolutely has good aspects, no doubt, but nothing about this is unquestionable. It’s significantly grayer due to all kinds of second order effects, even if you really believe in the problem and want to solve it.
Depends on how many more accidents worse-gripping tires cause that result in more totaled vehicles that require replacement and what people replace them with.
Depends on how much faster people have to replace these tires due to wear resulting in more baseline tire production.
Depends on how many more one-off flat tires people get that require getting a whole new set of 4 matched tires so their diffs aren’t destroyed.
Depends on whether slightly more efficient tires induce people to drive more on net because they feel like they’re using less gas.
Depends on this does or doesn’t affect how much tire material ends up in the environment and landfills.
There are so many levers one can pull on the “put less CO2 into the atmosphere” problem that it’s not at all clear that this one specific policy is worth it.
There’s also plenty of ways to make your point without stereotyping.
You have started out with the assumption that these higher efficiency tires are worse gripping. However, the article states that the manufacturer-supplied tires are generally more efficient (in order to get the milage numbers they advertise), and that it is the third-party replacements that are worse.
So either the manufacturer-supplied originals are more dangerous than replacement tires, or your argument is missing something.
The rest of your quasi-questions all would need to be evaluated to see if they are true or not... and one would hope that at least some of them were evaluated when creating the policy. You seem to be assuming they were not, without any real evidence one way or the other.
> So either the manufacturer-supplied originals are more dangerous than replacement tires
There's 3 main components to tire performance: efficiency, grip and longevity. OEM tires optimize for the first. They can compromise on grip and longevity. Most often I've experienced is the latter. So yes, OEM tires are "worse" in some aspects as replacements.
"the assumption that higher efficiency tires are worse gripping" This is fact not assumption. Ironically you are the one who made an assumption here. People who don't understand a topic should not attempt to regulate it based on assumptions.
> You have started out with the assumption that these higher efficiency tires are worse gripping.
Generally speaking, with tires you are trading off wear, grip, efficiency, and cost, among other things (like off-road durability which is irrelevant here). When you make a tire roll more efficiently, it tends to make it perform worse at gripping the road in all sorts of conditions, especially adverse conditions like rain and snow. I am speaking in generalities because there are thousands of tires from dozens of manufacturers and this is not a law of physics, but it is generally true in practice. Tires today are worlds better than tires of 50 years ago but this is still true to a first approximation.
So yes, I am making that assumption.
> So either the manufacturer-supplied originals are more dangerous than replacement tires, or your argument is missing something.
The tires that come on your car from the factory are optimized for one thing and one thing only: for the OEM to sell you the car.
OEM tires are famously (infamously?) often worse in terms of wear and grip than the equivalent tire available aftermarket because they are cheaper to produce (bringing down sticker price), roll more efficiently (helping them hit EPA fuel economy numbers), and quieter on test drives. Having a cheaper tire that is quieter on test drives and hits EPA numbers that are competitive with comparable models helps sell the car.
Higher treadwear doesn't help the OEM sell the car because your test drive isn't long enough to drive the car for 60,000 miles let alone 600. Higher grip doesn't either, as average buyers won't notice tire grip on a 15 minute drive on dry pavement and enthusiasts will replace the tires anyway. With the exception of certain enthusiast vehicles, if running a cheaper tire from the factory gets the price of the car from $40,000 to $39,950, the OEM will do it, even if the buyer has to replace the tire 20,000 miles sooner and it doesn't grip as well on dry pavement or in rain or snow.
> The rest of your quasi-questions all would need to be evaluated to see if they are true or not... and one would hope that at least some of them were evaluated when creating the policy. You seem to be assuming they were not, without any real evidence one way or the other.
I'm not sure what makes my questions "quasi", I'm just having a friendly conversation about tires on the internet.
There's almost nothing in human history with a worse record of causing unintended consequences than government regulation, even well-intentioned (cookie banners?), so I think I say charitably with some basis in historical fact that governments have a spotty record when it comes to understanding and predicting the second-order effects of the regulations they make. I ask my questions with that understanding. And I say all this as someone who is broadly sympathetic to and often in favor of many government regulations that reduce CO2 emissions and make cars more efficient. I enjoy clean air as much as the next person.
> Depends on how many more accidents worse-gripping tires cause
The US has an unusually high number of road deaths: https://archive.cdc.gov/www_cdc_gov/media/releases/2016/p070... and a lot of them are preventable. 1% less traction (or what ever it might be) is unlikely to be as bad compared to drink driving or not using seatbelts.
Valid point, I will grant that. It's also entirely possible that accidents due to less grippy tires are not evenly distributed (for example, due to climate or geography) and that slightly worse traction is less of a problem for most of California's urban population in particular.
So you’re saying there are a million factors that could (and arguably should) be researched, documented and actions taken based on facts revealed.
You’re not wrong, but you’re arguing against yourself.
The article is EXACTLY the kind of action that comes from research with the goal of improving the status quo, and you don’t like it.
So you actually don’t want any effort to improve things, you just want to poo poo any efforts.
Toyota is infamous for offering special, nerfed versions of well-known tires on their new vehicles. You buy a Tacoma, you don’t get the Wildpeak AT4W, which is a very good all terrain tire. Instead, you get the Wildpeak AT4WA, which is a nerfed version with reduced tread depth that is quieter and more efficient than the real AT4W but less capable and wears out faster.
Apologies in advance this turned in to a bit of a rant of violent agreement.
For most places k8s is a complete boat anchor. Ends up being a huge complication and sap on product momentum. Can’t tell you how many outages I’ve seen from k8s misconfiguration and misunderstanding.
In no world would I consider k8s to be boring, I can’t understand how all of these shops have convinced themselves that k8s specifically is the level of abstraction at which they want to be interacting with their infrastructure.
I think k8s happens because a large number of devs look at Heroku-like platforms and bristle at the notion that they could ever be expected to intentionally constrain their brilliant system designs into preexisting, Heroku-style shapes. It’s ego on some level.
That, and a ton engineers are still incredibly bad at trading off hardware cost and compensation/complexity/organizational cost. “Heroku will cost us $2000/month, running k8s on our own hardware will only cost $400/month.” Ok, but your team’s total comp is costing the company on the order of $1MM/year. Is saving $1,600/month on infrastructure to spend $20k/month on dev time a good deal? This happens all the freaking time, it’s crazy how little devs value their own time.
Homelab tinkerers are essentially a non-market. They barely want to pay for the cheapest commodity hardware. Tens of individuals would buy Oxide racks or theoretical microcomputers with their own money.
Not so! I've conservatively dropped $10k on my homelab so far, and have cobbled together a passable VM host/network/home-auto system in a half-rack. I would happily have paid more for an integrated (hypothetical) MicroOx! As fun as it is to play with cage nuts and to crimp cables, I love doinking around with a functional system even more.
Unfortunately yes. I would realistically pay about $10K for a MicroOxide rack, because that’s what I can justify spending on what is essentially a hobby. I know that’s never, ever going to happen.
I'm fluent in Rust and I find it quite enjoyable to read and write, more so than almost any other language I know. But, that's a subjective opinion, I wouldn't expect others to feel the same.
Rust probably has more to learn and is indeed probably _more difficult to learn_ than Zig in that it's simply a bigger language (which is quantifiable, even if only approximately) but difficultly of learning vs. enjoyment of reading/writing/speaking are different questions.
It's a bit like saying German is unfun to read and write. To who? To Germans?
Unfortunate how many languages with interesting stories were either glossed over or omitted entirely.
Clojure was an outright revolution against Java’s boring clumsiness, and many businesses are quietly making money with it today. Hickey even _explicitly_ comments on expertise (the OPs discussion about Rust and C++ being worth it) in the context of learning to play the violin.
Ruby declared itself as being all about “programmer happiness”, and while probably not as specifically a rebellion against Java, it attracted a ton of burnt out Java people who went on to found thousands of startups on Ruby. Ruby continues to be massive for web apps, Rails is still extremely popular compared to many alternatives.
Scala similarly to the previous examples was a Java-like with Haskell flavor that escaped an academic lab and accidentally took over the “big data” craze in the 2010s because they wrote Spark in it. If you were around then, Scala was truly hot at the time.
There are others of course but I found the examples in the OP a relatively surface level analysis of a space that has experienced an absolute explosion of diversity and novelty in the last 20 years.
Totally fair, but as I mentioned elsewhere, I left a lot of languages out in my consideration even when they're on my CV. Heck, I work in Java in my day job - I'm taking time away from it to write this comment - and realized after I'd finished my third draft that I didn't mention it at all. And I DO Clojure, have done Ruby, have done Scala (and will never do so again if I have any choice in the matter).
I could have gone into each language as a sort of postmortem - even for the ones that aren't dead right now - but for every one of them there'd be a host of people saying "wait, you're wrong" and they'd be right, and maybe I would be in that host saying I was wrong at the same time. (Again, see the footnotes: it's right there!)
But the piece isn't abotu a postmortem analysis of whether a language is fun or not - what I enjoy isn't going to be what you enjoy, nor should it be, and I don't care what you use, as long as you use it well and for the benefit of mankind.
How much load? How many concurrent connections? What machine? Don’t get me wrong, benchmarks like these are useful to help ballpark performance floors, but really only relevant for a given load scenario. They don’t mean a lot without context. Not an attack by the way, just feedback.
Programming is still in this goofy phase as a profession/industry where lots of practitioners interpret suffering and complexity and difficulty as signals of underlying quality.
There are still large numbers of programmers who see advances in human-computer interaction and tools as basically childish, because what matters to them is the feeling of machismo they get while programming, rather than whether their efforts make their users more successful.
See the pushback against IDEs (as you said), syntax highlighting (“syntax highlighting is for children”), Rust (“_I_ know how to manage memory, everyone else is an idiot who needs to git gud”), types generally (“_I_ don’t make type errors”). Even high level languages and garbage collection were met with similar derision when they were going mainstream. There are so many examples of this throughout the history of programming.
If something is hard to do, or resulted in something impressively complex rather than something underwhelmingly simple, it must be good.
Basically, we’re still a very immature profession and it’ll take time before we shed the “the most important thing about programming is that I get to be a wizard” stuff. The users care that the bridge doesn’t fall down when they drive over it. The users don’t care whether designing the bridge made me feel powerful and wizardly because I used a crayon rather than Solidworks.
reply