4 ms·
The Luddite sentiment common among programmers today really surprises me. The software we’re building today is vastly more powerful and capable than anything fr
by cageface 5y ago
The Luddite sentiment common among programmers today really surprises me. The software we’re building today is vastly more powerful and capable than anything from the C64 era.
- ketralnis 5y agoI don't think it's "Luddite sentiment" to ask why one computer feels as productive with the same perceived performance as one that's literally a billion times faster. I believe the sibling saying that it's programmer productivity is correct. That same programmer can and does now spend a week whipping together a program in Python that took a year under the older constraints. And users expect more out of them, with whizz-bang animations and app-store integration. But if that same programmer _did_ spend the year instead of the week, what could they do? The quality and performance would probably be a lot better. Unless they depend on externalities that don't also scale up their quality game, like basically anything involving the web.
- cageface 5y agoIt’s Luddite in that it rejects modern tools and methods in the belief that there’s an older, more artisanal method of doing work. If you believe this is the case then you can put your belief to the test. Build software the way you think it should be built and see if users are willing to pay for it.
- badsectoracula 5y ago> If you believe this is the case then you can put your belief to the test. Build software the way you think it should be built and see if users are willing to pay for it. "users willing to pay for it" is a very bad and simplistic metric because there is way more to user willingness to pay for something than how that something was made (not to mention that it excludes everything the user doesn't pay for) - it may not even have to do with the software itself. Also the software in question may not even be "free" to use the better approach: imagine, for example, a client for a chat service that allows embedding images, videos and audio in messages but the way the protocol works is for the server to provide those as iframe and/or html content. At that point the client will have to use a browser component in one way or another with all the baggage that entails even if the features themselves (images, videos, audio and text) could be implemented directly by the client. There is only so much you can do when you have to interface with a world built on tech that doesn't care about efficiency.
- phibz 5y agoI'd argue that most python programs couldn't do the same in a year under older constraints. It's objectively more difficult to write 6502 assembly than it is to write python. Modern computers have opened programming up to more people by making it simpler but with the tradeoff of more runtime execution cost.
- badsectoracula 5y agoLuddite is someone who is opposed to new technology, which doesn't apply here as the sentiment isn't about being opposed to the new tech but about the new tech not being taken advantage of. The software we build today is "vastly" more powerful in the sense that, strictly speaking, you can do more stuff, but it is way less powerful - and often broken - than what it could be, considering what you can see being possible on older hardware and what seems to be done in modern hardware. Also it isn't really something that happens today, here is a nice (and funny) talk from Joe Armstrong on the topic from almost 8 years ago[0]. Though this sort of sentiment goes way back, e.g. Wirth's classic "Plea for lean software" article from 1995[1]. (Joe's talk is more about the broken part and IMO he misidentifies the issue being about trying to make things fast when the real issue -that he also mentions- is that pretty much nobody knows what is really going on with the system itself) [0] https://www.youtube.com/watch?v=lKXe3HUG2l4 https://www.youtube.com/watch?v=lKXe3HUG2l4 [1] https://cr.yp.to/bib/1995/wirth.pdf https://cr.yp.to/bib/1995/wirth.pdf
- cageface 5y agoThis is because people don’t want to pay the cost of software carefully developed to take maximum advantage of modern hardware. In specific niches like audio production where this is desired then prices run into hundreds of dollars for a single plugin to cover the development costs.
- hedgewitch 5y agoAnd even then, quite a lot of that audio production software is very, very inefficient, primarily due to poor GUI development. There are a few popular choices of software that are very well-known for being CPU hogs, even relative to more complex software.
- FleaFlicker99 5y agoParticularly the business often doesn't want to take on the goal of improved performance when good-enough will suffice. Which can often make sense when you factor in increase development costs, reduced flexibility/maintainability, and reduced ability to recruit for people with the skillset to work on such things. Then again, performance is often a feature in itself. In some cases it can open whole new areas of potential business. Often times it isn't even particularly hard to achieve, it just requires decent engineering practices. Unfortunately good engineering practices can be hard to find/hire for, especially among a development community/culture that hasn't had to bother caring about performance for a long time.
- throwaway47292 5y agoAs I am writing this comment my 2017 macbook is spinning fans, as if it is doing protein folding.. and it has like 3 tabs open on chrome. And for what? to edit a text box? There are new capabilities around encryption and encoding, things like h265 and etc, which of course help with medical diagnostics and such. I would take c64 software any time, look at this https://www.youtube.com/watch?v=ROr8JhilPhI https://www.youtube.com/watch?v=ROr8JhilPhI its from 1983. Imagine what kind of software would the people from 1980s write if they just had a raspberry pi 4 to work with..
- philipkglass 5y agoOn the C64 text was PETSCII [1]. On your Mac in Chrome it's Unicode. Running a basic multilingual plane text editor on the C64 is probably impossible due to RAM constraints. Even with a RAM expansion and imagining it had a framebuffer I'm doubtful that the C64 could edit Unicode text at interactive speeds. In the 1980s only a small portion of the developed world's population used home computers. Today the majority of people use computing devices. Most of them use languages that cannot be represented with PETSCII or ASCII. It's amazing what motivated people can do with low power machines, but let's not forget how going back to the 1980s would discard valuable capabilities as well as bloat. [1] https://en.wikipedia.org/wiki/PETSCII https://en.wikipedia.org/wiki/PETSCII
- emptyparadise 5y agoMaybe C64 is out, but do you really think we need all the bloat of today to support Unicode text?
- sebular 5y agoPeople from the 1980s are still alive and they’re not making anything more impressive than anyone else. These people weren’t magicians only held back by a lack of computer power, they were (again, “are”) regular people trying to maximize their output given their resources. Let’s say you go back and hand a powerful computer to them. What would Mac Paint look like? I’m sure it would have colors (assuming you also have them a monitor), probably a lot more of those goofy and useless textured fills nobody wants, layers, probably some filters, higher resolutions, and probably simple brush strokes. But do you really think they would manage to implement any of the seriously impressive features that modern Photoshop has? Content aware fill? AI upscaling? Of course not. It would probably take them a long time to get smart selection working in a halfway decent manner.
- deleted 5y ago[deleted]