Finish your work... only to have legions of newb "hackers" bitching at you and calling your project dead because "(s)he hasn't posted an update in months"
Death to evergreen software! Let projects be finished!
Finish your stuff
31–40 of 104 posts
Re: Finish your stuff
#32Any software tool that is deemed as "complete" is not really complete. Even TeX, which will be releasing its final version when Donald Knuth feels the end of his life is near, is not complete because it is constantly expanded with reimplementations like XeLaTeX and LuaTeX and with thousands of plugins in constant development. GNU utilities like ls are not complete because they are built on top of operating system sys…
Re TeX: That's actually covered by the author. TeX itself is complete. Knuth isn't adding new features, instead the version number is converging to pi (new digit added) with bug fixes [0]. The other variations are not TeX (they're reimplementations) or they're extension built on top of the completed TeX program.
[0] https://www.tug.org/TUGboat/tb11-4/tb30knut.pdf [PDF, in case it wasn't obvious]
Re: Finish your stuff
#33Software can be usable but 'incomplete', in the same way that stools and Aerons are both usable, but stools weren't an unfinished technology. If your bug count is low and your software has features, it's already done.
Re: Finish your stuff
#34What would that look like? Consider an example: You have made a little web app that beeps at certain times of the day to remind me to do something. Is it complete? Oh, you want a calendar integration. That makes sense. You add it. Is it complete? Oh, you say you want to release mobile versions? Okay, now is it complete? Sorry, but the iOS version needs to be updated to remain compatible. Now is it complete? There is…
That is called feature creep, and is usually not viewed in positive light. Its real art to know how to decompose problems and design neat, contained, solutions. I'd also argue that the "change" you are seeing is mostly illusionary, but that is another story altogether.
> neat, contained, solutions.
Contained solutions can be only designed for contained problems. Sure if you define a limited set of requirements you can finish your project and will have a limited software that is only useful in that very limited context.
"change" might be unnecessary but it is certainly not illusionary.
Re: Finish your stuff
#35 Out of the frustration with AMQP I've started my own ZeroMQ project.
[1] https://en.m.wikipedia.org/wiki/ZeroMQ [2] https://en.m.wikipedia.org/wiki/Pieter_Hintjens
Disclaimer: I knew Pieter personally and met him several times at his home and at conferences.
Re: Finish your stuff
#36Earlier quoted context omitted.
That is called feature creep, and is usually not viewed in positive light. Its real art to know how to decompose problems and design neat, contained, solutions. I'd also argue that the "change" you are seeing is mostly illusionary, but that is another story altogether.
> neat, contained, solutions. Contained solutions can be only designed for contained problems. Sure if you define a limited set of requirements you can finish your project and will have a limited software that is only useful in that very limited context. "change" might be unnecessary but it is certainly not illusionary.
Then you split the problem into contained pieces.
Re: Finish your stuff
#37> Please join me in my effort and do finish your projects. Your users will love you for that. Will they? If your users are programmers, they might love you for that. For pretty much all other users, they will want more. "It would be great if your app did...". I would argue that users now expect software to change and add more features. And why wouldnt they, when pretty much all software they use is doing this? If you…
That's actually not my experience; I see people using "old" software all the time, and rarely looking for newer alternatives even if they feel that some things could be added or improved. As just an example, my mother still uses ATnotes - last released in 2005.
And I think the limited data we have shows that, like the number of people who upgraded their browsers before it was automatic.
Re: Finish your stuff
#38Earlier quoted context omitted.
> neat, contained, solutions. Contained solutions can be only designed for contained problems. Sure if you define a limited set of requirements you can finish your project and will have a limited software that is only useful in that very limited context. "change" might be unnecessary but it is certainly not illusionary.
Then you split the problem into contained pieces.
But then you didn't solve the problem. You solved pieces of the problem.
Re: Finish your stuff
#39Except that grep and make have continued to be augmented over time?
Re: Finish your stuff
#40Earlier quoted context omitted.
Then you split the problem into contained pieces.
But then you didn't solve the problem. You solved pieces of the problem.
That's a part of software engineering though.
Once you reach a certain scale, you have to decompose your problems into subproblems. You solve those and assemble them into the final system.
The people making AMQP (following the original author's example and line of reasoning) were solving too many problems: they had a message queue, they had a wire protocol, they had service discovery, etc. This is all fine.
The author and others went on to make ZeroMQ with the intention of focusing on the communication between nodes and various communication patterns (pub/sub, reply/respond, etc.). They had some work on what should go over the wire but not too much, and they didn't expose things like authentication or discovery of services. Why? Because those are critical to applications, but not to a distilled, core message queue.
Using ZeroMQ, now, you can build up to what AMQP wanted to be. You can agree between your customers that ZMQ will be how you coordinate between systems, but you define your own message format using a separate standard. That standard is now independent of the wire protocol as well. Take something like ASN.1 or protocol buffers and define your message schema using those.
You want discovery? You agree on how services should be announced (a schema in ASN.1) and where the service registry should live (this would be a system configuration detail, where you specify where your system looks for a registry, maybe even federate registries). But this doesn't redo the work of ZMQ or the work of the serialization/deserialization format defined above.
You want to handle authentication? You pick your desired authentication protocol (public/private keypairs for identity, a capabilities based system, access tokens, whatever) and you again define a schema, define where the authentication service is located (or how it's identified in the registry above) and continue.
We don't reinvent TCP every time we want a new network protocol (well, some people do). Why would you reinvent the message queue when its already been distilled to a basic and fundamental framework that can be used to implement your desired business logic (now, if the MQ lacks some features that are basic or primitive, then it should be extended because it's not complete).