I can get almost an perfect clone of the modal editing of vim with the hackability of emacs. It still needs some love but I've already submitted two patches and the developers were really supportive. If your looking for an excuse to do some haskell coding this might be a good option for you.
(When I write XMonad extensions, I do find the process a little tedious. I have to type my extension, then see if ghci can compile it, then I have to press a key to recompile and reload xmonad, then I can try out my changes. Every. Time. In Emacs, I just press C-M-x and try my change immediately.)
Really, there are two parts to editor extension. Some things are interactive hacks, and some things are structured sub-programs. Things like SLIME and CEDET are sub-programs, and they would benefit greatly from a more expressive (and faster-running language). But everything else benefits from the do-anything-you-want style of Emacs Lisp, because you can develop your development environment interactively. It's really a wonderful experience, even though you don't have closures or classes with multiple inheritance.
One of my plans for the future is to replace the C core of GNU Emacs with Haskell, so that complex extensions can be more easily implemented. But Emacs Lisp will still be around for when "scripting" is good enough.
* dynamic scoping. The lack of closures is pretty limiting. I can live without the objects and inheritance but I really really want closures.
* key bindings parsing. Vimpulse is basically incapable of implementing some of my most often used vim commands because of the way the key bindings are parsed.
Both of those things prompted me to go looking for an alternative and this is what I found. It's been fun so far, perhaps I'll hit a wall again and get dissatisfied but for now it's a handy hack on something in haskell project.
Again you have two worlds. If one changes the other has to follow. And you will always lost something when translating from one world into the other.
No you don't. You must've gotten use to old versions while this is true. Make your change and then restart right away -- if it won't compile you'll get an error popup but xmonad will continue chugging along merrily by running the last good version of your xmonad.hs.
Sorry if this seems painfully naive, but what happens to your current set of windows and apps?
Do you have to close out of everything in order to make a config change?
vc.el, erc, ediff, slime are doing well with elisp...
In some way also, the most complex the extension, the more reasons you have to use a higher level language, no?
Have you ever used Gnus? Have you noticed that if you have more than 10 message in an mbox or 100 in a maildir or 1000 on an IMAP server that it becomes unusably slow? Profile, and you'll see all the time is spent doing the parsing in elisp. Having the option of using a different language that compiles to native code would make these extensions faster and equally easy to write. Use elisp for the stuff that the users are going to play with; drop down to Haskell for the data structures that manage the mail. Best of both worlds.
People are always able to bend their tools to perform the work they want them to do. Ever use a flathead screwdriver to turn a phillips-head screw? It works. But it's a lot easier when you use the phillips-head screwdriver.
No, just no.
No, just no.
The question is "why did they do that" ? The most obvious answer is C: If you write your OS in C, you will most likely make C-like APIs, which don't properly hide low-level stuff, but are easier to implement (the "Worse is Better" principle).
And if you are writing X86 code you don't have a choice about register access - and why is that a problem anyway?
Do you want an OS that is actually a virtual machine? I don't. I want an OS that lets me use my CPU.
> If you write your OS in C, you will most likely make C-like APIs,
That's a fundamental misunderstanding. The API are written for the _hardware_. Did you forget there was an actual computer in there? It's nice and all to go high level, but at the end of the day you have a CPU and memory and you need to use it.
Almost, if not outright yes. Current OS'es already do manage memory in some ways, so they could as well do more work, so you don't have to re-invent that wheel every time you write a new compiler. Having a full blown virtual machine as an OS actually sound very promising : you can for instance migrate from X86 to ARM transparently, re-compiling nothing but the kernel. You can reduce hardware support for fancy features, simplifying it.
Now, a good enough compromise could be a layer of compatibility for a garbage collected language. And we already have plenty of these.
> The API are written for the _hardware_.
You got that backwards. The API is written for humans to use the hardware. If the hardware is complex and quirky, it's the job of the API to make it simple and straightforward. It's nice and all to go low level, but at the end of the day you have to get things done. You sound like you need every last drop of performance out of your CPU. When you really do, then you may want to do your work in kernel space with no runtime check at all. But most of the time, you don't.
To sum up, an OS written in C will most likely have a C-like API (I note that you didn't disagree with that). There's still the high-level vs low-level debate, but it basically has the same structure as the GPL vs BSD debate. I prefer high-level and GPL, on the grounds that they eventually enable more. You seem to prefer low level (and BSD?), on the grounds that they permit more (which is not the same at all). We could go on, but if we actually disagree on that point, I don't know how we could convince each other.
Low level has just a few well defined interfaces. High level has tons, and high level is not flexible either.
An OS will have a C like API not because of C, but because that's how computers work. C was written to copy the computer.
And what I said has nothing to do with GPL vs BSD, I don't think your analogy applies. And I don't agree with what you assume I meant about high/low permit/enable.
I simply said that an OS is made to handle an actual real computer, and it's written that way. It has nothing to do with C, it has to do with hardware.
Personally I prefer a mix - define the low level and allow using it. On top of that make tons of high level helper functions, but always make sure that even if you use the high level functions you are still allowed to use the low level if you want.
This is one of the most widespread and major misunderstanding about computers. Computer science is not about computers; Just like astronomy is not about telescopes (Dijkstra).
The only thing that really matter about computers is that they are communicating Turing-complete machines. Every communicating Turing-complete hardware on the planet is therefore the same, modulo the necessary emulation layer (performance is becoming secondary, so let's pretend it's not a problem).
What we want as humans is communicating Turing-complete machines that are easy to use. That's a fact about us, not about hardware. Therefore, OS APIs should depend on us, not on hardware. Having an OS whose API is influenced by the actual hardware is a pity. Making an OS whose API is influenced by the actual hardware is a shame.
* I also don't like Haskell, but wouldn't suggest OCaml either. (Lua seems born for the role, though.) I got burned hard by settling in with XMonad, only to find out that they didn't care about portability ("avoid success at all costs") - BIG waste of my time. I went back to C for my window manager. C was more stable than Haskell!
I would love to have an Emacs-like editor (scriptable, multiple buffers, no GUI or menus) that 1. used Lua instead of elisp, and 2. had a vi-style modal keyboard interface rather than primarily chorded keys. Oh, and not being tied to GTK is nice - I like being able to use Emacs in shells, from screen/tmux, etc.
One of these days I might give in and write one, but I've already got too many projects going.
Emacs Lisp is not particularly ancient anyway, changes are committed every day.
But honestly, lexical scoping reduces the chance of introducing unwanted binding at the cost of reducing the ease of "accidental" customization. Emacs' "nothing is closed" policy has worked very well for a lot of developers and users over the years. With enforced privacy, we're on the way to Eclipse, which can only be customized by 100 man teams working 18 hour days.
Remember, Emacs is not your backend batch processing app. You are always in front of it, interacting with it -- if it fucks up, you fix the bug right there because you are right there.
How the heck do you figure that? The majority of languages after emacs lisp specifically avoid dynamic scoping.