10 ms·

What 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 com

What 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 a new popular cal app that everyone uses. Should you update it to work with that? The problem isn't that the software is incomplete. The "problem" is that the world keeps changing. To the extent that the environment doesn't change (unix), you can "complete" your tool.

weavie 9y ago
I guess it depends on what granularity you are viewing your project at. Your beep app could be complete and if you want calendar integration, that's a new project that takes input that is somehow piped into it from the beep app. The ios version is a new project that imports beep as a lib.. It's one way to look at things anyway.
zachrose 9y ago
I think the Unix philosophy would have you pipe those beeps to another program that does your calendar integration.
- xyzzyz 9y ago
  You'd still need to write the glue code that correctly maps one program's output to the other program's expected input. I don't see how this is materially different. If by "Unix philosophy" you mean creating modular software, then sure, we're already doing this. If you mean pushing unstructured ASCII data through actual pipe(2)s, then I'm sorry, but this is not a workable solution in 2017.
  - Nullabillity 9y ago
    > You'd still need to write the glue code that correctly maps one program's output to the other program's expected input. I don't see how this is materially different. But you shouldn't need to be that person.
  - zachrose 9y ago
    Unix philosophy also seems to assume that the users and developers of the beep software are different people with different priorities than the calendar app people. I think the crux of this discussion is whether you are in one of these camps or you're trying to sell a holistic solution to their beeping calendar needs. The latter will never be done because holism means being tenderly connected to a changing world. But in terms of pipes, it seems like the 2010s version would probably be JSON over HTTP.
  - lgas 9y ago
    Well, part of the difference is that now the "beep" program can be considered finished and other people can use it piping it to whatever programs they want, and it will never (or at least rarely, compared to the monolithic approach) need to be updated because all it does it beep. If and when it does need to be updated it will be much easier to update because all it does is beep, so it doesn't include a calendar library and so on. It won't have to be recompiled when the calendar library is updated, etc. You have to do the same amount of work overall to get the same end results but the individual pieces can stabilize and be used independently.
- tmaly 9y ago
  it would be interesting if a protocol could be used in this case to serve the idea of a pipe
tedmiston 9y ago
I feel like unix philosophy applies more to libs and small CLI tools more than full blown web apps with evolving feature sets. Or you build an integration / plugin system, and each new feature is a self-contained plugin to do that one thing well.
zokier 9y ago
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.
- sly010 9y ago
  > 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.
  - wbl 9y ago
    Then you split the problem into contained pieces.
    - sly010 9y ago
      But then you didn't solve the problem. You solved pieces of the problem.
      - Jtsummers 9y ago
        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).
danielbarla 9y ago
It's finished when there's nothing left to remove.
- msla 9y ago
  As long as you don't remove things from the problem in the name of removing them from the solution. Or, to be less terse, don't say "Well, you shouldn't need to solve that problem!" or "You're holding it wrong!" Reality doesn't give you neat problems which map cleanly to the simple solution, and adding complexity is the only way to solve the problem, as opposed to a dishonestly reduced form of the problem.
eurticket 9y ago
I think we all can imagine it means you get the app running in the first place, it's in a stable state, ready for modifications and improvements; done in this circumstance should mean, the-first finalized version after the rough drafts-done.
zitterbewegung 9y ago
You are confusing release with maintenance. When you ship it it should be the example of "the little web app" and when you have others use it. That is "finishing". When you have something that has a modicum of value. If you add more features in response to users or sales or whatever metric that is the rest of your comment. Or maybe you don't need any more features in the future maybe its only bug fixes like TeX or the Python Requests library.
ChuckMcM 9y ago
So true. A friend of mine that does hardware says "I like hardware because when I run out of parts to install I know I'm done." :-) I've teased him about board re-spins and feature creep, but by and large because there are some externalized costs (like getting new board fabs) it is very crisp in prioritizing adding features vs being done.
Oxitendwe 9y ago
Porting your program to a different platform makes it a different program. It doesn't change the completeness of the original. Modifying your program to account for API changes also qualifies as "a different program" - you can have different programs that all do the same thing, for different platforms, for different API versions of the same platform, and have them all be "complete" even if you may need to write a new one at some point because you want to run it on your wristwatch or something.
takeda 9y ago
Yep, this is especially noticeable when using software (most common for libraries and drivers) that was abandoned. Even though the library worked perfectly fine several years ago and had many users, several years later it seems to show up some kind of errors that most people didn't experience, certain tasks require workarounds or are down right impossible to do. And the reason fir it is that the environment where the library operates changed and most likely it is used differently than in the past, but it gives a perception as if the quality of software actually degrades with time.
erikbye 9y ago
From the blog post: "Except for some basic UNIX tools, like grep or make, it's almost impossible to find anything that's truly finished, not simply abandoned." Now, granted, must of us on anything Unix-like is on a BSD or Linux, not on a UNIX, but grep and make are still being patched, here and there. Even 'ls' gets commits. We could get into a pedantic discussion on when something can be classified "finished," but that doesn't seem fruitful. I think we just need to realize that despite following the Unix philosophy (or something similar), which is mainly about modularity and composability, not a single part (modular piece, service, etc.) of modern systems can be left unmaintained, it can never be in a "truly finished state."

