drmeister

Alternatively - you can choose to program in Common Lisp - an industrial strength language that has been demonstrated in large projects like the QPX flight search engine (Google Flights).

For anyone who doesn't know - a big difference that Common Lisp brings to the table is that it has separate namespaces for variables and functions. This may not sound like much but it makes it much easier to write macros (code that writes code) and facilitates compile-time computing.

Another big difference between Scheme and Common Lisp is that the Common Lisp specification is _much_ larger and it comes with a much larger collection of standard built-in functions and macros and a standard object-oriented programming facility, among many other things.

I know this because I've spent the last six years implementing Clasp (github.com/clasp-developers/clasp) - a Common Lisp that interoperates with C++ and uses LLVM as the backend. There are several excellent implementations of Common Lisp - Steel Bank Common Lisp is a great place to start.

This is really nice! I wonder how well the ulisp compiler does with optimization - especially for code size. My group is developing Clasp Common Lisp and we use the Cleavir compiler (https://github.com/clasp-developers/clasp and https://github.com/robert-strandh/SICL). Cleavir is a new project to develop a powerful, portable Common Lisp compiler and it could be used to compile lisp dialects.

Awesome! Dunnet has a text editor built into it.

I implemented multithreading in Clasp using pthreads and added support for the 'bordeaux-threads' library (https://github.com/sionescu/bordeaux-threads). Now any program that does multi-threading using the bordeaux-threads library works in Clasp. This is how Common Lisp adds support for new capabilities.

You have four different choices for hash-tables. You choose how the key hashing should work with four levels - pointer hashing (which is very fast) to hashing the contents of arrays and list keys (which is slow). If you only get one choice then hash-tables wouldn't be as powerful.

After 35 years of programming, I discovered Common Lisp and programming is enjoyable again. I wish I'd discovered it earlier.

With what I've learned in the last five years I've (1) written a Common Lisp compiler that interoperates with C++ and uses LLVM as the backend (github.com/cando-developers/clasp); (2) I've used it as the basis of a programming environment for designing new molecules and materials; (3) we've developed a Jupyterlab kernel and ported Jupyter widgets to Common Lisp as the graphical user interface for the programming environment.

I say "I've" and then "we've" because while I started this myself - several people have joined me and we are now turning it into products.

Common Lisp is great - no other language is as rich and expressive and fun to program in. Real macros (code that writes code!), multiple dispatch, conditions and restarts - it goes on and on. There are lots of features in Common Lisp that haven't made it into other languages.

[edit]

Oh - and then there is this: http://greenlab.di.uminho.pt/wp-content/uploads/2017/09/pape... Of all the dynamic languages (and who doesn't like dynamic languages?) Common Lisp is the most energy efficient by a long shot.

You aren’t wrong - they did and keep doing it. ;-)

IMHO that’s why Common Lisp is decades ahead of other languages. Lisp made its mistakes in the 60‘s and 70‘s and largely corrected them in Common Lisp in the 80’s.

Cool! But the model of earth appears to experience gimbal lock - use quaternions for rotations.

It depends on the skills and our needs.

Yes - but we aren't ready to publish yet.

We are developing a matter compiler. We are working on designing molecular Lego to assemble them into new catalysts, therapeutic compounds, atomically precise membranes and sensors for proteins and small molecules. The goal is to make molecules that can do everything that proteins can do and that can be designed by human beings with computer assistance. We've developed a programming environment with a custom compiler and Common Lisp implementation for designing these molecules. We are looking for programmers with chemistry experience. https://www.youtube.com/watch?v=8X69_42Mj-g

It's more of an issue at the interface of technology and licensing. The CLHS (Common Lisp Hyper Specification) is a very large, web based document written in the 80's and it looks like an old Geocities web site. I believe the CLHS license says that it's not allowed to be changed (to protect the standard - I believe - someone correct me please) and so the community is working from slightly older drafts and figuring out how to automate the conversion to something that looks more modern. It's not a problem with Common Lisp - it's a problem that HTML, the web and user expectations have been changing over the years. There's that permanence thing again.

"Fluff" "FLUFF"??? If that's fluff then most of the rest of the web is fluff... oh wait.

Seriously, the web site is a very informative site about "Common Lisp" - a specific dialect of Lisp. It's right there when you click the link, big letters - "Common Lisp" - you can't miss it.

You could argue about the URL "lisp-lang.org" - but why?

Other examples...

C++ template programming necessarily followed a very different style than it does since variadic template were introduced with C++11. There were books written before C++11 wherein much of them was obsoleted by variadic templates. You do not want to let students get hold of those books and think the old way was the way things have to be done. Compare how boost::python was (is? I haven't dug into it recently) written compared to pybind11 - night and day differences in readability thanks to variadic templates. That's not a dig at boost::python - it was written with the C++ they had back then and it had to use Lisp-like list comprehension with tedious replicated boilerplate code to unpack argument lists.

Then there are raw pointers in C++ - we aren't supposed to use raw pointers anymore. We are supposed to use references and std::unique_ptr<x> and std::shared_ptr<y> and this thing called "move semantics". That stuff sucks for directed graphs and so I switched to compacting, tracing garbage collection for Cando.

C++ is being developed in a way that it retains backward compatibility with existing code - thank goodness for that! But there are styles of programming even for something as staid and venerable as C++ that, while supported, should pass silently into the long, dark night.

Then you have a language like Python that made sensible but breaking changes between versions 2.x and 3.x. Wow - look at the problems that is still causing. I love Python but I won't do anything with it that I can't rip out root and branch with more than a few weeks work. I say that even though Clasp's build system is completely implemented using the very excellent Python based build system 'waf'.

Then you have Javascript - it seems to change every time I blink. That doesn't mean I will stop using it for our web based Jupyter notebook user interface. Javascript is the only game in that town. I just close my eyes and hold on tight and try not to scream.

Common Lisp isn't like any of those, it grew out of a lot of very careful thinking and was specified around 1984 darn near perfect. There are some warts (logical pathnames - I'm looking at you) but even its warts are better thought out than some other languages features. Better implementations and more and better libraries come along - but the language has the same expressiveness, power and permanence it has always had.

As a Professor of Chemistry - I'm all about higher learning and I love curves (non-linear functions that is).

I don't agree that Common Lisp has a higher learning curve than other languages. To become operational - Common Lisp is no more difficult to learn than other languages. Bind variables, conditionals, loops and a little arithmetic and you can start doing some damage. You can write procedural code, functional code, object oriented code - whatever your problem needs.

It's that Common Lisp has a LOT more "up" than other languages. It keeps going up and up as you learn about macros and CLOS and multiple dispatch and restarts and upwards. It's really neat discovering all the things that you realize you were missing from other languages - some things that they add over time with ever more complex and arbitrary syntax.

When you get tired of writing "for" loops and agonizing how to manage memory for the next fancy data structure you want to implement - dive into it - it's great. Common Lisp will still be there.

I didn't want to call out an obvious typo - but then I thought "maybe they are talking about Javascript frameworks" and then I thought "yeah - one can always hope". :-)

No, none, zero, zip, nadda. What you do is you hook it to another really important idea and then you work until 3:00am every night for months and then years writing code. You take all those voices in your head that say you should not be doing this and squeeze them hard until they... go to sleep and stop bothering you. For me it started paying off in the last year and it is starting to look like it was a really good idea.

Common Lisp has: generic functions, homo-iconic macros written in Common Lisp, reflection, multiple dispatch, closures, optional typing, correct implementation of lexical scope, dynamically scoped variables, a metaobject protocol, conditions & restarts, and a compiler that is available for customization. One or a few of these have made it into other languages in some form or another - but not all together.

Common Lisp also has an excellent package manager (quicklisp/ASDF) a programmers IDE (emacs/slime vim/vlime), interoperation with C libraries (CFFI) and lots and lots of libraries that don't need to be constantly updated to keep them working because the underlying language changes.

I wouldn't call it just a slightly more powerful weapon.

Just the macros - my goodness - in Common Lisp you can write programs that write programs! It's easy and organic and elegant because they are written in the same language as everything else. Macros let you write code that customizes itself and optimizes itself at compile time for specific use cases. You can escape the drudgery of writing similar code over and over again. You kind of need s-expression syntax for macros to be easy to write - so no other language with complex syntax will ever have them like Common Lisp does.

Languages are all Turing complete - we can do everything in every language - but for the kind of hard problems that I want to solve, only Common Lisp has helped me out of the Turing tarpit. Also, C++ is a great domain specific language for creating tables of cache friendly compact data structures and it has great compilers.

Thank you - I'll check it out.

We exposed the AST and ASTMatcher libraries of Clang inside of Clasp and we use it to analyze all of the Clasp C++ code to build an interface to the Memory Pool System memory manager.

I want to have something that can include C and C++ header files and automatically expose them to the Common Lisp - that would be neat! Maybe we can steal some ideas like the includec function of Terra.

I say this with a perspective of watching it happen over forty years. I'll get all kinds of heck if I start saying this or that language has faded. But many languages have changed over time, sometimes in breaking ways, as their developers work to make them more expressive and add features. Code that is written one year often doesn't work a few years later - that's a kind of fading as specific reference implementations fade away and code written in them needs to be updated or it rots.

Common Lisp doesn't have this problem - and it has many features that other languages have added over time, often in less comprehensive ways. For example C++11 lambdas are not as expressive and powerful as Common Lisp first class functions, and I joke that C++ template programming is to Common Lisp macros what IRS tax forms are to poetry. Note: Clasp includes a lot of C++ template programming and C++ lambda code that I enjoyed writing and I am so grateful that C++11 added variadic templates. New language features can be added to Common Lisp by the programmer with macros, and for the really adventurous, they can be made efficient by augmenting the Common Lisp compiler. Common Lisp compilers are almost always written in Common Lisp and available and accessible. This is why Clasp uses a new and understandable Common Lisp compiler "Cleavir" (developed by Robert Strandh) and LLVM, which is a great C++ library for generating native code on a variety of processors. Cleavir will be an excellent platform for efficiently implementing new dynamic programming language features.

Thank you.

I did choose Common Lisp over Julia - I started learning Common Lisp in 2013 and Julia started becoming something around 2012.

I did so because of the permanence and the demonstrated expressiveness and power of Common Lisp. Common Lisp has been around for almost five times longer than Julia, and Common Lisp has demonstrated again and again that it is capable of solving hard, poorly understood, real world problems in a lot of domains.

Fun fact: Julia bootstraps off of an implementation of Lisp. Furthermore, most compiled languages are translated into an abstract syntax tree (AST) as part of compilation. Lisp S-expressions are a text based AST. So I can make the argument that Lisp is as close the "One True Programming Language" that we have. :-)

