Earlier quoted context omitted.
BeOS is the silent master we can all learn from
IIRC it still looked very Unix'ish once you dropped into the shell.
It ran bash, sure, but BeOS was not similar to Unix at all.
The Unix-Haters Handbook (1994) [pdf]
151–160 of 163 posts
Re: The Unix-Haters Handbook (1994) [pdf]
#152Earlier quoted context omitted.
I really like the concept of Lisp, but just plain find it too hard to read. Part of the problem is that small-scale groupings too closely resemble large-scale groupings. In most production languages, "big blocks" are visually different than "small blocks" (or groupings). For example, in C, parameter statements are grouped within parenthesis. Large scale groupings are done with curly braces. This provides visual cues…
> This provides visual cues about scope and intention without first reading each token. There isn't even a token to read in C. You have to infer what it is by parsing the thing in your head. Well, our visual systems have no problems doing this. The C function definition doesn't have an operator which would help me to identify what it actually is. float square ( float x ) { float p ; p = x * x ; return ( p ) ; } Where…
C itself is not the pinnacle of programming languages in my opinion. JavaScript does require a "function" keyword (although it should be shortened to "func" in my opinion.)
It still stands that "}" indicates larger-scale structures than ")" in C-like languages. Lisp has nothing equivalent, and I find a visual way to identify forests versus trees without first reading text is quite helpful. Your eyes may vary; everyone's head works differently.
But as evidence people agree with me, lisp had roughly 60 years to try to catch on as mainstream. It didn't. Nothing had more opportunities. If you don't win any beauty contests after 60 years, it's time to admit you are probably ugly to the average judge.
Re: The Unix-Haters Handbook (1994) [pdf]
#153Earlier quoted context omitted.
> This provides visual cues about scope and intention without first reading each token. There isn't even a token to read in C. You have to infer what it is by parsing the thing in your head. Well, our visual systems have no problems doing this. The C function definition doesn't have an operator which would help me to identify what it actually is. float square ( float x ) { float p ; p = x * x ; return ( p ) ; } Where…
C itself is not the pinnacle of programming languages in my opinion. JavaScript does require a "function" keyword (although it should be shortened to "func" in my opinion.) It still stands that "}" indicates larger-scale structures than ")" in C-like languages. Lisp has nothing equivalent, and I find a visual way to identify forests versus trees without first reading text is quite helpful. Your eyes may vary; everyon…
[deleted]
Re: The Unix-Haters Handbook (1994) [pdf]
#154Earlier quoted context omitted.
> This provides visual cues about scope and intention without first reading each token. There isn't even a token to read in C. You have to infer what it is by parsing the thing in your head. Well, our visual systems have no problems doing this. The C function definition doesn't have an operator which would help me to identify what it actually is. float square ( float x ) { float p ; p = x * x ; return ( p ) ; } Where…
C itself is not the pinnacle of programming languages in my opinion. JavaScript does require a "function" keyword (although it should be shortened to "func" in my opinion.) It still stands that "}" indicates larger-scale structures than ")" in C-like languages. Lisp has nothing equivalent, and I find a visual way to identify forests versus trees without first reading text is quite helpful. Your eyes may vary; everyon…
> Lisp has nothing equivalent
prog, let, defun all indicate block structures.
> Your eyes may vary; everyone's head works differently
No, it's just training. You are just unfamiliar with Lisp code. After a few days training, you should have little problem reading Lisp code. It's like bicycle riding: people can't believe that it is possible to balance it, but after a few lessons it's no problem.
That's an old saying:
'Anyone could learn Lisp in one day, except that if they already knew Fortran, it would take three days.' (Marvin Minsky)
Re: The Unix-Haters Handbook (1994) [pdf]
#155Re: The Unix-Haters Handbook (1994) [pdf]
#156Earlier quoted context omitted.
Well in some cases it was because conventional hardware caught up. When I arrived at my first job in 1998 we were using Symbolics Lisp machines. Two years later we were using TI microexplorer Lisp cards that were hosted in a Mac IIFx (something like [0]). When I left, two years after that, we were running Procyon Common Lisp on the IIFx itself, with no Lisp co-processor. The old Symbolics machine was booted up occasi…
Lots of people used Macintosh Common Lisp on Macintosh IIFX machines and later. The 68030 in the FX also enabled a better garbage collector for MCL.
We used Procyon Common Lisp because it was very nicely integrated with the Macintosh - especially for graphics - and had a great CLOS implementation. I used it to reimplement a clunky VAX-based FORTRAN modelling environment that had been developed in-house into a smooth Macintosh app with a graphical node-graph editor. In all of the system development I've done, this had the biggest 'awesome gosh wow' reaction I've ever received from the users.
Re: The Unix-Haters Handbook (1994) [pdf]
#157Earlier quoted context omitted.
Lots of people used Macintosh Common Lisp on Macintosh IIFX machines and later. The 68030 in the FX also enabled a better garbage collector for MCL.
We used Procyon Common Lisp because it was very nicely integrated with the Macintosh - especially for graphics - and had a great CLOS implementation. I used it to reimplement a clunky VAX-based FORTRAN modelling environment that had been developed in-house into a smooth Macintosh app with a graphical node-graph editor. In all of the system development I've done, this had the biggest 'awesome gosh wow' reaction I've e…
I have used it, too - but not for long. Usually I thought MCL then was better - Apple also bought it and then released it via their developer channel.
Unfortunately Procyon Common Lisp was taken off the market, when it was bought by Franz, Inc. They used the Windows version of Procyon CL as kind of a starting point for their Windows offering of Allegro CL, IIRC.
Re: The Unix-Haters Handbook (1994) [pdf]
#158Earlier quoted context omitted.
IIRC it still looked very Unix'ish once you dropped into the shell.
It ran bash, sure, but BeOS was not similar to Unix at all.
It had the coreutils, glibc, it used UNIX filemodes and the fork() process model, "/dev", etc. So, how exactly was it not a UNIX?
Re: The Unix-Haters Handbook (1994) [pdf]
#159Earlier quoted context omitted.
It ran bash, sure, but BeOS was not similar to Unix at all.
It had the coreutils, glibc, it used UNIX filemodes and the fork() process model, "/dev", etc. So, how exactly was it not a UNIX?
Ever try to port a POSIX utility to BeOS? I did. No mmap and no BSD sockets killed any chance of easily porting any network utility to BeOS. It had a directory called /dev, yes, but it was absolutely nothing like /dev on any Unix system; it's all home grown. No permissions; it's a single-user system. It stores file owners and modes, yes, but they don't actually mean anything; you don't need the +x bit to execute a file, you don't need the +x bit to list a directory, everything is owned by "baron", etc. It supported fork but it's incompatible with threads, and everything on BeOS is threaded. Some signals are implemented, but the C API is home grown instead of the standard POSIX calls. Etc. They built a Unix facade but the system is very un-Unix like.
If it were really Unix, they probably would not have needed to write a whole book on porting Unix applications: https://www.amazon.com/BeOS-Applications-Martin-C-Brown/dp/1...
Re: The Unix-Haters Handbook (1994) [pdf]
#160Earlier quoted context omitted.
C itself is not the pinnacle of programming languages in my opinion. JavaScript does require a "function" keyword (although it should be shortened to "func" in my opinion.) It still stands that "}" indicates larger-scale structures than ")" in C-like languages. Lisp has nothing equivalent, and I find a visual way to identify forests versus trees without first reading text is quite helpful. Your eyes may vary; everyon…
> Lisp has nothing equivalent prog, let, defun all indicate block structures. > Your eyes may vary; everyone's head works differently No, it's just training. You are just unfamiliar with Lisp code. After a few days training, you should have little problem reading Lisp code. It's like bicycle riding: people can't believe that it is possible to balance it, but after a few lessons it's no problem. That's an old saying:…
I tried to get used to it, I couldn't.