| |||||||||||||
Five Pitfalls of Linux Sockets Programming (developerWorks)Five Pitfalls of Linux Sockets Programming (developerWorks)Posted Sep 21, 2005 1:13 UTC (Wed) by Zarathustra (guest, #26443)Parent article: Five Pitfalls of Linux Sockets Programming (developerWorks)
"Sockets are the X-Windows of IO interfaces." -- Rob Pike
(Log in to post comments)
Pike's presentation Posted Sep 21, 2005 10:19 UTC (Wed) by man_ls (subscriber, #15091) [Link] Very interesting presentation. I wonder why it is so often like this: the first solution to a problem wins, even if better ones emerge over time.
Five Pitfalls of Linux Sockets Programming (developerWorks) Posted Sep 21, 2005 11:21 UTC (Wed) by hppnq (guest, #14462) [Link] Those examples aren't very convincing, are they? I'll admit upfront that I have always been a big W. Richard Stevens fan, and I adore shared libraries.I must say I found this presentation very enlightening. I have tried diff'ing two PowerPoint files, and indeed, it produces utter rubbish! It also fails miserably at driving my coffeemachine and I daresay I'll be able to find more flaws in this miserable good-for-nothing tool, given time and inspiration. So it'll be Plan 9 for me from now on. I'll be so relieved when I can finally use regexps in Netscape. And in diff as well, I presume.
Tool approach Posted Sep 21, 2005 15:46 UTC (Wed) by man_ls (subscriber, #15091) [Link] I think you have missed the point, probably because you did not want to see it. Pike says:The tool approach teaches lessons other communities can learn from. Try to diff two PowerPoint docs.It is obviously not meant as a shortcoming of diff, but of PowerPoint: binary formats break diff, so they might provide a similar tool. Then you say: I'll be so relieved when I can finally use regexps in Netscape.I think the author is not requesting regexp search in Netscape because it is useful; he is pointing out that it is not possible to use regular expressions at all. With command line tools, you can usually pipe the output to egrep; graphical programs break this paradigm and some others in the process, and often do not replace it with alternatives. The result is a less powerful environment.
Tool approach Posted Sep 21, 2005 17:32 UTC (Wed) by hppnq (guest, #14462) [Link] Are you kidding me?! Your quote is preceded by this ominous remark:
As for the Netscape example: that's without a doubt one of the most hilarious paragraphs I have ever read in a Unix related paper. I'll quote it here in full, just for your amusement:
Then think about regular expressions: This, in fact, reaches a level of stupidity that makes it hard to believe Rob Pike wrote this.
Tool approach Posted Sep 21, 2005 19:34 UTC (Wed) by nix (subscriber, #2304) [Link] What's stupid about it? Monolithic GUI tools are profoundly non-Unixlike, and this is just one of many reasons why.
I think Pike has a pretty good idea of what the Unix philosophy is like, and what doesn't follow it. :)
Tool approach Posted Sep 21, 2005 20:41 UTC (Wed) by hppnq (guest, #14462) [Link] Yup, but that's not the point. Read the presentation!
Tool approach Posted Sep 22, 2005 0:39 UTC (Thu) by man_ls (subscriber, #15091) [Link] Your quote is preceded by this ominous remark: "What Unix does well isn't what people want" So pray tell me, what is the lesson to be learned from not being able to diff two PowerPoint files?!People actually use PowerPoint files, and maybe they would like at some point to find the difference between two such files. I know I have felt similar needs with. So Unix cannot find the difference between some binary files, which is what people want. So maybe the publisher of PowerPoint should provide a "diff" tool, or change the format (which is IMHO what Pike hints at); or we should not use such abominations. Then if you use e.g. SVG you can diff two files; but you have to know the format well to understand the diff, and people do not want to learn complex formats. As for the Netscape example: [...] This, in fact, reaches a level of stupidity that makes it hard to believe Rob Pike wrote this.Keep in mind that Pike is writing about "the good, the bad and the ugly". Regular expressions have good, bad and ugly points.
Tool approach Posted Sep 22, 2005 5:06 UTC (Thu) by hppnq (guest, #14462) [Link] So Unix cannot find the difference between some binary files, which is what people want. That pretty much sums it up, don't you see? First, "Unix" has nothing to do with it, "Unix" couldn't find anything if its life depended on it. In any case "Unix" was not conceived so it could find the differences between PowerPoint files (which is more or less what Pike is saying of course), but then why would one expect such functionality? Because diff is part of the Unix heritage?! Sure, people use and depend upon graphical interfaces more than they did in 1970. And of course traditional Unixisms like pipes tend not to interface well with GUIs. Anyone who is of the opinion, that, because of this, there is something wrong with Unix, must be quite short-sighted. Personally, I find it amazing that the same system that started out as a platform for grep and diff is now effortlessly running OpenOffice on PowerPoint files. And it seems to me that the Internet is living proof of the immense success of the sockets implementation on Unix systems, for that matter. Unix is exactly what I want. ;-)
Tool approach Posted Sep 22, 2005 6:18 UTC (Thu) by man_ls (subscriber, #15091) [Link] Yes, I think I see the same thing: the original ideas that were fit for a stream of characters (cat, diff, grep) are not that good for a world of graphical interfaces, complex hierarchical objects and roaming networking. Of course there is nothing wrong with the Unix heritage!But we do not agree on what follows from there: you say that Unix is exactly what you want. Pike seems to say that Unix might (even should) be extended to encompass this new world of ours. And why not?
Tool approach Posted Sep 22, 2005 7:54 UTC (Thu) by hppnq (guest, #14462) [Link] I think it eventually boils down to what development model one believes in. I happen to think that evolution is the way to go. Which almost inevitably leads to compromises when trying to make subsystems play together nicely, especially if they have no common heritage.The funny thing is, of course, that one of the more sensible remarks in the presentation is the observation that interfaces only work at some level and in some context. So I wouldn't draw the conclusion that there is something wrong with the Unix model, because dammit, I can't "cat homepage.html | netscape | sort". I happily accept this, because netscape's interfaces to me and to the world are optimized for the purpose of browsing, which is what I usually want when firing up a browser. By the way, there are plenty of examples where both networking and GUIs are interfaced with the more traditional Unix way of working, or one wouldn't be able to implement a webserver in Korn shell or use scripting languages like Tcl/Tk.
Tool approach Posted Sep 22, 2005 8:15 UTC (Thu) by man_ls (subscriber, #15091) [Link] I think it eventually boils down to what development model one believes in. I happen to think that evolution is the way to go.The world is clearly on your side, since we are all using Linux and very few people use Plan 9; I'm not planning to use Plan 9! But the inertia still amazes me.
Tool approach Posted Sep 22, 2005 7:53 UTC (Thu) by rqosa (subscriber, #24136) [Link] > Does your web browser's Find command use regexps? Yes, it does. (I'm using Konqueror.)
|
|||||||||||||