I'm doing chemistry - that's fundamental and timeless - I find it maps beautifully to a fundamental and timeless language like Lisp.

This is a very nice web site describing a programming language with unparalleled expressiveness, power and permanence.

I am heavily invested in Common Lisp. We are developing a programming environment for designing new materials and molecules called Cando (https://github.com/drmeister/cando) using Common Lisp as a scripting language. Cando is running on Clasp (https://github.com/clasp-developers/clasp), a new Common Lisp implementation that interoperates with C++ and is based on LLVM.

What attracted me to the language, after 35 years programming in almost everything else, was how organically it lets one write software and how I don't have to worry about it fading like the next programming fad.

Looks great! I'm looking forward to exception handling support.

Neither the paper nor the comments have mentioned this: https://en.wikipedia.org/wiki/Truncated_Newton_method

The Truncated Newton method uses an inner solver that only runs for a few iterations to approximate the Hessian. The approximate Hessian is used to approximately solve Newtons equation. I've implemented it and it works very well. When it gets close to the solution the convergence is very fast.

I mention it because it sounds similar to what the paper discusses but you use conjugate gradients in the inner solver and Newton's equation in the outer solver.

So I've done basically the same thing with a few differences: (1) I chose Common Lisp as the language I would implement (2) I used C++ template programming to automatically generate wrappers for C++ library functions (like boost::python and luabind) so that I could expose C++ functions directly to Common Lisp. That allowed me to use the llvm C++ API directly.

The project is called clasp -> github.com/drmeister/clasp Send me a message - we should talk and compare notes.

Chris Schafmeister here - wow. Well, just make sure you always wear your safety goggles.

We have absolute control over the final stereo-isomer that comes out of the synthesis. The large molecules are assembled from building blocks that each contain two stereo centers. We synthesize all four stereo-isomers of the building blocks in separate bottles and then put them together in different sequences to create the large molecules. Where the programming (Clasp Common Lisp in the molecular design language that I'll announce soon) comes in is we can build computer models of all stere-isomers and, in software, figure out which ones can do the job that we want. Then we just synthesize that and test it in the lab.

Christian Schafmeister here - thank you for those kind words. I'm using Common Lisp as the basis for a programming environment for developing programmable matter (big, smart molecules and materials). I'll be announcing it soon - stay tuned. Designing molecules is one of the hardest problems in the world and it needs the most expressive, powerful language - Common Lisp. Oh - and C++, there's plenty of C++ in there as well :-).

I've implemented Common Lisp using llvm (github.com/drmeister/clasp). I've integrated the Boehm and Memory Pool system garbage collectors. How? It would take a long time to explain - but it's doable.

This is absolutely awesome. So many people coming together to design and construct such a complicated experiment. Excellent work and let's hope it teaches us how to do fusion.