Lambda the Ultimate

And it's not enough to abstract the hardware to build a relatively simple software system, because you have to support numerous extremely complex web technologies (HTML, Flash, ...) if you want to build a useable OS.

It's UNIX with Eclipse / IntelliJ to interface with the mediocre.

I see you are a new member. The atmosphere at LtU is normally non-condescending and tries to avoid insulting comments like the above.

I started out as an Emacs user, then used modern IDEs like Eclipse, and have recently been using Emacs to learn Lisp/Haskell/Oz/Isabelle. Emacs just feels clunky and outdated.

Obviously I meant it on a whimsical note, I had no idea someone would be so easily offended. If anything, being new, I have problems ascertaining temperament.

In short - Jeff, I don't think you're mediocre :-)

It strikes me as elitist. Many Lispers take this view, with Paul Graham leading the charge. My problem with people like him is that they are too evangelical, and take a single-minded view with Lisp at the center. So comments like "mediocre" are not innocent.

I'm not really enamored to any particular language/tool. They all have their strengths & weaknesses.

My problem with people like him is that they are too evangelical...

Maybe that's because they've found something that was very liberating and they want others to experience the same feeling?

That said, I agree with your sentiments. I've never really understood why people consider Java/C# to be "languages for the masses" or "languages for the mediocre" and Lisp/Scheme to be "languages for the elite." Scheme and Common Lisp are arguably much simpler than C#. In fact, when I first learned Lisp, my first thought was "This is so simple, you don't even have to hardly think about how to write a solution: you just write down what your thinking." When I program in Common Lisp and especially Scheme I rarely have to think about syntax, instead I focus on the problem at hand; this makes my life simpler: I just do it. (Side note: there are some features of Common Lisp I really like, but some need to removed: Scheme code always feels so much more simple and elegant to me.) C#, however, is a different story. When I code in C#, I am always concerned with two things: syntax, and how to convert the problem from a natural (for me) solution in to one that C# will understand (since Scheme and especially Common Lisp support multiple ways of thinking problems can generally be expressed close to their "natural" form in these languages). In fact, C# is so complicated that I wouldn't even think about writing a program without Visual Studio: doing so is pretty much impossible. Now granted with Visual Studio, C# is a fairly simple language but, my question is: how much simpler and more productive could languages like Scheme and Common Lisp be in a similar environment? (Dr. Scheme is a really cool Scheme environment that is fairly powerful.) The major problem with Scheme and Common Lisp (and many languages with non-imperative features/ideas) is the learning curve. Once you get past the fundamental ideas (functions as first class objects, the parenthesis, functional programming style, etc.) it's easy, and you’ll find yourself thinking in that mode, at which point you find yourself able to just write down the solution much easier than you could with a more syntax bound language). Until then, you might find the language difficult if you've trained yourself in a different paradigm.

As far as I'm concerned, no programming language is worth using unless it has an IDE. It doesn't have to be as complex as Visual Studio, but it needs a basic code editor and debugger.

I remember trying to learn assembly in the old compile and pray method. Trying to figure out what was actually happening at runtime was nearly impossible. Later I retook the class using MASM (think DOS edit with a machine-level debugger) and everything made sense. The difference was incomparable.

Now I am not saying you need to have a mono-theistic one-true IDE like Visual Basic, but at least throw me a bone. Give me something to help me understand exactly what the program is doing.

This is especially true with languages like LISP. I had a lot of difficulty learning this language because I never knew what was in memory or what order things were being performed in.

By there way, is there any IDE for LISP with a decent editor and debugger? The last time I used it all I had was a command-line interface.

By there way, is there any IDE for LISP with a decent editor and debugger? The last time I used it all I had was a command-line interface.

Depending on the definition of Lisp you're interested in, try DrScheme.

"no programming language is worth using unless it has an IDE"

That's odd, since language designers are designing a language, not tools to deal with it. Is a command-line interpreter and a text editor ok to you as an IDE? (loop edit compile run)...

I do believe that even a basic IDE improves productivity. Consider the most primitive IDE, which is just a LISP or Python REPL loop. Though it doesn't allow for stepping through code, you can at least get memory dumps after each command. And that gives you the ability to determine if your command did what you expected it to.

