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

Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"

doc.cat-v.org

Post reply on HN
Print view View original

81–90 of 112 posts

Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"

#81

Post by xtractinator »

buster wrote: post #46

I guess one can say that 25 years later this has been shown as (partly) wrong. I don't think Powershell really solves a problem, it's too complex to work with for the majority of problems. If i want complex data handling i write a script and put #!/usr/bin/env {bash,python,perl} in the first line. I think the missing point here is that the nice, line-based, really simple approach is that this is how we speak and writ…

I'm weary of using structured data, that is data that is structured in such a way that you don't need to understand what it's passing around. Keeping it simple means that the developer will always know exactly what data is being passed around.

This is important for a lot of reasons not all of them are related to only development as a job.

Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"

#82

Post by xtractinator »

nnnnni wrote: post #79
its_so_on wrote: post #41

Earlier quoted context omitted.

I like your observation but I don't like your conclusion. I think the major thing missing from the world is easy piping a la Unix. You can't pipe your list of paying customer's email addresses to paypal at the command line with some switches - really, no matter how many switches you use - and bill each one the amount stated, because "paypal" is not a commandline app. You can't pipe the results of some long-running an…

http://www.floodgap.com/software/ttytter/ http://mike.verdone.ca/twitter/ https://launchpad.net/twitter-cmdline/ http://ruby-paypal.rubyforge.org/ http://oreilly.com/pub/h/2222 Apparently twitter and paypal ARE commandline programs!

No, they have command line interfaces.

Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"

#83

Post by jejones3141 »

ori_b wrote: post #63
e12e wrote: post #57

Earlier quoted context omitted.

First thing I checked for too. Second thing I looked for was someone pointing out that this is asking for object oriented systems (such as Smalltalk or Self). But the third thing, no one mentioned: SNOBOL. Reportedly (because I haven't used it myself) it is better than AWK for complex matching.

I played with SNOBOL. It may have a more powerful matching engine, but power doesn't equate to usability. Having each line followed by 3 gotos does not good UX make.

Icon or its descendant Unicon might be worth a look, then.

Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"

#84

Post by adbge »

luriel wrote: post #22
gits1225 wrote: post #10

Earlier quoted context omitted.

offtopic: sam(and acme) sounds like an interesting method at first, but when you try it out, its really weird and slow to get stuff done. Its because for me, mouse is really inferior to keyboard to do the majority of the tasks. This is an except from coders at work: Seibel: Is there anything you would have done differently about learning to program? Do you have any regrets about the sort of path you took or do you wi…

Acme mouse chording is really cool, doing something similar with keyboard-oriented editors is much more tedious and often outright painful ( http://acme.cat-v.org/mouse ). I suspect ken spends most of his time thinking rather than typing, and I have found this to be true of most great hackers. Other famous Sam users include Brian Kernighan, Bjarne Stroustrup(!) and Tom Duff. Kernighan writes at least as much English…

    > I suspect ken spends most of his time thinking rather than
    > typing, and I have found this to be true of most great 
    > hackers.
Who cares? Slow input is still not a desirable property in a text editor.

Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"

#85

Post by ori_b »

jejones3141 wrote: post #83
ori_b wrote: post #63

Earlier quoted context omitted.

I played with SNOBOL. It may have a more powerful matching engine, but power doesn't equate to usability. Having each line followed by 3 gotos does not good UX make.

Icon or its descendant Unicon might be worth a look, then.

Maybe. I don't think I've ever really been constrained by the power of Awk's pattern matching. I wish I could do it recursively, but that's not so much a power issue as a composability issue.

Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"

#86

Post by mattdeboard »

Arelius wrote: post #74
haberman wrote: post #47

Earlier quoted context omitted.

> The direction you're suggesting we take things is, in fact, a fuller API. Nothing about my proposal has anything to do with an API. I'm just proposing a structured stream of data instead of an unstructured one. > They're slower and worse. I am proposing avoiding a serialize/parse step between every pair of pipeline elements (or using a more structured/optimized format if a serialization step is desired). Doing less…

> I'm just proposing a structured stream of data instead of an unstructured one. That's basically what an API is.

You are confusing the "how" (the API specification) with the "what" (the data the API exists to provide access to).

Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"

#87

Post by oh_sigh »

haberman wrote: post #28

The real problem is that Unix commands produce flat text output without any information about how to parse that text back into structured data. Any user who wants the structured version of the data has to parse it themselves, but these parsers are ad hoc and incomplete by their very nature. People praise perl, sed, awk, cut, etc. for being good at text processing. But the only reason they need these text-processing t…

find . -depth 1 -type 'f' -size +1M

Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"

#88

Post by Evbn »

akkartik wrote: post #76
haberman wrote: post #69

Earlier quoted context omitted.

When I talk about a "representation," I mean an in-memory format. For example, the "representation" of an HTML tree is the DOM. Yes, you have to agree on a serialization format (JSON, Protocol Buffers, etc), but that's not the same thing. From a serialization format you can represent the data however you see fit in your process. For example, a C++ user might represent a string as a std::string object whereas a Python…

Just a nit: I think protocol buffers include representations, not just serialization formats. You need to have the schema of the proto to parse it correctly, know which fields are required, repeated, etc. Am I understanding you correctly?

Schema isn't representation the way haberman is using it. He means something like implementation, which protobuf has in many languages in various VMs and can be easily ported to more.

Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"

#89

Post by Evbn »

pwpwp wrote: post #70
haberman wrote: post #28

The real problem is that Unix commands produce flat text output without any information about how to parse that text back into structured data. Any user who wants the structured version of the data has to parse it themselves, but these parsers are ad hoc and incomplete by their very nature. People praise perl, sed, awk, cut, etc. for being good at text processing. But the only reason they need these text-processing t…

Problem with PBs is that the receiver needs a schema to parse. JSON or S-expressions obviate that need.

Sender can send the schema, which it obviously has.

Re: Rob Pike: "Current Unix tools are weakened by the built-in concept of a line"

#90

Post by Evbn »

stcredzero wrote: post #38
anvandare wrote: post #33

Earlier quoted context omitted.

Actually I've been considering/dreaming about a thing like this for a long while now (ever since I got started with jQuery and discovered how smooth I could sail through the DOM with it). The idea I came up with (I'm most likely not the first to think of it, so tell me if someone already implemented it) is a sort of JavaScript shell for *nix that'd work similar to jQuery: passing along (collections of) JavaScript obj…

Or, one could write a library of standard parsers and serializers for the Unix tools that would parse and produce known JSON representations of data that could be passed between scripts.

That's recordstream
Post reply on HN