Do One Thing • Hacker News Board

Re: Do One Thing

#101

Post by TeMPOraL » Sat, Oct 31, 2015, 6:43 AM UTC

roel_v wrote: post #91

TeMPOraL wrote: post #82

Earlier quoted context omitted.

- It was much lighter; entire websites used to weight less than a single JS file today. We've increased the size of pages by an order of magnitude (and processing expense by at least two) for no real reason except laziness. - The SaaS/cloud model wasn't so popular, which means trying to lock you in by stealing your data, or doing absolutely ridiculous things like IoT does, wasn't something you saw.

But that's how it's presented, not content. Look I dislike 5mb pages with 2 paragraphs of text content as much as the next guy, but if I had to choose between that and 1000 shitty Geocities 'personal homepages' and the vast wealth of information that can be found on the internet today, I'd choose today in a heartbeat. How can someone claim with a straight face "but the web really was a lot more fun pre-dotcom-bubble"…

There is little actual content in present day Internet relative to its size. Look, what is produced on those websites that also tend to carry heavy presentation is not content. Real content is Wikipedia, or Hacker News, or various people and their various topical subpages, personal blogs, up and including stuff hosted at Geocities and Tripod Lycos. What is not content is most of the stuff that's created for money, including majority of today's "journalism". Information that is shallow, false and/or useless, and that exists only to make you click or buy.

90% of for-profit content could disappear just like that, and humanity would be much better off. Every information that is valuable, you can almost always find for free, posted by people who don't try to use you.

Re: Do One Thing

#102

Post by Too » Sat, Oct 31, 2015, 7:20 AM UTC

There is always . You can easily embed a youtube or vimeo video even if your core product is not displaying videos. I always felt that iframe is a bit of lost potential, what it needs is a javascript api so that you can communicate back and forth with the frame/plugin, last time I checked this was not allowed due to same origin policy.

After the communication channel is in place it needs a few standard interfaces, maybe there could be some video player interface with play/pause/seek functions. These dont have to be included in any w3 standard, its more of a de facto standard or agreement that if you make a video player and don't implement the IAwesomeVideoplayerInterface, websites will not allow embedding of your product.

What's sad is that it seems like vendors are trying to move away from this model, Facebook is the prime example of this with hosting of a copy of embedded videos and displaying linked news inline in their own format.

Re: Do One Thing

#103

Post by pjmlp » Sat, Oct 31, 2015, 7:49 AM UTC

Unix pipes only work in the CLI with a text based interface and even then they break down when the applications aren't able to parse the data.

So one always ends up massaging the data to make them be understood.

Piping concept was actually more powerfull in Xerox PARC systems by using the respective language REPL and do LINQ style data transformations.

However the problem of the article is that once you scale out of the CLI, you need a standard communications API to this type of stuff.

One that is able work in distributed systems, dealing with all types of failure issues.

If anything, native programming on the mobile offers some kind of piping thanks to intents, contracts and extensions.

Re: Do One Thing

#104

Post by chubot » Sat, Oct 31, 2015, 8:32 AM UTC

jobu wrote: post #27

There is some merit to "doing one thing well", but taken to the extreme it can be horrible in a different way: tar cvf - FILE-LIST | gzip -c > FILE.tar.gz ( https://xkcd.com/1168/ )

I just use GNU long options now, e.g.:

$ tar --extract --verbose --gzip $ tar --create --gzip --file sql.tar sql/

After switching to this style I never have problems coming up with the correct command. It's a lot easier to read in shell scripts too.

Re: Do One Thing

#105

Post by paublyrne » Sat, Oct 31, 2015, 8:34 AM UTC

paulddraper wrote: post #72

hasenj wrote: post #40

Earlier quoted context omitted.

> but its not because it did more than one thing, it is because it didn't do them well. In general I agree with your line of thinking, but I will nitpick on this particular sentence (or the way it's phrased) and say: the whole idea of doing only one thing is that if you try to do more than one thing, you will definitely not do them all well. I do agree with you though. The "many things" that postgresql does are all a…

What if something if really good at being a website?

Or really good at being a platform.

Re: Do One Thing

#106

Post by mbrock » Sat, Oct 31, 2015, 9:03 AM UTC

crdoconnor wrote: post #98

saosebastiao wrote: post #20

I'm definitely guilty of holding onto a philosophy and thinking it applies universally, so I can't blame people that hold onto the Unix philosophy extremely strongly. But I can't help but think that the world requires a hell of a lot more pragmatism than the Unix philosophy can provide. The first problem I see is that "One Thing" is really subjective. Some people might see Postgres as doing one thing really well (It…

Ironically the Unix philosophy doesn't even really apply to Unix itself - it mainly just applies to GNU tools. Unix is a general purpose operating system for computers of all shapes and sizes. You can't get much more generic than that.

It's still built on a simple kernel that doesn't do much and a user land of many independent processes. The philosophy doesn't forbid generality, it just encourages a "federalist" organization of cooperating programs communicating through simple kernel institutions (files, sockets).

Re: Do One Thing

