HN Theater @HNTheaterMonth

More presentations!

I think two are almost the same presentation:

https://www.youtube.com/watch?v=PQDwvatwjD8 (July 2010) 10S6P4 Christian Schafmeister 2010 UNTT 3rd Annual Conference Session 6 Presentation 4

https://www.youtube.com/watch?v=8X69_42Mj-g (July 2015) Clasp: Common Lisp using LLVM and C++ for Molecular Metaprogramming

https://www.youtube.com/watch?v=0rSMt1pAlbE (Aug 2015) Clasp: Common Lisp using LLVM and C++ for Designing Molecules

https://www.youtube.com/watch?v=9HXfvT85EFE (Oct 2018) Modular Polymer Catalysts - Chris Schafmeister

https://www.youtube.com/watch?v=mbdXeRBbgDM (Nov 2018) LLVM Developers Meeting: C. Schafmeister lessons Learned Implementing Common Lisp with LLVM

CLASP is a really interesting project.

For one, it's created and written by a Chemistry PhD researcher (Christian Schafmeister), not someone with a traditional CS background.

For another, it's one of the few languages that has ever attempted to interface with C++ at the template level - you can instantiate C++ template classes from CL, and catch C++ exceptions etc.

For yet another, he does compacting garbage collection for the C++ objects used in the CL implementation, with pointer patching and everything else.

There's a nice Google Tech Talk about it [0], that goes into both why he did this, and how he implemented this.

[0] https://www.youtube.com/watch?v=8X69_42Mj-g

⬐ pjmlp

I guess it helps that it is pretty much a Lisp for the research work that they are doing, instead of trying to cater to everyone.

⬐ gavinray

Dr Schafmeister is occasionally present on the LLVM Discord. The CLASP project is something else. That hour-long talk he gives on Youtube about it blew my mind.

Ah, related to #clasp:

https://www.youtube.com/watch?v=8X69_42Mj-g Clasp: Common Lisp using LLVM and C++ for Molecular Metaprogramming

https://www.youtube.com/watch?v=mbdXeRBbgDM 2018 LLVM Developers Meeting: C. Schafmeister lessons Learned Implementing Common Lisp with LLVM

https://www.youtube.com/watch?v=0rSMt1pAlbE Clasp: Common Lisp using LLVM and C++ for Designing Molecules

https://www.youtube.com/watch?v=9HXfvT85EFE Modular Polymer Catalysts - Chris Schafmeister

https://www.youtube.com/watch?v=PQDwvatwjD8 10S6P4 Christian Schafmeister 2010 UNTT 3rd Annual Conference Session 6 Presentation 4

⬐ kristjansson

In that they're both implementations of Common Lisp, but is there a deep connection between the two than that? Not that directing more attention to clasp is a bad thing!

⬐ fiddlerwoaroof

SICL is being developed in a modular fashion: I believe clasp uses SICL’s compiler framework Cleavir for its own compiler. (I’ve also heard that ABCL and ECL have considered reimplementing their compilers with Cleavir)

⬐ drmeister

Clasp author here - Clasp uses SICL's Cleavir compiler.

Common Lisp traditionally favors other forms of interoperability: with Assembler, C, C++, Objective-C, UNIX/POSIX, etc... For example one prefers to directly call old-fashioned GTK+, Cocoa or Windows - instead of calling via a Java UI layer or a Javascript library. Common Lisp has interoperability with the JVM in various forms (from FFIs to ABCL, a Common Lisp on JVM implementation), but it's not a popular choice.

There are several CL implementations with deep C integration, for example by compilation to C. CLASP has deep C++ and LLVM integration. Some implementation can create shared libraries which are being loaded from other programs.

CLASP: https://www.youtube.com/watch?v=8X69_42Mj-g

It's possible to bring Common Lisp on top of runtimes like the JVM or Javascript - but there is some larger mismatch, because Common Lisp (different from Clojure) a platform independent full programming language. For example Common Lisp specifies a numeric tower with bignums, some float types, complex numbers and rational numbers. JavaScript internally does only offer floats. Common Lisp also specifies its own object system, which does not map well on top of the JVM (single inheritance, non-dynamic) or JavaScript.

He's lowering the degrees of freedom in protien synthesis so they are simulatiable. https://www.youtube.com/watch?v=8X69_42Mj-g

⬐ justinclift

Thanks for clarifying, went and looked again. Yep, seems interesting. :)

  I was thinking about this the other day.  How can I expose my Common Lisp code to Julia.  
  

1. You could take the Clasp path by exposing CL to C++. https://youtu.be/8X69_42Mj-g

  This means taking /  writing a CL in Julia.
  

2. Julia has an AST representation written in femtolisp. So it would be in interesting target for CL or some glue middle language like Shen. http://www.shenlanguage.org/ https://youtu.be/lMcRBdSdO_U

> whose C++ implementation from scratch...

You're aware of clasp?

https://github.com/clasp-developers/clasp

Which builds (in part) on embeddable common lisp:

https://gitlab.com/embeddable-common-lisp/ecl

See around 20-30 minutes: https://youtu.be/8X69_42Mj-g

⬐ blu42

Nope, I'm seeing clasp for the first time -- Christian Schafmeister's talk was extremely nice to listen to!

I did come across some small LISP implementations at the early stages, but by that time I already had the AST builder done. Maybe because I didn't actively search for LISP implementations, as I didn't need a 'proper' LISP per se, more of a DSL for quickly writing ASTs of arbitrary complex computational expressions. Those ASTs were the final goal ; )

That is me, I'm half of that team (Martin Cracauer).

If you have any questions I'd be happy to answer.

If you want to learn more about the programming side of our work (not so chemical), check out our other videos. They are from programming conferences: Longer talk: https://www.youtube.com/watch?v=8X69_42Mj-g&t=177s&index=3&l...

Shorter one from the LLVM meeting: https://www.youtube.com/watch?v=gYYH2zF41fc&list=PLbl4KVdl9U...

(yes, the whole system is a compiler using LLVM as the last stage to make machine code from abstract assembly. The thing I always missed in SBCL)

⬐ agumonkey

Oh well I just had a question but not related to cando itself more about how you structure your research project / team / finance. But maybe that's not a place to discuss this.

⬐ cracauer

Feel free to message, here or on twitter or whereever.

That was my interest when I started my career, but didn’t do much on it.

Bio-informatics deals with the stuff you mentioned in-silico. There’re a whole bunch of libraries for many different languages, but I’ve not come across any specific language for bio-informatics.

You might find https://youtu.be/8X69_42Mj-g interesting, they developed a DSL in common lisp to generate C++ code using LLVM.

⬐ hsikka

Hey thanks, I’ll check out the video! That seems super cool

Thanks. I really enjoyed your Google Techtalk about CLASP https://www.youtube.com/watch?v=8X69_42Mj-g

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

⬐ amelius

That's very cool. How do you debug these programs? What is the molecular equivalent of "format"?

⬐ aoner

That was a very interesting presentation. Great work, is there any way to follow this (besides following your wok on clasp)? You mentioned carbon dioxide. Do you have some ideas about molecular motors and creating solid carbon out of carbon dioxide? Or hydrocarbons?

⬐ matt2ray

Does one have to be a graduate student in chemistry?

⬐ senatorobama

do you do remote?

⬐ drmeister

It depends on the skills and our needs.

⬐ senatorobama

Can I send my resume to you?

⬐ TeMPOraL

I've been to your talk in Kraków on the European Lisp Symposium! I love what you're doing!

Do you have any updates on that water-filtering molecule you showed us then?

⬐ drmeister

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

⬐ TeMPOraL

Great to hear; I'm now impatiently waiting for new papers or related talks! Don't forget to post it here when you publish!

The most inspiring talk a I have ever seen:

Clasp: Common Lisp using LLVM and C++ for Molecular Metaprogramming.

ABSTRACT

This talk describes our unique approach to constructing large, atomically precise molecules (called "Molecular Lego" or "spiroligomers") that could act as new therapeutics, new catalysts (molecules that make new chemical reactions happen faster) and ultimately to construct atomically precise molecular devices. Then I describe Clasp and CANDO, a new implementation of the powerful language Common Lisp. Clasp is a Common Lisp compiler that uses LLVM to generate fast machine code and it interoperates with C++. CANDO is a molecular design tool that uses Clasp as its programming language. Together I believe that these are the hardware (molecules) and the software (the CANDO/Clasp compiler) that will enable the development of sophisticated molecular nanotechnology.

https://m.youtube.com/watch?v=8X69_42Mj-g

Check out Christian Schafmeister's research if you are interested in this: https://www.schafmeistergroup.com/

There is a brief summary of the history of Schafmeister's approaches (and why he thinks direct copying of protein-based mechanisms from nature will not work) in this talk: https://www.youtube.com/watch?v=8X69_42Mj-g

⬐ agumonkey

I was very fond of his talk. Not much news but he answered on youtube saying he was still active on this. Time will tell.

⬐ TeMPOraL

He presented more of his work on last year's European Lisp Symposium, which I had a chance to see in person.

I actually asked him why he thinks "direct copying of protein-based mechanisms from nature will not work". He had a pretty smart answer for that, which I unfortunately don't remember anymore :(.

⬐ agumonkey

Heh, I'll ask that in a mail later too. I wonder how connected he is with other medical research fields, time to dig pubmed

⬐ TeMPOraL

https://www.youtube.com/watch?v=5bQhGS8V6dQ&list=PLA66mD-6yK...

Here's the video from last year's ELS.

At the beginning of it he actually explains some of the reasoning - i.e. proteins are cool and powerful, but a) too hard to design, and b) too fragile.

I'd argue that there are essentially two problems in computer science:

1. Math.

2. Dealing with the hardware.

Virtually all the ugliness is a product of the interface between these two areas. Dealing with the hardware requires a fascination with minutiae and imperfection, while working in Math requires a fascination with generalities and perfection. The people on the math side create systems like Haskell, which let you express very abstract concepts, and reason very generally about your code, but make dealing with hardware issues difficult. The people on the hardware side use things like Forth, which is very powerful for building code that works closely with the hardware, but whose paradigms actively discourage the generality present in many other languages.

And so, what's needed is someone who can develop a system that can fully express high level math concepts in such a way that there is a straightforward mapping to the messy world of hardware capabilities.

However, I think the "killing blow" for pure programmers' motivations comes when they realize that mapping between the pure world of math and the messy world of hardware isn't enough. The focus on "end users" is the tacit admission that even if you do successfully build a beautiful system, most people don't want to work at a high level of mathematical abstraction. If you really want to revolutionize computer science, in order to accomplish the actual revolution, your system needs to be able to let people work in the terms they're already comfortable with:

(messy world of existing programming languages) -> (your pure math) -> (messy world of hardware)

But I don't think these hurdles constitute a "great filter" in the sense of the original article. Its just a quirk of human nature that the people interested in the pure math bit in the middle tend to find the messes on either side tedious and unnecessary for their insights.

What essentially ends up happening is that the people who are only concerned with intellectual satisfaction get such a big dose of satisfaction from the pure math in the middle, that they never bother with the messy bits on either side. So I've found that the people who do the most impressive work have some external-to-computer-science itch they're trying to scratch. People like Christian Schafmeister[1] whose chemistry aspirations led him to create a new Lisp to glue together C++, Mathematica, Maxima, and Fortran in such a way that he can highly efficiently express and compute the math he was trying to solve. These kind of people fight through the messy world of existing languages to express the pure mathematics of their field in such a way that it can run efficiently on the messy world of hardware.

[1] https://www.youtube.com/watch?v=8X69_42Mj-g#t=17m25s

Dr Meister: Using Lisp, LLVM, and C++ for molecular programming: http://www.youtube.com/watch?v=8X69_42Mj-g

https://www.youtube.com/watch?v=8X69_42Mj-g

This talk is even better. "C++ templates are to Commmon Lisp macros what IRS tax return forms are to poetry". I don't know both well enough to tell if it's true, but damn it's a good metaphor.

⬐ TeMPOraL

I know both well enough and I think it's very true :).

Christian Schafmeister's talks are great and I'm very impressed by his work. It was a great experience to meet him personally on this year's ELS. One thing I learned from chatting with him during the conference break is that his work on Clasp is actually pushing LLVM forward - when implementing Common Lisp / C++ cross-linking he found some bugs that were there because apparently no one before has been trying to do the stuff he's doing - so he had to nag some Apple engineers to get to work and fix them ;).

A small few: http://lisp-lang.org/success/.

EDIT: Also, https://www.youtube.com/watch?v=8X69_42Mj-g for a recent example of Common Lisp pushing the limits of science and computing in chemistry.

Another project that seem to argue for better abstractions, is clasp, and it's use for (among other things) refactoring c++:

"Clasp: Common Lisp using LLVM and C++ for Molecular Metaprogramming": https://www.youtube.com/watch?v=8X69_42Mj-g

"Using Common Lisp to refactor C++": https://www.youtube.com/watch?v=h31pURzgYX8

"Clasp — Bringing Common Lisp and C++ Together": https://github.com/drmeister/clasp

Lisp is programmable programming language, especially Common Lisp. It works as programmer amplifier. Better you are, more you benefit from it.

I challenge anyone to watch this lecture from Christian Schafmeister and say they are not impressed: https://www.youtube.com/watch?v=8X69_42Mj-g and https://www.youtube.com/watch?v=0rSMt1pAlbE

⬐ robohamburger

Only part way through the first video but this is very inspiring.

"C++ templates are to common lisp macros as IRS tax forms are to poetry" so true.

⬐ tosseraccount

What popular programs are written in Lisp?

⬐ stray

The software I produce at work is Ruby. I don't know that it's popular -- but it is central to a large company's operations.

But I generate and validate that Ruby code with Common Lisp -- in other words, I write Lisp that writes correct, idiomatic Ruby.

I would be very surprised if I were the only person doing this.

⬐ giancarlostoro

Is it possible that you can share some information on this, if allowed by your company / employer? This is a first I've heard of this, sounds quite interesting.

⬐ copperx

I understand why you might want to do that, but why are your reasons for doing it?

⬐ eudox

Have you written about this somewhere? I've love to read more about it.

⬐ nabla9

Popularity is not the correct measure stick.

Lisp is more like research language than implementation language for bean counting apps. Better question is what bleeding edge things have originated, are being done or have been done in Lisp.

John Carmak is doing VR research with Racket.

Christian Schafmeister doing molecular metaprogramming.

Raytheon implemented a signal processing analysis pipeline for missile defense in Lisp

Commercial Lisp vendors keep lists of some of their customers. Specialized Cad programs like Bentley PlantWise are not popular but they are very complex.

http://franz.com/success/

http://www.lispworks.com/success-stories/

⬐ eudox

Maxima and pgloader

http://maxima.sourceforge.net/

http://pgloader.io/

⬐ defgeneric

pgloader (Dimitri Fontaine) is a great piece of software.

There's also cl-abnf from the same author and project which is another great example of the expressive power of common lisp.

Also, everything Fernando Boretti does is awesome ;)

https://github.com/eudoxia0 http://eudoxia.me/article/common-lisp-sotu-2015/ https://github.com/dimitri/cl-abnf

⬐ ronjouch

I'm regularly hearing about web applications written in ClojureScript, a.k.a. Clojure (a dialect of Lisp, [1]) compiled to JavaScript. Recently I've heard of:

- https://github.com/asciinema/asciinema-player

- https://precursorapp.com/ (not open-source)

[1] http://www.clojure.org/

⬐ dopamean

Clojurescript is not "also known as" Clojure.

⬐ dctoedt

> Clojurescript is not "also known as" Clojure.

The GP says "ClojureScript, a.k.a. Clojure ... compiled to Javascript, which (I believe) is accurate.

⬐ betenoire

That's not what he said:

aka. Clojure (...) compiled to JavaScript

You stopped reading a few words too soon :)

⬐ dopamean

Ha. I misread. Thanks for the correction.

⬐ zubairq

There are also others, such as Appshare which I have built

⬐ vmorgulis

Emacs?

