
Lisp-Flavored Programming Languages - pcr910303
https://github.com/dundalek/awesome-lisp-languages
======
cracauer
A quick look at what Quicklisp has to offer for libraries should quickly
convince people that fooling around with anything but Common Lisp would be
very energy-consuming.

[http://blog.quicklisp.org/](http://blog.quicklisp.org/)

~~~
iLemming
A quick look at what the job market has to offer (for those who interested in
Lisp) should quickly convince people that learning anything but Clojure would
be not only energy-consuming but also impractical.

~~~
kazinator
I know this isn't Reddit, but "nick checks out".

Knowledge and skill useful for finding a job is not all the knowledge that is
good.

Clojure was developed by someone called Rich Hickey. Not only were there no
Clojure jobs when he started hacking, there was no Clojure. That's a textbook
example of an energy-consuming and impractical waste of time.

For almost every piece of technology listed in a job ad that you think is
worth knowing, someone had to put in a whole lot of time and energy, not
knowing if it will pan out at all, and often that time and energy were
uncompensated by anything other than the existence of the thing in the end.

~~~
iLemming
You are right. I was just trying to semi-sarcastically mimic the comment, to
address "anything but Common Lisp would be very energy-consuming"

------
c3534l
I'm amused by the fact that when you criticize LISP's syntax, defenders always
say the syntax doesn't matter and real Lisp programmers don't even see the
parenthesis. But then you look at these implementations of Lisp-like variants
of existing programming languages and the thing the developers are most
enamored with is the repetitive, parenthesis-laden syntax of Lisp, while
keeping the majority of the non-Lisp semantics in tact (adding just a few
functional conveniences like first class functions).

I'm not even criticizing, most of these are hobby projects and you can code
how you like. I just think it's funny how hard Lisp clings onto the
parenthesis thing while claiming the parenthesis thing doesn't matter.

~~~
manifestsilence
I think the appeal of the syntax for those who get used to it is the
regularity, like you said.

The advantage of the regularity isn't its human readability, but its ability
to macro, no?

What I'd like to see is better tools for reading and editing such a regular
syntax. Probably I should just learn emacs, but I'm thinking someone could
make a more intuitive structured editor for LISP syntax. No need to mush
around blobs of text when everything is nested lists.

~~~
braythwayt
> The advantage of the regularity isn't its human readability, but its ability
> to macro, no?

This.

You can write macros for less regular languages, but there's always additional
friction involved. At some point, it comes down to whether you think LISP is a
"programmable programming language."

If you do, macros are a core part of the paradigm, and s-exprs make macros
easy to work with.

~~~
kazinator
I already really liked Lisp's syntax before I learned about the macros.

No ambiguity; no brain cycles required to work out what element is a child or
sibling of what element. Great editing ergonomics.

------
manifestsilence
The python ones, Hy and Pixie, look pretty cool. Two very different takes on
what it means to "use python" for a lisp.

Pixie uses the RPython toolchain and is totally its own language, with its own
VM and JIT.

Hy appears to be python with lisp syntax.

Both sound fascinating.

~~~
fernly
Yeah, I thought so too. I've been teaching myself Lisp as a side project,
working through online tutorials and, more productively, Paul Graham's "ANSI
Common Lisp", using SBCL and CLISP in a terminal window. OK, cool, try another
Lisp, leverage my Python knowledge.

Took a look at the github of Pixie: "pre-alpha" and no docs whatever. Not for
the student.

Hy is cleanly packaged, installed with pip3, has complete(ish) docs[1], great.
So I installed it and started it, it puts up a REPL prompt, and I paste in one
of the functions I've worked out:

    
    
        (defun hello ()
          (write-line "this is the prompt:")
          (let ( (name (read-line)) )
             (format t "Hello, ~A.~%" name)
             )
         )
    

Error message: "empty expressions are not allowed at top level"

Sorry? Exactly that usage, an empty expression when a function takes no
argument, is used on (I just checked) page 20 of Graham. But ok, I try it
without, "(defun hello" etc.

Error message: "NameError: name 'defun' is not defined"

You what? defun is introduced on page 14, and defined in the "Language
Reference" Appendix of Graham. OK, wait, what does Hy use, if not defun?
Search their tutorial chapter: "Define named functions with defn".

OK, this is a deal-breaker for somebody trying to learn (ahem) COMMON Lisp.
Why would you do that, just arbitrarily change the probably third or fourth
name a student learns after car, cdr and setv? And more importantly, if you
have taken it on yourself to dick around with (ahem) _Common_ Lisp at this
basic point, what else have you changed that will break the examples in my
textbook or online tutorial?

    
    
        pip3 uninstall hy
    

[1]
[https://docs.hylang.org/en/master/index.html](https://docs.hylang.org/en/master/index.html)

~~~
crematoria
Hy isn't a Common Lisp implementation, and it isn't trying to be one, so I
think this criticism is a little misplaced.

------
pjmlp
What about Dylan and other Lisps with Algol based syntax (M-expressions)?

------
rusini
I have designed a programming language that borrows an important part of its
architecture from Lisp(s) (maybe mostly Scheme, but also Kernel:
[http://klisp.org](http://klisp.org)). However, I have always opposed to the
concrete syntax of S-expressions (being mostly unable to be productive with
it).

My arguments are not on the familiarity side (with the infix notation), but on
the psychological one:

1\. S-expressions are not the most simple, natural, or uniform surface form
(as they claim); they do have syntactic sugar (quote, even lists themselves!,
etc.), so why not to add some more sugar (but sufficiently abstract of
course)?

2\. Humans' brain has limited "stack" space (especially when closing
parentheses); infix forms may "cascade" and do not consume the stack (equally
machine on human, due to possibility of "tail recursion")

3\. Lack of diverse "visual clues" for humans (note how most natural languages
have 40-60 phonemes, and none less than 15)

4\. S-expressions and homoiconicity are related but orthogonal features (so
the homoiconicity argument is often not valid)

Having that said, when I finally managed to write a working 50+-lines program
in Scheme, with "proper" indentation, I was just proud of it, and I said,
"Wow, it looks cool!". But I am still on the side of the above rational
arguments! My point is that as my experiment demonstrates, it is probably too
easy to get on an emotional side of computer-human interaction once you
accomplished something a bit challenging (like speaking in classic
S-expressions)?

~~~
dreamcompiler
For me S-expressions feel like the most natural way to program because they
_compose_ naturally with zero ambiguity. Infix notation might be slightly
clearer for simple expressions but it doesn't compose: As soon as you try to
compose infix notation you have to add parens, depend on unstated precedence
rules, or both. Lisp's philosophy is to just use parens everywhere, make
everything composable, and have no precedence rules.

That said, I would hate to write Lisp code with Notepad. Fortunately nobody
does this. In conjunction with a paren-matching, auto-indenting programmer's
editor (which is roughly all of them these days), S-expressions are easy. A
good editor is vital not just for writing Lisp programs but also for reading
them.

I will not claim parentheses are mandatory. I find Haskell just as simple,
unambiguous, and composable _without_ (many) parens but that's only because it
has automatic currying, and that takes a bit of practice to wrap one's head
around.

~~~
krapp
IMHO, if you need an editor with paren-matching and auto-indenting (and maybe
even syntax highlighting) just to make working with your language tolerable,
that's a possible design flaw in the language.

I know it's heresy in a Lisp thread to claim that it's possible for a language
to have too little syntax, but I can write Javascript, C and C++ just fine in
Notepad or Sublime Text if I want.

------
swlkr
Toccata seems very interesting! I like the clojure-like syntax and the gradual
typing aspect of it.

------
aidenn0
C/C++ should really be separated. There are very few lisps with good C++
interop, and so they are an interesting category on their own.

------
haileris
I already see a trend building behind functional programming and LISP. Oh
brother, right after I started reading SICP.

~~~
zabzonk
LISP is a functional programming language.

~~~
braythwayt
For some definition of "functional" that was appropriate when LISP was
discovered, and of course any claim about LISP tends to be met with, "which
one?"

LISP really deserves to be "grandfathered in" as the original functional
programming language, but if it were discovered today, we'd likely call it a
multi-paradigm language that supports functions as first-class entities.

And as a "programmable programming language," we can use LISP to implement
many other paradigms, including what we now consider "functional" programming.

~~~
erik_seaberg
Lisp's development was skewed by the high cost of memory. Early on, scope was
dynamic, lists were mutable and often spliced in-place, linear searches were
typical (hash tables were almost unheard of), and there were very few first-
class types because a pointer only had so many tag bits available.

~~~
lispm
Things evolved in the 70s. Hash tables were added over time, with some
alternatives were using some tree like search. Usually the first thing was to
make the symbol table not a list -> making the symbol table a hash table was
reportedly done in 1971 by Jon L White. Tag bits then also were not a part of
the pointers (with only very few exceptions), but a part of the data object
(numbers, strings, arrays, symbols, ..).

------
threatofrain
> julia --lisp

------
rwmurrayVT
AutoLISP for AutoCAD products :)

------
zitterbewegung
Cool list I made a pull request .

------
byron_fast
Where "flavor" means "subset of". But good on them.