weavie 9y ago

I guess it depends on what granularity you are viewing your project at. Your beep app could be complete and if you want calendar integration, that's a new project that takes input that is somehow piped into it from the beep app. The ios version is a new project that imports beep as a lib.. It's one way to look at things anyway.

zachrose 9y ago

I think the Unix philosophy would have you pipe those beeps to another program that does your calendar integration.

xyzzyz 9y ago
You'd still need to write the glue code that correctly maps one program's output to the other program's expected input. I don't see how this is materially different. If by "Unix philosophy" you mean creating modular software, then sure, we're already doing this. If you mean pushing unstructured ASCII data through actual pipe(2)s, then I'm sorry, but this is not a workable solution in 2017.
- Nullabillity 9y ago
  > You'd still need to write the glue code that correctly maps one program's output to the other program's expected input. I don't see how this is materially different. But you shouldn't need to be that person.
- zachrose 9y ago
  Unix philosophy also seems to assume that the users and developers of the beep software are different people with different priorities than the calendar app people. I think the crux of this discussion is whether you are in one of these camps or you're trying to sell a holistic solution to their beeping calendar needs. The latter will never be done because holism means being tenderly connected to a changing world. But in terms of pipes, it seems like the 2010s version would probably be JSON over HTTP.
- lgas 9y ago
  Well, part of the difference is that now the "beep" program can be considered finished and other people can use it piping it to whatever programs they want, and it will never (or at least rarely, compared to the monolithic approach) need to be updated because all it does it beep. If and when it does need to be updated it will be much easier to update because all it does is beep, so it doesn't include a calendar library and so on. It won't have to be recompiled when the calendar library is updated, etc. You have to do the same amount of work overall to get the same end results but the individual pieces can stabilize and be used independently.
tmaly 9y ago
it would be interesting if a protocol could be used in this case to serve the idea of a pipe

tedmiston 9y ago

I feel like unix philosophy applies more to libs and small CLI tools more than full blown web apps with evolving feature sets. Or you build an integration / plugin system, and each new feature is a self-contained plugin to do that one thing well.

zokier 9y ago

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.

sly010 9y ago
> 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.
- wbl 9y ago
  Then you split the problem into contained pieces.
  - sly010 9y ago
    But then you didn't solve the problem. You solved pieces of the problem.
    - Jtsummers 9y ago
      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).

danielbarla 9y ago

It's finished when there's nothing left to remove.

msla 9y ago
As long as you don't remove things from the problem in the name of removing them from the solution. Or, to be less terse, don't say "Well, you shouldn't need to solve that problem!" or "You're holding it wrong!" Reality doesn't give you neat problems which map cleanly to the simple solution, and adding complexity is the only way to solve the problem, as opposed to a dishonestly reduced form of the problem.

eurticket 9y ago

I think we all can imagine it means you get the app running in the first place, it's in a stable state, ready for modifications and improvements; done in this circumstance should mean, the-first finalized version after the rough drafts-done.

zitterbewegung 9y ago

You are confusing release with maintenance. When you ship it it should be the example of "the little web app" and when you have others use it. That is "finishing". When you have something that has a modicum of value. If you add more features in response to users or sales or whatever metric that is the rest of your comment. Or maybe you don't need any more features in the future maybe its only bug fixes like TeX or the Python Requests library.

ChuckMcM 9y ago

So true. A friend of mine that does hardware says "I like hardware because when I run out of parts to install I know I'm done." :-) I've teased him about board re-spins and feature creep, but by and large because there are some externalized costs (like getting new board fabs) it is very crisp in prioritizing adding features vs being done.

Oxitendwe 9y ago

Porting your program to a different platform makes it a different program. It doesn't change the completeness of the original. Modifying your program to account for API changes also qualifies as "a different program" - you can have different programs that all do the same thing, for different platforms, for different API versions of the same platform, and have them all be "complete" even if you may need to write a new one at some point because you want to run it on your wristwatch or something.

takeda 9y ago

Yep, this is especially noticeable when using software (most common for libraries and drivers) that was abandoned. Even though the library worked perfectly fine several years ago and had many users, several years later it seems to show up some kind of errors that most people didn't experience, certain tasks require workarounds or are down right impossible to do. And the reason fir it is that the environment where the library operates changed and most likely it is used differently than in the past, but it gives a perception as if the quality of software actually degrades with time.

erikbye 9y ago

From the blog post: "Except for some basic UNIX tools, like grep or make, it's almost impossible to find anything that's truly finished, not simply abandoned." Now, granted, must of us on anything Unix-like is on a BSD or Linux, not on a UNIX, but grep and make are still being patched, here and there. Even 'ls' gets commits. We could get into a pedantic discussion on when something can be classified "finished," but that doesn't seem fruitful. I think we just need to realize that despite following the Unix philosophy (or something similar), which is mainly about modularity and composability, not a single part (modular piece, service, etc.) of modern systems can be left unmaintained, it can never be in a "truly finished state."