I noticed that the expression "Systems Programming" now seems to mean a much higher level that it used to. In my mind, writing a web server is still an "application" and is not equivalent to, for example, writing an operating system. The Go language is also claiming to be a "Systems Programming Language" but I won't use it for what I call "Systems Programming"...
I'm not the parent, but I usually consider anything requiring fairly intimate knowledge of the hardware and operating system "systems programming", such as writing a database.
Others seem to refer to it as anything that could be considered part of the OS, like writing drivers.
Some systems programming is writing applications. But they are applications that have intimate knowledge of the system. For example, the shell is a user-land application, but I clearly put implementing it under the "systems programming" label. Same with implementing a webserver.
I'm pretty sure Go at least aspires to "systems programming" in the classic sense, since its designers include some Unix and Plan9 veterans. Whether they'll succeed or not is another question, but they do seem to have a genuine C replacement in mind.
Slightly off-topic: ever since I started working my way through Land of Lisp a while ago, I decided I would spend some time trying to seriously learn a lisp dialect. I was thinking that dialect would be Clojure because of its compatibility with Java and its community. But can anyone speak for Racket? I couldn't find a "why racket?" section on their homepage.
I love racket. It's basically scheme with a bunch of extra goodness (libraries, language features) added on top.
You may have heard of it before it was renamed (it used to be known as PLT Scheme).
I've just started working through Land of Lisp as well. I find myself wishing I were writing Racket instead of Common Lisp, but it's entirely possible that's just because I'm more familiar with Racket/scheme.
I am also more familiar with Racket and Scheme, but was considering working through Land of Lisp. Do the code and problems in the book lend themselves to translation into other languages? That is, do you think one could learn both CL and Racket fairly well by working through the book first in CL, then translating to Racket?
I bought Land of Lisp when it first came out, but I just barely started reading through it a few nights ago (school keeps getting in the way). I believe the stated intention of the book was to teach any lisp (but the book uses common lisp). The first guessing-numbers game would be trivial to translate to Scheme. I'm assuming there will eventually be games with graphics, and I'm not sure if those will be as easy to translate or not due to library issues.
I wish I could offer a more definitive answer, but I'm just not far enough into the book yet to say.
Disclaimer: I don't know a ton about this. But one of the often-cited reasons for learning a Lisp is the power of Lisp macros for creating domain-specific languages. My understanding is that one unique feature of Racket is how it takes this idea to the next level: not only does it offer a powerful hygienic macro system; Racket also thinks of "languages" as libraries. The Racket folks have built a platform where it is easy to define non-trivial (and even non-Lispy) languages, and freely incorporate code written in those languages into other Racket programs.
I think this response sold me on learning Racket first (though it was definitely a cumulative effect of hearing people's good experiences).
I don't have a project in mind for either dialect. Basically, I want to learn lisp because I've heard learning lisp has certain mind expanding properties. This feature sounds like the mind expanding-est of all. And whatever skills I learn with Racket will probably be easily translated to Clojure, so it's not like I'd have wasted my time if I ended up working in a Clojure shop or on Clojure project.
Some* argue that hygienic-macros are an unnecessary burden because sometimes you need to capture variable names and this is easy to do with Common Lisp. The situation with Scheme is different because it stores variable and function definitions in the same way (Lisp-1 vs. Lisp-2).
Racket is simply fantastic. I use both Clojure and Racket and I have few complaints about either. Clojure's main advantages are the performance of the JVM, larger library ecosystem, and a larger community. Racket has plenty of things to be jealous of though, the efficient pattern matcher, the typed variant and the contract system are particularly cool.
I also use both Racket and Clojure. I thought that Clojure was just a little faster than Clojure, but uses about twice the memory as Clojure. I also like Gambit-C and SBCL a lot, and it is sometimes a real toss-up which Lisp to use.
Almost funny to compare now to the old days: I had a Xerox Lisp Machine in the early and mid-1980s. A great tool for rapid prototypes, but the question I could never answer was: how to deploy Lisp applications cheaply. That is no longer a problem!
You said: "I thought that Clojure was just a little faster than Clojure, but uses about twice the memory as Clojure." Which of those "Clojure"s should be "Racket"s?
I tried racket but just could not get namespaces to work, and the tool I was using, ometa for scheme[1] did not want to work properly without them. I spent hours, asked on the chat, read the documentation, etc. but just could not get it working. It felt like a bad omen, and ever since I've unfortunately been put off the language. The whole response I got/the documentation treated the whole thing as 'well it's obvious - foobar the fargle', where 'foobar the fargle' just made no sense to me. Maybe just not clever enough for racket...
Racket is an exceedingly mature and stable implementation, with vast library support, of a language I have learned I don't really like (after writing my PhD dissertation program in it). It is still Lisp and that makes it miles ahead of conventional languages, and the library support is really nice, but there are a lot of difficult to pin down subtle philosophical points encoded in Racket by its designers that I don't like as much as, say, Common Lisp—the ones I remember are I couldn't figure out how to get a REPL in the context of a module, I don't like static typing in a Lisp and the module system in Racket encourages that, and I dislike Racket's native OO system but there were a few others. Clojure is more comfortable to me for some reason.
Which is not to say that you should not absolutely go for it. Fantastic environment all told and if you aren't coming to it with preconceptions then it's probably a better place to start learning than something as baroque as CL.
Has any one created any Windows GUI's using Racket and if so, what was the experience like? I,ve been learning Clojure and having a lot of fun but not a big fan of Swing, so hoping Racket might be a better fit.
Racket is Rodney Dangerfield of languages, an amazing effort in programming language design that gets no respect.
Beyond what others have covered, the new Typed Racket effort is simply amazing and as of yet even hardcore Racketeers have not fully explored it.
It is different and novel type system with a really well thought out syntax notation. The type system has seamless coverage from static type checking which continues into runtime with contracts. It is really novel. In some sense the amalgamation of the best ideas from the "dynamic" typing crowd as well as from the "static" typers.
Second I can't highly recommend enough an alternative development environment using emacs and the most excellent Geiser project for Racket and Guile. It offers a bit of a return to that agile REPL based development feel that some say is missing somewhat with the DrRacket GUI IDE.
35 comments
[ 2.9 ms ] story [ 73.5 ms ] thread(I'm not necessarily disagreeing with you, but you haven't provided a definition of what you consider systems programming.)
Others seem to refer to it as anything that could be considered part of the OS, like writing drivers.
You may have heard of it before it was renamed (it used to be known as PLT Scheme).
I've just started working through Land of Lisp as well. I find myself wishing I were writing Racket instead of Common Lisp, but it's entirely possible that's just because I'm more familiar with Racket/scheme.
I wish I could offer a more definitive answer, but I'm just not far enough into the book yet to say.
* Tons of interesting language extensions -- any Scheme you have ever thought of -- implementations of laziness, static typing, logic programming, FRP
* Very good online documentation
* Great libraries for lots of things, combined with really easy online package management @ http://planet.racket-lang.org/
* Go look at all the cool things it does, don't they look fun? http://docs.racket-lang.org/
(require (prefix-in sqlite: (planet jaymccarthy/sqlite:4)))
and then have it automatically downloaded (plus dependencies) and ready for prime time...
See: http://docs.racket-lang.org/guide/languages.html
I don't have a project in mind for either dialect. Basically, I want to learn lisp because I've heard learning lisp has certain mind expanding properties. This feature sounds like the mind expanding-est of all. And whatever skills I learn with Racket will probably be easily translated to Clojure, so it's not like I'd have wasted my time if I ended up working in a Clojure shop or on Clojure project.
Thanks to everyone who responded.
This paper(http://www.ccs.neu.edu/scheme/pubs/scheme2007-ctf.pdf) demonstrates how they made an explicitly-typed dialect of the dynamically typed language Racket.
Truly awesome stuffs.
Some* argue that hygienic-macros are an unnecessary burden because sometimes you need to capture variable names and this is easy to do with Common Lisp. The situation with Scheme is different because it stores variable and function definitions in the same way (Lisp-1 vs. Lisp-2).
* http://p-cos.net/lisp/guide.html
Almost funny to compare now to the old days: I had a Xerox Lisp Machine in the early and mid-1980s. A great tool for rapid prototypes, but the question I could never answer was: how to deploy Lisp applications cheaply. That is no longer a problem!
I tried racket but just could not get namespaces to work, and the tool I was using, ometa for scheme[1] did not want to work properly without them. I spent hours, asked on the chat, read the documentation, etc. but just could not get it working. It felt like a bad omen, and ever since I've unfortunately been put off the language. The whole response I got/the documentation treated the whole thing as 'well it's obvious - foobar the fargle', where 'foobar the fargle' just made no sense to me. Maybe just not clever enough for racket...
/rant
[1]:http://www.lshift.net/blog/2008/07/01/ometa-for-scheme
Update mzscheme namespace usage for eval to use namespace anchors
I ought to check it out, I've not taken a look at the project for >1yr.
Which is not to say that you should not absolutely go for it. Fantastic environment all told and if you aren't coming to it with preconceptions then it's probably a better place to start learning than something as baroque as CL.
Beyond what others have covered, the new Typed Racket effort is simply amazing and as of yet even hardcore Racketeers have not fully explored it.
It is different and novel type system with a really well thought out syntax notation. The type system has seamless coverage from static type checking which continues into runtime with contracts. It is really novel. In some sense the amalgamation of the best ideas from the "dynamic" typing crowd as well as from the "static" typers.
Second I can't highly recommend enough an alternative development environment using emacs and the most excellent Geiser project for Racket and Guile. It offers a bit of a return to that agile REPL based development feel that some say is missing somewhat with the DrRacket GUI IDE.