2 ms·

In the first place, good software is software that exists. I don't know ticki or his work, but if it is vaporware what he calls vaporware, then there is no way

In the first place, good software is software that exists. I don't know ticki or his work, but if it is vaporware what he calls vaporware, then there is no way for it to be good software. If ticki reads this: props for the clear words. Honest posts like this are rarely seen. And good luck for your career in mathematics. Though I figure great mathematics is not much different than great software (I'm not talking about glue-coding): It needs to exist. You need to find simple, obviously correct, and useful models to create something that other things can build on. And if you decide to come back later: A clear goal helps separating the essential from the non-essential. Formalism is only a tool, not an end in itself.

hardwaresofton 9y ago
I don't agree with the notion that software has to be finished to be good (which isn't exactly what you said but the implication seems to be there). Taken literally, software that is unfinished (i.e. unusable) cannot possibly be good, obviously, but software that was been theorized but didn't necessarily exist in finished form until relatively recently is pretty common. If you don't want to make a bundled mess of spaghetti design, theory/play/experimentation that doesn't necessarily turn into a functioning project is crucial, ideas are sometimes reused/refactored into a project that is completed. Maybe if none of his work was actually published at all, then that statement would make sense (since it would literally be impossible to derive value from something that doesn't exist), but he's contributed documentation, schematics, etc, it's vaporware in the sense that it isn't a finished product and may never actually become one since he's not supporting it anymore, but if someone else sees what he's done (ex. https://github.com/redox-os/tfs https://github.com/redox-os/tfs), they might pick it up and finish it. ATM there are 500+ commits to that project, I find it hard to believe that if what he was doing is worth doing that those commits are completely worthless.
- grosjona 9y ago
  Yes totally agree, good software evolves to be that way. It's never perfect from day 1. On day 1 you don't ecen know what users want because you have no users to tell you what is required.
- jstimpfle 9y ago
  My statement was about software, not about what can be learned from failed projects. Sure experimentation has value, even if it only leads to the insight that theory can rarely be applied to software in materialized form. And I think that's the gist of the post. Take regular expressions, one of the theories that actually have been applied successfully to practice - because they are easy to understand and, as a corollary, describe practical concepts. Now, where are state machines implemented in their as a materialization of their abstract form? I don't know, maybe not even in a rather generalist tool like grep. They are at least not useful for lexers (one canonical use case for RE), because the formal overhead gets in the way of converting literals and looking up identifiers. In Software you need to cut corners to be able to implement useful functionality and achieve good performance.

hardwaresofton 9y ago

I don't agree with the notion that software has to be finished to be good (which isn't exactly what you said but the implication seems to be there). Taken literally, software that is unfinished (i.e. unusable) cannot possibly be good, obviously, but software that was been theorized but didn't necessarily exist in finished form until relatively recently is pretty common. If you don't want to make a bundled mess of spaghetti design, theory/play/experimentation that doesn't necessarily turn into a functioning project is crucial, ideas are sometimes reused/refactored into a project that is completed. Maybe if none of his work was actually published at all, then that statement would make sense (since it would literally be impossible to derive value from something that doesn't exist), but he's contributed documentation, schematics, etc, it's vaporware in the sense that it isn't a finished product and may never actually become one since he's not supporting it anymore, but if someone else sees what he's done (ex. https://github.com/redox-os/tfs https://github.com/redox-os/tfs), they might pick it up and finish it. ATM there are 500+ commits to that project, I find it hard to believe that if what he was doing is worth doing that those commits are completely worthless.

grosjona 9y ago
Yes totally agree, good software evolves to be that way. It's never perfect from day 1. On day 1 you don't ecen know what users want because you have no users to tell you what is required.
jstimpfle 9y ago
My statement was about software, not about what can be learned from failed projects. Sure experimentation has value, even if it only leads to the insight that theory can rarely be applied to software in materialized form. And I think that's the gist of the post. Take regular expressions, one of the theories that actually have been applied successfully to practice - because they are easy to understand and, as a corollary, describe practical concepts. Now, where are state machines implemented in their as a materialization of their abstract form? I don't know, maybe not even in a rather generalist tool like grep. They are at least not useful for lexers (one canonical use case for RE), because the formal overhead gets in the way of converting literals and looking up identifiers. In Software you need to cut corners to be able to implement useful functionality and achieve good performance.