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

The Unix-Haters Handbook (1994) [pdf]

web.mit.edu

Post reply on HN
Print view View original

241–250 of 316 posts

Re: The Unix-Haters Handbook (1994) [pdf]

#241

Post by dahart »

jackhammons wrote: post #219
dahart wrote: post #105

Earlier quoted context omitted.

Ha! I switched to Mac so I could have pipes, grep and bash. I personally believe a big reason for the Mac resurgence has to do with the switch to UNIX. I was on Windows using Cygwin for years before anyone I knew was using a Mac. Then OSX came out, and all of a sudden all the academics I knew switched to Mac, and a couple years later most of the professional programmers I knew had switched. The great thing about a Ma…

Have you tried the Windows Subsystem for Linux?

I haven't tried it yet, but I am looking forward to it.

Re: The Unix-Haters Handbook (1994) [pdf]

#242

Post by mustacheemperor »

problems wrote: post #119
pjmlp wrote: post #112

Earlier quoted context omitted.

> How does one use a Mac without grep or piping? Using Finder, XCode, Objective-C and Swift frameworks,...

Bluh, don't get me started on Finder. Icons in directories would randomly be overlapping just because I hadn't been in them in a while and new files were added, they added this weird tagging system with colors that just doesn't make sense to me at all, it randomly thinks I want to view some sort of "recently used files and some random shit" list instead of my homedir. I don't know what the devs of it were thinking. E…

Finder is absolutely boggling to me. I've considered switching to Mac as a mobile development platform a few times, but every time I sit down to actually USE one I realize I'd rather just put Ubuntu on a windows laptop or something.

>I don't know why people seem to think Apple is some sort of UI god when they can't even make a usable file manager.

I know! I ask myself how this is possible every time.

Re: The Unix-Haters Handbook (1994) [pdf]

#243

Post by dualogy »

dsmithatx wrote: post #73

When I read this 20 years ago I would never have believed I'd be typing this on a Mac laptop running yet another Unix variant. This line is now so funny... As for me? I switched to the Mac. No more grep, no more piping, no more SED scripts. Just a simple, elegant life: “Your application has unexpectedly quit due to error number –1. OK?”

> No more grep, no more piping, no more SED scripts

Fedora/Gnome here. I never use this sort of stuff, and modern power users really don't have to. That's why I categorically state that practically no-one in the real world "uses Unix", even though most OS-es incl mainstream mobile ones derive directly or indirectly from it, save for Windows and esoteric ones.

Do I enjoy modern Linux? Heck yeah. Do I want to use Unix? Piping and grepping and cat'ing and touch'ing and so forth? It's not rocket science but it's also a doggerel not smooth UX for me, and "not smooth" means not productive.

If I need to compose functionality for "shell"-based task automation, I whip up a small Go program. Portable across OSes should I ever move, bin dir is in PATH, compiles fast enough to not need script interpreter for iterating the "script" (tool) at hand, and the syntax and semantics are saner to me than sh scripts, aka no impedance mismatch vs other coding tasks.

(Sure enough though, for one-offs "search these for that" while already in the bash/etc, the built-in old-school tools still come in handy occasionally)

Re: The Unix-Haters Handbook (1994) [pdf]

#245

Post by dahart »

derefr wrote: post #234
dahart wrote: post #187

Earlier quoted context omitted.

The finder is a wart. Apple does have a lot of good UI elsewhere, but the finder needs an overhaul so bad it hurts. Know what drives me the most nuts? That there's a single default key (Enter) to rename a folder, while you have to use a key chord (Command-O) to enter a folder. It's so backwards, renaming is not something I spend even remotely as much time doing as moving around. That's not to mention the so completel…

> (Command-O) to enter a folder. I use Command+Down, which opens Finder shell-objects generally. It's the "descend" to Command+Up's "ascend."

Not sure why I haven't been using that, but that is better than Command+O for sure, thanks!

Still, all navigating should be single-key-able, right? I guess it is technically, with left & right arrow keys in the List & Columns views, but I don't use those or like those as much, for whatever reason.

Re: The Unix-Haters Handbook (1994) [pdf]

#246

Post by DonHopkins »

mcguire wrote: post #139
zeptomu wrote: post #67

Earlier quoted context omitted.

> Most applications uses opengl these days. Now 'most' is a relative term, but I do not think that's true at all. There are very few applications that use OpenGL. Obviously games are an exception, but if you count in all GUIs I would say mostly target X11 (via Gnome or KDE).

Chrome (and I guess most web browsers) do. Stupid, stupid Nvidia drivers...

And that's basically the only application that counts any more these days.

Re: The Unix-Haters Handbook (1994) [pdf]

#247

Post by [deleted] »

mcguire wrote: post #139
zeptomu wrote: post #67

Earlier quoted context omitted.

> Most applications uses opengl these days. Now 'most' is a relative term, but I do not think that's true at all. There are very few applications that use OpenGL. Obviously games are an exception, but if you count in all GUIs I would say mostly target X11 (via Gnome or KDE).

