Related
I'm interested in seeing how low-level a programmer can go in pure Common Lisp (or, failing that, in implementation-specific extensions). Google hasn't been able to find me much information about this, so I'd like to hear what the experts have to say. This post mentioned a feature of SBCL to define what the author called "virtual operators", but searching for "common lisp virtual operators" didn't yield much. The author also mentioned how hard it was to find documentation about it. Do similar systems exist for other implementations, is there any basis for it in the standard (though considering that such a feature would mostly be used for writing ISA-specific code, portability shouldn't really be high on the priorities for users of it), and where can documentation for features such as this be found?
It would be great to find a way to extend the "programmable programming language" concept to low-level code as well (especially for areas where efficiency is highly important and other libraries written in C or assembly may not be available).
This is very implementation specific and not portable at all.
Yes, SBCL uses VOPs, but other implementations have completely different compilation targets.
If you intend to go low-level in a somewhat portable way, you have two avenues:
Optimize using declarations, inlining, manual unrolling etc., checking your progress with disassemble
Implement a static blob externally, then interface it with an FFI
I am somewhat familiar with Scheme. I am reading OnLisp, and would love to do a real world project in it. Most likely web development. I would love to know what kind of setup people use to develop websites in lisp. I have a couple of macs at home and I have figured I would use clozure cl. I am wary of a few things though. I have read on the internets that cl doesn't have reliable threading facility nor good networking. Is this true? What was your experience?
PS:Don't tell me about clojure :). Lisp is a itch I need to scratch.
Currently I'm using Restas a framework based on Hunchentoot and inspired by the route system of Rails. I also use Postmodern to interact with a PostgreSQL database and I generate HTML with cl-markup though I'm thinking about switching to cl-who which looks more customizable.
When I've started I've also considered using Parenscript to generate the JavaScript but now I'm just happy with Mootools and plain JavaScript.
Everything runs on SBCL and is available with Quicklisp.
Not sure why it wouldn't have "good networking"; you can't rely on threads if you want to write a portable Common Lisp application since certain implementations don't support them (AFAIK, just clisp, though you can compile it with experimental thread support). If you plan on picking an implementation and sticking with it, you won't have that problem.
The "standard" CL web stack is Hunchentoot/cl-who/clsql, though you can find tutorials that run on Araneida or Portable AllegroServe.
The setup I use is Debian/SBCL running quicklisp and the above systems along with MySQL (though I'm seriously considering jumping over to Postgres) for the database and nginx to run in front of Hunchentoot serving any static content.
mck- has been maintaining the heroku common lisp webapp.
https://github.com/mck-/heroku-cl-example/tree/
The problem with Common Lisp's "networking" is, we don't have sockets in CL standard, so each implementation has it's own socket API. We have some attempts to give a common interface though, like usocket. You can find a list of networking related packages here.
If you need a web framework, look into Caveman. I haven't used it yet but it looks like the most complete CL web framework I've ever seen.
I've worked on a number of products that make use of code generation. It seems to be the only way to achieve both a high degree of user-customizability and high execution speed.
The downside is that we are requiring users to install a compiler (primarily on MS Windows).
This has been an on-going headache, because vendors like MS keep obsoleting compilers, and some users tend to have more than one compiler installed.
We're considering using GNU C, and possibly C++, but even there, there are continual version issues.
I've considered possibly generating assembly language, in an effort to get off the compiler-version-treadmill, but assembly languages are all machine-specific.
Ideally there would be some way to produce generated code that would be flexible, run fast, and not expose us to the whims of third-party providers.
Maybe I'm overlooking something simple, like Java. Any ideas would be appreciated. Thanks.
If you're considering C and even assembler, take a look at LLVM first: http://llvm.org
I might be missing some context here, but could you just pin yourself to a specific version? E.g., .NET 2.0 can be installed side by side with .NET 1.1 and .NET 3.5, as well as other versions that will come out in the future. So as long as your code makes use of a specific version of a compiler, what's the problem?
I've considered possibly generating assembly language, in an effort to get off the compiler-version-treadmill, but assembly languages are all machine-specific.
That would be called a compiler :)
Why don't you stick to C90?
I haven't heard much of severe violations of standards from gcc's side, if you don't use extensions.
And you can always distribute a certain version of gcc along with your product, say, 4.3.2, giving an option to users to use their own compiler at their own risk.
As long as all code is generated by you (i. e. you don't embed your instructions into other's code), there shouldn't be any problems in testing against this version and using it to compile your libraries.
If you want to generate assembly language code, you may take a look at asmjit.
One option would be to use a language/environment that provides access to the compiler in code; For example, here is a C# example.
Why not ship a GNU C compiler with your code generator? That way you have no version issues, and the client can constantly generate code that is usable.
It sounds like you're looking for LLVM.
Start here: The Code Generation conference
In the spirit of "might not be to late to add my 2 cents" as in #Alvin's answer's case, here is something I'd think about: if your application is meant to last for some years, it is going to face several changes in how applications and systems work.
For instance, let's say you were thinking about this 10 years ago. I was watching Dexter back then, but I guess you actually have memories of how things were at that time. From what I can tell, multithreading was not much of an issue to developers of 2000, and now it is. So Moore's law broke for them. Before that people didn't even care about what will happen in "Y2K".
Speaking of Moore's law, processors are indeed getting quite fast, so maybe certain optimizations won't be even that necessary. And possibly the array of optimizations will be much bigger, some processors are getting optimizations for several server-centric stuff (XML, cryptography, compression and regex! I am surprised such things can get done on a chip) and also spend less energy (which is probably very important for warfare hardware...).
My point being that focusing on what exist today as a platform for tomorrow is not a good idea. Make it work today, and surely it will work tomorrow (backward-compatibility is especially valued by Microsoft, Apple is not bad it seems and Linux is very liberal about making it work as you want).
There is, yes, one thing that you can do. Attach your technology to something that just won't (likely) die, such as Javascript. I'm serious, Javascript VMs are getting terribly efficient nowdays and are just going to get better, plus everyone loves it so it's not going to dissappear suddenly. If needing more efficiency/features, maybe target the CRL or JVM?
Also I believe multithreading will become more and more of an issue. I have a gut feeling the number of processor cores will have a Moore's law of their own. And architectures are more than likely to change, from the looks of the cloud buzz.
PS: In any case, I belive C optimizations of the past are still quite valid under modern compilers!
I would stick to that language that you use for generating that language. You can generate and compile Java code in Java, Python code in Python, C# in C#, and even Lisp in Lisp, etc.
But it is not clear whether such languages are sufficiently fast for you. For top speed I would choose to generate C++ and use GCC for compilation.
Why not use something like SpiderMonkey or Rhino (JavaScript support in Java or C++). You can export your objects to JavaScript namespaces, and your users don't have to compile anything.
Embed an interpreter for a language like Lua/Scheme into your program, and generate code in that language.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm working on a toolkit (sort of a live-CD Lisp-in-a-Box) for people new to Common Lisp, and I want to make sure it is broadly satisfying. What is attractive to you about Lisp? What do/did/would you need to get you started and keep you interested?
What I have so far: SBCL 10.22, Emacs 22.3, SLIME, and LTK bundled together and configured on a Linux live-CD that boots entirely to RAM.
I've now released the result of this; it is available at the Thnake website.
I would include at least cl-ppcre, clx, Hunchentoot, and Weblocks.
I guess that you would have to negotiate with the respective authors, but including "On Lisp", "Practical Common Lisp", and "Successful Lisp" would be a great asset for the CD.
What would be really nice is to use stumpwm as the window manager on your live CD.
Emacs almost prevented me from learning Common Lisp. It took a lot of effort to slog through it. Emacs and SLIME are too much for a beginner and will never be broadly satisfying to beginners. If I want to learn a new programming language, I want everything else to stay out of my way while I learn it. The task of learning Lisp is hard enough without added technicalities and complications of setting up an environment. Isolate the variable.
Set up SBCL with rlwrap or an equivalent. rlwrap supports very basic paren matching and history searching and can even do tab-completion. Not as fancy as SLIME but a beginner doesn't need SLIME. A beginner needs to be able to run hello-world without spending an hour fighting Emacs. Provide Emacs/SLIME as an option but don't require it.
My suggestion is to include an HTTP server like Hunchentoot and a popular web framework. I suspect that most people that want to learn Lisp these days do so because of reading Paul Graham, and wanting to mimic his success at building Viaweb, so being able to easily create and modify powerful web applications would be a strong selling point for your live CD.
Include Emacs, of course, but you might want to have something gentler.
The Lisp environment I found easiest to slip into was Macintosh Common Lisp, with the FRED editor (Fred Resembles Emacs Deliberately). Digitool didn't successfully make it into the current era of Macs, but they open-sourced a lot of their stuff as they folded. Try www.clozure.com or search for "openmcl" on Google.
There was a project to get the Fred environment running on Openmcl, but I don't know the status offhand (I haven't done anything with Lisp in a long time, and haven't been paying attention on the mailing lists).
So, my recommendations:
Ask Paul Graham if you can include "On Lisp". Since he's giving away a download for free, the odds are good that he'll give permission. (His other excellent Lisp book, "ANSI Common Lisp", is apparently still selling, so it's unlikely he'll give you permission there.)
At least check out the MCL stuff to see if there's anything you can find to make it easier. Emacs is a great Lisp environment, but it's a bit intimidating for the beginner.
I haven't looked at the SBCL documentation lately. Is it fairly readable and beginner-friendly? Perhaps somebody could write up some quick instructions on how to get going and how to debug. Emphasize mouse use at first, even if using Emacs.
What would really get me interested in Common Lisp is a modern set of libraries at the level of .net or Java, as well as some really good documentation that isn't gnarly.
In terms of software, a nice gui editor along the lines of notepad++ or jEdit would be good. Emacs/vi & text-based editors always seems quaint and antiquated for serious development.
Reading Paul Graham makes me want to learn Common Lisp. But if I actually sit down to try learning it, the urge subsides.
Everything in clbuild (http://common-lisp.net/project/clbuild) should be a good candidate to be included. Incidentally, all packages in your list except Emacs are also managed by clbuild. I think it'd be good if the collection of projects in clbuild could gather some momentum towards standard-common-lisp-library-hood.
This does:
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
Of course I'd also like to learn more Python 3.0, erlang, and F#. I believe that functional languages (not to say that Python is a functional language) provide just a different perspective. The more perspective you have the better solutions you can architect. It is all about using the right tools for the job too, but if you don't at least have familiarity with something you might never think to solve a problem with a particular tool. I guess it goes back to the old saying that to a carpenter everything looks like a nail. I do not want to be hammering C# into everything when there are better solutions available. Also, times change and fads do with them.
Emacs does have a bit of a learning curve, but it is great for serious development -- no pesky mouse-driven gui bling in the way of the (text-based) code.
Out-of-the-box CUA-mode is enabled these days (so C-x, C-c, C-v works "standard"), and there is a menu with file-operations like save, etc, so it shouldn't that hard of a slog, if it's all pre-packaged. But pre-configuring the .emacs file to ensure that CUA mode is enabled, SLIME doesn't have to be configured by the user etc. is a must -- plus perhpas more documentation within for the user for .emacs configs - links to EmacsWiki, etc. (hrm, if this is on a CD, it's unlikely that the user would be configuring it themselves, isn't it....)
I have some interest in learning Lisp, but I don't 'like' most of the resources available. How about extending this project to the creation of some sort of a "community" responsible for providing tutorials or something, in order to make Common Lisp more popular and easier to learn? Bad/weird/useless idea?
I think the idea of including tutorials is an excellent one.
In addition to the ones already stated, there is both the easiest book for newbies on lisp (A Gentle Introduction to Symbolic Computation) and several excellent websites hiding out there on the web that people should know about. Here they are:
A Gentle Introdiction to Symbolic Computation
Learning Lisp
Casting Spels
Learning Lisp Fast
As far as I undertand you are doing Thnake.
Thank you for greate live distro!
I tried it couple of days before and found it rather impressive and interesting.
There are couple of things it obviously lacks, such as LTK since you have already included Common Lisp and Tcl/Tk. And since there is gtk, you can include bindings and documentation for CL and Python.
Also there is a need in Lisp Hyperspec, and preconfiguaration of Slime to use it. (Same for documentation for Python and Tcl) May be it would be better to add emacs-w3m for fast and convenient documentation browsing.
There's always Practical Common Lisp, a book on Common Lisp which is readable in its entirety online. There's also a packaging of Emacs with a CL implementation meant for using along with the book.
You should definitely add Vim too, configured with the RainbowParenthsis plugin.
rlwrap for SBCL is a good idea, and so is (require :sb-aclrepl).
Weblocks should come with cl-prevalence and maybe Elephant/BDB, too.
I am a college student at a school that teaches mainly in Java. One of the strong points of Java, which I quite enjoy, is the large collection of libraries. What makes these libraries especially useful is the extensive documentation and organization presented via JavaDoc. Are there any library collections for Common Lisp which also have these qualities, and is there a tool similar to JavaDoc which would assist in the building, maintaining, or expanding of these libraries?
Yes there are extensive, documented library collections at http://www.cl-user.net,
http://www.cliki.net and http://clocc.sourceforge.net. As well as advanced 'asdf' or 'mk-defsystem' base infrastructures to use them.
No, there is no comprehensive, consistently documented library collection. The inexistence of such a thing is Common Lisp's biggest problem right now. If you're interested in helping the Lisp community, this may well be the thing to attack first.
Also, while there are various JavaDoc equivalents, there is no widely accepted quasi-standard as for Java.
Now there is quicklisp and it made everything so much easier!
http://www.quicklisp.org/
Github contains a lot of lisp projects, not to mention Sourceforge
Try cliki or common-lisp.net.
As to javadoc...you know about docstrings? If not, find out. Also find out about all the other self-documenting features.
It sounds like you haven't read the spec. Always read the spec, whatever you are doing.
I recommend clbuild, which contains a collection of quality libraries compiled by a group of experienced, discerning lisp programmers (as well as script to download and install those libraries).
If you want guidelines for writing highlevel/api documentation, I suggest you follow the examples set by Edi Weitz and others (e.g., see Hunchentoot, Vecto).
For lower level implementation documentation, I think the built-in docstring mechanism together with Slime's source navigation and autodoc facilities comprise the best existing environment for code exploration.
Tinna is a Lisp documentation system that is comparable to JavaDoc.
There are many available libraries for Common Lisp and many of them are thoroughly documented. JavaDoc, in my own experience (or any such tool like Doxygen for C++), is not a valuable tool to document a library but more to document its implementation.
So documentation is not a matter of tools here, but of will of the lib's author to write a decent manual. In this area, Common Lisp is like any other language: there are beautiful pieces of engineering with wonderful documentation, quick and dirty code without the slightest sign of documentation, as well as all possible combinations of code and documentation qualities...
All in all, I personnally found that Common Lisp libraries have a pretty high overall quality.
If you are used to Java, you may give Clojure a chance and keep using the Java libraries you know.