4 ms·

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

by 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.

by gizmo 10y ago

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.