Chrome (and I guess most web browsers) do. Stupid, stupid Nvidia drivers...

[deleted]

Re: The Unix-Haters Handbook (1994) [pdf]

#248

Post by DonHopkins »

ajross wrote: post #125
tonyedgecombe wrote: post #116

Earlier quoted context omitted.

Win32 with function signatures that look like this: HWND WINAPI CreateWindowEx( _In_ DWORD dwExStyle, _In_opt_ LPCTSTR lpClassName, _In_opt_ LPCTSTR lpWindowName, _In_ DWORD dwStyle, _In_ int x, _In_ int y, _In_ int nWidth, _In_ int nHeight, _In_opt_ HWND hWndParent, _In_opt_ HMENU hMenu, _In_opt_ HINSTANCE hInstance, _In_opt_ LPVOID lpParam ); The only redeeming feature is the documentation.

Yeah, I don't understand the grandparent on that. The Xt API (and the Athena widget set) were hardly a great work of computer science. But they were relatively clean and easy to understand, and basically invented the "widget" (rectangle on the screen that can draw itself and respond to input in an encapsulated way) component model that we're all still thinking in today.

I wouldn't say Xt invented the "widget", and I would never pass up the opportunity to state most emphatically that Xt widgets are neither clean nor easy to understand.

Here's a video tape by Brad Myers called "All the Widgets" [1] that shows demos of widgets from way back, many of them long before Xt. (Over 175 segments, from 30 systems, from 15 companies!)

[1] https://www.youtube.com/watch?v=9qtd8Hc90Hw

All the Widgets, by Brad Myers. This was made in 1990, sponsored by the ACM CHI 1990 conference, to tell the history of widgets up until then. Previously published as: Brad A. Myers. All the Widgets. 2 hour, 15 min videotape. Technical Video Program of the SIGCHI'90 conference, Seattle, WA. April 1-4, 1990. SIGGRAPH Video Review, Issue 57. ISBN 0-89791-930-0.

What kicked Xt's and Motif's ass, especially in terms of power and flexibility, as well as being clean and easy to understand, was TCL/Tk.

The reason TCL/Tk was so successful in spite of how lame TCL was as an scripting language, is that TCL was there from day one of Tk's design, not an afterthought.

As a result, there was no need for Tk to invent a bunch of half-assed kludges, and require applications to build complex Rube Goldberg devices on top of those, when Tk could simply call into TCL to do anything the scripting language interpreter could handle, including calling into the application's C code from TCL.

So there was zero overlap between what the scripting language could do, and what the toolkit needed to do. And that made the toolkit vastly simpler and more consistent, and much easier to flexibly program and modify.

Xt based toolkits like Motif [2] had to built on top of all that half assed pseudo-object-oriented crap trying to reimplement programming language level concepts like objects, components, properties, defaults, inheritance, events, handlers, delegation, layout, etc, in brittle C and macros.

[2] http://www.art.net/~hopkins/Don/unix-haters/x-windows/motif....

Motif was yet another proof of Greenspun's tenth rule of programming [3]: Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

[3] https://en.wikipedia.org/wiki/Greenspun's_tenth_rule

So just start with Common Lisp, or at least something in the ballpark like TCL, PostScript, JavaScript, Lua, etc.

Re: The Unix-Haters Handbook (1994) [pdf]

#250

Post by vram22 »

seanp2k2 wrote: post #194
dahart wrote: post #182

Earlier quoted context omitted.

> Objective-C looks like a clusterfuck and I never want to touch it. This is pretty much moot now, the Apple world is abandoning Obj-C, but AFAIK it's just old, not bad. Like, came out at the same time as C++ old, and has seen fewer changes to the language than C++ has. It's a compiled, C-like language, so yeah, hard to use and very easy to crash, just like C & C++. Interested to hear your point of view on what makes…

I remember trying to do the "construct a function name as a string and call it" thing in VB6 many years ago before I "knew better". Any idea what that functionality is called? I always wondered why languages wouldn't let you do that.

>I remember trying to do the "construct a function name as a string and call it" thing in VB6 many years ago before I "knew better". Any idea what that functionality is called?

It's called by various names - not sure if there is an official one - such as dispatch tables, jump tables, dynamic dispatch, etc. It's a pretty old technique, I would say it probably dates from the time of early high-level languages, and I seem to remember that it was used in assembly languages too (so probably even earlier), by using various addressing modes (indexed, indirect indexed, etc. (those terms are from long-forgotten 6502 instruction set BTW), storing the address of a function at a location and then jumping to that address (where the address is dynamically set at run time by some other bit of code based on some condition), etc.

Here is a simple example in Python:

Simulating the C switch statement in Python:

https://jugad2.blogspot.in/2016/12/simulating-c-switch-state...

Edit: Googled and got a couple of relevant links:

https://en.wikipedia.org/wiki/Dispatch_table

https://en.wikipedia.org/wiki/Branch_table

Post reply on HN