A new version of Common-Lisp.net has been launched
common-lisp.net
common-lisp.net
The SBCL compiler actually has a type inference engine built in to it.
> compile time type checking
Aren't those the same thing?
For example if you know that + is defined for numbers, then you can inference that a and b must be numbers: (+ a b)
If you know that a and b are numbers then you can inference that subexpressions need to deal with numbers only:
(let ((a c) (b d)) (declare (type number a b)) ....)
Allegro CL and LispWorks for example are doing this type inference. But their compiler will not tell you that type declarations are violated.
SBCL OTOH treats type declarations as type assertions which can be checked at compile time. ADDITIONALLY it also does type inference - and additionally uses this information for compile time type checks.
OK, on that definition, of what possible use is a type inferencer? Aren't they useful only as a component of a compile-time type checker?
Basically CCL's compiled code is often as fast as code from SBCL, LispWorks, Allegro CL. But one has to declare much more types of variables and functions explicitly with CCL. The code needs to be littered with type declarations.
A compiler with a (better) type inferencer can propagate the type information it already has and this is often enough for fast code. A good compiler can then also tell the developer where it lacks type information and then you can decide to declare types explicitly. SBCL/CMUCL does that in a very noisy way with lots of information generated by the compiler. ;-)
See for example: http://home.pipeline.com/~hbaker1/TInference.html
EDIT: lispm is right, too, of course. You can look at it either way. If your program required top performance and you were going to tag every type until it ran super fast, then inference buys you the convenience of not needing to do as much. If you weren't going to bother with that, then inference buys you extra performance without all the effort.
EDIT: as a non-native speaker I distinctly remember first reading the word and happily using it ever since, when appropriate.
Wait, is that really not the standard behavior?
A compile time type checker is expected to signal errors at compile time for programs whose types don't check out.
You can use a type inferencer without signaling any errors at compile time (for example, by deferring errors to runtime) and you can signal type errors at compile time even if you don't infer any types (like C compilers, that demand all variables have a declared type).
CCL itself is multi-platform but the IDE is currently Mac-only.
But why is it 'high performant' compared to other implementations? Like say CMU CL(now SBCL).
For example, in this case why would one use Clozure CL instead of SBCL?
Same thing. Franz is the company. Allegro Lisp is the product. Like "Apple Macintosh computer."
> But why is it 'high performant' compared to other implementations? Like say CMU CL(now SBCL).
Somewhat better compiler, but mainly lots of extra features (better debugging, graphics, better libraries).
> why would one use Clozure CL instead of SBCL?
I use CCL because 1) I like the IDE and 2) its compiler is fast so you can always compile everything essentially for free. In other CLs you have to choose between running in compiled or interpreted mode, and that can sometimes cause problems. CCL doesn't have an interpreter at all. It always compiles everything and that makes it easier to use.
SBCL is essentially a compiler-only implementation of Common Lisp. That is, for all but a few special cases, eval creates a lambda expression, calls compile on the lambda expression to create a compiled function, and then calls funcall on the resulting function object. A more traditional interpreter is also available on default builds; it is usually only called internally. This is explicitly allowed by the ANSI standard, but leads to some oddities; e.g. at default settings, functionp and compiled-function-p are equivalent, and they collapse into the same function when SBCL is built without the interpreter.
http://www.softwarepreservation.org/projects/LISP/maclisp_fa...
Just to add to the above, I like CCL because it gives nice compiler messages --sometimes it warns me about things SBCL won't notice.
https://franz.com/support/documentation/10.1/doc/debugging.h...
Also, it may not be necessary to master the most complicated machinery: compiling function by function gives lots of hints, and the very nice [log4cl](https://github.com/sharplispers/log4cl/) is handy.
Hey, I apologize if that was something that hurt you in anyway.
I discovered Lisp a few months back, I had of course heard of it long back, but kind of discovered using it only months back. I don't code in Lisp at day job or full time. But many of my problems related to understand data structures and algorithms have vanished since I started thinking of them in Lisp.
Mostly because I started to think in terms of recursion well, and other list manipulation stuff feels like it just comes to naturally. Not sure why this, or its unique to me. But for some reason I find it very easy to think and work with trees and graphs when I think of them as lists.
Always looking forward to learn and do more.
Yeah, most of incidental complexity vanished away once I start using clojure. Lisp is pretty cool in that there is very little to learn in way of syntax and ceremony.
If you are new to functional programming, I suggest understanding reduce well. Understanding it forms the basis of higher order functions. Also half of clojure core is implemented with reduce.
Also, I highly suggest watching the talk “simple made easy”. One hour of time spent there pays off in many many months/years
The 'fast' Lisps are often the native Lisps (SBCL, Clozure CL, Allegro CL, LispWorks, Lucid CL, ...). For selected applications some implementations were more specialized (for example GCL with fast numerics for Maxima)...
SBCL has the advantage of some more advanced type handling.
But fast isn't just low-level benchmarks. It might mean fast for a certain application. For example on the Deep Space One spaceship the application was deployed with LispWorks (and not OpenMCL/Clozure CL) because LispWorks had the best GC (soft realtime) and could be running on a hardened PowerPC processor on a real-time OS.
And 'fast' in Lisp is also important for mostly unoptimized, but compiled, code with full runtime checks and lots of flexibility. Stuff which would be 'full debug' mode in C++. For example the typical Lisp Machine OS could run in a full development mode without much runtime speed penalty - just lots of space penalty. It still had to deal with the window system (written in Lisp), disk access (written in Lisp), interrupt handler and scheduler (written in Lisp) ... Is that 'fast' enough for the interactive user? Benchmark-wise the system might be slow, but it might perform well for applications running multiple threads and lots of interrupts.
Imagine your application is a CAD system written in Common Lisp with CLOS (there are and were a bunch of those). It might need a large address space and zillions of CLOS objects. Will it run fast enough for interactive 3d workloads? How fast is the GC? How fast is the CLOS implementation? How does it deal with FFI operations into OpenGL... Stuff like that had been developed with Lucid CL and Allegro CL. At a time when CMUCL still was printing GC messages to the terminal...
Nowadays a lot of machines are "fast enough" and have lots of memory. But when one needed a 64bit SGI for a demanding application, Allegro CL was the thing to use. I think the IDE for Crash Bandicoot was Allegro CL on an SGI. Later similar graphics applications in Lisp ould also run on large Windows NT machines with faster graphics cards. Today Allegro CL is also the only CL one I know, which has a partly parallel GC - a demanding application like their database and knowledge-bases drives the need for faster runtimes. Lucid CL no longer exists (though LispWorks provided support for it), but it had a compilation mode for full-program compilation, which enabled good runtime performance. Many commercial applications had been deployed with it - until the company went away - after investing lots of money into an advanced C++ IDE which did not fly on the market. With something like LispWorks and Allegro CL one can develop normal-looking and fast applications for the desktop - stuff which feels much less sluggish than your typical Java desktop application and has useful interactive performance.
>>Imagine your application is a CAD system written in Common Lisp with CLOS (there are and were a bunch of those).
For some one considering seriously writing Lisp as a full time job, are these kind of opportunities still there?
I mean how big is Common Lisp usage these days?
Syscog is a Portuguese company focused on Lisp based solutions.
http://www.siscog.eu/index.asp
https://franz.com/success/customer_apps/scheduling/siscog.lh...
Seconded.
http://www.andrewlangman.com/articles/the-missing-lisp-book....
Or, more seriously, I think an O'Reilly book on common Lisp would go a long way toward promoting the language. As would one from the Pragmatic Programmers.
Though it is an alien...
Btw., for a decade or so O'Reilly actively refused to publish Lisp books - which did not make them very liked in the community.
Interesting, any idea why? I would have thought they would have been happy to publish Lisp books, since they have published books on so many other computer subjects. I used to be a huge buyer and reader of their books. Only reason I can think of for them not wanting to publish Lisp books is perceived small market size - do you think that was it? But on the other hand, they did publish books on topics like XML-RPC, which was probably not very much used even when they published a book on it. I had that book, it was about using XML-RPC from multiple languages [1].
[1] Programming Web Services with XML-RPC:
We're NOT looking for:
Books that overlap too heavily with our existing books. Books on proprietary technologies that don't have a huge user base. Books on miniscule (i.e., personal or nascent) products, even if they are open source. Books on topics that have dismal sales despite quality books being available. (If you're addressing a topic where good books have sold dismally in the past (for instance, LISP, LaTeX, or Web-based training), you have a much higher threshold to clear with your proposal. Convince us why there is a revival of interest in your topic, or why your approach to a deadly topic will provoke interest nonetheless.) Books that have been rejected by other publishers, in most cases.
I guess the problem with writing such a book is finding a market for such buyers.
There are some very good lisp libraries on github that aren't in the project list, such as many of the web libraries I use every day like https://github.com/fukamachi/caveman or https://github.com/fukamachi/dexador
I've also started a new library for creating a Solid Pod host https://github.com/gibsonf1/cl-solid
Is there a way to elegantly link to github projects as well?
As one of the few programmers who has worked in CL commercially in this century, my general analysis is that the language has way too much rope. The code base I worked on wasn’t too clever by half, it was too clever by leaps and bounds. I’d genuinely never start a multi engineer project in Lisp ever.
The way I see it, all the power and flexibility of CL is what keeps it alive; any other language would have died off with so little people working on the libraries. I used to not mind this that much, but recently I also started working on Clojure code, and the difference is like night and day.
I'm sad to see this is still the case. When I got into Lisp (Common Lisp) ten years ago, one of the first thing I did was ask what logging library I should use by default. Almost all the answers I got were variations of, "In Lisp, it's so easy to write your own, you shouldn't bother looking for one by someone else." One kind person gave me an FTP url to a tar file on a server at MIT and warned me that it might not work because he thought the person it belonged to might be retired or dead. And then he told me, "You'll see when you look at the code, it's so easy, you might as well write your own." Very frustrating. Every time I see an article like this, I hope things have changed, but at this point I wonder if Lisp is in a sense too good to ever be done right, like the kid who is so bright in school that he never learns how to do anything difficult. But now I'm getting flashbacks to all the speculation and armchair psychoanalysis we used to do about why the Common Lisp community was the way it, and that never did any good.
Right now, you have a pretty solid logging library in CL that is pretty much the go-to for anything but simplest of needs: log4cl[0]. It's feature-rich, performant, and even integrates with Emacs/SLIME. The README covers a lot of those things... briefly. Good luck figuring out how to e.g. use the (log:config) facility for anything more complicated than changing log levels. As you can see[1], it has a huge docstring describing a lot of things, but the description is shallow. It's like 20% of what is needed to figure out common things like just saving output to a fresh file (without automatic log rotation).
This is IMO a good example of the problem I see in those libraries that are actually solid and done. They miss detailed user-oriented documentation, forcing you to wade through code, which can get pretty complex[2].
--
[0] - https://github.com/sharplispers/log4cl
[1] - https://github.com/sharplispers/log4cl/blob/8c42ca6bd07726fc...
[2] - Try to macroexpand a simple call to logger, like (log:warn "Foo" some-object). Performance and power can be nicely wrapped under a clean set of macros, but if you deviate from the intended use case, you'd better have a spare couple of hours for figuring out how things work.
Any language that has to compete and be acceptable to the larger programming community today needs libraries. So it kind of becomes a Chicken/Egg problem.
I don't think anything today will ever reach the levels of Java usage. Partly because no company is likely to spend on a new language as much as Sun spent on Java.
So you are pretty much well off building on their ecosystem than fight it.
Having said that, TCO is the only thing I missed in Clojure compared to CL.
To take an example: in a project I'm working on, we're using Ring[0] at the backend + bunch of middleware, including Liberator[1]. Take a look at e.g. Liberator docs[2] and tell me, where's a CL library for just that, with so much thought that went into it? Or, in a CL project we had to implement CORS handling ourselves, whereas in Clojure we get it for free. Etc. This kind of story seems to repeat every time I need a library. In Common Lisp, you have to hope that Edi Weitz, Shinmera or Fukamachi wrote something, and that you won't have to patch much to make it work for you. In Clojure, everything I've seen so far[3] makes me expect to find solid and feature-complete libraries whenever I need something.
Now to be clear, I still love working in Common Lisp. It's just that my experience with Clojure made me jealous.
--
[0] - https://github.com/ring-clojure/ring
[1] - https://github.com/clojure-liberator/liberator
[2] - http://clojure-liberator.github.io/liberator/
[3] - I've been writing Clojure for only couple of months, so this may be colored by first impressions.
>Ring is a Clojure web applications library inspired by Python's WSGI and Ruby's Rack.
We have had this on the Common Lisp world for years, see "Clack" and "Lack" -- two libs that work together and do exactly this.
> Take a look at e.g. Liberator docs[2] and tell me, where's a CL library for just that
If you want exactly a "Liberator" in Common Lisp, there has been a good one for 3 years on:
https://github.com/joaotavora/snooze
Note how Snooze uses Clack. Clack is almost a de-facto standard now.
To be honest, REST services can be done with a regular web development routing lib.
>Or, in a CL project we had to implement CORS handling ourselves, whereas in Clojure we get it for free
But it's only adding a few headers to your HTTP headers... Patching the response handler to add those is an easy task in CL (Clack already has the facilities to let you add middlewares into the response handler), does one really need a library for that?
I don't want to sound arrogant, but the complains seem a bit exaggerated.
You can do exactly the same in Common Lisp, by using ABCL.
I am a happy "customer". (ABCL is free)
Clojure for certain feels much more modern. They actually have modern build tools, logging systems, and testing frameworks, which is nice. The emphasis on more data types than just linked lists was amazing, sometimes you just need a hashmap, and Clojure's worked great. The rate of progress on the build tools was frankly spectacular, and some of my favorite libraries in the world are available in Clojure (core.logic anyone?)
The Clojure community has an approach to libraries that is utterly unique in my experience, and I miss it in other languages. Clojure libraries are the most lightly coupled libraries I've ever seen, as they use data as the API (a very Clojure and very Rich Hickey thing to do), which makes tying libraries together a trivial and reliable thing to do. They also have a habit of finishing libraries and not arbitrarily creating competitors for whatever reason. The result is that there are a lot of Clojure libraries that are narrowly scoped, feature complete, and trivial to upgrade if necessary. I really miss that.
Clojure also had some downsides however, both for how we used it and in general. The team that I worked on with it is now mostly Java these days.
Domain specific issues. If you have a bunch of objects that are similar syntactically, but vary semantically, you do not want to use Clojure. Clojure has very poor structures for handling this kind of stuff, and it's very very easy to accidentally go from your pretty record type back to a regular persistent hashmap on accident. Basically Clojure encourages (although does not strictly enforce) hashmap oriented programming. There are some domains where this is fine, but ours was decidedly not one of them.
Guidance wise, interacting with Clojure maintainers was rough. It's their project and they can guide it how they want, and we just got the feeling that they couldn't give a rip about what anyone else wanted. That's their right, but it was super annoying as an end user of the products that they were pushing so hard. We never really had any luck getting any of the bugs or issues that we found dealt with by the core team. We got the distinct impression that they were running the code we submitted and then deciding post-facto that what the code did was exactly what they'd wanted in the first place, but proving that is of course impossible. It's been a few years since I last tried to talk to them, so it's entirely possible that this has turned around since then.
I quit that job before Spec was released, so I cannot really comment on how effective that is in bullet-proofing a Clojure code base. What I can say is that the core Clojure libraries are wildly type unsafe, to a degree that's really only beaten by PHP. There are a ton of core functions that'll change output types without warning, sometimes in several different ways. Nominally this is fine because all the collections are built on top of the seq abstraction, but in reality that abstraction is as leaky as they get. The result is that our code base was littered with "(map identity x)" and "(vec y)" and "(into {} z)" to handle all these little weird edge cases. My suspicion is that Spec is a tacit admission that these little type errors really get out of control in a larger Clojure code base, and they're trying to fix it without having to revamp the entire core library.
That being said, between the two I would start any modern project in Clojure rather than CL. Access to Java, modern libraries for web development, and a much much larger pool of developer talent to access are absolutely killer features for that language over CL.
>That being said, between the two I would start any modern project in Clojure rather than CL. Access to Java, modern libraries for web development, and a much much larger pool of developer talent to access are absolutely killer features for that language over CL.
While I agree with the "larger pool of developer talent", I am already working with ABCL which has pretty easy Java interop.
As for developer talent, What's difficult to find, is to find developers who really grok macros and the "code is data" feature.
When you find one, he/she will have it very easy to jump from CL <--> Scheme <--> Clojure, so i'm not too worried about that.
> You can find a library for anything these days
https://www.quicklisp.org/beta/
Kudos to the new Common-Lisp.net!
I would like to recommend to add links to websites like planet.lisp.org to make common-lisp.net look active on a regular basis. Another interesting style is used by haskellnews.org/grouped.
As some one new, but with active interest in Lisp, I'm genuinely curious to know the projects you've worked on.
Unless some one describes it to us, we wouldn't even know what that experience even felt like.
"Graphical Programming with Xerox Lisp"
https://www.youtube.com/watch?v=J4F6ioMKiqw&list=PL80581C8F8...
"Symbolics Lisp Machine"
https://www.youtube.com/watch?v=o4-YnLpLgtk&t=28s
"The Interlisp Programming Environment (1981)"
https://news.ycombinator.com/item?id=5966328
"Interlisp-D Reference Manual Volume II: Environment"
http://www.bitsavers.org/pdf/xerox/interlisp-d/198510_Koto/3...
I mean not exactly, but mostly like that?
Lisp Machines allowed for multiple applications, the Emacs was only related to the REPL and text editing, aka Zmacs.
https://en.wikipedia.org/wiki/Zmacs
I don't use Emacs regularly any longer, but it used to lack the ability to embedded widgets or graphics on its REPL, one of the reasons why I used to be a XEmacs user instead.
Back to Lisp Machine, you have to imagine that the whole OS is written in a mix of Assembly and Lisp, nothing else.
Then the whole OS was exposed to the developer, as they were single user workstations.
Imagine the ability to access any running application from the REPL and interact with it in some way, for example, reformat the selected image in the word processing application. As very basic example.
Something that on modern systems is only kind of replicated with COM/.NET alongside PowerShell, and it fails short of what was possible.
When an application would trap at any level, the debugger pane gets invoked and you are able to fix the error, followed by redoing the action that triggered the error.
Also the OO system was much more powerful than what most OO programming languages are capable of. You had multiple inheritance, traits (aka protocols), aspects, contracts, multiple dispatch available.
Something I have always felt was a killer-feature of the Windows and Office platforms, and something the industry is moving away from. I never saw what you describe, but I'm sad to increasingly lose what interop we've had since the 1990s and 2000s in exchange for cross platform support, security of one kind or another, and silo'd cloud services.
But then again, what you describe sounds worse not better. Like half "wow, malware playground", and half "I just wanted a nutcracker but all I have available is this hammer factory and the machine shop which built it". Would I see the past differently if I started there, then moved to this present? Would I see COM interop differently if I had started in a world of Apps with constrained interop based on a "share this content with a link" popups?
Along with "if everything's top priority, nothing is", and "one size fits nobody very well", if a system is configurable for any task, does that mean it fits no task very well? A set of magnetic letters on a fridge door lets you rearrange the words to say whatever you want, but that doesn't make it "better than all novels".
But I'd expect a lot of needs for security and encryption since those times had almost no troubles regarding this.
Pharo just to occasionally check how much it has changed since those days.
Yes, Smalltalk does provide a similar experience to Lisp Machines.
Also if you read Xerox papers about Mesa XDE and Mesa/Cedar, one the goals was to provide a developer experience similar to the Lisp and Smalltalk workstations in the context of a strong typed systems programming language.
As a fan of lisp and smalltalk myself, and as "one of the few programmers who has worked in CL commercially in this century", I take my emacs hacking sessions as the most similar experience to it I can have in a daily basis, but in the link I posted, Kent Pitman says:
"I don't even find Emacs itself to be equivalently self-documenting and easy to get around in, much less the many systems that Emacs touches."
I did the first version of that, it was easy to get pharo image and program to try it. I highly suggest playing with it.
- feeling of a single language and semantics at all layers - very different OO feel than java/cpp, much more human, much more thoughtful
'Boolean>>ifTrue:' is just the gateway drug.
Not hanging yourself is a convention and most languages that are more mainstream have bigger communities and more conventions (and frankly, more adults encouraging them).
I have a hard time blaming the language for what are essentially organizational problems.
Too many lisp people start projects doing everything with a single implementor.
Therefore the convention starts out as “whatever this guy wants to do that works.” Anyone working in a bubble like that is bound to eventually create something that makes sense to the implementor, but not necessarily outside people.
Which is why you need peer review when you’re writing your code. If you don’t get it, you’re gonna have problems. Maybe there is something about lisp that makes it difficult to review, but I think more likely there is something about lispers that makes them unwilling to do that particular set of work.
> Now make this thought experiment interesting: Imagine adding object orientation to the C and Scheme programming languages.
How was it done in Lisp?
1) various experiments and getting real work experience with 1st and 2nd generation OOP in Lisp (Flavors, Loops, CommonObjects, Object Lisp, ...)
2) various proposals for a standard OO system
3) a small group (with people from Xerox PARC, Symbolics and Lucid) working on an OO system with large amounts of user feedback -> developing a full-blown portable public domain CLOS implementation and using public mailing lists for feedback. The resulting implementation PCL (Portable Common LOOPS) was ported to more than a dozen Lisp implementations. A SPEC was written. Books were written.
The result was CLOS. THE object system for Lisp. Built with the input of hundreds of developers/users.
It worked great. The fear of group work in and for Lisp is massively overblown.
> Why don't they make a free development system that calls to mind some of the lost glories of the LispM, even if they can't reproduce another LispM? The reason why this doesn't happen is because of the Lisp Curse.
The reason is that the first systems were developed in a totally different environment: large research organizations like PARC and MIT AI Lab swimming in DARPA money employing the brightest minds of their generation. A genius like Richard Feynberg wanted to work there: '...many a visitor at Thinking Machines was shocked to see that we had a Nobel Laureate soldering circuit boards or painting walls...' http://longnow.org/essays/richard-feynman-connection-machine...
The hacker community can't replicate that in their spare time.
This is really like some one describing Ice Cream to a person who never tasted it ever.
The solution is to be sad, in the same way we can be sad about the loss of the library of Alexandria, and move on, creating new works of beauty. As brought up above though, it's very hard to do this in your spare time... Few are lucky enough to hack with CL professionally, and I would wager even fewer still of those are any less free than other companies' employees of business needs coming first and forcing some terrible choices in the development cycle. Still, there can be beauty in the system, and CL is very much a systems-oriented language... (https://www.dreamsongs.com/Files/Incommensurability.pdf describes it as more of a programming system than a programming language, even.)
I mean I understand licensing and all that, but much of that code is past its commercial use.
Merely reading OnLisp and Let Over Lambda felt like some one opened up a new portal to a world most of the world's programmers don't even know exists.
I would die to read and learn from code written in the past.
Which, IMO, is mostly bollocks. See: CLOS, Quicklisp, Clack/Lack, ASDF, etc.
Lisp brings a lot of power to the table along with relatively weak code organization constructs. A great example of this is the concept of package privacy, something that can be ignored in CL by using a double colon instead of a single colon. Sure, ideally experienced engineers would not abuse this, but that sure is a dangerous tool to leave around when deadlines are looming.
My personal favorite WTF from CL was the :around methods from CLOS. These allowed you to wrap a function with other functions, possibly from a completely different place in your code base, and handle any setup/teardown as needed. We typically used them for database transactions, along with the ability to catch exceptions and trigger a DB rollback. The catch was that every single around method had to call the magic (call-next-function) function, otherwise the main function would not be called. Wondering why in the hell the function you just called isn't actually executing is quite a brainfuck, especially when it was caused by a bug in a completely different package.
CL + Emacs was truly great though, best editor to language integration I've ever seen, period.
Java has public/private/protected/package-scope, but you can get around it trivially with reflection. (Java 9 I think "fixed" this, but you can override it at startup time.) Personally I'm in favor of Python's "we're all adults here" philosophy.
Proxy patterns are common in large Java code bases, and various other things inspired by aspect-oriented programming. I've never thought to blame the language though because someone forgot to call (or decided not to call, e.g. because it got too smart with a cache) child.method() on the real object it is wrapping.
Its a big like what Larry Wall talks about code complexity(https://en.wikipedia.org/wiki/Waterbed_theory). Basically if say a language X provides in built feature to do complex task Y, and it a little hard to understand. In another language Z which lacks the feature, the code that one has to write to achieve Y will be equally complicated and hard if not more.
Sounds like a not-so-appropriate way of doing it.
I do this by wrapping my transactions... on a (with-transaction ) expression! Which is easily done using CLSQL (common lisp lib). This would do exactly what you want: exec the rollback, etc. Note that I speak from personal experience: this has worked perfectly on a commercial project.
>Lisp brings a lot of power to the table along with relatively weak code organization constructs. A great example of this is the concept of package privacy, something that can be ignored in CL by using a double colon instead of a single colon. Sure, ideally experienced engineers would not abuse this, but that sure is a dangerous tool to leave around when deadlines are looming.
CL is, mostly, for ideally experienced engineers. And i'm not being smug or elitist here. Ideally experienced engineers are able to leverage the full power of CL.
>when deadlines are looming.
And the reason to use CL is precisely to enable greater speed of development for complex stuff, so deadlines don't scare you so much (compared to using a lesser-featured language like Java for example)
for me the "rope" was the ridiculous complexity of things like the "loop" macro. Coming from a newb (to CL) perspective and wondering "how do i use this thing" ... ugh you could probably write a small book on all the different ways to use that thing. This type of stuff was littered through the language. Instead of small focused functions that were really self explanatory, but limited in capability, you have things that are way too ... i dunno "configurable"? "modifiable"? There were also thinks akin to "method overloading" but done by a drunk person seeing how many "useful" ways they could call this one function.
The core language documentation is extraordinary. Probably better than any language out there.... but I moved on to Chicken Scheme for my personal work. Life was much better afterwards.
You are not forced to use it. I like the LOOP macro, but there are many alternatives, which you can easily load and use.
>Instead of small focused functions that were really self explanatory, but limited in capability, you have things that are way too ... i dunno "configurable"?
So, for example, it looks like you would have liked to use the ITERATE lib instead of the LOOP macro.
The worst bit of rope I ever personally saw was reader macros. These allowed you to essentially modify the grammar of the language on the fly, inserting functions into the lexer to handle unknown symbols at read time. This is exactly how the quote operator, which allows you to insert literal code without running it, works. Since this happened at run time, any reader macro you registered affected all files that were read later, and thus was build order dependent. If you wanted to use your reader macro in every file, you better load it first and hope it doesn't break any of your libraries.
CLOS, the standard OOP structure of CL was also full of foot guns. It's super impressive that they managed to add an OOP system to an existing language without breaking everything, but the design was .... dangerous. CLOS has some pretty weird rules around method routing, with the methods existing outside Objects and routing be handled by argument specificity. The moment you find yourself extending classes just to win the specificity race with another method you have gone too far and it's time to turn around and go back down whatever road you came up.
For the most part CLOS was fine, but you could design yourself into some really weird corners. The worst part about CLOS was the before, after, and around functions. These allowed you to add functions that wrapped your regular functions, possibly multiple times with order of execution being handled by similar specificity rules. The kicker was that every of these methods was responsible to call the magic "call-next-method" function, which continued the call chain down the stack. If an around method did not do this, the main method would never execute. It is super confusing to manually call a method, only for it to not execute or trigger your debugger, especially since you can register around methods on any method from any package.
Also, CL has a very weak definition of package privacy. Any public symbol, function or otherwise, is accessed externally with the form "package:symbol". But private symbols, those not explicitly exported, can be accessed with "package::symbol". Much like ruby's much maligned "send" method, there's nothing preventing sane programmers from staying way the hell away from private methods. But just like ruby's send method, that is a mighty tempting tool to leave laying around when deadlines loom and pressure is mounting.
Before I finish, a sibling comment mentioned the loop macro. This thing is absolutely insane, I personally stayed way away from it because I never really mastered it, and syntactically is didn't match anything else from CL. Here's a valid example from the "LOOP for Black Belts"[0] page.
(loop for i in *random*
counting (evenp i) into evens
counting (oddp i) into odds
summing i into total
maximizing i into max
minimizing i into min
finally (return (list min max total evens odds)))
And before you ask, no symbols like "counting" are not already functions in the lisp standard. That would be far too easy. God help you if you have a loop call that needs to be modified just enough to make using loop unfeasible.
[0] http://www.gigamonkeys.com/book/loop-for-black-belts.html
Common Lisp has readtables, which you can create and change. So you can read certain files with a different readtable, leaving the default intact.
> It is super confusing to manually call a method
This is just the usual super method call in most object-oriented programming languages. If you have method and you want to call the method from the superclass, you have to explicitly call it.
> loop macro
The LOOP macro is not CL specific. CL has inherited it from Lisp Machine Lisp, which got it from Maclisp. At MIT it was even a single source file for several different Lisp dialects. The origin of this macro is actually Xerox' Interlisp - where it was called FOR.
It's not that bad once one masters the basics and the documentation is in the ANSI CL standard.
The upgrade from LOOP is the ITERATE macro, which even more powerful, but with more parentheses:
That a footgun can be occasionally be handled carefully does not erase the fact that it's a footgun. The ability to modify the read table on the fly is for certain super interesting, but IMHO very dangerous. I am glad that the languages I use on a daily basis do not have this capability, for certain.
> This is just the usual super method call in most object-oriented programming languages. If you have method and you want to call the method from the superclass, you have to explicitly call it.
Not a good comparison. While there is some similarity to super in languages like Java, the :around and call-next-method in CLOS is far more dangerous. In Java, super calls are inside the method in question, any stupid decisions around super are right in front of you. In CLOS, it can be in any file in your code base. This makes the source of the problem far less clear, and expands the possible scope of WTFs by a lot.
> The LOOP macro is not CL specific. CL has inherited it from Lisp Machine Lisp, which got it from Maclisp. At MIT it was even a single source file for several different Lisp dialects. The origin of this macro is actually Xerox' Interlisp - where it was called FOR.
An interesting history, for certain, but still jarring as hell, in my opinion. Macros like these are un-lispy, and really never should have been included. I always avoided them for the more primitive looping constructs, but which ones exactly now slip my mind.
Haven't seen much danger with it in practice.
> In Java, super calls are inside the method in question, any stupid decisions around super are right in front of you
The problem you mentioned was when the super call was missing. You have to find out which method gets called for the runtime object and then see that the super call is missing.
In CLOS I'd list the applicable methods and edit the first :around method.
True, CLOS is the much more complex system, with a meta-object protocol, generic functions, multi-methods, multiple-inheritance, meta-classes, method combinations, ...
Java was designed for the simple case and then promoted for the 'industrial programmer' - which explains part of its success - but it got complicated soon and people added for example Aspect Oriented Programming to it - which has similar features like CLOS :around methods.
> Macros like these are un-lispy
Not really. What you think as un-lispy is perfectly fine for many. There is a tendency to narrow down the language to simplify it, like Dylan or many others. Lisp is always more about freedom of design, experimentation, flexibility. Otherwise we wouldn't have widely different extension approaches in one language: format strings with loops, a whole complex language for printing code, macro like LOOP, ...
Sure you can just use macros to reorder arguments and make code more convenient, but at the same time you can use macros to add radical different sublanguages - that's one of the reasons I use Lisp - it allows me to do that and many have implemented very interesting language extensions on top of Lisp. Personally I think with some practice LOOP macros are relatively easy to write and I even prefer them over tail-recursive loops in Scheme - which are IMHO much harder to follow.
You know, there are languages that don't allow you to shoot yourself in the foot, because they don't allow any guns.
I prefer languages with power.
>The ability to modify the read table on the fly is for certain super interesting, but IMHO very dangerous.
> I am glad that the languages I use on a daily basis do not have this capability, for certain.
Reader macros are there to be used when they are necessary. And in those cases, they make ALL the difference in the world. In such cases, the "languages that do not have this capability" will require a lot of code, often hard to maintain, to achieve the same result.
So, i prefer languages with guns.
>Macros like these are un-lispy, and really never should have been included.
LOOP wasn't included on a whim. Read about the Common Lisp standard creation, it was based on at least a decade of experience writing Lisp for "serious" stuff.
Note that the compiler will often tell you if the LOOP is wrongly written, at compile-time.
It is ugly to some. I love it. On imperative programming, a big part of programming is doing iteration. LOOP makes iterative code read easier, natural, as you sample code snippet proves. LOOP looks like that because it's a DSL; it is a DSL tailored for doing iteration.
>How do I figure out what magic keywords are available within this loop macro? It's maddening!
Yeah, but then it comes on second nature.
Again, you're not forced to use LOOP, there are alternatives like ITERATE.
If you just want option types that you can use with lists, the most direct way to do that is by encoding None as NIL and Some x as (list x), which still lets "no value" be false, makes "some value" true even for the empty list, and pairs nicely with pattern matching libraries like Optima (which people yearning for option types might also be interested in):
(match maybe-value
((list value) value)
(nil 'not-found))
It might also make sense to represent the absence of a value by just not assigning a value. For example, CLOS instances won't bind their slots to anything by default, so trying to read them will signal UNBOUND-SLOT. You can check if it's bound beforehand with SLOT-BOUNDP, and CLOS does differentiate between a slot not being bound and a slot not existing at all. If you're working on something interactively and UNBOUND-SLOT gets signalled, by default execution will pause, and Lisp will offer strategies for resolving the issue, like entering in a value to use instead for just this call, entering in a value to store in the slot for later use, just aborting the computation, etc. That's a pretty nice experience (and just the tip of the iceberg) that people coming from more static languages might not even think about.
If you're returning a value to someone, maybe it would be best to work like GETHASH does and return two return values, the first either a value pulled from the table or a default, and the second a boolean indicating whether the key was present or whether you got the default. Because Lisp has multiple return values (not like Python or Ruby where you're really just returning a sequence and then destructuring it), callers that are fine with the default and don't care if it was actually present can just use the primary return value, and since the default is provided when you call GETHASH, you can also do nice things like (incf (gethash key hash 0)).
There's other ways too, of course, but it's impossible to say what would be the most appropriate solution without knowing more about the problem. (eq nil '()) returning T is not a bug, so the issue must be higher up the call stack. If that seems like a dealbreaker to someone, they're probably just looking at it in isolation and not thinking in terms of Lisp as a whole.
There is a boolean type in CL. You can declare variables as boolean and they will be enforced to hold the T and NIL boolean values.
>Maybe I'm nuts, but that really isn't acceptable in this century.
Perhaps you haven't realized this: Booleans are all over the place in CL, they are first class: Any value is true in CL, except the NIL value, which is synonym with the empty list (). This sounds strange, but makes perfect sense in practice and makes writing code really easy.
i personally prefer forums for help, support and learning from the community, over any other option (mailing lists, irc, stackoverflow, etc .. )
most programming languages websites nowadays includes a discourse based forum and it works greats
i strongly recommend adding one
And calling CL "modern" is... ironic at best.