#107

Post by progman » Sat, Oct 31, 2015, 9:08 AM UTC

dahart wrote: post #30

rco8786 wrote: post #9

I agree on the face of things, but what the web is missing from the unix philosophy is an equivalent to |. Without the ability to string multiple, focused tools together even tools that did one thing well(i.e., Evernote) will continue to add features until it does a bunch of things meh.

Absolutely! And just follow that to logical conclusions, to me it seems to answer the question of why we don't have it, right? On the web, "|" (pipe) means integration with other services, and it comes with all the associated trials and tribulations. To make web pipes work, just to even get started, you first have to solve authentication and data format/transfer standards. Those things are a big pain, its not surpris…

> To make web pipes work, just to even get started, you first have to solve authentication and data format/transfer standards.

Unix pipes have already solved the authentication problem. For instance, to stream a compressed harddisk copy safely between two hosts you can use the following statement:

  dd if=/dev/harddisk | gzip -9 | ssh user@xyz dd of=hdcopy.gz

Data format standards could be implemented right now using encrypted JSON or something like that. I would prefer Lisp s-expr by the way because they could be handled immediately in client/server lisp without any transformation.

Re: Do One Thing

#108

Post by fractallyte » Sat, Oct 31, 2015, 9:29 AM UTC

pjmlp wrote: post #103

Unix pipes only work in the CLI with a text based interface and even then they break down when the applications aren't able to parse the data. So one always ends up massaging the data to make them be understood. Piping concept was actually more powerfull in Xerox PARC systems by using the respective language REPL and do LINQ style data transformations. However the problem of the article is that once you scale out of…

The Amiga ecosystem perfected this: most (good) software featured an ARexx 'port' - an API, based on the REXX language, that enabled any one program to communicate with another. Or one could simply write an ARexx script to automate a process.

Here's an example of the first occasion I seriously used this, when producing a 3D anaglyphic animation for video: graphics frames - two images for left and right - were rendered in VistaPro (the original 3D landscape generator); as soon as rendering was complete, ImageFX (image processing software) picked up the output and combined the channels to make an anaglyph; this was then sent to the PAR animation recorder (a video recorder). So, THREE separate large packages from different software companies, working in synchrony with each other via ARexx. The whole operation worked so smoothly and efficiently, first time, that I still recall it with awe.

Sadly, yet another killer Amiga feature that never made it to modern computing...

Re: Do One Thing

#109

Post by pjmlp » Sat, Oct 31, 2015, 9:44 AM UTC

fractallyte wrote: post #108

pjmlp wrote: post #103

Unix pipes only work in the CLI with a text based interface and even then they break down when the applications aren't able to parse the data. So one always ends up massaging the data to make them be understood. Piping concept was actually more powerfull in Xerox PARC systems by using the respective language REPL and do LINQ style data transformations. However the problem of the article is that once you scale out of…

The Amiga ecosystem perfected this: most (good) software featured an ARexx 'port' - an API, based on the REXX language, that enabled any one program to communicate with another. Or one could simply write an ARexx script to automate a process. Here's an example of the first occasion I seriously used this, when producing a 3D anaglyphic animation for video: graphics frames - two images for left and right - were rendere…

The libraries concept used to extend the OS were another cool Amiga feature.

I would say the closest we have today to ARexx experience are Powershell and AppleScript.

Re: Do One Thing

#110

Post by chipsy » Sat, Oct 31, 2015, 9:47 AM UTC

astine wrote: post #16

On the 'do one thing and do it well' issue, there seem to be two spectrums: 1. suitability of a tool to multiple tasks 2. number of features a tool has This makes for sort of a field with four quadrants: 1. simple but flexible tools 2. complex and featureful tools 3. specialized but simple tools, 4. highly specialized and highly featureful tools So take a tool like grep and it clearly belongs in the first quadrant. Y…

I came up with a three-tier model myself:

   1. API or API-like things (grep)
   2. Highly configurable app (Photoshop, Word)
   3. Default-heavy app (Instagram)

The tricky thing is that 1 and 3 are the easy slices, relatively speaking. If you only need the 80% case, it can probably be automated into something as simple as a selfie app, with a finite, well-understood level of design and engineering. And if you need something extremely custom, you want the data model exploded into its smallest parts so that you can put it back together again - and the small parts can again be relatively simple, well documented, and easy to maintain.

But the middle part, the product that is complex and configurable, but not really "programmed" with code except through a limited script layer, is the fat middle, because it demands so much more UI, and an experience that is well-integrated, amenable to default workflows, and yet also very easy to customize. Over time, big software projects always drift towards the middle.

The article specifically fits my model's type 1. A type 1 product is nearly ideal for the hacker who wants to glue together a bunch of different technologies. It only falls down when the abstractions are too crude or mismatched to the problem. But the operating system itself is more like a type 2 product - there are numerous assumptions about what the environment, services, access methods, etc. look like, conventions that were established early on in computing and haven't yet been revised. Every programming language makes accommodations for working in that environment, and not your weird custom operating system.