Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Actually there used to be a 100x better approach to software than this blog post. Yes, that meant 10000x better software.

All you needed to do is break down what you were doing into steps, and pipe one step to the other with this character: |

Unfortunately, one thing led to another and, well, we are 10,000 times slower now than then.

whats your email address | confirm your email | get a link | pay with my payment processor | get my service

Hahaha, setting this up today takes 8 hours. Approximately 10,000 times slower than it should be. Actually, someone who can set up a complete billing solution in a day is considered a hero.

Amazon is the only company that even comes close to doing for the web what we had twenty years ago for local sys admin tasks. Only one lets you manage loads of complicated files (kind of cool) and the other lets you provide a service to hundreds or thousands of people (kind of awesome).

where did we go wrong.



I wish someone would reply instead of just downvoting, so I can at least see if I've made myself clear.

It used to be that for most tasks a superuser, a real ace of an admin, used to do, they would NOT write new programs: instead they would stitch together old ones.

I wish I could find it but am having trouble just now, but there was an experiment done among various programming groups completing the same task. You had people doing it in various scripting languages, C++, Java, whatever.

The way I recall (again, having trouble finding this), the team or person/approach that won handily was the one using Unix from the standard commandline interface (e.g. bash) - no scripting or programming at all! Where instead of writing a program to do it all, the person or group simply used standard Unix tools, piping them together etc, until the problem was solved. This approach was by far the fastest.

I'm saying, these days on the web we don't really have the same thing when you develop a new application. We don't have a "Unix of the web" - though, again, AWS and Amazon's ambitions on e.g. payment, database, etc, seem to be vaguely in that direction - which is far more productive than writing a piece of software.

No matter how productive -- HOW PRODUCTIVE! - you are at writing a script to bill a user ten dollars, you can never -- NEVER! -- be as fast as typing "| bill 10.00" where "bill" takes an email address on standard input. That Unix program does not exist.

The way the web is developing, it does not look like it will exist. This was my point. I guarantee you that typing "| bill 10.00" is nearly ten thousand times as fast as writing any program in any programming language that does that.

Unix works because someone took the time to write programs that can be stitched together at the command prompt (or from a script). The Internet just doesn't work that way.

The blog post I'm referring to ends with: "Is that just the way things must be, that geniuses are in short supply and ordinary intelligence doesn’t scale efficiently? How much better could we do with available talent if took a better approach to developing software?"

I say, the problem is that the geniuses are no longer creating the "Unix programs" of the web. They are writing software, i.e. lines of code, they are not writing web "utilities".

If all the geniuses got together and gave me the top thousand things you need an API for, and instead worked on making them a set of small, modular Unix commands, then I would be literally ten thousand times more productive than now.

I could literally do in 20 seconds of typing what I can do in two days.


You know, I like grep and sed and all that too, but what the hell are you talking about here?

The bill command just takes an email on stdin? How's it know which account that email belongs to? From a database? With what credentials? Does it bill to paypal or visa? To which merchant account number?

The thing with "unix style programming" fetishism is that, yeah, pipes are great, but now you're writing incredibly complicated options parsers to configure all your little standalone programs. Isn't there a point at which a simple method call is easier? We've had method calls for a long time.

The reason you were downvoted (not by me) is probably that people thought this was obvious and you were being obtuse and ideological.


Instead of doing "| bill 10.00", I'd do "from payment import bill; bill(10.00)".

Now the issue is implementing the payment library, just like you'd have to implement the 'bill' program.

Your argument is for composability, and while UNIX utilities are certainly a great example of that (which I use every day!), they're hardly the only. Perl, Python, Ruby, etc all have plenty of small libraries to solve specific problems.


The problem is this begins to break down when you want to do more complicated things, A small gripe that still illustrates the point:

> be as fast as typing "| bill 10.00" where "bill" takes an email address on standard input.

What happens then when "bill" takes and email address on stdin but I need it to take an amount on stdin and an email address on the command line. This is the sort of thing that unix starts to break down on, you spend far too much time trying to munge the data into the delicate format that various programs expect it on.

Secondly you say: > No matter how productive -- HOW PRODUCTIVE! - you are at writing a script to bill a user ten dollars, you can never -- NEVER! -- be as fast as typing "| bill 10.00" where "bill" takes an email address on standard input. That Unix program does not exist.

But have little evidence to back that up, and with a little inspection it seems that that holds very little grounds against something such as "bill(10.00, email)" as one would do in a modern environment.

If you want to know why you are being downvoted, it's because you have remarkable claims (10000x improvement is very remarkable) with little to zero evidence to back those claims up.


Look at the video he linked, here: http://tele-task.de/archive/video/flash/14029/ (tldr: 20.000 lines seems to suffice to make a running OS with "personal computing" apps.)

I think you will mostly agree with the video, but If you don't know of the Viewpoint Research Institute, it will be worth your while.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: