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

81–90 of 104 posts

Re: Finish your stuff

#81

Post by Ericson2314 »

Oxitendwe wrote: post #74
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…

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

Re: Finish your stuff

#82

Post by takeda »

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…

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.

Re: Finish your stuff

#83

Post by zachrose »

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.

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.

Re: Finish your stuff

#84

Post by gkya »

derefr wrote: post #70
gkya wrote: post #63

Earlier quoted context omitted.

But isn't that a bit like sitting on someone else's chair? You can't control things you don't own.

Yeah, I'd compare that more to living in a hotel, and coming into your room every day to find that the hotel has replaced the chairs. The hotel, here, is the web service, or your OS's package manager If you have a problem with constantly changing chairs, you're free to find a new hotel that doesn't do that—probably one with "LTS" in the name.

I was referring to individual software packages, an entire distro is a bit of a different beast. Going with the same chair analogy, well, you'd mostly care about the chair in your room, no? The one that you use the most. That's similar to what I do with Ubuntu (and any other OS): it takes care of all the programs except Emacs which I compile myself following master, Firefox Developer Edition which I'll use until 57 comes out, and my scripts and utilities that I've written. It's impossible to micro-manage every bit of software I directly or indirectly use, but it's a nice trade off to ensure the most important bits myself and trust the rest to the distro maintainers.

Re: Finish your stuff

#85

Post by gkya »

fasquoika wrote: post #66
gkya wrote: post #63

Earlier quoted context omitted.

But isn't that a bit like sitting on someone else's chair? You can't control things you don't own.

This seems like the kind of question liable to open a whole can of worms about free software and what it means to "own" a program

I don't think so, as this comment won't be seen all that much; but I'd say that that's a can of worms that we should open.

Re: Finish your stuff

#86

Post by elihu »

Jtsummers wrote: post #59
elihu wrote: post #53

I don't agree. The goal of software isn't usually to discover some perfect abstraction with nothing left to add and nothing to take away, the goal is usually to solve some practical real-world problem. If your software satisfies the requirements without taking too much time or effort to create, then it's a success. If a project is going to be used by a lot of people or become some kind of industry standard, then it m…

The author's point is not that there shouldn't be new systems or that no systems should ever change. He's not arguing for a perfect abstraction, either. Following his development path (AMQP->ZeroMQ->nanomsg + libmill + others) his interest was in decomposing the larger system (AMQP which included message queues, databases for storing messages, wire protocols, etc.) into its smaller parts so that you could build back…

> Following his development path (AMQP->ZeroMQ->nanomsg + libmill + others) his interest was in decomposing the larger system (AMQP which included message queues, databases for storing messages, wire protocols, etc.) into its smaller parts so that you could build back up to it in a better way. It happens that when you get to those lower levels, you can call them done.

I think breaking things up into small pieces so that it's modular and you can work on one part at a time and then assemble a working system out of individually-testable working parts is a good thing (especially if you can re-use parts that other people have already made), but I don't think that's quite the argument the author was making.

I think the author was arguing that you should reduce the scope of the task any time you notice open-ended requirements with no clear completion criteria. I think that's good advice most of the time, but there are exceptions. It's okay to have a project that isn't "finished" if it's useful.

Re: Finish your stuff

#87

Post by sophacles »

sly010 wrote: post #38
wbl wrote: post #36

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

I'd love for a lot of the pieces of my problems to be solved.

I think our industry forgets that solving 50% of the problem is still a big improvement over having the whole problem.

Re: Finish your stuff

#88

Post by Oxitendwe »

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

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 tries to use this type without deliberately accessing its internal members, at which point you're doing exactly as much intentional effort as if you used a convenient accessor macro that checks to make sure it's not the nil case. While I agree that C (and its type system) could be much better, fixing the problem is not quite as simple as "just design a better type system".

Re: Finish your stuff

#89

Post by tmaly »

zachrose wrote: post #10
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…

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

it would be interesting if a protocol could be used in this case to serve the idea of a pipe

Re: Finish your stuff

#90

Post by [deleted] »

gkya wrote: post #85
fasquoika wrote: post #66

Earlier quoted context omitted.

This seems like the kind of question liable to open a whole can of worms about free software and what it means to "own" a program

I don't think so, as this comment won't be seen all that much; but I'd say that that's a can of worms that we should open.

[deleted]
Post reply on HN