One of the coolest parts is how Roswell with scripts: you can run a local file, or in a custom directory just for scripts, and even better: you can install scripts from libraries.
This way, if a library needs to expose some functionality to the terminal, just add a Roswell script =]
So I found this README hard to understand, as someone who doesn't work with CL on a daily basis (but is familiar with lisps like clojure, and having used SBCL before).
I'm worried about how bad fragmentation is, and why a tool like this is even needed. This is a "full stack environment" for CL web development? I don't even know what that means... not all lisp dialects are similar so why are they stuffed under one tool that treats them like they are?
There's so much about this tool I don't understand, but maybe that's fine, since I don't use SBCL or any lisp dialect(other than clojure) very often on any real projects
Yeah, that paragraph is a bit misleading (and the whole readme could use some more love).
Roswell is basically a tool that help you quickly setup a Lisp development environment. You can think of it as Ruby Version Manager (RVM) for Common Lisp. It can be used to install the latest version of the Lisp implementation of your choice (which is really a great feature if you use Debian stable or Ubuntu LTS), easily switch between various implementations, and even switch between different versions of each implementation. This makes testing your Lisp code across multiple implementations a breeze, especially when you use Roswell with CI tools.
That the majority of Roswell developers are web developers and use it to develop, test and deploy web apps are merely a coincidence. Roswell can be used to develop all kinds of applications.
Regarding the fragmentation issue, on Linux there are basically two major open source implementations that most people use nowadays: SBCL and Clozure Common Lisp (CCL). So it's hardly an issue at all.
Thanks for the clarification -- I might suggest that the word "web developer" not be used, because it obscures the meaning -- when you say "web developer" and "lisp", I instantly think Clojurescript (maybe it's just me). Now that I understand it I get how useful it is -- I've always found it difficult to wrangle the different implementations of common lisp.
If I'm understanding correctly, what you mean is people who develop web application servers, or the "backend" part of websites/apps.
Also it would be wonderful if the first thing in the readme was just how to set up with a specific language. A "getting started" section might be just the trick, to show that you can install roswell, and then install your desired implementation of common lisp super quickly and easily.
Also thanks for sharing on the fragmentation front -- I thought SBCL still had a bunch of competitors.. Though I know racket has quite it's share of proponents.
Roswell, is a "killer app", as far as using Common Lisps with Continuous Integration and Coverage services (TravisCI, CircleCI, Coveralls et al) is concerned. It is not an interface to CI systems it is an Lisp Implementation manager and makes using CI services dead easy event multiple lisp implementations. Roswell also provides a handy hash bang scripting for Lisp.
This is a neat system, but I have to say Racket has been dead on easy and just works on Linux and Windows. I feel like I am starting to be the Racket Evangelist but it is such a great experience after javascript, Python, Haskell and old school Assembly and Pascal.
Racket is not Common Lisp which is what Roswell is built for, so why bring it up here?
I've used Racket ever since it was called PLT Scheme but I've moved on to Common Lisp for the past 5 years, once I realized that there is basically nothing that Racket does better than CL, and a lot that it does worse, interactive development being the most important.
SBCL being 2-4x faster without declarations or special optimization passes (in my own code I could get 10x the
speed of Racket by doing declaration passes) is also immensely useful.
Not to mention, the thriving ecosystem around Common Lisp.
Quicklisp has helped with the explosion of popularity and there are well-maintained good libraries for the vast majority of tasks one would like to do. Most of these libraries are also portable across CL implementations which is something one doesn't see in Scheme-land (besides the lack of libraries to begin with).
But the reason I brought up Racket has to do with the Title: "A Lisp interpreter ..." The title wasn't a Common Lisp ... and I just said I found Racket to be flawless in that regard since TECHNICALLY Racket is a Lisp which I find to be better for my personal programming especially with FP, though CL has great OOP.
Shouting alone won't convince anyone.
Note that there are people who hesitate to call Racket a Scheme (http://stackoverflow.com/a/3358638/124319). I would consider Julia to be closer to Common Lisp than Scheme.
By the way, are you sure you wouldn't have talked about Racket if the title was different?
In fact this really does not matter: nobody mind if you talk about Scheme, or Haskell, or any other language. In all other threads people can't refrain from talking about Rust or D whenever someone mentions C++ (for example). However here I fail to see the link between Roswell and your comment.
> I found Racket to be flawless in that regard
With regard to installing different implementations?
> I feel like I am starting to be the Racket Evangelist
There is no bold. So your saying Racket isn't a Lisp? I think you might be on a tangent right now that isn't true. I am guessing your reacting to something different. Racket 100% is a Lisp it isn't in the group called Common Lisp but it certainly is a Lisp.
The title is 'A Lisp installer...' - not an 'interpreter'. Pay attention what it is about. The page also says: 'Roswell - Common Lisp environment setup Utility'
> and I just said I found Racket to be flawless in that regard since TECHNICALLY Racket is a Lisp
Can Racket set up a Common Lisp project? No. That's what this tool is about.
Racket is a descendant of Lisp. Not Lisp. It is nowadays its own language.
> which I find to be better for my personal programming especially with FP, though CL has great OOP.
The topic was about a new installer for Lisp, not an 'interpreter' and not 'Racket'.
Racket is great - this site even uses it - but the relevance here is near zero.
I'm learning to code, and switched from "Learning Python the hard way", to "learn Python programming games" (much much better IMHO for raw beginners) to follow "How to design Programs" and passing to racket. The environment is so much easier to start with, installation, tools (DrRacket is awesome!), deployment of programs (easy to wrap in an exe), very good documentation..
I see the usefulness of Python and I like it, but for my needs, Racket is just perfect. I'm not learning to get a job as a programmer or create heavy production code, just develope some small side projects for fun. I find that Racket helps me with this out of the box easily.
As gammafactor notes, Racket is not Common Lisp. Nor does it have any other implementations, free or proprietary. That's one of the great advantages of Common Lisp: a single standard, implemented multiple times by multiple people, running on many platforms.
Racket is definitely neat. I don't know for certain, but I hope it learns from some of the same lessons that CL learned from. Still, why not use the standardised, industrial-strength Lisp?
> But the title of the post wasn't a Common Lisp ... it was a Lisp interpreter which technically Racket is a Lisp.
Common Lisp is Lisp: it's a standard which specifies the minimum required functionality of a Lisp implementation. Anything which doesn't meet that standard isn't Lisp.
Scheme, Racket, Hylang, Clojure may each be a Lisp, but none is Lisp (unless one of them has bothered to implement the Common Lisp standard).
I also like what I see every time I visit Racket but the fact that I'm not aware of any other project except Racket itself which uses the language and tools gives me the odd "why is this not more appealing - what's the hidden catch" tingling. Even OCaml has several fairly well known programs people use.
1) People's perceptions that Racket is an educational program
2) It's hard to communicate the unique qualities of Racket. "Racket is a full-spectrum programming language. It goes beyond Lisp and Scheme with dialects that support objects, types, laziness, and more. Racket enables programmers to link components written in different dialects, and it empowers programmers to create new, project-specific dialects. Racket's libraries support applications from web servers and databases to GUIs and charts."
A programming language for programming languages isn't an "Oh I get it right away.".
1. This perception comes from the fact that it is heavily used as an educational program. That there of course nothing bad about this.
2. The text you quote precisely communicate what Racket is: a language marketed like a programming-language research toolbox and not like a day-to-day programming environment. I don't really think that Racket developers really try to sell the language in the same way Scala or Clojure ones do.
Also, a lot of people actually "get it", and choose not to use the language.
> This manual describes the C interface of Racket’s run-time system. The C interface is relevant primarily when interacting with foreign libraries as described in The Racket Foreign Interface; even though interactions with foreign code are constructed in pure Racket using the ffi/unsafe module, many details of representations, memory management, and concurrency are described here. This manual also describes embedding the Racket run-time system in larger programs and extending Racket directly with C-implemented libraries.
I'm curious how much Typed Racket is actually used in the wild. I wonder if it is as esoteric as, for example, Typed Clojure, which is falling a bit out of favor for lots of folks. Would I be likely to find a lot of people who use Racket in this way, or is it a niche part of the community?
It is not really the thing you think it is. A lot of high-profile teams have given up on typedclojure in favor of run-time checks like the Prismatic tools.
This way, if a library needs to expose some functionality to the terminal, just add a Roswell script =]