4 ms·

So is there any way to stop this treadmill, short of overthrowing capitalism itself? Edit: If that seems like a non-sequitur, I said it because the parent comm

So is there any way to stop this treadmill, short of overthrowing capitalism itself? Edit: If that seems like a non-sequitur, I said it because the parent comment started by saying that the market is wasteful.

gizmo 10y ago
There is certainly a case to be made for overthrowing capitalism, but I don't see why an anti-capitalist revolution would automatically result in a society with higher quality software. Open source software suffers from much the same problems as commercial software. There is much about writing good software we haven't figured out how to do yet as an industry, and in the meantime we have to work with tools that are totally inadequate.
- mwcampbell 10y ago
  Why do you think our tools are inadequate? What would adequate tools be able to do that our current ones can't?
  - gizmo 10y ago
    Way too much to cover in depth. In short, it's all terrible. We're mostly using tools from the 70s, and we're still to this day plagued by use-after-free and out-of-bounds errors, nullpointer exceptions, awful debuggers, race conditions, slow compilation times, bad primitives for multithreaded work, just to name a few. We've known for decades that we can do better and ways to do better have been studied in depth by academia. That's just the basics. Then there is futuristic things: Why can't we move running processes from one physical machine to another? Where are the debuggers that allow you to go back and forward in time? Why can't we visualize the data structures in our program and trivially change the data layout to see how that affects performance? When I look at the demo of the Xerox Sparc interface (1982) and compare that to where we are today it's pretty clear to me we messed up big time somewhere along the road: https://www.youtube.com/watch?v=Cn4vC80Pv6Q https://www.youtube.com/watch?v=Cn4vC80Pv6Q
    - TeMPOraL 10y ago
      > We're mostly using tools from the 70s We're using the shittier tools from the 70s, because the better tools died off - which is sad, because we still didn't manage to recreate some of the features those tools offered. The success of UNIX and C seems to be caused by the same phenomenon that causes Electron to succeed and bloat to proliferate - what wins aren't good solutions, but those which get popular quickly.
      - deleted 10y ago
        [deleted]
      - chii 10y ago
        > aren't good solutions, but those which get popular quickly. but by the judgement of a majority, those tools are good! That's why it got popular. Any personal sense of aesthetics from you (or anyone) doesn't matter at all here, and most people who call tools that failed 'good' are only judging it by personal aesthetics.
        TeMPOraL 10y ago
        I'm not talking aesthetics here; I'm talking about shitty engineering. Often legitimized by nonsense phrases like "worse is better" these days.
    - nostrademons 10y ago
      For people who have an exceptionally high tolerance for learning what people actually care about and why the shitty technological solutions won in the marketplace, this is probably an opportunity. When I entered the workforce in 2005 after learning all about bygone languages (Common Lisp, Smalltalk, Dylan, Haskell, Erlang, Ocaml, etc.) in college, it was really, really painful going back to Java. Java had gotten so many fundamental language features wrong when better alternatives were well-known in research literature. Monitors instead of CSP, null types instead of Maybe, inner classes instead of closures, manifest typing instead of type inference, no first-class functions, mutability everywhere, conflation of modules & classes, not even a semblance of pattern-matching. But I could use it to write software that performed well, that could be deployed with tooling that everybody used, that had a wide base of available libraries, that had IDEs and other tooling available, and that other programmers could maintain. It's 12 years later, and all of my recent projects have been in some combination of Swift, Rust, Kotlin, or ES6+React. And most of these languages have: promises & message-passing instead of explicit locks; Optional types or at least some form of null-safety; lexical closures; type inference; first-class functions; immutable-by-default; module systems that don't require that you shove everything into a class; and pattern-matching. But they also did the hard work of figuring out an interoperability story with some large existing body of code; of writing decent package managers and easy build systems; of making the language reasonably performant for most everyday tasks; and of (in Swift & Kotlin's case) providing full support within an IDE. All the language features that were common in research languages of 2005 but missing in industrial programming of the time are now very usable in the industrial programming of now. I wouldn't be surprised to see a similar renaissance in tooling over the next decade, with exotic features like time-traveling debuggers, fully-inspectable systems, and migratable processes becoming standard in the next generation of IDEs.
userbinator 10y ago
I don't think capitalism is to blame, as this is endemic even in free software. The way to stop this is to stop repeating dogmatic myths about optimisation, consider efficiency/optimisation as an integrated part of the design process and not something to be applied afterwards, and focus on "user time is expensive" instead of "developer time is expensive" --- and sometimes, those users may also be developers.
- deleted 10y ago
  [deleted]
- chii 10y ago
  > user time is expensive that's not always true, especially from the point of view of the dev.
  - username223 10y ago
    Yep. With forced auto-updates, software companies have implemented "software gavage," and the devs are just getting paid to push code down users' throats. It's much harder to entice users with something they might actually want.
ue_ 10y ago
Within capitalism, products are made to maximise exchange value rather than use value. This is because it is more profitable to optimise for products to be exchanged rather than used. In fact, it can be detrimental to maximise use value, because a product that can be used for longer will mean that fewer people will have motivation to purchase another one any time soon. I like the idea of overthrowing capitalism itself to resolve this.

gizmo 10y ago

There is certainly a case to be made for overthrowing capitalism, but I don't see why an anti-capitalist revolution would automatically result in a society with higher quality software. Open source software suffers from much the same problems as commercial software. There is much about writing good software we haven't figured out how to do yet as an industry, and in the meantime we have to work with tools that are totally inadequate.

mwcampbell 10y ago
Why do you think our tools are inadequate? What would adequate tools be able to do that our current ones can't?
- gizmo 10y ago
  Way too much to cover in depth. In short, it's all terrible. We're mostly using tools from the 70s, and we're still to this day plagued by use-after-free and out-of-bounds errors, nullpointer exceptions, awful debuggers, race conditions, slow compilation times, bad primitives for multithreaded work, just to name a few. We've known for decades that we can do better and ways to do better have been studied in depth by academia. That's just the basics. Then there is futuristic things: Why can't we move running processes from one physical machine to another? Where are the debuggers that allow you to go back and forward in time? Why can't we visualize the data structures in our program and trivially change the data layout to see how that affects performance? When I look at the demo of the Xerox Sparc interface (1982) and compare that to where we are today it's pretty clear to me we messed up big time somewhere along the road: https://www.youtube.com/watch?v=Cn4vC80Pv6Q https://www.youtube.com/watch?v=Cn4vC80Pv6Q
  - TeMPOraL 10y ago
    > We're mostly using tools from the 70s We're using the shittier tools from the 70s, because the better tools died off - which is sad, because we still didn't manage to recreate some of the features those tools offered. The success of UNIX and C seems to be caused by the same phenomenon that causes Electron to succeed and bloat to proliferate - what wins aren't good solutions, but those which get popular quickly.
    - deleted 10y ago
      [deleted]
    - chii 10y ago
      > aren't good solutions, but those which get popular quickly. but by the judgement of a majority, those tools are good! That's why it got popular. Any personal sense of aesthetics from you (or anyone) doesn't matter at all here, and most people who call tools that failed 'good' are only judging it by personal aesthetics.
      - TeMPOraL 10y ago
        I'm not talking aesthetics here; I'm talking about shitty engineering. Often legitimized by nonsense phrases like "worse is better" these days.
  - nostrademons 10y ago
    For people who have an exceptionally high tolerance for learning what people actually care about and why the shitty technological solutions won in the marketplace, this is probably an opportunity. When I entered the workforce in 2005 after learning all about bygone languages (Common Lisp, Smalltalk, Dylan, Haskell, Erlang, Ocaml, etc.) in college, it was really, really painful going back to Java. Java had gotten so many fundamental language features wrong when better alternatives were well-known in research literature. Monitors instead of CSP, null types instead of Maybe, inner classes instead of closures, manifest typing instead of type inference, no first-class functions, mutability everywhere, conflation of modules & classes, not even a semblance of pattern-matching. But I could use it to write software that performed well, that could be deployed with tooling that everybody used, that had a wide base of available libraries, that had IDEs and other tooling available, and that other programmers could maintain. It's 12 years later, and all of my recent projects have been in some combination of Swift, Rust, Kotlin, or ES6+React. And most of these languages have: promises & message-passing instead of explicit locks; Optional types or at least some form of null-safety; lexical closures; type inference; first-class functions; immutable-by-default; module systems that don't require that you shove everything into a class; and pattern-matching. But they also did the hard work of figuring out an interoperability story with some large existing body of code; of writing decent package managers and easy build systems; of making the language reasonably performant for most everyday tasks; and of (in Swift & Kotlin's case) providing full support within an IDE. All the language features that were common in research languages of 2005 but missing in industrial programming of the time are now very usable in the industrial programming of now. I wouldn't be surprised to see a similar renaissance in tooling over the next decade, with exotic features like time-traveling debuggers, fully-inspectable systems, and migratable processes becoming standard in the next generation of IDEs.

userbinator 10y ago

I don't think capitalism is to blame, as this is endemic even in free software. The way to stop this is to stop repeating dogmatic myths about optimisation, consider efficiency/optimisation as an integrated part of the design process and not something to be applied afterwards, and focus on "user time is expensive" instead of "developer time is expensive" --- and sometimes, those users may also be developers.

deleted 10y ago
[deleted]
chii 10y ago
> user time is expensive that's not always true, especially from the point of view of the dev.
- username223 10y ago
  Yep. With forced auto-updates, software companies have implemented "software gavage," and the devs are just getting paid to push code down users' throats. It's much harder to entice users with something they might actually want.

ue_ 10y ago

Within capitalism, products are made to maximise exchange value rather than use value. This is because it is more profitable to optimise for products to be exchanged rather than used. In fact, it can be detrimental to maximise use value, because a product that can be used for longer will mean that fewer people will have motivation to purchase another one any time soon. I like the idea of overthrowing capitalism itself to resolve this.