That's odd, since language designers are designing a language, not tools to deal with it. Is a command-line interpreter and a text editor ok to you as an IDE? (loop edit compile run)...

No. It needs at least a way to step through the code and display what is in memory.

I realize that, in the initial stages, language designers need to focus on the language and not the tools. But at some point they need to put the effort in to polish the tools if they expect people like me to consider using them for any serious work.

As for me, I have no idea on how to debug code in language which does not provide a decent REPL. The level of introspection available with visual studio-style debuggers is simply unacceptable.

You know the Myst games also run on Mac?

My main "axe" of choice is a low-end Apple iBook running OS X. I also have a Win XP/Mandrake Linux box at university which only ever boots Windows to view password-protected Excel files I'm sometimes sent — can OpenOffice handle these yet? Oh, it was also booted to play Façade (for research purposes!). I use the Ion non-overlapping window manager on the Linux box which is really nice, and has given me an incentive to learn some Lua. Most of the apps I actually use are cross-platform, so I have a pretty similar set-up on all 3 OSs.

Home: WinXP for games; Ubuntu for everything else. Work: WinXP with Visual Studio 2005.

For those who enjoy that sort of thing. (Like me. :)

It just works too... :)

The OS focus plus the analysis paralysis of Francois, etc., really did kill the TUNES project, years before I got involved. There was also a good measure of libertarian politics plus the stubborn unwillingness of the OS fanatics who joined to learn even the least interesting high-level languages (e.g. Lisp).

It's only me working on Slate right now, plus many intermittent volunteers. Slate just puts together Lisp and Smalltalk ideas, and hopefully Erlang and E soon. It's also a scripting language with its own environment. The GUI is finally coming together, with a lot of ideas behind that. If I can manage to get most of the good ideas from the "dynamic" / "living" language community together in one place, and keep it flexible enough that people who don't "get" that paradigm won't be bothered by it, then I'll consider it a success.

I don't think it's worth making a better OS until this hodge-podge of better-language islands decides to compromise to work together - without a conception of a truly better environment that is economically easy to get to, systems code is just a curious artifact. But I haven't been able to approach this issue until lately, due to health problems. Chances are that Microsoft Research projects will go farther than anything else that's been envisioned, simply by being funded (and there is the effect of Microsoft/Sun educational donations having dried up the attention/funds to systems programming research).

"shells may be powerful, but they don't hold a candle to MS-Dos for ease of use."

yes, certainly it's far easier to fully type commands and filenames rather than rely on tab completion.

"Even simple things like changing the environmental variables is hard"

like "set foo=2" (DOS) vs "foo=2" (bash)?

"The same can be said when comparing DOS edit to emacs or vi."

yeah, sure anything with drop down menus is far easier on novice. Except when you have to make the same change over and over and wish the editor had keyboard macros or when navigating large blocks of text with nothing more than pageup/pagedwn and wishing for marks...

its definately easy to get in, and to get out once you know something more powerful.

"If the average user cannot figure out how to use a feature, that feature doesn't exist for the average user. Thus for the average user, Unix has less features than a typewriter without a backspace key."

the average user is average for a reason.

Now that's trolling at its finest. When done poorly (or done to be disruptive), trolls are the bane of any Internet (or offline) community, and deserve to be exiled forthwith.

But when done properly (and sparingly), a well-executed troll is a thing of beauty.

I wonder how many indignant replies you'll receive... so far, one such reply has been posted. :)

I wasn't joking, trolling, or playing any other games. I was dead serious.

like "set foo=2" (DOS) vs "foo=2" (bash)?

Explanations like that are useless to me, because the poster didn't first tell me how to determine if I was using bash. Nor did the poster tell me what the syntax would be for a non-bash shell.

An aside, how would I find that information? The man pages assume that you already know the name of the command you want to use, and some (i.e. this example) don’t even really have a name. With Windows, I can at least to type Help to see a list of common commands.

As for vi and emacs, why don't they have the same capabilities as DOS edit?

This is a real issue many facing many products. Why did the developers spend so much time of the advanced stuff, while neglecting the basics that would have made them accessible to the majority of users? I can see no reason why vi or emacs cannot have the same features as DOS edit in addition to their advanced capabilities.

"If the average user cannot figure out how to use a feature, that feature doesn't exist for the average user. Thus for the average user, Unix has less features than a typewriter without a backspace key."

the average user is average for a reason.

I find this sort of attitude to be very juvenile and unprofessional. Average implies 50%; if 50% of my target audience finds that my program is too hard to use, then I did something seriously wrong.

Operating systems like UNIX and Linux don’t have chance in the general marketplace because the developers are too lazy to make their programs easy to use. Ease of use is a hard problem, and frankly not very interesting, so I understand why it is often neglected. But for professionals, that is not a valid reason for not doing the right thing. They are getting better, but the command line interface still needs a complete overhaul before the average user can touch it.

But for professionals, that is not a valid reason for not doing the right thing.

Ah, when it comes to the Right Thing, I don't think you'll find that in Unix. Although, it is getting better. Unfortunately, I don't think you'll find that design philosophy in any popular OS. Again, they are getting better, but we've still got a long way to go.

And with that, I do have to say, I would be fun to play with one of the systems that have that design philosophy. The Lisp Machines, and a Smalltalk OS are one's I've heard about. Squeak is pretty cool---albeit kind of "Fisher Price." It would be interesting to work on a system like that that ran "on the metal."

I'll treat your comment seriously.

Is it possible, that DOS (or whatever the Windows command shell is called these days) seems more familiar to you, because you're familiar with it?

Confusing familiarity with ease of use is a common error; the only fair comparison is when one considers a user who is unfamiliar with all systems under consideration.

Neither command shell is all that usable to those without some training. If I'm a newbie user, I wouldn't know that to get a directory on Windows I type "dir"; nor would I know to type "ls" on a Unix machine. I'll give MS points for having documentation available at "help" (as opposed to "man" or "apropos", neither of which is particularly intuitive). I'll also give MS points for a sort option to dir (in Unix one pipes the output of ls to sort, if one wants a sort order other than the ls default). But the Windows command shell, overall, doesn't strike me as particularly more novice-friendly than the Unix variety--command shells, by their nature, are poor interfaces for neophytes to access the computer with.

Regarding the emacs/vi question: What is it you desire? Both can do far more than dos edit; perhaps what you want is an editor which a neophyte can use without having to know a ton of commands to enter insert mode, or such. Such an editor exists on most Unix systems, it's called pico.

Regarding the chance of Unix/Linux systems in the marketplace--they're doing very well, last I checked. MS is still the dominant desktop player--especially in the home--but many office desktops now have penguins inside them. Making pronouncements which contain language like "never" is almost always premature hubris--just ask IBM.

I'll also give MS points for a sort option to dir (in Unix one pipes the output of ls to sort, if one wants a sort order other than the ls default).

Running ls --help|grep sort reveals quite a few options for sorting the output. I quite regularly use -St, myself.

One thing I learned about *nixes when migrating from the DOS/Win world is that they usually provide at least four ways to do the thing you thought they couldn't do, plus at least one alternative approach that makes the approach you were looking for seem obsolete.

But we are straying off-topic...

I'll give MS points for having documentation available at "help" (as opposed to "man" or "apropos", neither of which is particularly intuitive).

Actually, typing help at the prompt for the default shell (bash) on both my Mac and my (Red Hat) Linux box produces this friendly message

These shell commands are defined internally.  Type `help' to see this list.
Type `help name' to find out more about the function `name'.
Use `info bash' to find out more about the shell in general.
Use `man -k' or `info' to find out more about commands not in this list.

followed by a list of the bash internal commands. Granted, the bash internal commands aren't necessarily all that helpful, but the message also points me at man -k, which is useful, since it's apropos under another name.

If you don't want that power (or the associated documentation), then by all means use something other than UNIX.

Again, that is the kind of attitude I find to be very detrimental. I don’t think I am alone in wanting programs that are both intuitive enough to use with minimal documentation and yet still have well documented advanced features for the people who need them. There is no reason why I cannot have both.

In regards to the audience, a text editor is one of the core utilities in any operating system that every person has to use on a regular basis. Therefore, any text editor should be usable by every person.

As for my comment about the “marketplace”, I am referring to the kind of stores in which the average person buys software. I don’t write software for computer scientists and network administrators, I write software for laymen who need to accomplish something.

Again, that is the kind of attitude I find to be very detrimental.

There are lots of cases where the more powerful choice is the more difficult to learn. A manual transmission gives you more power (because it gives you more control) than an automatic. Thats not a bad thing, its just different.

In computing, a program (or programming language---the off topic thread comes full circle and is now on topic for LTU!) is powerful when it lets you do what you need to do, but that requires learning how to use the program. Sure, given two equally powerful programs it is perfectly reasonable that one might be easier to use than the other (in which case the easier one might be the better choice). To be so easy that a person could use it without having to learn a whole system, requires that the program do what you desire of it for you. That requires the program to know what you want. Unfortunately, it is very difficult (I argue impossible) to foresee every possible use of a particular program, hence that program will be less powerful than one that gives you more power via what is essentially a DSL (even if it is a graphical one).

In regards to the audience, a text editor is one of the core utilities in any operating system that every person has to use on a regular basis.

Yes.

Therefore, any text editor should be usable by every person.

No.

I agree that there should be a text editor on the system usable by every person, but not that every text editor be usable by every person. Earlier you were complaining about vi and emacs. Now, if those were the only options, you might have a point, but their not. Most UNIX systems have alternatives to vi and emacs, for example: cat and ed (I kid! I kid!). Seriously, there are more user friendly alternatives out there besides vi and emacs. Personally, for quick and dirty editing, I like to use vim. (I'm an oxymoron: I like vim better than emacs, and I like Lisp too!) Now, most people who know how to use vim and emacs can tell you that they are more powerful than a plain old text editor. To make them usable by every person would require that most of that power be taken away. For example, one of my favorite things about vim is its easy navigation and editing commands (hjkl for moving around, p for paste, etc.). I like these commands much better than the ctrl-this ctrl-that of some editors (ehem...emacs) and the mouse driven commands of other editors. Now, in order for this to work properly, vim has to have different modes of operations. At this point we've gone past the point of usability of the average user. But you take away the modes to make it usable by the average user, and you take away one of the most powerful features of vim.

Earlier it was stated that the average user is average for a reason. This is true, but not in the sense you might think. Its not me being arrogant or anything. The average user isn't stupid. They are more than intelligent enough to learn vim. Its just that they are uninterested. They are mentally lazy. They don't want to learn how to use a program, they just want to use it.

I'll tell you a secret, okay? I didn't learn how to drive until I was 20 years old. Now, I'm not stupid. I'm not of such low intelligence that I couldn't figure out how to drive until I was 20 years old. No, I was simply uninterested. I learned how to drive, not because I had a burning desire to drive across the country, but out of necessity. I don't like to drive to this very day. I do it because it is a necessary part of the modern life, especially where I live: a fairly rural area with no public transportation. But you know what? I had a desire (I wanted have the ability to go to work, the store, and other places without having to rely on other people), but in order to meet that desire, I had to get a car. Now, what do you suppose an honest car dealer would tell me if I said to him, “I need a car that is easy to drive, one that will just work.”? It sounds like such a reasonable request, but anybody who owns a car can tell you such a request is impossible to satisfy. If I want a car, I'll first have to learn how to use it. Driving is hard. I would argue it is much harder to learn how to drive than it is to learn the basics of text editing with vim. Driving requires coordination and you have to have an ability to focus on the road while at the same time watching around the vehicle for dangers. Now if I simply learned how to drive, I would be partly there, but I still might be surprised to learn that I was suppose to periodically get my oil changed when my engine goes bad, or that I was suppose to keep an eye out for bad/low tires, when one blows on the highway.

As far as tools go, some tools are for professionals, and some are not. I am an average cook. I'm average for a reason (You guessed it: I haven't put forth the effort to become better than average!). I would be lost if you put me in a professional chef's kitchen. I wouldn't know the first thing about how to use the equipment, but there is no doubt in my mind that the equipment is much more powerful than the equipment I have in my kitchen. You wouldn't expect that a professional chef use the same tools that I use, would you? Or that his tools be easy enough for me to just walk in there and start using them? No, that would be absurd! There is no way his tools could be that simple, unless if they were preset to do certain things that I understood. But, if they did that, then they would no longer be powerful tools, because they could only do what the builder of the tool envisioned, and not what the chef envisioned.

There is some points about Unix (actually Linux) which I find rarely mentionned.

First, the whole Unix idea (see the original CACM paper on Unix) was about combining cleverly several small programs for customizing or enhancing data processing.

This is the whole insight in the original shell, and the pipe mechanism. The 1980's or 90's unix system could not be useful without the pipe(2) system call.

And STDIN_FILENO don't appear often inside Linux kernel's source. And indeed, it is just a human convention that Unix programs take their main input from file descriptor 0 and produce their output on file descriptor 1. Of course, this convention is enforced by most unix commands, and by the shell.

But we could live with a different convention. (BTW, stuff like D-bus or Corba are somehow similar to such different conventions).

And with today's Linux major applications (like Gimp, Firefox, Openoffice, ...) such conventions are much less important, and the whole idea of cleverly combining several programs has gone: there is no simple way to, for instance, inject a piece of a web page from Firefox into an openoffice document (you can do that with your mouse, or using scripting languages; but it is not as easy as the old pipe trick in unix commands, and certainly not easy to program as quickly as a dirty shell script).

My point is that, from a language point of view, current Linux applications are very different from old unix commands. Current applications are (unfortunately) no more designed to be combined, and the whole idea of combining or pluging various software has gone (in recent Linux big software).

And once could indeed have a Linux system where every program is (e.g. a FastCGI server) interacting with a browser, which would then become the current equivalent of the console (or xterm, which is just a virtual console) in the 1990's.

