71–80 of 177 posts
I thought the Unix philosophy embraced the idea of "small tools that do one thing really well." > Please join me in my effort and do finish your projects. Hear, hear. A friend and I hosted a "Finish it! Weekend" once (as opposed to a "Startup Weekend"). The idea was to get people together for one weekend and finish that last 10% or whatever of a project. Sadly we were the only two to show up. (And we both finished ou…
Love it. I'm stealing this idea.
Is nanomsg finished? I found its Windows support rather broken -- failing test cases. Strange lockups. https://github.com/nanomsg/nanomsg/issues I do not see Martin working much on those these days. Does anyone know how untangle those state machines besides him.
Am I the only one that really hates the carpenter analogy? As someone who does woodworking on the side of my programming, there's a million reasons why it's a terrible way to think about software development. The chair doesn't have supported platforms, new security issues, or the need to be updated so that people keep buying the same chair. Someone else isn't going to have to come along later to maintain the chair an…
The analogy makes no sense. There's so many fundamental differences between physical objects and software that my eyes glazed over as soon as he started the carpenter rant.
This is absurd. A finished project is a dead project. If it isn't improving, it's dying. Never finish your projects (unless you're just doing homework). Software is a system. Systems of any non-trivial complexity are living things that must adapt and evolve. Constantly. (Also, there is absolutely nothing wrong with abandoning a project. Gain as much as you can from your experience and quickly move on to something bet…
Earlier quoted context omitted.
If you're embarrassed by the first version of your product (i.e. suppose it's buggy, or is lacking in it's UI) then it's probably not ready to ship? There is nothing worse than shipping a half-baked product.
"If you're embarrassed by the first version of your product (i.e. suppose it's buggy, ..." A first release must not be buggy. But it can have a limited set of functionality. Imho, the real art of software development is to restrict the initial set of functionality and get that done, as quickly as possible (but not quicker), bug free (sic) and useful.
I thought the Unix philosophy embraced the idea of "small tools that do one thing really well." > Please join me in my effort and do finish your projects. Hear, hear. A friend and I hosted a "Finish it! Weekend" once (as opposed to a "Startup Weekend"). The idea was to get people together for one weekend and finish that last 10% or whatever of a project. Sadly we were the only two to show up. (And we both finished ou…
Nice idea. Call it a "FinishUp Weekend" as opposed to a "StartUp Weekend"?
This is absurd. A finished project is a dead project. If it isn't improving, it's dying. Never finish your projects (unless you're just doing homework). Software is a system. Systems of any non-trivial complexity are living things that must adapt and evolve. Constantly. (Also, there is absolutely nothing wrong with abandoning a project. Gain as much as you can from your experience and quickly move on to something bet…
Is TeX dead?
Sometimes, genius strikes and you get something so precisely thought out and so well executed that it lasts for generations.
Still, I'd have to answer your question in the affirmative. The original TeX is quite dead indeed. It (and the ecosystem around it) have evolved significantly over the years and continue to evolve as we speak, so it is far from finished.
Just an aside on the carpenter metaphor, there's sort of a running joke that a carpenter's house is never finished. It's not just the software profession that has this problem.
Programming is more like policy writing. Definitely not like carpentry.
Outstanding issues may exist for feature requests that I don't need, or for minor bugs that won't occur in anything but obscure edge cases that don't apply to the primary use case. I welcome high quality patches but otherwise have no interest in pursuing them.
Oh, come on: software is usually much more than a table or a chair. It grows, it needs care, it is more like a plant than something static. What does it even mean to "finish" a program like 'ls' given the increasing complexity of filesystems with time?