Oh my goodness. My old lisp tutorials are on HN again.
Before anyone takes potshots, please understand that these tutorials have a very specific purpose: to get our AI students up and coding AI projects as quickly as possible given what they know (C++/Java). So instead of talking up front about the things that make Lisp special, I'm basically talking about how to write C in Lisp. Hence, the tutorials don't ever discuss CLOS, macros, advanced packages, conditions, streams, the type lattice, SLIME, ASDF, Quicklisp, indeed any installable packages at all. Because we get to many of those things, and the wonders of Lisp, later in the class.
We see all the "railroad paths" through the syntactic combinations. Because it's not a recursive grammar, it's practical to unfold everything in one diagram. Instead of bubbles and arrows, he marked it up with LaTeX nested parentheses in 2D.
The whole guide is somewhat similar in flavor to the cheat sheets in mathematics books (trig identities, derivatives, integrals, useful equations, and so on).
> Closures are examples of powerful things which C++ simply cannot do.
Not true anymore. This article seems rather old, considering it refers to Racket as "PLT Scheme" here: http://cs.gmu.edu/~sean/lisp/, so it's at least 7 years old, possibly older.
Closures in the functional programming sense don't really exist in C++. "Closing over" a value means something quite specific, and C++ captures don't do this; they merely copy by value or reference an outside entity. The only way to get close to it is if your C++ lambdas exclusively capture and thus increment the reference count of shared pointers only, and no other types. Not exactly idiomatic.
I don't think this is correct. I'm not sure there are many people that would argue that C++11 doesn't have lexical closures just because its closures need to take into account the semantics of C++ itself. Anyone who says that, doesn't really understand how C++ is used, frankly.
You said it yourself, if you specify generic close by value, you will get the behavior you want. If you know your closure won't outlive the stuff it closes over, you can capture by ref. If you need some other behavior, you use smart pointers and capture by value or mix and match based on what you're capturing.
Just because C++ doesn't automatically figure it out for you isn't an argument against it having closures, any more than not a having bignum or rational built in means it can't do arithmetic.
It's better to call them what they are in C++, lambdas, rather than closures, in my opinion. The flexibility that proper closures provide in functional languages just cannot exist in C++ and mixing the terms freely only confuses the matter.
Maybe a repository and pull requests could be a way to facilitate it. If there was another trusted party with commit rights it would not be so much on you.
I like the early introduction of the debugger. One of the more interesting features of CL, in my experience, is the conditions and restarts system... and built in debugger.
One approach to development in CL is to evaluate a form you would like to have. You end up in the debugger. You write the implementation until the error goes away. Repeat until you have a working system... interactive, hate-driven development at its finest.
In fact that's one of my favourite things about CL: it's so interactive that it almost never crashes. You can still interact with your program, see all of the data, debug it, and continue.
In Common Lisp users use Common Lisp rather than users using programs written by programmers in <language x>. I think it comes directly from the idea of Lisp Machines where typing s-expressions was how users used the computer.
That's radically different from Smalltalk and the Dynabook. Part of its mandate was to be used by children which by definition meant there was an assumption of substantial difference in cognitive capacity between end users and programmers.
That's the intellectual model that's mostly won. It's distinct from a model in which the causal premise for differences in knowledge is expertise and experience.
Incidentally, this is one of the most interesting aspects of the "crank" operating system Temple OS, every program in the language is written in a variant of C that's compiled on the fly, and the shell itself is just a C REPL. I've never used it but found this article very interesting:
>> it's so interactive that it almost never crashes
I learnt game programming and OpenGL from the ground up using CL. If it were not for CL, I probably would not have the patience to hang around.
I used LispWorks OpenGL bindings and with vertical sync integration, live updates to a running OpenGL program after modifying the code is/was super fun.
The biggest advantage I have found using CL is in learning hard topics as you at least have the language and the tooling get out of your way helping you focus on the problem at hand.
>One approach to development in CL is to evaluate a form you would like to have. You end up in the debugger. You write the implementation until the error goes away.
This doesn't sound very sustainable or effective to me... almost all the bugs I encounter in programming are algorithmic in nature. The code compiles without error and runs without crashing, but it just happens to do X instead of Y. The code fails because I didn't understand the problem well enough. That's one thing that computers can't really help with yet.
I think part of the idea is that you write the implementation, test it immediately to make sure it does Y, then restart.
Note that this is not how I really program either, but I've not tried it enough to have an opinion about whether it's effective forme, and I suspect it'll be one of those 'matter of taste' things (I barely use interactive debuggers at all).
If HN had a FAQ this might be near the top. As new people go into CS they seem to be aesthetically drawn to, or repulsed by, Lisp. The irony is there is no objective truth so these two groups of people spend a lot of time supporting their arguments (google search will amaze you, even Paul Graham has been sucked into this) but it's not very common for people to change sides after their initial indoctrination.
I have come to view this as one of few (only?) metaphysical topics seriously discussed in computer science.
Someone on SO once said:
'the correct Lisp answer is more gnomic. Something like: "If you have to ask, you are not ready." Then if anyone questions further, the correct answer is either "yes" if it's an either/or question or "You are not ready."'
> it's not very common for people to change sides after their initial indoctrination.
I was initially repulsed when I saw examples of Lisp code. After I had been in the static, Algol-like world for many years (Pascal, C, Ada, C++) I encountered more dynamic languages like Perl, Java, Python, and Ruby. I was fascinated by things you could do in those languages (especially Python and Ruby), and then learned that Lisp had been doing these kinds of things better for decades. That got me interested enough to move beyond the dislike of things like parentheses.
However, now things are different. There are now several choices of languages that have a mix of expressive power and efficiency that rival or surpass Lisp such that it doesn't stand out as much. I would say it's ability to be customized is now the main feature and curse of the language. It causes some people to love it, but makes it unsuitable for the typical large team project unless you have very strict controls on how it is used.
I've always wondered why LISP was such a hot-topic of discussion for CS people. I'm not technical myself, but the idea of different computing languages being more/less efficient in certain tasks is interesting.
I don't know how valid this is, since I've only spoken with a handful of Lispers, but it seems that they appreciate the freedom and lack of boundaries/rules/limits that Lisp provides. They talk about it like a language that can do anything, because it has no rules on what it can or cannot do.
But at the same time, my friends also remind me that the lack of limits means that they are more accountable for every line of code, and that as a beginner, it'd be best for me to use something more structured (they always say Python) until I'm comfortable taking off the training wheels.
The 'freedom' of Lisp that you're describing comes from a different relationship between the language and the programmer than you have in other languages. In almost all non-lisp languages (including all the popular languages you've heard about), you're a user of the language. There's a set of syntactic and semantic rules provided by the language designers, and you're supposed to use them to express your programs. There's a strong separation between the language designers and the users of that language.
On the other hand, Lisp languages (affectionately called "programmable programming languages"), remove that separation almost completely. As a programmer using a Lisp, you're provided with enough tools to build new syntax and semantic rules, so that the language better matches your problem domain. This is a very powerful technique, but obviously also dangerous.
As a simple example, say you wanted to do OOP in Python, but for some reason Python didn't provide the "class" keyword. At this point, you'd be totally out of luck. Your best bet would be to send a request to language designers, and in the meantime try to program OOP-style in structural code. On the other hand, if someone took away the "defclass" macro from Common Lisp, you could quickly reimplement it yourself and thus introduce OOP facilities that look and work as if they were a part of the language from the start (in fact, building your own simple OOP is pretty much a textbook exercise for lispers).
That much of power can obviously confuse people who didn't do much programming before. It's good to start with a simpler language first - be it something like Python, or even subset of Scheme that's used in SICP, which sacrifices some of the Lisp power for making it suitable as an introduction to programming.
> I've always wondered why LISP was such a hot-topic of discussion for CS people.
Because in a discussion with five CS people, only one has actual real Lisp programming experience, one has some freshman experience in some professor's one-weekend Lisp-like dialect where a run-time type error segfaults, and the other three have different misconceptions about what Lisp is.
The number of times I've mentioned common lisp and gotten "Oh yeah, that's the language with no loops, just recursion, right?" does sadden me a bit.
To clear it up for anyone reading this:
Scheme has tail-call elimination as a requirement of the language; common lisp does not, and even includes an (overly?) sophisticated DSL for iteration in the standard library.
Also 95% of what you learned about lisp in your "Survey of programing languages" course was wrong.
The loop macro may be described as overly sophisticated. However, I can't help but get a chuckle with how much all of the new "stream" based mechanisms in java[1] mimic it. Ironically, with what appears to be more parens.
To be fair, the LOOP facilities are ridiculously complex. Similarly so are the FORMAT facilities.
I regret not knowing more about them as a younger programmer. Most of the "power" of lisp is always shown in the ability to compose programs out of forms. It is amazing how much code you can avoid writing by just using either loop or format. Or both.
I'd be interested to see some data on what the real ratio is.
I suspect that 1 in 5 might actually be high, which IMHO is sad -- not because I think less of those without any kind of Lisp experience, but because I think they are seriously missing out.
For any CS folks (or just developers in general) who have thought about learning a Lisp of some sort, but for some reason have never gotten it done, I would encourage you to do so -- it really is worth the effort.
I know; if any random sample of five CS people could be expected to have 0.9 to 1.1 Lispers in it with a 19/20 confidence, that would be a different world, ha!
Universities sometimes do their fair share to screw this up even further. In my Alma Mater, there is this famous PhD who managed to discourage a generation of students from Lisp by the sole virtue of how she did the classes. :/.
Some languages are absolutely more efficient for certain tasks.
Here are some probably not very contentions examples:
If you pick Brainfuck for your language it will probably take you longer to write your program than Java.
You will probably be able to write a network server in Go faster than you will be able to write it in assembly.
Those may seem contrived, but if you start to compare things that could be actual business decisions it becomes much harder for everybody to remain objective.
You also get to the point for which there may be no universal answer for each programmer. This is at least partly because many programming tasks are quite mundane, and so wouldn't be any faster/slower in general between, for example, Javascript and Lisp. You give them to me and I'll do it much faster in Lisp, while a javscript developer will do it much faster in javascript just because the task is simple enough that individual proficiency with the tools trumps any minor differences for such tasks.
It's common for Lisp newbies to think they can just hack a Lisp program until it works because it's so forgiving. Wrong. Lisp does provide an enormous amount of freedom, and knowing your integers and your buffers cannot overflow, taking the sqrt of -1 just works, and having infinite precision fractions are all pretty great. But you still have to know about algorithms, data structures, and software engineering if you're going to succeed at Lisp.
I think the underlying point of contention is that in Lisp, your code is basically a serialized AST. That gives you considerable power (macros, the ease of "compiling to Lisp" even in a running program), but working that close to the compiler can also be a pretty raw experience.
The only thing you need to do to understand lisp's entrancement is to write an interpreter for it, and in doing so you'll see why it's easier to write a lisp interpreter than it is for any other language. All you need to understand the appeal is a look at https://github.com/kanaka/mal.
Personally I learned the appeal of lisp while following this tutorial on writing a scheme in Haskell: https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_.... There's a reason there'll never be a tutorial like that for a toy Haskell interpreter.
That whole argument "you have to write your own Lisp and then you will see the light" is completely wrongheaded and should be retired. Any computing person with two brain cells to rub together sees red flags in it. Did you build your own bicycle from scratch before understanding the wonder of riding a bicycle? The way Lisp is taught is wrong too; students in some courses are given too many exercises involving hypothetical scenarios in which some half of Lisp is missing and they have to put it back.
A Scheme that someone wrote in 48 hours following a tutorial isn't something I'd want to use in production. It's missing the whole angle of Lisp being a feature-rich, mature language suitable for production use.
A Lisp is valuable because of what you don't have to write in it to get the job done.
You're arguing against the concept that writing one's own Lisp is necessary, and you're right: it's not necessary to implement Lisp to appreciate it.
The post you replied to, OTOH, was arguing that writing one's own Lisp is sufficient, and I think it's right: if one implements Lisp from scratch, one will end up appreciating Lisp. Outside of half-assed homework assignments, anyway.
What people need isn't sufficient so much as efficient.
To appreciate Lisp (or anything) is really to appreciate the underlying requirements (and that they are done).
Some people absorb requirements very well (and then appreciate them) if they force themselves to implement the requirements, which is fine. Even those people can't just confine their appreciation to that which they're able to implement, because then the scope of their appreciation will be rather small.
I really appreciate John Carmack's approach to determining shadow maps for a scene: the clever "cast a ray from a point on the surface to infinity and determine whether it intersects a shadow volume boundary an even or odd number of times" so then you know whether it's in the shadow volume (w.r.t a light source) or not. So we go backwards from a pixel on the screen, to some point on an object's surface. For each such point (consequently pixel) we can determine whether it's in shadow; and we can reduce that to a 2D shadow map in pixel space. Terrific, right? And about the shadow volumes, they are basically just conical shapes made using the 2D contour of the objects as seen from the POV of the light source, and capped at the end somewhere so they are finite. I'm not going to sit here and implement it all though. It's not that I couldn't find the time but that it's out of scope. I can play it out in my head though and see it working which is a good enough facsimile.
I don't mean to imply that I've done this (aside from copypasting from that wikibook). I just think that understanding why it's easy to do this for lisp is important.
Interestingly this is also true of FORTH, which is why we have hundreds of poorly documented FORTH compiler/interpreters and almost no decent libraries or actual programs written in FORTH.
If you are really in a hurry and can't commit to learning the hundreds of forms in Common Lisp, Scheme is a minimalist alternative. The entire language has only a few forms on which make up everything else.
Scheme of 1975 was minimalist and it lacked a lot of things you need, like error handling. Since then Scheme went through various rounds of standardisation - currently Scheme R7RS large is in the works. Plus there are many quasi-standard extensions, based on SRFI: https://srfi.schemers.org.
If you add the usual stuff to Scheme then it is as large as Common Lisp.
Also Scheme is not generally simpler than Common Lisp. Macro programming or control flow in Scheme is not simpler than Common Lisp.
What is simpler than Common Lisp, is the core language used in education to teach programming concepts. For example in SICP a simple Scheme subset is used without any macro programming. But any practical variant of Scheme will quickly approach and sometimes even surpass Common Lisp.
Disclaimer: I like Scheme and love Racket but have an ongoing exercise in Common Lisp. [1]
Common Lisp has the advantage of having done a pretty good job at the hard problem of naming things and so ordinary activities have names with regular semantics like |remove| and |remove-if| -- generally |some-name| tests against a value and |some-name-if| tests against a predicate. Functions on sequences have keywords as supporting parts of speech that make it possible to state intent rather than write an implementation -- Common Lisp contains several domain specific languages that have proven to be useful.
One way to learn them is to read Steele's, Common Lisp: the language.
It's not that a programmer can't write their own version of |copy-tree| and a naive implementation is fairly easy. It's not but nominally more difficult or verbose than writing it in a Scheme or Clojure. The difference is that Common Lisp's built in |copy-tree| is probably sophisticated for performance and robustness reasons. Schemes come out of a pedagogical context and there not having a built-in |copy-tree| can be a feature because of what people may learn by its absence. Racket's Student Languages push this toward the limit.
To put it another way, Assembly Code has fewer constructs than Python, but often there is an advantage that comes with Python's higher level abstractions.
There's more stuff in Common Lisp, but once I learned the concepts behind how the naming worked, a lot of them didn't need to be learned as much as I just assumed they were there.
The "standard library" is large, but really well thought out. Writing in Scheme, I'd often need to implement functions that I knew were already in CL, so Scheme ends up being more work in the long run.
And it's not like a person needs to memorize all of the language constructs before using it. The REPL in Slime is incredibly helpful in discovering functions and verifying how they work, and Stack Overflow or web search can be really helpful finding out if a particular function is built-in or not.
R7RS doesn't seem to define special forms per se; it considers anything other than define-syntax, literals, variables, calls, lambda, if & set! to be derived expression types; I think quote & quasiquote probably have to be considered special forms in at least some senses.
Scheme itself is a minimalist language, but a practical Scheme must add in plenty of functionality not specified in the standard. A truly useful Scheme will thus be roughly as big as Common Lisp, or bigger — only much less of that bulk will necessarily be standardised & portable.
This probably depends on your implementation of choice and what counts as "everyday" programming.
Racket has a minor language for shell mix-ins[1] and Racket itself has some nice ways of dealing with command-line arguments[2]. However, all command-line arguments are passed as strings, which means extra steps in converting them to native types (numbers etc.). I find it very pleasant and Racket in particular has both a good standard library and a whole bunch of libraries that probably cover a majority of what one might need for smaller tasks. But again, it depends on what you consider "small-scale programming"
Scheme is absolutely a suitable replacement for perl or ruby, but the ease with which you can accomplish things will depend on the set of libraries available, which varies a lot between implementations.
Racket is not just Scheme anymore, but it does still support various versions of Scheme as well as a number of Scheme-based languages. It has a package management system and a fairly large set of packages for basic tasks. The core system, base libraries, and major libraries are well documented and it's got a great built-in IDE.
Guile also does more than just Scheme, but it's been the "official extension language of GNU" for a very long time, so it's got bindings to a lot of libraries and it's used in some interesting applications and tools.
Chicken Scheme also comes with a package system, 'eggs', that has a pretty nice collection of practical packages available for easy installation. You can run your programs via the interpreter, or you can compile them via the compiler, which goes through C so it's got great C interop.
There are a lot of other options with a variety of strengths and weaknesses, but those are good ones to look at for starting out and doing scripting duties.
First, there are many different Scheme implementations and they differ significantly. The standard is small and SRFIs not always sufficient, so implementations invent their own extensions. There is some review of available options here: https://wingolog.org/archives/2013/01/07/an-opinionated-guid...
Personally, I use Chicken Scheme for command-line utils (thanks to AOT compilation Chicken Scheme programs start-up time is much shorter) and Racket for GUI programs. Both implementations offer stability, ongoing development and a package ecosystem which has most of the things I need. They also provide extensive tooling, with Racket going as far as providing an IDE and visual debugger.
Most of the problems you'd have when replacing PERL or Ruby with a Scheme would have to do with library/package availability. If your use-case doesn't require a library which your Scheme lacks it may be a suitable replacement for PERL, Ruby, Python or JavaScript (node).
Both Scheme and Common Lisp are suitable replacements for basically any scale. Most Scheme implementations do implement large (the most useful) parts of the functionality of Common Lisp not in the Scheme standards.
Perl and Ruby want to be suitable replacements for Scheme, not the other way around. The authors of these languages were well aware of Lisp and many features and aspects are imported wholesale. These systems amount to the author's critique of Lisp -- what they felt was lacking in syntax or style or hygiene or principles. Ruby says, Scheme is okay but why not more convenient syntax for objects? Perl says, Lisp is cool but why not a maddening assortment of wingdings?
Scheme and CL bicker over whether an empty list embodies the concept of falsehood. JavaScript says wat? And Haskell is like, lol.
For tasks where Perl and Ruby shine, I don't think generic Scheme is a great replacement. Maybe scsh (https://scsh.net/) or (not Scheme, but Lisp) kazinator's TXR (http://www.nongnu.org/txr/)
Yes. It will probably take a while for you to become comfortable, but once you have become fluent with irregex and the other very nice libraries, there is no going back.
Then here are some very nice SRFIs around to do most of what you want, and I believe chicken comes with basic pattern matching facilities as well (although not as sweet as the ML-type which are checked at compile time).
Bonus: it's also really really sexy once the logic of why there are parens become apparent... (post understanding a bit about functions that return functions, the meaning of REPL and a bit about the implementation of macros).
The Lisp library ecosystem is not as organized as that for some other languages. But, quicklisp succeeded in giving a good central point and simple access to libraries. Some reasons for the situation are historic, but some result from the fact that there is not a canonical Lisp implementation as for languages like python, java or perl. The commercial Lisp implementations (and most open source ones) ship with their own set of supporting libraries, so you are less dependent on third-party libraries to get stuff done.
But to everyone who wants to get started with Lisp, I can only recommend not to focus on libraries first. Between what the language includes (especially Common Lisp), and what the implementation ships with, you should be set up to do a lot of serious programming. If there is anything, which you cannot do with the default environment and with what you cannot implement faster yourself, then its time to use quicklisp to add the missing pieces. But having written some pretty large Common Lisp programs myself, they tend to depend on only a very few external libraries.
Seriously. I just started looking into Common Lisp last weekend, and if it weren't for the active communities on Reddit and IRC, you'd get the impression that the language was abandoned some time in 2012.
Common Lisp is a very stable language. The standard hasn't changed in twenty years, so (unlike many other languages) old code is still perfectly good. Libraries that haven't been updated in a decade still work just as well as they did a decade ago.
It's not just that standard hasn't changed in almost twenty-five years, most of it was agreed upon in the early 1980's and it was developed by consensus among a language community of working programmers and commercial interests.
This is nice to know. Do Quicklisp packages typically come with test suites? At least then I can check if a package will work before I commit to using it.
Not only do many of the do, it is common practice for release candidates of asdf, sbcl (and probably other implementations) to run those tests against release candidates as a regression test.
But unfortunately not all libraries set up their test-ops properly. You can usually find a readme at ~/quicklisp/dists/quicklisp/software/... which might have instructions for running tests.
My subjective impression regarding third-party libraries specifically is that if anything, the situation has improved a lot in the past 5 years, mainly due to Quicklisp becoming the de-facto standard. Now there's a curated collection of libraries that are tested to work across multiple CL implementations, pull dependencies properly, etc., instead of the previous mess of manually downloading .tar.gz from random places on the internet.
But if you look at Clojure libraries, some of them were last updated in 2012. That's because clojure solves problems (& it's not that the maintainers have disappeared) :)
A funny thing is: A typical response from CLers to this type of comment is "yes CL can handle large projects". There is a definition gap, though, where one imagines a project that is "large as in a company", i.e. a large project that involves many people, while another imagine that is "large as in a system", a project with a large SLOC. And they are sometimes mixed.
CL can handle a large SLOC, as evidenced by the fact that the huge compiler such as SBCL itself is written in CL. But it won't be as popular as Java or C++ are, so it would become a problem when CL faces a project which is "large as in company".
SBCL is not really that large in LOC, though it has some complexity. It's a mid-sized Lisp program with some complexity, since it implements a type inferencing native compiler with backends for various platforms. SBCL itself was derived and simplified from the CMUCL implementation.
There are some CL code bases with millions of lines. But even a million line in todays terms is not much for some companies which are using other languages. If we look back, the operating system and basic environment (GUI, IDE, basic apps) of the Lisp Machine OS was around 500 kloc. Later versions with more stuff and some applications were nearing 2 Mloc. The commercial CL companies (Franz, Harlequin/LispWorks, Lucid, Xerox, TI, LMI, Apple, Goldhill, DEC, ...) usually should have developed code bases with +1MLOC already in the 80s / early 90s. Some Common Lisp based CAD software was/is in the range of 5-10 MLoc. Some application code might be much larger. For example Boeing has whole jet aircrafts designed in Lisp using the now discontinued iCAD application.
> so it would become a problem when CL faces a project which is "large as in company".
Common Lisp has been used in environments with up to 300 developers. This is not really a large number, but a larger number of what people typically think of a Lisp project. Symbolics, the Lisp Machine company, had at max 1000 employees - with probably a third of that software developers. Lucent developed network switches in the 80s/90s with 100+ Lisp developers. ITA was developing their flight search engine with a 100+ team with a lot Lisp developers. There are also smaller companies with a long history - for example Cyc is being developed using Lisp since thirty years.
One problem was/is finding these people. An old saying was that there were more Lisp Machines than developers able to use them. Today it would be even more of a problem, since the number of interesting Lisp projects at universities is smaller than what we had in the 80s/90s. Thus fewer students get in contact.
Probably a good idea to visit the European Lisp Symposium in Brussels, April 2017. Meet some fellow Lisp users from academia, industry, ...
So one of the first recommendations on that site is for the Clack family. The first link to clacklisp.org has now started pointing to the github project. For a long while before that it was just dead.
Clack, whilst being a great concept suffers from a lack of documentation. What documentation is there is confusing. It seems Clack has in the past couple of years been split out into a separate project - Lack. There's no documentation around as to why this has been done. I can't find details on how to write middleware for it. I need to look through the source.
I'm trying to get Ningle working. The Redis session middleware seems broken. It doesn't seem thread safe at all. I seem to have other problems with by body parameters being mutated as it passes through the middleware.
I have gotten very close to just dropping Clack and moving onto raw Huchentoot or Allegro serve, but it saddens me that a project with such promise shouldn't get the love it deserves so I will probably persist and hopefully help to improve the project.
Don't get me wrong, I love Common Lisp as a language and use it daily. But problems like this are just standard.
Yeah, I am liking clack and I really need to get off my butt and write a tutorial or something for it. It's much less complicated than it looks. However, I agree that much of the middleware that ships with it is at a level I would call "Proof of concept" rather than "Production ready."
I agree about the lack of documentation being a major pain point in the ecosystem.
As far as web projects goes, this looks promising: https://github.com/Shirakumo/radiance Shinmera puts a lot of effort into finishing his libraries and documenting them well, so I expect that this library would be nicer to use than many of the alternatives.
If you use microprocessors from companies like AMD and Intel, there is a good chance that parts of their design were checked with large amounts of Lisp code.
> This directory contains an ACL2 library of register-transfer logic, developed at AMD from 1995 to 2011, and at Intel from 2012 to the present, in support of the mechanical verification of the floating-point arithmetic units designed
during those periods by the respective companies.
No, lol, it's exactly normal compilation. It's a buzzword that differentiates languages without normal compilation (esp using VM's or interpreters) from special implementations of them that do support that. The latter have "AOT" compilation. Wikipedia states the difference is AOT compiles the bytecode of an existing VM. It's still just a compiler, though, given the end result is mostly the same.
Yeap. It's quite a common linguistic phenomenan, when a term like JIT stops being a fringe thing and enters mainstream discourse among an audience, what used to just be "normal" now gets a name.
"Imperative programming" might be another one. IRL, think about how "cisgender" has entered into mainstream vocabulary in the past few years, or "heterosexual" many years before that.
Yes, because nowadays VM with dynamic compilation are a thing on mainstream computing, which used to be only available on mainframes or specialized hardware systems like those developed at Xerox PARC, DEC and ETHZ.
So ahead-of-time compilation, as linguistic term and CS literature, was born as a way to differentiate from dynamic compilation.
Not just AOT; you can also easily compile new functions at runtime, and then even serialize the entire program's state, including JIT-compiled functions, into a new compiled image that starts instantly.
An old write up, but it shows the style of repl programming. I have been using Common Lisp since the 1980s, and for me it is all about using a bottom up interactive programming style - same as programming in Haskell, Ruby, Python, Scala, etc.
Since Lisp flamewars are to the average Hackernews what catnip is to a cat, Hackernews pounces on a years-old quick-start guide to Lisp for university students who took AI as an elective to meet their major requirements, and who will likely end up hating Lisp with the fury of a thousand suns by the time they graduate.
The Clojure Inquisition stops by to remind everybody that what really matters in programming languages is how many hipsters you can attract into your fan base.
Would you please stop making up generalizations about Hacker News to score rhetorical points? It indulges the desire to feel better than everybody else, which gets upvotes since (ironically) everybody loves having that indulged. Nevertheless it makes for a bad HN comment because its underlying message is just "Look at me." I recommend listening to https://www.youtube.com/watch?v=mmb7TU0OrOI instead.
I emphasize this because you posted https://news.ycombinator.com/item?id=13943374 a few days ago, which was a particularly dismaying example. Comments like that basically activate a bug in human firmware to the detriment of substantive discussion.
Oh please. My goal was not to score rhetorical points but to make HNers crack a smile in the style of http://n-gate.com/hackernews/
If you think I'm being overbroad in my generalizations, of course I am. As they say, "That's the joke."
I'll stop but only under protest, and with the note that I think HN administration is misreading the effect this has on people. (Hint: it's funny because the average Hackernews sees a little of themself in the n-gate posts, not because they feel smugly superior.)
Before anyone takes potshots, please understand that these tutorials have a very specific purpose: to get our AI students up and coding AI projects as quickly as possible given what they know (C++/Java). So instead of talking up front about the things that make Lisp special, I'm basically talking about how to write C in Lisp. Hence, the tutorials don't ever discuss CLOS, macros, advanced packages, conditions, streams, the type lattice, SLIME, ASDF, Quicklisp, indeed any installable packages at all. Because we get to many of those things, and the wonders of Lisp, later in the class.