Why does the idea of combining programs has faded away and became irrelevant on modern Linux systems? (An ordinary Linux user probably don't use the pipe mechanism often, while it was central to Unix 20 years ago).

"Nor did the poster tell me what the syntax would be for a non-bash shell."

And how did you know what was the DOS syntax in the first place?

"An aside, how would I find that information? ...With Windows, I can at least to type Help to see a list of common commands."

So, you never used a computer before and it shows you nothing more than a black screen and a blinking text cursor. You type "hello". Nothing happens. "hi" doesn't work either. "obbey my commands, stupid machine", nothing yet. "aaaaarrrgggh" is no use.

Finally, in total despair, you type "help"´and the few DOS commands are available to you, in alphabetic order. Yeah, definately better than "man" and its "What manual page do you want?" and not accepting page "numbers".

That's why, i guess, the FSF opted for the much more approachable "info" documentation system. I guess it could be the guy's second choice after "help".

"As for vi and emacs, why don't they have the same capabilities as DOS edit?"

Now, you either is really trolling or just playing dumb. I imagine you're talking about drop-down menus? Both emacs and gvim provide them for the novice.

"Why did the developers spend so much time of the advanced stuff, while neglecting the basics that would have made them accessible to the majority of users?"

The original Unix command set was not created with "the majority of users" in mind. Actually, they were developed way before computers went mainstream among the general non-technical population and "the majority of users" were computer technicians indeed.

Most modern *nix projects, like KDE, GNOME and othersm though, are far more approacheable for non-technical people.

"Average implies 50%; if 50% of my target audience finds that my program is too hard to use, then I did something seriously wrong."

Do not suffer this much. If you were designing an intercontinental plane, you're not supposed to make it so that _any_ person can pilot it. Sometimes, the goal is to have power at the expense of ease of use. Those who wish to harness such power will have to train themselves at it, study it.

"the command line interface still needs a complete overhaul before the average user can touch it."

It will happen when AI is advanced enough so that it can disabiguate human language phrases. But then, people will likely feel better talking to their machine rather than typing at a keyboard, so that the command-line interface will always be better enjoyed by technical people anyway, who wants their stuff done directly without much intervention from an eletronic nanny...

So do I on the two desktops I work on.

BTW, when at office, I often ssh to my home PC for development (I'm working on GCC, the MELT branch). It's faster.

My laptop is running Ubuntu/Intrepid. I used to have Debian/Sid on it, but I find the interface to the Wiki simpler on Ubunutu (and also, Ubuntu has many proprietary drivers).

...and vice versa...

General purpose programming languages should be judged in part by their suitability as operating systems, and operating systems should be judged in part by their symmetry of interface and suitability as a programming language.

Some languages stand up better under this scrutiny than do others. Smalltalk, Lisp, Logo Writer, Ruby, and (of course) Oberon all fare quite well. C, with its external linker that prevents casual operation and extension from 'within' a C environment, doesn't fare quite so well.

I'd love to get rid of the artificial division between OS and language that exists today. It wouldn't prevent working with other languages, but it would mean doing so involves compiling to the OS's language rather than to machine code. Essentially, a language with sufficiently powerful compile-time metaprogramming facilities would serve the purpose of providing all other 'languages' used by an OS.

I guess the way I wrote the above sounds a bit combative. But, yeah, essentially I agree with Adam. Alan Kay's work on 'reinvention of computing' also leads in this direction, as does my own unfunded labor.

Actually both threads are barely on topic for LtU.

Well, you're definitely someone who can assert that in an official capacity.

But I feel some need to defend such topics. I'm of the opinion that theory and practice cannot be divided. And practical application of PLT really means its use in interface designs of all sorts: programming languages, library APIs, communications protocols, type systems, and operating systems among them. OTOH, topics like "Let's build a programming language" are hardly discussions related to "existing work".

LtU is foremost a place to learn and exchange ideas. The LtU Forum is not a debating forum for advocacy, posturing, attacks, vendettas, or advertising. It is a forum for informed professional discussion related to existing work.

I can see why you'd prefer to focus on papers and products, though. Doing so seriously reduces risks of topics created entirely for advocacy and posturing.

Still, I can offer one short story: I discovered this forum only through a link to Frank's comments in "Let's build a programming language" - a page from which I learned and was able to benefit from an exchange of ideas between people who (largely) discussed the topic in a manner befitting informed professionals.

Taking the liberty of inferring what Ehud has to say... Detailed design discussions, like building a PL or an OS from scratch, have a tendency to focus too much attention on implementation details and not enough attention on areas of general interest. They also don't tend to get any actual work done - just a lot of idealism. The relevant part of the policies document is:

Discussions which start out with the posting of an opinion or idea that hasn't been clearly described, and for which no references are given, tend to result in unproductive debates with a reduced quality of discussion. It is much easier to evaluate and respond to someone's position when given a link to a carefully thought-out description of that position, and/or references which put the idea in a clear context. If a long description proves necessary, it should be posted elsewhere, such as on your own blog or website, and posted as a link on LtU.

Ehud can correct me if I'm reading his advisory in the wrong way.

I wouldn't expect a detailed OS design from a "Let's build an OS" topic any more than I'd expect a detailed language design from a "Let's build a language" topic (which, for the record, is not at all). Rather, what such a topic provides is a vector for people to voice which 'general properties' of a language or OS that they see as important or deserving of greater priority. These ideas, the discussions, and the links to more in-depth material, when provided by a large group of professionals with a real interest in PLT, provide an outstanding place to start brainstorming work for such things as next-generation operating systems and languages. The variation among LtU members is only an advantage for this purpose because it is likely that they have thought of things and voiced ideas or concerns that you or I have not even begun to consider.

Still, it's off topic (or 'barely on topic'). One wouldn't want too many of these brainstorming discussions floating around. But, like a heady wine, a little bit can be good for the heart. Moderation in all things, right? And you guys are the moderators.

Although I have sympathy for what you are saying, I also figure that the LtU ethos has been to try and funnel opinions via discussions grounded in external resources. For the most part, this has served LtU well over time - though it may have prematurely curbed some interesting discussions as well. Anyhow, the solution is rather simple. If a topic interests someone, they can write up a well-thought out piece elsewhere and post a link here on LtU. That way, the disucssion can elicit opinions on topics of general interests, but be directed to original material to determine whether a thread is straying too far off course. The external resource provides a needed focal point.

As for moderation, it has only been applied a handful of times, and only in the most egregious instances where things get disruptive and attempts at persuasion fail. Ehud and other long-term participants really don't like applying a heavy hand. The above reproach is simply a mild reminder of the course that LtU has attempted to lay out.

Couldn't have said it better myself.