Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Finish your stuff

250bpm.com

Post reply on HN
Print view View original

91–100 of 104 posts

Re: Finish your stuff

#91

Post by lgas »

xyzzyz wrote: post #64
zachrose wrote: post #10

Earlier quoted context omitted.

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

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.

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.

Re: Finish your stuff

#92

Post by erikbye »

kmicklas wrote: post #62

The reason this is an implicit principle of the Unix philosophy is because the Unix philosophy is to be as lazy as possible as the tool-creator and push all complexity onto the tool-user. Thus we get things like Go, regular expressions, and null pointers. People outside this school of thought don't finish their projects because their projects actually try to solve the underlying problems in computing, which are inevi…

Examples of underlying computing problems that are unsolvable if one follows the Unix philosophy? Keep in mind that it's often misunderstood what the primary tenets of the Unix philosophy are; your comment demonstrates you, too, have misunderstood.

Re: Finish your stuff

#93

Post by erikbye »

Ericson2314 wrote: post #81
Oxitendwe wrote: post #74

Earlier quoted context omitted.

What do null pointers have to do with the UNIX philosophy?

It's not on the stated list, but null pointers is a classic expedient unsafe shortcut for those too lazy to design a better type system. C is full of such shortcuts (c.f. Algol 68).

This is just wrong, and insulting; the Unix philosophy is not about laziness.

Re: Finish your stuff

#94

Post by erikbye »

Oxitendwe wrote: post #88
Ericson2314 wrote: post #81

Earlier quoted context omitted.

It's not on the stated list, but null pointers is a classic expedient unsafe shortcut for those too lazy to design a better type system. C is full of such shortcuts (c.f. Algol 68).

First of all, that has nothing to do with the UNIX philosophy, second of all, it has nothing to do with type theory. Anyone is perfectly capable of implementing a Maybe/Option/whatever type in C, allocating it on the heap (because you wouldn't be able to return it if it were stack-allocated), and then returning a pointer to it, whereupon C's actual type system would happily complain about mismatched types if you trie…

UNIX is a trademark; It's "the Unix philosophy", not "the UNIX philosophy."

Re: Finish your stuff

#95

Post by erikbye »

projectramo wrote: post #4

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…

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

Re: Finish your stuff

#96

Post by onion2k »

tomc1985 wrote: post #31

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!

This is a really good point. I'm guilty of seeing a repo that hasn't had a new commit in 18 months and choosing not to use that code because it's 'not supported any more'. Maybe maintainers could help by making it clear that their code is still supported but just doesn't need any changes in the Readme or something.

Re: Finish your stuff

#97

Post by oceanswave »

zokier wrote: post #20
projectramo wrote: post #4

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…

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.

Feature creep, or the phrase du jour- technical debt. It was a touchdown when it was done, but the world has moved its goalposts

Re: Finish your stuff

#98

Post by pronik »

The author implies that by releasing new versions of our software with security patches or features we somehow differ from construction where house are considered finished. They are not - there is a lot of maintenance to be done, painting, replacing pumps, sewage pipes, insulation, cables, I even had a house where we got a new balcony some 20 years after the house was "done", dito a completely new elevator recently some 40 years after finishing the house. I'm sure that if constructing houses had been as easy as rewriting software, we'd get a lot of other convenience changes just for the sake of being modern.

Software engineering is not flawed. It just lacks hundreds of years of experience which it will gain with time.

Re: Finish your stuff

#99

Post by rurban »

googamooga wrote: post #35

Out of the frustration with AMQP I've started my own ZeroMQ project. I doubt that Martin was the sole initiator of ZeroMQ project. I think that late Pieter Hintjens, the original author of AMQP, deserves some credit as well, at least out of respect[1][2]. [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…

Martin was the founder and developer, Pieter the evangelist and wrote the documentation.

Re: Finish your stuff

#100

Post by kmicklas »

erikbye wrote: post #92
kmicklas wrote: post #62

The reason this is an implicit principle of the Unix philosophy is because the Unix philosophy is to be as lazy as possible as the tool-creator and push all complexity onto the tool-user. Thus we get things like Go, regular expressions, and null pointers. People outside this school of thought don't finish their projects because their projects actually try to solve the underlying problems in computing, which are inevi…

Examples of underlying computing problems that are unsolvable if one follows the Unix philosophy? Keep in mind that it's often misunderstood what the primary tenets of the Unix philosophy are; your comment demonstrates you, too, have misunderstood.

What have I misunderstood?
Post reply on HN