What could conceivably be done to address Lisp's impenetrability & niche status

A chap on CIX responded to my last piece on Lisp, and it led to a long answer, which my CIX client then crashed and threw away. So if I have to rewrite it, I'll do it here and it will maybe be read by a few more people. Perhaps, ooh, a dozen.

> Trouble is, it comes across a bit as a "lost wisdom of the ancients"
> story.

Yes, it does. But I am OK with that, if I can turn it into a coherent article that tells a comprehensible story.

> Lisp was a niche language in 1960, it's a niche language today. It
> has been a niche language for all the intervening period and I expect it
> to be a niche language for all time to come.

It's a fair point, but there are ways around that. One of the problems, though, is that the Lisp community are very resistant to them.

The thing that my research and my various discussions online are leading me to believe is this:

There are many things about Lisp that used to be distinctive, powerful features decades ago – not merely the functional programming model, but lambda calculus, closures, higher-order functions, tail recursion, lazy evaluation and so on. However, today, other languages can do these things. Perhaps some can do all of them, others only a subset, but that doesn't matter if these are the tools you need to crack your particular problematic nut. And the other languages that include these features do not have the feature that is the biggest problem with Lisp: its obfuscatory syntax, or as the Lisp advocates would have it, its *lack* of syntax. (Of course, as in the case of Perl, for example, they may have their own obfuscatory issues.)

But the problem is that that syntax is both the biggest obstacle to learning and using it, and yet at one and the same time, also absolutely integral to the one feature that sets Lisp apart from pretty much all other languages: its syntactic macros.

( Read more... )

It's not about the programming language.

The only reason why the language should intrude into the discussion is the side-question of whether certain language facilitate or hinder certain types of work.

Look at it from a different angle. For many a working programmer (and writer, believe me), the WWW is a massive distraction. A necessary one, but one that is separate.

What do you need to do, if you are co-working on a significant project? Edit code, obviously. Save it, compile it, run it, probe it with debuggers. Navigate your filesystem, load and view other files, move stuff between them. Occasionally, read and write email, or IRC, or (more historically) newsgroups, to discuss what you're doing. Possibly retrieve files from remote servers or put them there.

The point being, Emacs has extensions to do all this, so that you can do it all in a consistent fashion in a consistent (if horrible) UI, so that you can spend your entire day inside a single Emacs session and never leave and thus mentally never have to change gear.

Emacs, for some of its fans, is their entire OS. Their computer runs something that lets them launch Emacs and has an accessory function of browsing the web.

I don't do this - I don't speak Emacs at all - but I know people who do and really like it.

Well, turn that inside out. Consider an OS whose sole purpose is to do this: a Lisp interpreter running on the metal, which runs Emacs, and inside that, you have all the other functions. No distinction between "OS" and "apps", or between different apps. The OS runs the HLL you're writing natively, so there's no interpreter or compiler or linker. Everything you see is drawn by your editor and is live code that is executing in the environment - you can, if you wish, tweak the email function or the file manager to your taste, or if you want, go grab a new one off the Internet and plug it in instead.
( Read more... )

What have we lost out on? (A bit more discussion about dynamic, environment-based OSes)

> In short, the more somebody sounds off about a language or OS, the
> less they should be trusted. But I think you're reaching the same
> conclusion.

Well, yes...

> First, from a "wisdom of the ancients" POV: what have we lost out
> on?

That's what I am trying to work on elucidating, understanding and finding
out how to explain.

In general, because I don't yet know enough to have any alternative, I
have no recourse except to be vague and hand-wavey:

What we have now are very fast, very capacious, very very stupid
computers. What ought to be arcane internal concepts are exposed at the UI
and users have to learn to manipulate them: files, folders, file *types*,
documents, binaries and executables, source code, interpreters versus
compilers, and so on.

As Stanislav Datskovskiy put it in http://www.loper-os.org/?p=55 :

<<
The computers we now use are descended from 1980s children’s toys. Their
level of bedrock abstraction is an exceedingly low one. This would be
acceptable in a micro with 64K of RAM, but when scaled up to present
proportions it is a nightmare of multi-gigabyte bloat and decay.
>>

( Read more... )