331–340 of 504 posts
> The demand upon a resource tends to expand to match the supply of the resource (If the price is zero).
Have cheap hardware, software will expand to use more of it.
Earlier quoted context omitted.
But in your example, your only describing one specific task (n=1). The issue is that time accumulates non linearly as the number of tasks increase. i.e the petrol stations must be able to supply enough petrol to all customers that drive the most inefficient car. The culture of "developer time is most important", makes overall system performance someone else's problem, because "my program is fast enough when I measure…
> But in your example, your only describing one specific task (n=1). That's to maintain parity with the example TFA gives. I'm not saying it's never worth it... Of course you'll optimize often repeated tasks, loops, etc. Here's what TFA quotes as bad reasoning, because it makes fun of optimization effort in some cases: "@tveastman: I have a Python program I run every day, it takes 1.5 seconds. I spent six hours re-wr…
But as many languages support implicit static typing, the folklore that dynamic languages are "more expressive" is not actually correct.
such as:
let x = "string literal" //compiled as string
let y = 42 //compiled as int
let z : i32 = 100 //compiled with type declared as 32 bit int.
Earlier quoted context omitted.
I wish more companies thought like this in general. I often think about the nature of the work I'm doing as a developer and wonder if it's making society better off as a whole. The answer is usually a resounding no.
Same here, but why exactly? In my country, SW engineer is one of the best careers in terms of income, and I bet it is similar in most of the other countries. Why do we deserve that much buzz/fame/respect/income if the work we are doing is NOT making the society better? These thoughts just haunt me from time to time.
I understand that you're asking a theoretical question, not a practical one, but in practical terms the answer is fairly simple. Our economy is not built to (indeed, is built not to) reward individuals in line with what they contribute to society. An entirely different set of incentives are what structure our economy, and therefore the jobs and lives of most people.
In some sense, David Graeber's Bullshit Jobs is all about the widespread awareness (and denial) of this phenomenon, and what caused it. I wouldn't say it's a perfect book but it's the best one I've read on the subject.
> Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? I think the analogy here is backwards. The better question is "how much would you prioritize a car that used only 0.05 liters per 100km over one that used 0.5? What about one that used only 0.005L?". I'd say that at that point, other factors like comfort, performance, base price, etc. become (relatively) much more important. If bas…
I have to be careful about what I describe, but I don't think people care about speed or performance at all when it comes to tech, and it makes me sad. In fact, there are so many occasions where the optimisation is so good that the end user doesn't believe that anything happened. So you have to deliberately introduce delay because a computer has to feel like it thinks the same way you do. At my current place of emplo…
IMO it can be attributed more to bad UI than optimizations.
Long ago I watched a documentary about the early Apple days, when management was encouraging their developers to reduce boot times by 10 seconds. The argument was that 10 seconds multiplied by the number of boot sequences would result in saving many human lives worth of time. Edit: found a link with the same story: https://www.folklore.org/StoryView.py?story=Saving_Lives.txt The software world needs more of this kind…
Meh this is manager-speak for "saving human lives" which they definitely were not. They weren't saving anybody. I mean, there's argument that, in modern day, 2020, time away from the computer is more well-spent than on a computer; so a faster boot time is actually worse than a slower boot time. Faster boot time is less time with the family.
Good managers, like Steve Jobs was, are really good at motivating people using false narratives.
An unpopular but effective short-term solution: Developers ought to use five year old hardware for development and testing tasks. FWIW, my work laptop and mobile phone are both 2015 models and I feel they're completely adequate for running all the software I've written.
I remember a story about an electronic musician who preferred to mix his songs with earbuds/headphones instead of with a high-end megabucks studio sound system. His reasoning was basically, “that’s how my fans will listen to my music, so I need to make sure it sounds good to them.” I can’t remember who it was, but the idea always stuck with me. Anyway, I agree that we should test our applications with the same hardwa…
I've listened to quite a few people on YouTube and some musicians who clearly did their editing with a certain pair of headphones/earbuds. It comes through immediately on my speakers because high pitched whining noises made it through the edit (making it nearly unbearable to listen to) and/or they boosted the bass to infinity. (Usually indicates they never listened to their project on speakers because the bass heavy music between cuts becomes disgustingly loud whereas on headphones it's not that bad)
It makes listening to their content impossible on decent speakers but fine on okay headphones.
Earlier quoted context omitted.
He hints at Electron in the end, but I think the real blame lies on React which has become standard in the past five years. Nobody has any fucking idea what’s going on in their react projects . I work with incredibly bright people and not a single one can explain accurately what happens when you press a button. On the way to solving UI consistency it actually made it impossible for anyone to reason about what’s happe…
What is better? Jquery? It comes with its own can of worms and React designers had solid reasoning to migrate away from immediate DOM modification. In general UI is hard. Nice features like compositing, variable width fonts, reflow etc come with the underlying mechanisms that are pretty complicated and once something behaves different to the expectations it might be hard to understand why.
Literally anything built with NPM: megabytes? tens of megabytes? in size, totally inscrutable, code being pulled in from hundreds of megabytes of code in tens of thousands of packages from hundreds or thousands of people of unknown (and unknowable) competence and trustworthiness, if it breaks not only do you not know who to blame but you probably have literally no idea what wrong.
Yeah, jQuery was probably better.
Performance is one thing, but I'm really just struck by how often I run into things that are completely broken or barely working for extended periods of time. As I write this, I've been trying to get my Amazon seller account reactivated for more than a year, because their reactivation process is just... broken. Clicking any of the buttons, including the ones to contact customer support just take you back to the same…
That's because the shotgun approach(sick 40 developers on a single problem idc how they dole out the workload) works well for most low stakes, non-safety-critical software.
So like a reactivation portal for your Amazon seller account is very low stakes. But Boeing treating the 737-MAX the same way, would be(and was) a very bad idea.
Because that low-stakes approach is extremely bug prone.
Earlier quoted context omitted.
Depends on your definition of genius, but I definitely agree that these folks don't quite hold up the sentiment that "anyone can do it." I would put Martin Thompson, Raph Levien, and Jonathan Blow at least in the top 0.1% of programmers. They are great examples for his overall point though. It probably would've been better just to leave out the genius bit and talk about them as folks proving it can be done.
You should add the late Terry Davis to your list, or if that area interests you, read up on his work: https://en.wikipedia.org/wiki/TempleOS
Earlier quoted context omitted.
What is better? Jquery? It comes with its own can of worms and React designers had solid reasoning to migrate away from immediate DOM modification. In general UI is hard. Nice features like compositing, variable width fonts, reflow etc come with the underlying mechanisms that are pretty complicated and once something behaves different to the expectations it might be hard to understand why.
UI is hard because you're using a hyper text language with fewer features than were the standard in the 60s. Then with styling on top of that, then with a scripting language on top of that. Reading Computer Lib/Dream Machine over the holidays and I wonder where it all went so wrong.
On both ends.
Software developers hate boring software for pragmatic HR-driven career reasons and because devs are apes and apes are faddish and like the shiny new thing.
And commercial hegemony tends to go to the companies that slap something together with duct tape and bubble gum and rush it out the door.
So you get clusterfucks like Unix winning out against elegantly designed Lisp systems, and clusterfucks like Linux winning out against elegantly designed Unix systems, and clusterfucks like Docker and microservices and whatever other "innovations" "winning out" over elegantly design Linux package management and normal webservers and whatnot.
At some point someone important will figure out that no software should ever need to be updated for any reason ever, and a software update should carry the same stigma as...I don't know...adultery once carried. Or an oil spill. Or cooking the books. Whatever.
But then also it's important to be realistic. If anyone ever goes back and fixes any of this, well, a whole lot of very smart people are going to go unemployed.
Speaking of which...