Edit: Urbit has a Lisp (http://urbit.org/)

⬐ defgeneric

Urbit is deeply reactionary.

⬐ vmorgulis

Curtis Yarvin, yes.

Brendan Eich is a bit too.

⬐ kruhft

The underlying 'functional assembly' VM language of Urbit (Nock) is a lisp that works on arbitrarily large integers. Here's a compiler for it I wrote a while ago, written in Common Lisp:

https://gist.github.com/burtonsamograd/29103c2dfaa67f4fd344

⬐ vmorgulis

Interesting.

The music on your home page reminds me a bit Utopia soundtrack (like the sound of the frog).

https://www.youtube.com/watch?v=_ZYVb8Q5i9w

⬐ kruhft

Thanks. I wrote it myself. I just put out a new album yesterday:

    http://kruhft.bandcamp.com/album/listener

⬐ ZenoArrow

If you count dynamic websites as programs then you're using one right now. ;-)

⬐ xrange

A better question: "What impressive programs are written in Lisp?". Or "Why isn't there a Squeak-like Lisp machine environment, where 'compatibility' doesn't have to matter?". If a language is incredibly productive and programmable, why don't we already have a VPRI-like STEPS environment in 20,000 lines?

http://www.vpri.org/pdf/tr2011004_steps11.pdf

⬐ delish

> What impressive programs are written in Lisp?

I'd only call this anecdote, but one or more benchmarks assert that cl-ppcre, common lisp's perl-compatible regex implementation, is faster than any other, include perl's.

The larger question I'm intuiting from your post, "Why doesn't language power make a difference in practice?" I don't have an answer to.

⬐ AnimalMuppet

> Why doesn't language power make a difference in practice?

Depends on your definition of "make a difference in practice". If you mean "make the language become one of the dominant ones", yeah, that doesn't seem to have happened. Either Lisp is less effective in the large than one would expect from its power, or it's less powerful in practice than people think, or power has almost no relation to language dominance.

But if you mean "make a difference to the user", well, it lets the user more easily write the program that the user wants to write. In practice, that makes a difference - to that user.

⬐ None

None

⬐ ianmcgowan

This is covered in the article. You might say it's the central point of the article - lisp attracts "lone wolf" programmers who want to build perfect abstractions closely mapped to the real-world problem; as opposed to projects that require many man-years of effort run by MBA's who want fungible "resources" to do their tiny-bite-sized pieces according to spec. The philosophy is different.

⬐ vmorgulis

There is OpenGenera (but more than 20k sloc):

https://github.com/ynniv/opengenera

⬐ defgeneric

State of the Common Lisp Ecosystem, 2015

http://eudoxia.me/article/common-lisp-sotu-2015

⬐ jdblair

AutoCAD uses AutoLISP for scripting and extension. Its been a significant part of AutoCAD since 1986.

http://ronleigh.com/autolisp/ahistory.htm

⬐ kruhft

emacs (mostly)

⬐ mkramlich

Signpost.com's backend was Lisp. Originally, when the company was named Postabon.

I know because I worked directly with their cofounding CTO, Shaneal Manek, during the early buildout phase. I wrote their launch iPhone app, and it talked to a web service Shaneal made, in Lisp. Our app was featured on live TV during some morning business news segment, major network. It was pretty exciting. Anyway they later shifted the feature set and, I believe, rewrote the backend in Java, after Shaneal went to Greplin. Pure speculation for the rewrite was because it was considered as being easier or "cheaper" to find Java devs. Though I'd argue a sharp/solid engineer can work in any language, and Shaneal was definitely that.

I'd suggest also that perhaps the biggest strategic win was that the combination of our slick iPhone app and the Lisp backend with the CxO's pedigrees all helped them to eventually land investment from Google Ventures. Runway and eyeballs are king.

I also worked at Orbitz as a senior engineer back when they used ITA and ITA had not yet been bought by Google. So I can +1 confirm on what is probably the most famous commercial application of Lisp.

⬐ incepted

Not many, but even so, this is never the right question to ask.

That question would be: what programs are written in <LANGUAGE> that couldn't benefit from being rewritten in another language?

And most often, the answer to that question is none.

Because languages matter a lot less than language fanatics want you to think.

As for Lisp, I used to be a total fan until I realize the importance of a sound static type system, and now I will never go back. Lisp will never go anywhere because this is the 21st century and we know now that static type systems are an absolute requirement for modern programming.

⬐ lokedhs

Right. That's why no one seriously consider Javascript for any new project, and no one would propose the idea of using it on a server.

I am not saying that you are wrong in liking static typing, but arguing that dynamically typed languages are non-starters in this decade is a statement that is easily disproven by the existence of Javascript.

⬐ dmbaggett

For one, the service that performs the vast majority of airfare searches -- formerly ITA Software, now Google Flights.

Having spent time at the MIT AI Lab and having co-founded a company whose principal product was a Lisp/C hybrid, I think the challenge with mainstream adoption of both Lisp-like and functional languages is the syntax. There's an element of "don't use a programming language that's hard to hire for" but I think that's secondary as it never bothered us or posed a real problem.

Naughty Dog's Crash Bandicoot games (which I also worked on) used Lisp for all the character control logic.

⬐ kruhft

> I think the challenge with mainstream adoption of both Lisp-like and functional languages is the syntax

Ironic(?) considering there is almost no syntax to Lisp.

⬐ defgeneric

It's really such a simple syntax change from f(x) to (f x) yet it makes an enormous difference and opens up a whole new world of possibilities. Sure, there are homoiconic languages in which you can write macros that aren't lisps but the expressive power and ease of use suffers. Take for example macros in Julia (itself heavily lisp-inspired), they're possible but ugly and not nearly as seamless as macros in lisp.

⬐ dmbaggett

That's exactly the problem: until you're used to it, it looks nothing like psuedocode. Contrast with Python. I'm not saying it's right, I just think this is the issue.

⬐ kruhft

Really, the major difference syntactically is:

   (f x)

vs.

   f(x)

I've never really understood why people seem to have such a hard time with that.

⬐ xrange

    c = sqrt(a*a + b*b)
    
    (set! c (sqrt (+ (* a a) (* b b))))

⬐ klibertp

    (define c
      (sqrt
       (sum (sqr a)
            (sqr b))))

Which you read out loud like this: "c is a square root of a sum of two values, squared".

Easy to read as you see and easy to understand. This:

    c = sqrt(a*a+b*b)

is way harder to read.

⬐ mahyarm

I think the thing about lisp isn't the fact that it's functions start with a paren. It's the fact it uses function composition to write everything that makes it harder to keep track of. Most languages don't define their functions like this:

  c = sqrt(a^2+b^2)
  vs.
  define(c, sqrt(sum(sqr(a),sqr(b))))

  def getMaxValue(numbers):
		answer = numbers.first()
		for (i in xrange(numbers.length)):
			if (numbers[i] > answer):
				answer = numbers[i]
		return answer

  vs.
  (defun get-max-value (list)
	  (let ((answer (first list)))
	    (do ((i 1 (1+ i)))
	        ((>= i (length list)) answer)
	      (when (> (nth i list) answer)
	        (setf answer (nth i list))))))

  if you could only use python functions:
  defun(get-max-value, [list], 
		let(answer,first(list)),
		 do( (i,1,(1+ i)), 
		 	(>=(i, length(list)), ans), 
		 when( >(nth(i,list),answer), 
		 	setf(answer,nth(i,list)))))

  defun(get-max-value, [list], let(answer,first(list)), do( (i,1,(1+ i)), (>=(i, length(list)), ans), when( >(nth(i,list),answer), setf(answer,nth(i,list)))))

⬐ klibertp

> if you could only use python functions

I'm not sure if this is what you're talking about but there actually is a Lisp where you can call Python functions. It's called Hy[1] and I encourage you to take a look, it borrows some good solutions from Clojure, but generally is quite an acceptable Lisp :)

[1] http://hylang.org

⬐ lispm

The actual Lisp version is:

    (defun get-max-value (list)
      (reduce #'max list))

or even

    (defun get-max-value (list)
       (loop for element in list maximize element))

⬐ mahyarm

Not really. We are demonstrating how multiline statements become hard to read in lisp because in practice you can only use function calls to write everything.

Any language where you write an entire function as a huge one liner expression with functionality in nested function calls is hard to read. It's the behavior, not the syntax per say.

What the actual behavior is doesn't matter as much, even if you can reduce both of them to one liners in many languages.

ex:

  def get-max-value(list)
    reduce(:max, list)
  end

⬐ klibertp

I already mentioned sweet-expressions in another comment. And also, there's one important thing we're forgetting when discussing syntaxes, which is the fact that we very rarely read the code without syntax highlighting, so the examples you posted actually look like this: http://pygments.org/demo/3781004/

This does change the situation somewhat.

⬐ lispm

Not really, since Lisp does not only have function calls, but special forms and macros.

In actual Lisp practice, one uses macros, special forms and function calls.

You seem to have failed to understand the difference.

There are two REAL reasons why Lisp is harder to read than some other languages:

* the syntax looks and works slightly different and most programmers have been trained to other programmning language syntax. With training, this is less a problem.

* Lisp uses a data syntax as the base layer of the programming languages and encodes programs as data. So the syntax of Lisp comes on top of s-expressions. Very few other programming languages are doing that and as a consequence it complicates a few things. The user of Lisp has to understand the effects of code as data. This is something you don't have to understand in Java or Python. It can be learned, but it has to be learned.

At the same time, this code as data principle of Lisp gives a lot of power, flexibility and new capabilities. It makes Lisp different and in some way more powerful than Java or Python. The added power comes from easy syntactic meta programming in Lisp, which neither Java nor Python provide. This has also consequences for interactive programming, since programs can be written and manipulated by programs under user control.

⬐ jstimpfle

No.

Why do mathematicians not use s-exps but syntax that is much more similar to C? Reading "sum" "mul" etc. takes longer than if you have visual anchors like * +. And infix is an advantage for simple expressions, because they split arguments, where as with sexps you have to parse from left to right and count parens.

⬐ vlasev

As a mathematician, sum(whatever) or product(whatever), reads just fine. There are in fact, a lot of uses of sums and products, so after a while, they are pretty naturally.

⬐ jstimpfle

Yes, sum(whatever) is fine. What is "whatever"? If it's the common case of two operands, then I don't think you're making a point against a + b.

And you don't think (sum (mul a (minus b c)) d), or (+ (* a (- b c)) d) for that matter, is more readable than a * (b-c) + d, do you?

> There are in fact, a lot of uses of sums and products, so after a while, they are pretty naturally.

I think you are talking about summing up a collection (like, an array, a matrix, etc.) as opposed to building an expression tree. Of course, sum(myIntList) is just fine. That's a whole different story.

There are also the rare cases where you have to sum, like 6 integers. (sum a b c d e f) might not be worse than a + b + c + d + e + f. But that's by far not the common case in most problem domains. The common case is like a*(b-c) + d.

⬐ klibertp

> Why do mathematicians not use

Please tell me why should I care. No, really - I'm a programmer, not a mathematician.

> Reading "sum" "mul" etc. takes longer than if you have visual anchors like * +.

Citation for this?

IMO it's exactly the opposite, but I may be wrong. Some kind of reference would be nice.

> And infix is an advantage for simple expressions, because they split arguments, where as with sexps you have to parse from left to right and count parens.

Ok, so 2 ("sum" vs. "+", 3 vs. 1 char) additional characters are bad, because they take longer to read, but for example 3 additional characters here:

    (+ a b c d)
    vs.
    a + b + c + d

are good, because they take longer to read. That's interesting.

⬐ jstimpfle

>> Reading "sum" "mul" etc. takes longer than if you have visual anchors like * +.

> Citation for this? IMO it's exactly the opposite, but I may be wrong. Some kind of reference would be nice.

I know it from myself and don't think I have to to provide evidence that by large most people work like this. Reading and interpreting text is just WAY more complex a process and thus much slower than associating a shape with a meaning.

For example, application designers have known for a long time that it's important to build a symbolic language (icons etc) because that's just way faster (once you have learned what the symbol means, for example with the help of a tooltip).

There's another guy who explained this at length

http://c2.com/cgi/wiki?LispLacksVisualCues

Search for "top" throughout the page.

> (+ a b c d) vs. a + b + c + d

Yes. But as explained in my other comment, that's not optimizing for the common case.

⬐ klibertp

> I know it from myself and don't think I have to to provide evidence that by large most people work like this. Reading and interpreting text is just WAY more complex a process and thus much slower than associating a shape with a meaning.

I don't think there is a difference in speed between reading "sum" and "+". You don't read the word "sum" letter by letter: you see it as a whole token and your brain recognizes it instantly.

> For example, application designers have known for a long time that it's important to build a symbolic language (icons etc) because that's just way faster (once you have learned what the symbol means, for example with the help of a tooltip).

You're talking GUI, which is different than writing and reading code. There are, for instance, much less GUI elements visible on the screen than there are identifiers even in a short snippet of code and there is much more context available for deduction in the code than in the GUI. I don't think the two situations - recognizing GUI features and recognizing and understanding identifiers in the code - are comparable.

⬐ jstimpfle

Come on. It's totally obvious that the shapes of * and + are much simpler and much more distinct than "sum" and "mul" (which by the way are relatively short and simple examples for words).

Humans have excellent shape recognition -- recognizing (and differentiating) a tree and a person happens subconsciously, effortlessly. Interpreting the words "person" and "tree" takes way more effort.

Similarly, humans have usually very good spatial sense. If there are persons to the left and to the right of a tree, it is effortless to recognize that they are "separated".

> You're talking GUI, which is different than writing and reading code.

No. I'm talking perception.

> There are, for instance, much less GUI elements visible on the screen than there are identifiers

That depends. There are very complex GUIs out there. But let's assume it for a moment. (By the way that typically that means the code is not good (weak cohesion)).

> there is much more context available for deduction in the code than in the GUI.

That is not supportive of your previous argument: The more identifiers, the less context per identifier.

> I don't think the two situations - recognizing GUI features and recognizing and understanding identifiers in the code - are comparable.

It's both about perception. It's very, very important that programmers can focus on their work instead of wasting energy building parse trees in their minds, incurring severe "cache misses". Again, take this simple commonplace example:

  (sum (mul a (minus (b c)) d)
  a*(b-c) + d

If you don't think there's a huge difference I can't help you. I'm sure I need about three seconds to parse the sexp as a tree and figure out what goes with what. Then I have to go back and interpret the operators.

Conversely, the infix/symbol operators example I can map out with minimal, and linear, movement of the eyes. In most cases I don't even need to parse it as a tree -- it's almost a sequence. On a good day, it costs me maybe a second to parse the thing and extract the information I need.

Another advantage of symbols for arithmetic is that they give a sense of security, because one can intuitively infer that they have "static" meaning. While usually words are reserved for things that change, i.e. mutable variables. Being able to infer non-mutability based on shape alone gives a huge advantage.

⬐ klibertp

> Come on. It's totally obvious that the shapes of * and + are much simpler and much more distinct than "sum" and "mul"

I disagree that it's obvious. Moreover, I don't believe there is a measurable difference between the speed of recognizing "sum" and "+", once you're equally familiar with both.

> The more identifiers, the less context per identifier.

I don't believe it's that simple, but we're starting to go into semantics (which are part of comprehensibility of code, but not part of it's readability I think).

> If you don't think there's a huge difference I can't help you.

I think you can help yourself: just go and train yourself in reading prefix notation, like I did. Then get back to this example and then tell me again that there is a huge difference.

> I'm sure I need about three seconds to parse the sexp

I don't even know how to measure the time I needed to read the sexp, it was that short. And I even instantly realized that you've put parens around "b c" in the "minus" call, which would cause an error in most lisps.

> Conversely, the infix/symbol operators example I can map out with minimal, and linear, movement of the eyes.

That's why I used newlines and indentation in my example above. To take your example:

    (sum (mul a (minus b c))
         d)

This also reads linearly, just in a different order than you expect. This doesn't make it objectively harder or slower to read, it's just unfamiliar to you.

Also see my other comment on familiarity: https://news.ycombinator.com/item?id=11180682

⬐ jstimpfle

I'm not interested in differentiating between readability and comprehensability. If I want to work on some code I need to comprehend it. That starts "in the small" with the mechanical aspects of "readability", if you will. Where to draw lines is not relevant. Every aspect to the process of comprehension is important. The "small" aspects are more important than you might think: Because they affect every line of code. Whereas there are fewer instances of the more global aspects to comprehension.

Like in a binary tree, where half of the elements are in the lowest level.

> you've put parens around "b c" in the "minus" call

You have a point. One pair of Irritating Superfluous Parentheses less.

    > (sum (mul a (minus b c))
    >      d)

Even the consideration to sprinkle such a trivial expression over multiple lines hints at the superiority of a * (b-c) + d. It's just the most straightforward thing to do. No far-fetched argument can change that.

I'd love to see eye-tracking data which show the tradeoffs between various syntaxes.

The regularity and the simplicty of sexps is of course good for computers, because these can barely associate. Because they can't learn new tricks (they have fixed wiring). But humans have streamlined their languages (which also includes syntax; again, I'm not differentiating here) to their environments since forever.

Sexps are also good for abstraction and meta programming. But as we all know abstraction has a cost and there is no point in abstracting an arithmetic expression. And most code, for that matter.

⬐ klibertp

> I'm not interested in differentiating between readability and comprehensability.

Fair enough, but then please stop using single letter variable names, add type annotations where applicable, provide docstrings and contracts for functions. Comprehensibility is so much more than syntax that I think mixing the two will make for even more interesting, but even less fact-based discussion.

> I'd love to see eye-tracking data which show the tradeoffs between various syntaxes.

Yeah, that would be very interesting. The thing is, there is no such data available, but you still are convinced that one kind of syntax is better than the other. I'm not - from where I stand the differences and tradeoffs in readability of syntaxes, once you know them equally well, seem too minor to measure.

> Even the consideration to sprinkle such a trivial expression over multiple lines

No. It's just different way of getting to the same effect. I don't see why would one be worse than the other (splitting things using infix operators vs. splitting things using horizontal and vertical whitespace).

Other than that, you completely avoided the familiarity issue. Do you think that we're genetically programmed for reading infix syntax? If not, then it means we need to learn infix syntax just like any other. My question was, would someone not yet exposed to infix propaganda have a harder time learning infix (with precedence rules and resolving ambiguities) or prefix?

You also ignored my question about the difference in readability when you are equally well trained in both syntaxes. You can't compare readability of two syntaxes fairly unless you have about equal amount of skill in both. And the fact that readability is influenced by skill is undeniable. So, in other words, are you sure you're as skilled with sexps - that you wrote comparable amount of code - as with infix? Honestly asking.

⬐ jstimpfle

> Comprehensibility is so much more than syntax

Absolutely. It's a tender flower.

> No. It's just different way of getting to the same effect. I don't see why would one be worse than the other (splitting things using infix operators vs. splitting things using horizontal and vertical whitespace).

It's very important since size matters. Efficiency of encoding and cost of decoding (~ perception) matters. But if you don't think it makes a difference -- fine, you are free to read braille instead of plain text even if you have perfect eyesight. You can also add three layers of parens around each expression if you think that's more regular.

> Do you think that we're genetically programmed for reading infix syntax?

No. There's this fact that all combinations of basic grammar are represented in natural languages: SVO, SOV, VSO, VOS, OSV, OVS. And then there are some programming languages which don't differentiate between subjects and objects, but go for (OVO), VO, VOO, VOOO... (or concatenative style OV, OOV, OOOV...). Which is great since the goal of formalism is to be "objective". (Note that Object-oriented programming is actually subject-oriented programming from this standpoint. It's not "objective")

Instead I say that it is more efficient if syntax is optimized for the common cases. Shorter is better, if the decoding won't produce more cache misses. Infix and symbols don't produce cache misses for the vast majority of humans, in the case of arithmetic (read: mostly sequential, barely tree-shaped) expressions.

Sexps are inherently unoptimized for the common cases. They are "optimized for abstraction": for regularity. It is an explicit design goal to not differentiate things which are different "only" on a very concrete level. Instead of content, form is accentuated. This is not suitable for the > 95% of real life software that is just super-concrete and where abstraction has no benefits.

I'm sure I have now given 5 to 10 quite plausible examples which support the standpoint that symbols-and-infix arithmetics is good for humans, based on how their mind works. You haven't provided any counter-arguments but just shrunk off everything. But thanks anyway for that. I think I'm satisfied now with the examples that came out.

> are you sure you're as skilled with sexps [..] as with infix?

No. Never will be.

Are you? Show me a Lisp program with more than casual usage of arithmetics and tell my why you consider it readable. By the way, the first google hit I just got for "lisp arithmetic readability" is http://www.dwheeler.com/readable/

⬐ lispm

> Infix and symbols don't produce cache misses for the vast majority of humans

You tried to prove your theory by finding positive evidence. But the evidence is very weak and far fetched.

> which support the standpoint that symbols-and-infix arithmetics is good for humans, based on how their mind works.

Given that we largely don't know how the mind 'works', that's a weak argument.

> Show me a Lisp program with more than casual usage of arithmetics and tell my why you consider it readable.

Given that a lot math code is expressed in low-level Fortran, I'll take Lisp every day.

From a statistics system in Lisp:

    (defgeneric gaussian-probability-density (x params)
      (:documentation "general gaussian density method.")
      (:method ((x number)
                (params gaussian-probability-univariate-parameters))
        (\ (exp (* -1.0 (/ (- x (mean params))
                           (standard-deviation params)))
           (sqrt (* 2.0 pi (variance params))))))

I find that perfectly readable.

⬐ AnimalMuppet

If my cup hadn't been empty, you would owe me a new keyboard.

What? You were serious? Um, no. Just no. Your way is not easier to read - at least, not for (I would guess) 95% of programmers, and 99% of humans.

⬐ klibertp

How do you know? Any proof/any scientific source, or is it just lore and how you personally feel about this?

⬐ AnimalMuppet

I already admitted that it was a guess. But I still think I can defend it.

Starting in elementary school, everyone learns to read math notation. By high school, everyone knows what

  c = sqrt(a*a + b*b)

means. The Lisp version may be easier to read for those who have spent enough time using Lisp. That's not the majority of programmers, though, and it's only a tiny minority of the general population.

Do you think that, to a non-Lisp programmer, the Lisp version is easier to read? Do you think it is easier to read to a non-programmer who has had high school math? Or is it just easier to read for you?

⬐ terminalcommand

Learning lisp syntax requires just a very short introduction. In SICP, it is said that they never formally taught lisp at class. The students just pick Lisp up in a matter of weeks.

⬐ klibertp

> Starting in elementary school, everyone learns to read math notation. By high school, everyone knows what

We're either talking about objective readability or personal familiarity. What you say is that, after extensive training for many years, it is easier for people to read notation they were trained to read. This is both true and utterly uninteresting.

What is interesting, though, is how much training you need to read prefix and how much training you need to read infix. It's obvious that infix takes more time to learn: operator precedence and things like using "-" in both infix and prefix forms make it objectively more complex than prefix notation. You just forgot how much time you spent learning it.

> Do you think that, to a non-Lisp programmer, the Lisp version is easier to read? Do you think it is easier to read to a non-programmer who has had high school math?

Again, this is not interesting at all. You're talking familiarity, not readability. Of course, it's easier to read something you've been taught to read. To make this more objective, take an elementary school kid - who wasn't exposed to years long infix propaganda - and check both notations' readability with them.

Personally, I learned to read just about any kind of notation used in programming. From my observations, there are only minor differences between the speed of comprehension when using different notations - once you've trained enough. The difference is how much training you need. I can tell you that reading J - an infix language, it's an APL descendant - took me much, much longer to master than reading Lisp.

⬐ Houshalter

Imagine you removed a parenthesis at the end. Would you even notice? It's not compact at all, and there are fewer visual cues.

Infix notation works better when it is applicable. Limiting the number of parentheses is also best when possible.

You can add parentheses and make it less compact if you want. You could theoretically write c=sqrt(axa+bxb) as:

    c =
        sqrt(
            ((a *
                a) + 
                (b *
                    b)))

But that's just ridiculous.

⬐ klibertp

> It's not compact at all,

You are now arguing against parens. You can have mostly prefix syntax without parens, with blocks delimited with indentation only. Scheme's sweet-expressions[1] are one such example. Anyway, please take my example, remove the parens and check if your argument still applies.

If it does, then it's down to the function names and your (common) misconception that "+" or "^" is somehow more readable, easier to understand or something than "sum" or "sqr". Where I simply disagree. BTW: why do you insist on using infix syntax for a couple of operators, while you use every other possible operator in a prefix notation and are happy with it? What is the difference between "sqrt" and "-" which makes it ok to use sqrt in prefix form?

> Limiting the number of parentheses is also best when possible.

No. It's only best if it aids readability. This is something that Lisp does rather well actually - there are many examples of equivalent Java and Clojure expressions where Clojure version has half as many parens. Getting rid of parens for the sake of getting rid of parens is counterproductive.

[1] http://srfi.schemers.org/srfi-110/srfi-110.html

⬐ Houshalter

Because your version takes up 6 lines! A simple one line expression!

And yes you can remove the parentheses, but not only does no one do that, it still takes up 6 lines. And then you have significant whitespace too.

>why do you insist on using infix syntax for a couple of operators, while you use every other possible operator in a prefix notation and are happy with it? What is the difference between "sqrt" and "-" which makes it ok to use sqrt in prefix form?

Because that's universal and standard for math notation. But also sqrt only takes one argument. If it took two arguments, then it would be perfectly reasonable to add an infix operator for it too. Many languages do add infix operators for everything from combining strings to ANDing booleans, etc, because they are so much more readable.

⬐ knughit

Yes, whichever ever one you have seen a million times before looks more readable. So?

⬐ AnimalMuppet

Something nobody has mentioned yet is that, in the C-style version, the precedence rules are eliminating some parentheses. You can't do that in Lisp (except maybe with a macro). But then, in Lisp, you don't have to remember precedence rules.

In this example, the advantage is on the C side, because pretty much everybody who knows any math knows that multiplication has precedence, and they can just read that syntax. If you have to go look at the precedence chart in K&R or Stroustrup before you know how to parse the expression correctly, well, then the Lisp approach is probably more efficient...

⬐ 21

Can you understand why most have a hard time with

  (* (+ a b) (+ c d))

instead of

  (a + b) * (c + d)

Hint: if the first notation is so superior, why don't math papers use it.

⬐ Jtsummers

I do understand, but I'll also point out that that first expression will often (with longer variables or expressions in particular) be broken out like:

  (* (+ a b)
     (+ c d))

Which is readable, though not necessarily compact.

Also, * and + in the former, aren't strictly the same as in the latter. * and + take an arbitrary number of parameters in CL. From [0], `(* )` => `1`. I can't test, but I believe `(* 2)` => `2` (the spec doesn't describe the case of a single parameter, unless I'm missing it). `+` is the same, but `(+)` => `0` instead, it's identity value.

Order of operations is made more explicit, and, I've found, it's more useful to think of `+` and `*` as `sum` and `product` rather than `plus` and `times`.

[0] http://www.lispworks.com/documentation/HyperSpec/Body/f_st.h...

[1] http://www.lispworks.com/documentation/HyperSpec/Body/f_pl.h...

⬐ rol

If you have Quicklisp[1] installed you can install the "infix" package and get infix notation in Common Lisp[2]:

    $ sbcl
    This is SBCL 1.2.4.debian, an implementation of ANSI Common Lisp.
    More information about SBCL is available at <http://www.sbcl.org/>.
    
    > (ql:quickload 'infix)
    ; Loading package
    (INFIX)
    > #i(1 + 1)            ; addition
    
    2
    > #i(2^^128)           ; exponentiation
    
    340282366920938463463374607431768211456
    > (defun factorial (x)
         #i(if x == 0 then
              1
            else
              x * factorial(x-1)))       ; infix function call
    
    FACTORIAL
    > (factorial 5)
    
    120
    > #i(factorial(5) / factorial(6))
    
    1/6
    > '#i((a + b) * (c + d))      ; Put a ' before the #i() to see what code is generated
    
    (* (+ A B)
       (+ C D))

--

[1] - https://www.quicklisp.org/beta/ [2] - Don't know if there is a similar package for Scheme.

⬐ adwf

I wouldn't recommend using infix libraries if you really want to get into Common Lisp though. They're a bit of a crutch for people coming from other languages, but that's it.

Pretty much the whole language is based on Polish notation. The sooner you realise that + - * / are just function names like any other, the better you'll do.

For example:

  (+ 1 2 3)

  in plain symbols is just:

  (function parameter parameter parameter)
  
  But if I were to write my own addition function:

  (addition 1 2 3)

  it would also be:

  (function parameter parameter parameter)

  and so is:

  (http-request "http://www.google.com")

  (function parameter)

If you use infix notation, you're writing half your code in a competely different semantic to the other half. I can't imagine it helping people really get a proper grasp of how Common Lisp works.

⬐ jrapdx3

> Don't know if there is a similar package for Scheme.

I have to agree with others in the thread that infix in Lisp/Scheme is not the convention, and IMO an awkward fit. Don't recall encountering infix in any published/shared code I've seen, it may exist, but to learn Scheme becoming comfortable with s-expr notation is definitely necessary.

However, there is SRFI 105[0] which describes "curly infix expressions". It's implemented in Guile 2.x, possibly available in a few others but evidently not had a lot of uptake among Schemes.

[0] http://srfi.schemers.org/srfi-105/srfi-105.html

Edit: added URL

⬐ 21

Math does also have `sum` and `product` in the form of Sigma and Pi. Of course, not exactly the same thing (since they operate over a set, not discrete elements).

I would venture to say that the reason infix notation is naturally preferred is related to our psychology, the same way most human languages are SVO (Subject Verb Object) or SOV. VSO languages (Lisp like) are less prevalent.

In general my opinion is that when a majority vastly prefers one alternative, there is usually a strong reason for it (even if it may be irrational) and it's foolish to go against the grain.

⬐ Jtsummers

Infix is mostly used, in programming, within mathematical and logical expressions. But the majority of my code spends its time in some kind of chain of function calls, which has the verb first. Maybe if I did more with OO-languages I'd see it differently?

⬐ AnimalMuppet

Interesting. OO syntax often is object.function(arguments), which is subject-verb-object order. I never thought of it that way before. You can throw some adverbs in among the arguments, too.

⬐ knughit

That's correspondent with how Java and especially Obj-C and super especially AppleScript programmers try to write code that reads like COBOL, er, English.

⬐ knughit

Lisp is VOO, not SVO.

Java is SVO.

C is VOO too.

⬐ stan_rogers

I seem to recall that SOV (reverse Polish notation) is marginally more prevalent than SVO among the world's languages... though it is true that most creoles are SVO, which does at least seem to indicate that it's a default of sorts.

⬐ mbrock

Nobody claimed Lisp syntax was optimal for math papers. Neither is C syntax. The Lisp syntax does have advantages for program source code. Sure, it has disadvantages too. Everything is a compromise.

The Lisp syntax is so incredibly controversial, and that fact itself is incredibly strange to me. I see it as a pragmatic engineering decision: let's represent source code as syntax trees, and then sophisticated editing modes become straightforward, macros become straightforward, and the syntax becomes very uniform.

This big thread indicates another reason Lisp isn't popular: because people keep arguing back and forth about the textual syntax, rather than discussing actual experiences with using it.

⬐ lispm

There are actual features which make Lisp a bit more difficult to understand and a few are related to syntax: especially the code as data feature. Some elements of the language have different purposes: both as code and as data. Symbols can be data and they can be identifiers. Lists can be data and they can group elements of the programming language. Others have only one purpose. For example an array is always data.

Symbols and lists behave differently depending on the context:

Examples for Lisp snippets:

   (foo bar baz)  ; it could be a macro, function or special operator form

   (quote (foo bar baz))   ; here it is data

   (defun do-something (foo bar baz) (a b c))  ; here it is an arglist

   (defun do-something (a b c) (foo bar baz))  ; one element later it is a form

These context need to be learned and actual visual clues are a) the symbol in front and b) the structure of the expression.

This is puzzling for a lot of people. A few never really take that hurdle.

⬐ kruhft

Yes, they learn the second syntax from birth. There have been arguments to teach the lisp syntax in mathematics due to it being easier to understand with multiple arguments:

    (+ x y z a) instead of (x + y + z + a)

Also, there are no order of operations problems with the lisp syntax like there are with traditional mathematical notation (unless you use parens, which makes it look even more lispy).

⬐ Shorel

I found math major students to grasp Lisp much faster than C.

Therefore I would say the answer is simply familiarity and concern for the audience.

⬐ greydius

So why don't we write all binary operations that way? eg. x f y instead of f(x,y). I've always felt more comfortable with prefix notation, especially because it easily generalizes to more than two arguments. I think infix notation is an accident of mathematical history.

⬐ knughit

Welcome to Haskell, where anything can be infix :-)

⬐ greydius

That can be nice in a lot of situations. e.g.

    (+) 4 2
 vs. 
    (+) <$> Just 4 <*> Just 2

I usually prefer the applicative style above to

    liftA2 (+) (Just 4) (Just 2)

because it preserves the "form" of the original expression and generalizes to more arguments. ie. it doesn't require liftAn for whatever n number of arguments my function takes.

⬐ ACow_Adonis

With all due respect, math papers don't, I think, pretend that their syntax makes any claims to optimality of any kind.

Indeed, most math syntax (in my experience) has a very explicit reason why it's used: historical circumstance, convention and common tradition.

⬐ weavie

Arithmetic is one place where infix notation is generally easier to read. If I were writing a program that basically just did a load of mathematics I may even consider using a different language.. However looking over the software I generally develop, I probably need to use arithmetic in about .01% of the code.

⬐ wolfgke

> Hint: if the first notation is so superior, why don't math papers use it.

As a mathematician I'd love to use it in my papers, but no reviewer would accept such a paper.

⬐ stray

I have no idea why the people who write math papers make the choices they make.

But I'd like to point out that in your second example the parentheses are needed because infix notation is inherently more complicated.

In the first example however, the notation is far simpler: a simple list of function plus zero or more arguments.

⬐ lispm

Math papers use a very complex 2d notation last I've looked.

⬐ dragonwriter

> Hint: if the first notation is so superior, why don't math papers use it.

Math papers usually use neither the first nor the second.

they use:

  (a + b)(c + d)

in the example you propose, and, reversing the operators so that the first style would have:

  (+ (* a b) (* b c))

and the second:

  (a * b) + (c * d)

math papers would usually have:

  ab + cd

So, I'm not sure "math papers do it differently" is the argument you want to use to advance your second syntax over the first.

Of course, since in lisp + and * are variadic rather than binary operators, they are a lot more like the pi and sigma operators applied to sets in mathematics than binary operators. Which are prefix, not infix. So, there's that.

⬐ whitegrape

Additionally there's more than one macro system out there to allow for infix math in Lisp... And for non-mathy things, in Clojure at least you're often using the threading macro -> or some variation of do/doto.

⬐ stray

It's probably because in algol derived languages -- when you encounter parentheses, something weird is happening -- something you've got to put extra thought into.

Maybe the ordering of something is being forced. Maybe something else is going on, but whatever it is requires more thought than things that are parentheses free.

So you look at Lisp and your brain locks up the brakes, with "WTF is going on here??? I'm out".

⬐ lawpoop

I guess that's ironic, but with people coming up used to all the ornate syntax, one of the common balks is "all those parenthesis, it all looks the same" and "there is no syntax, how do you read this."

It's like going from Arabic numerals to counting by groups of five; initially, it feels like you're losing expressive power. And, of course, at a glance, you can't read "|||||||||||||||||||||||||||||" as quickly as you can "28".

⬐ kruhft

Here's a good wiki on the topic:

http://c2.com/cgi/wiki?LispLacksVisualCues

After a brief period of usage 'the parens disappear' and you just read the code by indentation.

⬐ marssaxman

So, uhh... why not use a notation where nesting is expressed via indentation, then? I don't understand how the syntax can be considered superior if the way people actually cope with it is to hide another syntax inside it.

I was dumping ASTs as part of a little language project recently and my first impulse was to render them as S-expressions. Alas, it just wasn't readable; I couldn't make any sense of it. Indented YAML style lists, though? The structure pops right out and the information I wanted was immediately obvious. There were no constraints here, I was free to render text in any way that suited me; the Lisp style syntax just wasn't helpful.

⬐ scentoni

A Lisp with significant indenting (like Python) would bear a strong resemblance to Haskell.

⬐ tilt_error

I prefer having a parser produce an abstract syntax tree. From an expressiveness viewpoint, you get a good deal of raw power from being able to manipulate this directly instead of having to instruct a lexer/parser to do it for you. I don't necessarily think this is a good thing though.

⬐ reitanqild

I know almost nothing about lisp, but what comes to mind is car, cdr which aren't exactly the most descriptive keywords of programming languages I have seen.

(I think they are replaced in modern versions but my point still stands as I remember the old ones, not the new)

⬐ defgeneric

Yes but can you do caaaaaar or caaddaar or cdaar, etc. with head and tail?

In 5 characters with cadar you can express walking along a tree structure to get exactly the node you want.

⬐ AnimalMuppet

Sure. caaaaaar -> heaaaaaad. cadar -> heaiad. It's one more character, but if you really want to express yourself that way, there's no reason you couldn't...

⬐ davexunit

car, cdr, cadr, and friends are discouraged in some Lisp communities where pattern matchers are available.

⬐ kruhft

Yes, sometimes 'car' and 'cdr' are replaced with 'first' and 'rest' and are some of the first things you cover when learning the language, so I don't think the names would really be hindering adoption for those that try to learn the language. The benefits of car and cdr are that they can be composed: (caadr l) instead of (car (car (cdr l))) for example.

⬐ AnimalMuppet

Well, if you use "first" and "rest", then (caadr l) could become (firrest l) or something like that...

⬐ bhrgunatha

I like Racket's second, third, fourth,... etc. [1]

I don't think there's an equivalent to cddadr for example, but at that level of deconstruction you're better off abstracting the data structure (maybe a struct [2]) or using some other mechanism like match [3]

[1] http://docs.racket-lang.org/reference/pairs.html?q=second#%2...

[2] http://docs.racket-lang.org/reference/define-struct.html?q=s...

[3] http://docs.racket-lang.org/reference/match.html?q=match#%28...

⬐ adrianm

If you mean Lisp as a straightforward expression of "Lambda calculus" then I would agree.

However, Lisp as in Common Lisp most certainly has a good amount of syntax. And let's not forget macros which amount to user defined syntactic extensions.

Here are some examples of syntax built into the standard:

Lambda lists have varying syntax depending on context. http://www.lispworks.com/documentation/lw70/CLHS/Body/03_d.h...

Declarations have both standardized and implementation defined syntax for introducing information into the compile-time environment: http://www.lispworks.com/documentation/lw70/CLHS/Body/03_c.h...

Type specifiers introduce new syntax for both standardized and user-defined types: http://www.lispworks.com/documentation/lw70/CLHS/Body/04_bc....

Logical pathnames: http://www.lispworks.com/documentation/lw70/CLHS/Body/19_ca....

Feature expressions: http://www.lispworks.com/documentation/lw70/CLHS/Body/24_aba...

And of course, programmable reader macros which is how syntax for every single language primitive in the language is introduced: http://www.lispworks.com/documentation/lw70/CLHS/Body/02_d.h...

Here's an example of a complex standardized macro with its own domain specific syntax (loop): http://www.lispworks.com/documentation/lw70/CLHS/Body/06_a.h...

Let's not forget that most of what one might think of as built-in features in Common Lisp are actually standardized extensions to the language built with macros.

All of the power, expressivity, and extensibility of Common Lisp is what makes it my favorite programming language. It's what makes everything like above possible and gives power back to the user. But ignoring the syntactic complexity will not win us any followers!

TLDR: Common Lisp isn't simple, but it exposes one of the most powerful and empowering programming environments we have.

⬐ kruhft

> If you mean Lisp as a straightforward expression of "Lambda calculus, then I would agree.

That's what I was talking about. The language, being programmable, especially with read macros, can be used to create a very syntactically full language, but at it's basic core level, there is really just '(', ')', '.' and symbols.

⬐ Avshalom

There aren't a lot of symbols to Lisp but there's plenty of syntax

Using Racket:

  (if bool then else) instead of (if bool then) or (if (bool then) (bool else))
  (if (> x y)
    (x)
    (y)) ;fails for numbers because (x) is considered a function call (even though 3 is an invalid identifier and thus can be assumed to be always be a number).
 (define (fun x y) (...)) instead of (define fun (x y) (...)) or (define ((fun (x y)) (...)))

That's syntax.

Just because I'm not using {}'s here and infix there doesn't make it any less syntax. That's just the two most basic forms too; bring in loop? forget about it. This also ignores things like '(@,) or (x . y) but I'm not a lisper so I don't know how often that actually comes up

⬐ stray

I think you're conflating syntax with semantics.

⬐ Avshalom

I am not. Syntax is the structure, semantics the meaning (I mean more or less).

(def (fun x y) (...)) is syntactically different than (def fun (x y) (...)) even if they are semantically equivalent.

⬐ greydius

The syntax is the same. Both are s-expressions. The difference is how a particular implementation interprets them. In this example, it would depend on the semantics of def.

⬐ lispm

That's only the syntax of s-expressions - a data format.

The Lisp syntax is defined on top of s-expressions.

For example Common Lisp has a CASE operator. That's the EBNF syntax:

    case keyform {normal-clause}* [otherwise-clause] => result*
    normal-clause::= (keys form*) 
    otherwise-clause::= ({otherwise | t} form*) 

An example:

    (case id
      (10 (foo))
      (20 (foo) (bar))
      (otherwise (baz)))

The expressions are written using s-expressions as data. But still there is structure in those s-expressions, described by the EBNF syntax of CASE.

Every special operator and every macro provides syntax. Since users can write macros themselves, everybody can extend the syntax. On top of s-expressions.

⬐ greydius

That is interesting. I've always considered lisp in terms of denotational semantics. In fact, I wrote a toy lisp in which the complete grammar was basically

    list -> ({symbol | number | string | list}*)

and then it was up to the interpreter to decide the meaning of special forms. (I say "basically" because there was also desugaring of '(...) to (quote ...)).

⬐ Avshalom

(3) vs 3 is a both really. In say smalltalk you can call 3 and it would return 3 because semantically it's an object where as in lisp it's not callable (even if in CL it may be represented as a CLOS object I don't know)

syntactical ( ) isn't actually a procedure call we can see this in (define (id x y) (..)) or (let ((x 3)) ...) in the theoretically pure Lisp semantically it's just a leaf in the tree but as part of an if-block in a real language it gets treated as procedure call even if it makes no sense.

⬐ mroll

Lisp as the idea has no syntax. Racket is a dialect of that idea, and the authors have decided to add syntax.

⬐ Avshalom

Lisp "as the idea" is not a programming language. Racket is a language, Common Lisp* is a language. No one writes code in the IDEA of lisp, indeed no one can because no computer yet can pull instructions out of what ever aether contains platonic ideals.

* using SBCL: (defun foo (x y) (...)) instead of Racket (define (foo x y) (...)) is again an example of syntax.

⬐ brianclements

Technically, this might be syntax, but as someone who is learning Racket (and programming) in the beginning stages, it's so much less syntax to remember then even python (underscore, double underscore, with, decorators, list comprehensions etc all have their own syntax nuances), the only syntax I see in Racket is the s-expression, the quote, and the dots. Everything else is just the flow of programming logic. It really does free my mind to work on the problem domain itself! Been enjoying SICP so much.

⬐ Avshalom

Racket doesn't get quite as bad (well it does but it tries to keep things looking like S-exps) but consider CL's Loop macro http://www.unixuser.org/~euske/doc/cl/loop.html loop is (from what I understand) idiomatic too. Yes it's a macro (so is (defun ...) though) but it's syntax a CLer needs to know in order to deal with CL in the wild. Format is famously even worse.

⬐ baldfat

Even Racket says loops are unRacket like and so does R. I avoid loops at all cost and use list whenever possible.

⬐ aidenn0

Loop is idiomatic, but whether or not it is syntax is arguable, as it is implemented entirely as a macro.

⬐ adwf

A lot of people abandon loop for precisely that reason (it's un-lispy) and use Iterate.

https://common-lisp.net/project/iterate/

Even the ITA/Google style guide says to avoid loop if possible:

https://google.github.io/styleguide/lispguide.xml#Iteration

⬐ lispm

But the ITERATE macro is syntax, too.

Almost every macro in Lisp provides syntax.

⬐ aidenn0

An equivalent to iterate/loop where each compound form need be replaced by an anonymous function and each binding is replaced by a dictionary entry could be implemented completely as a function. Is this also new syntax?

If not, how is the macro different other than implicitly changing the evaluation?

for a more simple example, why is the idiom CALL-WITH-FOO (implemented as a function) not syntax while WITH-FOO (implemented as a macro) is? What precisely is syntax is somewhat nebulous (if I use a regex library in C, have I added syntax to the language? Regexes certainly are syntax, despite being wrapped in a C string).

⬐ adwf

Yes, but I thought his point was more that whilst Lisp has a very easy, simple and regular syntax, ie. (func arg1 arg2 (func arg3)) and so on, it's less simple and regular when you get to the loop macro (loop arg keyword arg keyword...). Hence why I mentioned the Iterate library as something a lot of people use to get back to the regular syntactical appearance.

It's one of the strengths of Lisp imo; that you don't need to think much about how the parser is going to interpret your code (ie. missing semi-colons, whitespace, use curly brace here, square bracket there, etc.), just stick to (func arg1 arg2) and all you're left with is your own logic errors.

⬐ breuleux

It's debatable whether "simple and regular syntax" is a strength or a weakness. Lisp/Scheme might be too regular for their own good. Consider the following statements in Scheme, for instance:

    (lambda x (+ x x))
    (cond (> x 2) (+ x x))
    (if (> x 2)
        (do-this when-true)
        (also-do-this when-true))

They are syntactically correct (technically), but they are probably not what you meant. So you still have to pause and ask yourself how cond works... except the parser will not help you.

That is to say, a problem with s-expressions is that they are so regular that everything looks the same, and when everything looks the same, it can become an obstacle to learning. Mainstream languages are not very regular, but they are more mnemonic. I think Lisp works best for a very particular kind of mind, but that for most programmers its strengths are basically weaknesses.

⬐ aidenn0

SBCL will warn or error at compile time on the first two, and there are similar issues to the third one in many languages; it's a semantics issue more than a syntactic issue.

⬐ mkramlich

best constructive takedown of Lisp I've read, thank you. I've had a love/hate relationship with Lisp for years. Yes, its strength is also its weakness. Its so much harder on the programmer at read/review time. Even though at write time its power is unmatched, almost intoxicating.

⬐ lispm

    (if (> x 2)
        (do-this when-true)
      (also-do-this when-true))

In some other language:

    x > 2 ? doThis(whenTrue) : alsoDoThisWhenTrue();

Same problem. Maybe even slightly worse. For example it could be:

    x > 2 ? doThis(whenTrue) ; alsoDoThisWhenTrue();

To spot the difference between a colon and the semicolon: tough.

⬐ lispm

    (func arg1 arg2 (func arg3))

That's the syntax of function calls.

But Lisp has a few special forms and zillions of macros. Most of them are syntax.

Lisp has IF. What is the syntax of IF?

    IF form then-form else-form+

Lisp has COND. What is the syntax of COND?

    cond {clause}*
    clause::= (test-form form*) 
 

List has DEFUN. What is the syntax of DEFUN?

    defun function-name lambda-list [[declaration* | documentation]] form*

Now what is the syntax for LAMBDA-LIST?

    lambda-list::= (var* 
                    [&optional {var | (var [init-form [supplied-p-parameter]])}*] 
                    [&rest var] 
                    [&key {var | ({var | (keyword-name var)} [init-form [supplied-p-parameter]])}* [&allow-other-keys]] 
                    [&aux {var | (var [init-form])}*]) 

and so on...

> It's one of the strengths of Lisp imo; that you don't need to think much about how the parser is going to interpret your code (ie. missing semi-colons, whitespace, use curly brace here, square bracket there, etc.), just stick to (func arg1 arg2) and all you're left with is your own logic errors.

What you describe is just the data syntax for s-expressions. Not the syntax of the programming language Lisp.

⬐ adwf

> What you describe is just the data syntax for s-expressions. Not the syntax of the programming language Lisp.

Exactly. The data syntax if what most people worry about. The names of the verbs (funcs/methods/etc.) may change from language to language, but the data syntax is what trips people up. I think Lisp has one of the simplest and clearest. There are very few cases of "oh you can't write that there, only nouns are allowed in that position".

I agree with your point, but I think we're arguing slightly different points here ;)

⬐ aidenn0

with regards to Naugty Dog, The Jak & Daxter games were written entirely in GOAL, an in-house scheme implementation that compiled down to assembly.

⬐ chadzawistowski

GOAL and GOOL were both used by that studio: "Game Oriented Action Lisp" and "Game Oriented Object Lisp".

They switched to C++ because it was too hard to find good lisp devs.

⬐ lispm

They switched to C++ because they were bought by Sony and integrated into their landscape. They thought that sharing C++ code would be useful. As it turned out, they put Scheme back into their production pipeline.

⬐ chadzawistowski

Oh, good to know!

⬐ samth

That's not quite right. These days Naughty Dog uses a DSL called DC built in Racket to write all the "data" in the game (everything from cut scenes to character attributes). Running DC produces data files shipped on the DVD of the game, and used by the big C++ engine that's running on the PlayStation.

Dan Leibgold gave a talk about their system at RacketCon a few years ago: https://www.youtube.com/watch?v=oSmqbnhHp1c

⬐ viperscape

might like this: http://practical-scheme.net/docs/gdc2002.html it's about using scheme in production house for final fantasy movie

⬐ drmeister

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 :-).

⬐ noselfrighteous

Beautiful ideas! Do you have a way to control the final stereo-isomer that comes out of the synthesis? I'm thinking of the "256 stereo-isomer" molecule that you mentioned. Or is it a case of brute force and select afterwards?

⬐ drmeister

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.

⬐ noselfrighteous

Awesome! Thanks for that.

⬐ girvo

This is why I love HN! Amazing video, and that project sounds fascinating. Where can I go to keep an eye on it?

⬐ JabavuAdams

Very, very interesting stuff, thanks.

Every couple of years I spend a couple of months with Lisp and then decide that I actually want to use Lisp to generate code in other languages. Recently I've been on a modern C++ kick, and have been really amazed at how Clang and LLVM are being used to do code indexing.

So, C++ + CL + LLVM + scientific computing ... wow!

⬐ agumonkey

I too enjoyed the spiroligomer talk, not all of it, but the deep down approach felt good. If I had more biochem knowledge I'd assemble a team.

⬐ cperkins

Amazing work.

⬐ surprisetalk

Your "molecular metaprogramming" presentation is, without exaggeration, one of the most beautiful lectures I've ever encountered.

You've instantly inspired me to change career paths. This weekend I'm going to set up a home chemistry lab so that I may one day contribute to the amazing body of work you've started.

Does anybody on HN have some recommendations for learning intermediate chemistry? or setting up home labs? Just for context, I have math/CS degrees and have already taken introduction courses to physics, chemistry, and biology.

⬐ drmeister

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

⬐ surprisetalk

Will do, chief! Thanks again for the inspiration.

⬐ chm

Synthetic chemistry is not really something you want to learn on your own in your basement. You can do it, but you're much much much better off just following real laboratory courses in college. They'll teach you proper lab safety in a safe environment, and the range of reactions you'll be able to perform will be much wider than what you could do in your basement. Most undergrads will perform a Grignard reaction, but I would not advise you do that in your basement.

If you're interested in theory, then it's a whole other thing.

(I'm a chemist.)

⬐ surprisetalk

I obviously have no idea what can/can't be done at home yet :)

But UCLA is right down the street; I'll see what they have to offer.

Thanks for the tip!

⬐ chm

Anything could be done at home, but at what cost (safety + economic)? If you get some lab experience by following courses, you might even land an internship in a synthesis lab if you're lucky :)

If you're asking yourself what kinds of problems is a Lisp good for you should probably watch this: https://www.youtube.com/watch?v=8X69_42Mj-g (A computational chemist built himself his own Common Lisp implementation because no other language available was powerful enough for his needs...)

It basically boils to: if you're solving a truly new and interesting problems for which the current libraries and ecosystems don't matter that much to you anyhow (because what you do is too bleeding-edge / ahead of everyone else, so you'll write your own better stuff anyhow), than you might want to choose a Lisp.

And if your problem is so bleeding-edge and exotic that you also need to build your own programming-language for it, than you might just as well build yourself a Lisp (like the guy in the video did) and add your needed features to it, because this would be easier than any other approaches and allow you to spend more time on your problem and not on the language...

EDIT+: another example is DWave using SBCL: http://www.dwavesys.com/careers/senior-software-developer - if quantum (or analog... anyway...) computing is not "truly new and cutting edge", than I don't know what is

Unrelated to VR but still: if anyone here hasn't yet watched drmeister's talk about Clasp and his "molecular metaprogramming" project, please do. Absolutely fascinating stuff.

https://www.youtube.com/watch?v=8X69_42Mj-g

Also recently discussed on HN: https://news.ycombinator.com/item?id=9721801

Same here, I never understood Java interfaces, abstract classes, and a ton of other "features" but picking up Clojure was a breeze. I don't understand why complicating thing that supposed to be simple helps you by any mean. On the top of that, I have seen several cases when Java programmers tipped over in their own code because of the complexity that they thought they understand, except there was a particular case when it was doing something else then expected.

Reasoning about Clojure (LISP) code is always easy because if you follow best practices you have small functions with very little context to understand.

On the top of these, I see the ratio of LOC 50:1 (worst case even higher) for Java : Clojure code that does the same thing. Usually people get triggered and say why does it matter, but in reality less code is better for everybody. Easier to understand, less chance of errors, etc. Correctness was long time lost for majority of Java developers, just put out a survey and you can see it for yourself.

It is also pretty common practice not to handle exceptions well and just let a DNS not found error explode as an IOexception and good luck tracking down what caused it (literary happened to me).

I understand that the average Java dev does not see any value in LISP (Clojure) but it silly to expect that the average of any group is going to lead the scientific advancement of any field including computer science.

One tendency that you can see if you are walking around with open eyes that the people who spent significant time in developing procedural code in an imperative language understand the importance of functional language features and the power of LISP. One can pretend it does not matter see you in 5-10 years and see how much this changes.

https://twitter.com/id_aa_carmack/status/577877590070919168

https://www.youtube.com/watch?v=8X69_42Mj-g

https://www.youtube.com/watch?v=P76Vbsk_3J0

I can recommend to watch Schafmeister's Clasp talk[1] at Google. Its quite impressive.

[1] https://www.youtube.com/watch?v=8X69_42Mj-g

⬐ hga

And here's the HN discussion of that video, https://news.ycombinator.com/item?id=9721801 with a fair number of comments from Schafmeister.

So no one will mention the Clasp (Lisp on LLVM developer)? He built a language to build better, albeit not visualize, better molecules.

If you are on this article, you probably will love to watch this guy. I am computer nerd and this guy makes me want to go back and study chemistry.

https://www.youtube.com/watch?v=8X69_42Mj-g

⬐ dalke

I just watched it. I heard pretty much the same aspirations since the 1980s. See https://www.fourmilab.ch/autofile/www/section2_82_2.html for when AutoDesk looked at entering this field.

At 15:56 the speaker says "Synthetic chemists normally they design things with plastic model sets."

This just isn't true, and hasn't been for a very long time. At 17:54 he even says there's GUI-based software now to design molecules. That's what most chemists use.

My experience is that it doesn't take 20 minutes to draw a molecule using the current generation of tools. In fact, you can try it now - go to http://web.chemdoodle.com/demos/sketcher or https://pubchem.ncbi.nlm.nih.gov/edit2/index.html or http://scitouch.net/ketcher-demo/ketcher.html and draw one yourself. (This is for small molecule chemistry. For large molecule chemistry, there are other tools and other issues to worry about.)

In minute 23 he talks about computing the second derivative of the force fields, and how complex it is. Thing is, my co-worker did that manually when he wrote the original NAMD implementation. (NAMD is a molecular dynamic program.) So it's not something that's all that hard to compute. It's just tedious. (And his code is 10% slower than the hand-written code, so he knows that people do this sort of thing manually.)

While it's useful to have automatic code generators if you want to add new force fields often, we just don't do it all that often, because parameterizing the force field is the hard problem, not computing the second derivative.

At 31:25 he says that SciPy is only really possible because of Boost.Python. This isn't true. I just downloaded scipy-0.16.0b2 and verified that it does not use Boost.Python. ("ag -i BOOST_PYTHON_MODULE" finds no matches.)

At 49:30 he talks about a technique that sounds like pharmacophore models, which have been around since at least the 1990s. There are tools that will build molecules to fit pharmacophore models.

What I didn't see was anything about dealing with waters, and counter-ions, toxicity, or AMDE (absorption, distribution, metabolism, and excretion) issues.

I didn't hear anything which required multiple years of tool building ("yak shaving") to get to what he wanted. Every technique he mentioned is something that people have been doing already, in C/C++/Python.

⬐ dekhn

scipy uses cython (previously swig). It is correct that its performance depends on C and Fortran code (but you knew that).

Are you sure your coworker found the derivates for the force field? They were already published when VMD was written.

I think you're trying to quibble with some of his minor points. Schaf's quite aware of water and counterions (we used to work in the same room at UCSF when he was writing AMBER's LEaP tool that adds water and counterions to molecules).

⬐ dalke

The speaker said that SciPy uses Boost Python. My comment here was that it does not. I said nothing about SciPy's performance.

I didn't say that my co-worker was the first to compute the derivatives. I said that it wasn't that complex of a task. Mark Nelson worked out by hand the second derivatives for the force fields and implemented them in NAMD (note: NAMD is not VMD). He also checked it against a couple of other implementations, including the one in XPLOR. I think he also checked against PMD and YAMD, and I believe he noticed that the PMD implementation was copied from XPLOR.

My point is that it's not hard to find these manually. In any case there's little need to figure it out from scratch since nowadays the force-fields are available in code with a permissive license, and the math available in publications like https://books.google.com/books?id=GYTuCAAAQBAJ&pg=PA168&lpg=... .

It can make sense to develop new tooling to generate code automatically. The result might be faster than manual code, but as we heard, the auto-generated code is currently 10% slower than manual code. Or it might make sense when developing many different types of force fields, like what Konrad Hinsen does in ScientificPython (see http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.... ). However, I heard nothing about developing new force fields, and in any case, parameterization is the limiting factor, not computing the second derivatives.

My 'quibbles' are two-fold. The major one is that I heard or read 30+ years of history on how molecular modeling can be used to design solutions to real-world problems. The 1980s thought that it would be a CAD problem (which it wasn't). The late 1990s thought it was a simple matter of nanotech, with all sorts of designs for nifty diamond-based structures with no real-world hope. We've had special purpose programming languages for molecular modeling, custom computers with specialized networks, custom designed chips, GPU-based implementations, and more.

There's no evidence that the limitation is in the tooling, which is a major part of the speaker's thesis.

The minor one is that if someone makes minor mistakes that end up placing the speaker in a brighter light, and says them with confidence, then I believe it's reasonable to discount more the major points said with confidence which have less evidence, and which also place the speaker in a brighter light. What you see as quibbles for minor points I see as a way to judge how strongly the speaker is willing to trust personal beliefs over evidence and proof. (Yes, those personal beliefs might be right, but that's my previous point.)

⬐ dang

Discussed recently: https://news.ycombinator.com/item?id=9721801

" I rarely clip aneurysms now. All the skills that I slowly and painfully acquired to become an aneurysm surgeon have been rendered obsolete by technological change.

Although neurosurgery is no longer what it once was, the neurosurgeon’s loss has been the patient’s gain. "

so nice to read this

many of the entrenched remain so through superstition at the loss of progress,

but to read someone speak highly of a practice that rendered a section of their skill set obsolete is heartening

i have family who work in trauma and they condescendingly balk at my excitement over new medical technology:

https://www.youtube.com/watch?v=aA-H0L3eEo0#t=3m14s

https://www.youtube.com/watch?v=8X69_42Mj-g#t=14m17s

personally, i look forward to bones:

https://www.youtube.com/watch?v=02Or-Hx3yqc

⬐ drmeister

Hi, I'm Christian Schafmeister. Thank you so much for the nice comments! I just want to point out that this work was all done with your tax dollars. This work was made possible by support from the National Institute of Health (NIGMS), the National Science Foundation (NSF) and the Defense Threat Reduction Agency (DOD:DTRA).

⬐ PuercoPop

The speaker also has some more info in his blogpost about the talk: https://drmeister.wordpress.com/2015/06/15/i-gave-a-talk-on-...

⬐ bratsche

For anyone looking for the project: https://github.com/drmeister/clasp

⬐ dekhn

I recently used the author's software (we went to grad school together); software he wrote ~20 years ago that is still useful.

⬐ mark_l_watson

Great talk. Both parts were interesting: tool building and the application of designing molecules.

⬐ graphene

Super interesting.

If you read the Feynman speech that he references at the beginning, he actually mentions that as you scale machines down, things like mechanical rigidity will degrade and you will need to change your design rules accordingly. I always assumed that when you reach the molecular level, thermal motion and the constant bombardment by water molecules would mean that the only viable option is to use proteins, just like nature does, so it's very interesting to see that this guy is aiming to use more rigid structures at the molecular level. I guess this is a way to reduce the complexity (degrees of freedom) compared to designing protein tertiary structure. I wonder if this is too constraining though, he admits he has yet to figure out how to build mechanical machines using this approach, and intuitively I'd expect that to be very difficult with this degree of rigidity. You might need the additional flexibility of peptide chains to do many of the interesting things that are possible.

He does point out the advantage of durability, but this raises the obvious issue that one of the questioners alluded to, namely toxicity/pollution risk. I'd think degredation by biological or other means would be a feature, not a bug, since as he points out, even conventional plastics are a huge pollution problem.

Fascinating stuff nonetheless.

⬐ drmeister

Christian Schafmeister here - thanks! You make some very good points that I can address: (1) Things made with "Molecular Lego" still move, but they keep their shape just enough to organize atoms/groups to do things like speed up reactions and bind other molecules. We've explored dynamics in several of our papers. They aren't too constrained - they are constrained "just enough"; and we can build in flexibility and hinges where ever we want. (2) We don't know how to make mechanical molecular machines with them yet; we need to start making a lot of them and explore their properties to figure that out. The first folks who smelted iron didn't know how to build motors with it - it took a lot of people playing around with iron for a long time to figure that out. I think we can get there in less time but it will take work. (3) Re: toxicity/pollution - this is the first non-natural molecular technology that contains the solution to any problems that it generates. We need to learn how to make catalysts well and then we can build catalysts that break these molecules down. Conceivably, we could build materials that contain the catalysts that break them down and are activated by an external signal. Or we make materials out of bigger bricks (built from Molecular Lego) and we fish them out of the environment, tear them apart from each other, check them for defects and build new materials with the good ones and recycle the broken ones. We can also build catalysts that break down every other indestructable material that we've been dumping into the environment for 100 years. Regarding toxicity, these molecules are made out of carbon, nitrogen, oxygen and hydrogen - the same atoms you are made out of. They are inherently non-toxic (there are qualifiers on this).

⬐ graphene

Hi Christian, great to have you replying directly like this; I hope my criticism came across as constructive, since I'm super excited about and impressed with this work, as someone also chasing the dream of molecular nanotechnology.

Re: rigidity; I'm curious (apologies for not having read your papers) how you define "just enough" flexibility, and how your design tools take freely moving components into account. Would you agree with my intuitive feeling that there's a tradeoff between designability and functionality, and that your spiroligomer work sits between rationally designed protein structures (very hard problem) and Drexlerian molecular-scale gears and ratchets (similar, determinsitic design rules as in macroscopic systems)? Or, do you feel that anything protein "machines" can do, spiroligomer machines can do too?

I recently started a startup that has molecular nanotechnology as the end goal, and my thinking has been that the flexibility of proteins is an essential element in achieving the capability to design and manufacture with atomic precision, and that the concomitant complexity of the large numbers of degrees of freedom can be tamed with a data-driven approach leveraging machine learning algorithms. I'd love to hear if you have any thoughts on this, and how it relates to the spiroligomer approach.

⬐ istvan__

This was the best tech talk I have seen for a long time. Thanks for sharing it.

⬐ BenTheElder

This is one of the most fascinating talks I've seen in a while. Thanks lispm.

⬐ sunkencity

This is the best presentation I have seen in years.

Macros are truly the way up if we are to escape the gravity well of calculus for bio chemistry. How else to gain delta v?

⬐ cracauer

Thanks again, Christian.

⬐ ris

How does one person manage to be so productive?

⬐ mahmud

Focus, dedication, specialization, experience, and superior choice of technology.

⬐ kazinator

Outsource to libs. Look at the list of dependencies given on the github project's page:

https://github.com/drmeister/clasp

Do any of this from scratch and your productivity will plummet:

LLVM for compiling; Boehm for garbage collection; GMP for bignums; Readline for interactivity; C++11 for ... cough ... oh will you look at the time---lesson is over for today, grasshoppers!

⬐ ris

Cool, but if that makes things so straightforward, where's your performant Common Lisp implementation? (Where's mine?)

I did watch the lecture, I do know how many libraries he used...

⬐ aidenn0

Your point stands, but one nit-pick:

The Boehm GC is only so it doesn't run out of RAM while bootstrapping, it uses the Ravenbrook MPS precise garbage collector once it's bootstrapped.

Also note that Christian reported that Ravenbrook was very responsive when he discovered a few deficiencies in the MPS library.

Also he used clang to walk his C++ code to automatically generate information in order to enable precise GC of C++ objects.

⬐ drmeister

Christian Schafmeister here with a shoutout to the Ravenbrook people who are awesome and very helpful. They have excellent documentation: https://www.ravenbrook.com/project/mps. I don't own stock or anything but now that I'm using MPS I'd like more people to know about it. If you are interested in developing a more generalized version of the static analyzer that I wrote to automate GC for C/C++/Objective-C - get in touch with me.

⬐ wtbob

Fascinating, fascinating talk.

⬐ graovic

brilliant

⬐ aidenn0

Christian Schafmeister and Robert Strandh (creator of work-in-progress SICL, which Christian now uses in Clasp), both took on the multi-year project of creating a new CL implementation; Robert completely from scratch, Christian leveraging the high-level parts of an existing implementation, while completely rewriting the low-level ones.

I have a lot of respect for these guys; I had a few new ideas for ways of implementing Common Lisp, but decided not to when I realized with the amount of free-time I have, it would be about a decade of work.

I've spoken to Robert online, and he mentioned that a lot of people told him a from-scratch implementation was doomed to fail. The only reason those people were wrong was in that they underestimated his tenacity.