So basically an open source vector computer? I can see usage as a co-processor, but not as a main processor.
Currently, Writing a Radeon R500 driver for 9front. Its an absolute dream how easy the operating system and kernel architecture makes that. Hell, if I just let VESA do the VGA work, the driver’s basically 5 lines! Along with that, I have a version control system on the back-burner. I have some rough wave simulation code for a game engine i’m writing for a client, too. That’s about it :)
Given time how likely is it for Go to reach speeds that meet or exceed Java, C, or C++?
llvm seems to be the great equalizer here. If a language can keep its memory use under control, and minimize other “busy work”, they should start converging on “llvm fast”.
Go already exceeds or matches Java, but I doubt it will ever compete with good C, much like C can’t compete with good assembly. Bad C (and especially bad C++), it will probably outperform now, or in the near future.
On what kind of loads and with or without JIT? Do you have any references?
So he discovered one of the core principles of UNIX ;-)
As an aside: there isn’t really a good way to input text on smart phones. Swype works, but if I remember correctly, its proprietary.
Except that the post demonstrates multiple prototypes of text-based interfaces on mobile … In fact, nearly every screenshot is in a mobile form factor.
Maybe in bulk, sure.
But he’s talking about using SMS. You’re naturally constrained to a character limit there. You’re rarely going to tap out more than a paragraph or two at most.
Also, a funny aside: this message was dictated using Siri. I’m not sure I agreewith his assertion that speech to text is that much more difficult.
I’m not trying to start an editor way in any way, but at this point: why not emacs? You’re losing the lightness of Vim by adding all these plugins, one of the best features of vim, in my opinion. I use evil-mode for almost everything in emacs, and I do wish it integrated better. Using vim simply for the universal conventions that come with it makes sense to me.
What do you mean by lightness?
You can have a fairly rich experience in vim without any added latency. Some plugins affect performance, but they’re swiftly removed from my bundle. Most of my plugins are language-specific and unintrusive, so they only load when the respective language is active in some buffer or I invoke them specifically.
Forcing myself to use vim as just a text editor when it can be much more is unproductive.
As for one why might prefer to use vim than emacs, it’s largely the same reason that I prefer vim over Sublime Text, or Atom, or Eclipse, or whatever. I feel more at home with vim, and I relate better to how the ecosystem operates than other options.
I agree, although I still use vim. If you use vim, you should be using it as a text editor, and not an IDE. If you want an IDE as your editor, then use emacs. If you want an IDE and vim, then take advantage of more versatile tools like your shell and language REPL or something.
Or you know, the guy can use what he wants for what he wants. If he wants to try and turn vim into an IDE, who are we to tell him that he is wrong?
To call the OP’s setup an IDE is a bit of a stretch regardless. And OP does mention moving to the REPL in another terminal “you must launch a Clojure REPL manually in another terminal thought”.
It’s interesting but I’m still left wondering why? Anyone care to explain that part?
The cannonical answer to that question is that all the LispMs, even later hardware like the TI lisp machines was expensive performance general purpose hardware for software development specialists of the time. As funding dried up for the AI work that Lisp had become most famously associated with in the popular press the fortunes of the LispM companies also waned. At the same time the Intell 8080 and the consequent IBM PC compatible flood dominated the low end market which the LispM companies had largely ignored.
In ‘83 the Symbolics 3600 workstation was released, MSRP $110,000 and in '84 the Apple Macintosh MSRP $2,500 ushered in what we know as the personal computing revolution. The rest is as they say history.
Also compilers got better and memory got cheaper. As suggested in my article, not long after the fall of the LispM companies it simply stopped making financial and technological sense to invest in special purpose hardware when better software environments enabled by larger memories could efficiently compile Lisp programs to machines lacking hardware support for the various concepts of Lisp evaluation.
That’s a good overview. I’m sorry I wasn’t clear in my question. Why would someone want a “LispM like system”? Maybe there’s an assumption of FP nirvana in there that I don’t understand.
This article assumes that the reader is at least curious about LispMs which are often held up as a lost FP nirvana and seeks to distroy this collective delusion while pointing out that we have the means to build equally good tools for ourselves in exsting platforms and obvious future platforms should we choose to.
As to why one would want such a system, the simplest answer is pervasive system wide introspection for documentation, source and user modification the various benifits of using a memory safe host language asside and neglecting the various advantages in terms of proof by construction, pattern matching, static effect analysis and other work which the FP crowd has produced since the original fall of the LispMs.
I’m not really sure where to start here.
The Lisp Machines have pretty much nothing to do with a “lost FP nirvana”. Working in Common Lisp, or the Lisp Machine Lisps like ZetaLisp or Interlisp, had little to do with functional programming.
Lisp Machines are about an entire experience for expert developers. It isn’t just the OS. It isn’t just the hardware (compared to other hardware of the time). It isn’t just the applications that people ran on them. It was the entire environment, how it worked, how it fit together and how it was built to be a productive environment.
There are some ways to run Open Genera, but often, I wouldn’t recommend it. It takes serious time and investment to fully understand what’s going on and know how to use things well enough to understand the power of the whole package. I don’t find that most people that I’ve seen try to run Open Genera have actually expended an effort beyond the tinkering stage. I, myself, don’t feel like I’ve done enough work in the environment despite spending some serious time with it.
If you want to read what someone who has used them extensively has to say about why they were nice, I’d suggest Ergonomics of the Symbolics Lisp Machine - Reflections on the Developer Productivity from Rainer Joswig.
There’s still a lot to learn from what was done on the Lisp Machines. A good example of that is the whole subject of “Presentation-based UIs”.
I don’t think we’ll have a situation again necessarily where everything is in Lisp (or some other language) from the ground up on top of the hardware in a world where everything can be viewed, inspected, modified at run-time. Most of our developer tools today are a shadow of what they could otherwise be and that’s sad.
Hopefully, we’ll have more people like Rainer Joswig tell us about the good parts of the things that have been lost. Many of the people involved in these things have moved on. Many have retired. Some have died. I hope we’ll hear more of their stories before they’re lost.
BSD and it’s philosophy achieves a little bit of that view, inspect, modify everything ideal – though at compile time – not at run time unfortunately. From a user’s perspective (which – I understand – we’re not talking about here – we’re talking about serious experts here) that would probably lead to chaos. As a developer, do you really want people messing with the internals of your program’s execution – it would add so much more complexity – you’d have to think of everyone as a developer essentially. You’d only want that if you wanted to eliminate the masses – everybody who only want to use a computer to share music, write documents, and – at most from a programming perspective – write simple UIs. And from security perspective – this wouldn’t work at all.
I think the reasons why a functional operating system hasn’t really caught on is because most OS development is geared towards embedded systems development. The last I worked with embedded systems they were still using semaphores and locking shared global variables for concurrency – but I don’t think they really need something to handle a lot of multi-threading – medical devices and specific device chips only need to handle interrupts from buttons and timers. A lot of the practical improvements functional programming has brought to the table has been for web applications and servers, since they have to deal with relatively huge amounts of data. These improvements I’m talking about are namely over node, golang, and nginx (possibly).
From a productivity and ergonomics perspective, yeah, I don’t see why their aren’t more varieties or userlands and keyboard layouts. I suppose the way we use unix and keyboards is just culturally baked into us – with only a little reason – maybe if somebody really pushed for a change it would happen, but at the moment it’s not like its broken or anything. (Touch screen keyboards that allow for custom keyboard configurations could bring back some of those keyboard ideas from the Symbolics Lisp Machine)
Actually now might be a really good time to build an OS with a functional programming language. “Purely” functional probably wouldn’t be practical – because it would be too slow – but say you had an OS with a functional concurrency model in place – you’d probably see a huge gain in the ability of a single server to handle a lot of threads if the threading was all handled at the OS/hardware level instead of the application. Software is cheaper than hardware – so if it was done right – there’d be a market for it. I’ve read facebook uses specialized hardware to handle their huge amounts of network traffic. Monads could also be used to deal with buffer overflows. If the x-windows systems used a more actor based concurrency model to update the window – you’d possibly see a much smoother desktop experience.
Just talking loose here for conversation – so if I’ve said anything ignorant - sorry – I should go read a book on operating systems design.
I’d like to respond to this, but I feel like doing so here would be too limiting.
There have been end-user friendly, multi-user, programmable systems where almost anything (above a layer in C) could be modified. They even had security models for dealing with multiple people having differing privileges with respect to different parts of the code.
I’ll try to find the time (in the near future) to write a blog post or two about one such system that I spent years working on, using, and that I still miss.
Is this system publicly known? If yes, how was it named?
I don’t know what BruceM means (and would like to), but Sandstorm gives a current example of a security design that could make it work.
It wouldn’t be that hard would it? Have the kernel keep track of who has access to code, and those that do are allowed to modify the code while its running. You don’t have to think of the end-user as a developer, you just have the ability to do so if you want. Beyond making it so that a multi-user system is stable and secure in such a system, it kinda is a none-problem.
I think though, that in C or Lisp based system it would only be possible to have two users. Those who have access to the run-time code and those that don’t – since if a user has access to the run-time code, there’s nothing stopping him from writing code to give him higher access privileges. Could be possible with a typed system though.
Typing is no panacea here. A security system can offer sufficient protections to allow this all to work.
The system that I’m referring to is largely gone from the net, so when I start to write about it, it’ll mostly be the only info left online about it. It was similar (in some ways) to LambdaMOO.
LispM were much more like Smalltalk environments than a dedicated OCaml machine (as much as I’d like to have the latter). They were designed for programmers who didn’t want an impenetrable barrier between what you as a programmer do and what the system is.
Great reply, thank you!