
A programmable programming language (2018) [pdf] - azhenley
https://cs.brown.edu/~sk/Publications/Papers/Published/fffkbmt-programmable-prog-lang/paper.pdf
======
yters
I used Racket for a couple projects, but meta programming hasn't turned out to
be super useful. When I did use meta programming, I got pretty confused when
returning to my code after leaving it for awhile.

I know PG claims meta programming was the secret to ViaWeb's success, but I'm
not sure how exactly that was the case, and even if true whether that is still
relevant today.

I have found Python to hit the sweet spot much better in terms of rapid
prototyping, and providing a runway to making the prototype more rigorous and
maintainable.

~~~
wry_discontent
I've found Python to inhibit me a lot from moving quickly past the very
initial stages.

I'm fond of Clojure for that, but it tends to de-emphasize macros as a good
way of doing things. Most things are just regular fns.

~~~
yters
Do you find it is easy to come back to your Clojure code and understand what
is going on?

~~~
wry_discontent
The issue with that, I've found, is that you do actually have to read the
code. I do JS professionally, and you can definitely tell some of what's going
on just from the shape of the code, but I've found Clojure doesn't do that.
That said, after a couple minutes looking at something, it's usually clear.

------
agalunar
One of my best friends did his Masters work designing a programming language
that can be modified on the fly; I'd highly recommend the paper:

[https://dspace.mit.edu/bitstream/handle/1721.1/113144/101799...](https://dspace.mit.edu/bitstream/handle/1721.1/113144/1017990524-MIT.pdf)

~~~
nielsbot
The API for building grammars seems straightforward to use.

------
Koshkin
The usefulness of this depends on how you want to solve the problem at hand.
One approach to programming is to create a DSL for the problem domain and then
solve the problem using that DSL. Languages (such as Common Lisp) that include
advanced means of metaprogramming are perfect from this perspective.
Otherwise, one has to create an API to approximate the DSL - which could be
rather hairy, so one may try to manage the complexity of this particular
representation by either using a preprocessor or even, as an extreme measure,
by writing a separate language processor (compiler or interpreter) for the
DSL.

------
jmull
I feel like general purpose programming languages very widely already let you
express DSLs, with semantics, names, structure, etc. appropriate to the
domain.

What they do restrict, to various degrees, is the syntax.

So what we're talking about here is custom/customizable syntax to go with your
DSL. That can be nice, but it comes at a high cost -- e.g., developers will
have to understand the syntax, it will need to be maintained and extended as
requirements grow or change. Of course it's worth it in some cases, and tools
to help do it are great when it is.

But I just don't see that there's a general problem that we don't have enough
custom language syntax to deal with.

------
sam_lowry_
LISP?

~~~
DannyB2
Racket is a Lisp. One that facilitates building other languages.

~~~
schwurb
You could characterize Racket as THE lisp when it comes to well-behaved and
well-researched metaprograming.

------
jimbob45
I feel like there's something so comforting about having a concrete language
you can rest your back up against though. Once you start throwing in #DEFINEs
and typedefs, I start to question whether I can trust anything I'm seeing on
the screen to not be hiding crucial secrets from me.

Maybe it's just me.

~~~
bob1029
Having constraints imposed upon me by my tools is the only way anything ever
gets done. If you put me in front of a blank canvas, and then tell me I can
alter the nature of the canvas itself to whatever extent I desire (I.e. in
hopes of making using it easier), I'll never get to the point where I'm
actually painting on it. Or, perhaps I do manage to produce an end result, but
no one else can understand what it means.

Even with a mountain of constraints, there is still usually far too much
subjectivity in software development. This language seems to me to be moving
the needle in a very wrong direction. Having a stable basis that is
standardized and everyone can (mostly) agree upon is the foundation for
growing a technical team or community. Being able to type "LINQ GroupBy Select
examples" into your preferred search engine of choice and receive actionable
advice is clearly an advantage for productivity. Sure, in a purely academic
sense there is almost certainly a more ideal solution. But, if you are seeking
to actually get things done, constraints are the name of the game.

~~~
discreteevent
I remember some interview with Ulrich Schnauss (electronic artist) where he
went back to plain synthesisers for the same reason. Too many things to tweak
meant he wasn't able to focus on the piece.

------
bitwize
Meh, in practice most people will use JavaScript and Babel.

~~~
iLemming
Yeah, and that is a problem with the majority of programmers. They readily
choose a seemingly easy path instead of something that leads to simplicity.
Lisp is a fantastic idea that (even after over six decades) is still very much
relevant today. Once you get used to program with a true REPL, every other
(non-lispy) language starts feeling like frustratingly over-engineered,
bloated, and unnecessarily complicated. Waiting for compilation cycles and
annoying syntax quirks would slowly turn what once was a joy into a "just a
job."

It feels incredibly liberating and joyous to be able to grab any part of your
program and without any preceding ceremony just to "eval" it and see what
happens.

And let me prematurely answer the comments that probably will be thrown here.
No, other languages (most of them) don't have real REPLs. What they have, at
best can be categorized as "interactive shells".

Younger folks who are learning, juniors, seasoned developers who for one or
another reason, never had any exposure to a Lisp, please do yourselves a
favor. Try Racket, Clojure, Clojurescript, Fennel, Chez. Give Lisp an honest,
heartfelt attempt to learn it.

Follow the work of people like Harold Abelson and Gerald Sussman, Matthias
Felleisen, Dan Friedman, Rich Hickey, Guy Steele, Richard Gabriel, Alan Kay,
and many others.

Once you attain familiarity with a Lisp to the sufficient level, perhaps then
you will get it. You will see that it is indeed a lifetime investment that
would allow you to reap the rewards for the entirety of your career.

I am telling you all this, not from the top of some ivory tower. I never went
to CS academia. Like most of you, I am altogether a self-taught programmer. I
am honestly begging you not to make the same mistake that I did. For many
years I have ignored Lisp due to my self-righteous ignorance. Unknowingly, I
delayed my true growth, and I sincerely regret it.

~~~
lispm
> No, other languages (most of them) don't have real REPLs. What they have, at
> best can be categorized as "interactive shells".

> Try Racket, Clojure, Clojurescript, Fennel, Chez. Give Lisp an honest,
> heartfelt attempt to learn it.

Compared to actual Lisps, some of these have mostly interactive shells.

[https://www.youtube.com/watch?v=o4-YnLpLgtk](https://www.youtube.com/watch?v=o4-YnLpLgtk)

~~~
iLemming
We can debate for a long time if other Lisps deserve the status of "true" lisp
or that title forever belongs to Common Lisp only. There are many prominent
Lispers that criticized Common Lisp for being overly bloated and for
butchering the sole idea of Lisp. To be honest I do feel like agreeing with
them and kinda glad that Common Lisp is dying. That is why I did not include
CL in that list.

~~~
lispm
Unfortunately you are missing out on a lot of things Lisp has to offer, by
working with non-core Lisp-variants. For example it would be clearer to you
what interactive working with a Read-Eval-Print-Loop in Lisp actually can do -
besides the simpler improvements in interactivity. There is a whole world of
core Lisp which you are ignoring. You are also slightly misleading people by
not mentioning core Lisp languages and language contributors to those.

> or that title forever belongs to Common Lisp only.

Emacs Lisp, Visual Lisp, ISLisp (an ISO standard), various Common Lisps and
their variants, Interlisp, Portable Standard Lisp, ... and a bunch of others.

You are setting your focus on languages which are more or less derived from
those (for a reason, often with specific improvements or alternative
features), but missing out on the core language implementation features. All
the above have LISP in their name, which Racket, Clojure, Clojurescript,
Fennel, Chez don't. There must be a reason for that. ;-)

Take Clojure and ClojureScript. Without Common Lisp those would not exist. I
can remember when Rich Hickey was an active Common Lisp user (he used
LispWorks and we were on the same mailing lists). He developed stuff in Common
Lisp, worked on Common Lisp to Java integration, wrote a first sketch of
Clojure in Common Lisp and so on.

Luckily he was open minded, learned a lot and created a language (with lots of
lessons from Common Lisp), which a lot of people like...

The language you wish is dying, was literally the one where Rich Hickey
learned from..., like many people before and others, open minded, will also do
in the future.

~~~
iLemming
I don't want to criticize CL, but I feel today it's neither an introductory
Lisp nor academical or pragmatic. I think advocating for Lisp by pushing
newbies to CL, telling "that's the true Lisp, and others not so much" is
damaging. Common Lisp today has become like a Latin of Lisps - knowing it is
awesome, but practicality of that knowledge is quickly becoming irrelevant.
Those who have zero exposure to Lisps can be easily intimidated by it.

My own opinion about CL (why I said "I'm kinda glad it's dying"), shaped
through influence of other respectable Lispers quotes:

Guy L Steele notably criticized its standard for being over 1000 pages.

Daniel Weinreb criticized it for being Lisp2:

> ... It makes the language bigger, and that's bad in and of itself.

Richard Gabriel:

> “Common Lisp is a significantly ugly language. If Guy and I had been locked
> in a room, you can bet it wouldn't have turned out like that”

Paul Graham:

> A hacker's language needs powerful libraries and something to hack. Common
> Lisp has neither. A hacker's language is terse and hackable. Common Lisp is
> not. The good news is, it's not Lisp that sucks, but Common Lisp.

etc.

~~~
lispm
> but practicality of that knowledge is quickly becoming irrelevant

just the opposite. When there is lots of interest in Lisp derived languages,
the core language stays important, since it's the fountain for many ideas.

> through influence of other respectable Lispers quotes

But you ignore the context. The only real one critical about Common Lisp is
Paul Graham, and he got rich and famous through a Common Lisp application: he
wrote an online-store system in CLISP and wrote two books on CL, one of which
is a real classic: On Lisp. But later he was critical and designed Arc as a
very different take on Lisp: small language, small programs, small
identifiers, for web programming. It's the one which was used to develop this
website here on Hackernews.

Guy L Steele, Gabriel and Weinreb came actually out of a tradition where they
used Lisp systems which were MUCH larger than Common Lisp. Steele literally
worked two decades with and for Maclisp and Common Lisp. Steele wrote the
first two defining books on CL. Steele also has a much larger scope: he worked
on things like Scheme, High-Performance Fortran, Parallel Computing with the
Connection Machine (which started out with a parallel Common Lisp), C, Java,
Fortress, ...

Weinreb was working at Symbolics on and with Lisp Machine Lisp. He co-wrote
one of the first object-oriented databases, in Common Lisp. Later he took
those ideas to a C++ based OO-database. Years later Dan was back working with
Common Lisp at ITA where he spent lots of time... I met him once in Hamburg at
a Lisp meeting and he was happy then, working with SBCL and Clozure CL.
Unfortunately he died much too soon.

Gabriel worked on the Common Lisp design. He also wrote a book on benchmarking
Lisp. Then published a critical paper on Common Lisp and THEN founded a
company which developed a wonderful implementation: Lucid CL. He also was then
working on the CLOS standard proposal.

You are totally missing on the background and what these people actually were
working on. Since the broader Lisp community is very diverse and always was,
there were and are always critics in all directions. Some people think modern
Lisp is too static, other think it is not static enough, some think it's too
interactive, others think its not enough interactive... but you need to
understand the context.

Steele, Weinreb and Gabriel were actually the first designers of Common Lisp -
the so-called 'gang of five' included also Fahlman and Moon.

It's like claiming that Tolkien was critical of The Lord of the Rings, because
it has too many pages, took too long to write it and there are lots of new
fantasy books. Tolkien wrote that defining book - like Steele, Weinreb and
Gabriel developed Common Lisp and Graham wrote a classic book on (Common) Lisp
programming.

There are lots of other things in the Lisp history and I'm happy that some
people work to preserve those ideas - not wishing to ignore it and that they
are dying.

[http://www.softwarepreservation.org/projects/LISP](http://www.softwarepreservation.org/projects/LISP)

~~~
iLemming
Okay, that is fair. I honestly appreciate you spending your time, convincing
me. To be honest I did not need much convincing. I am sold on Lisp already and
CL is just a matter of time for me, personally. But I still think it's not a
good introductory Lisp for those who still need convincing. Maybe after using
it a bit my opinion changes, but I know several former CL devs, they share the
similar opinion.

~~~
lispm
Maybe somebody does it like Rich Hickey, coming from C++, checking out CL for
some time and then moving on. But it transformed him. The next generation may
look at Clojure, check it out some time and then move on to design the next
thing... it might then be helpful to understand where SOME (by far not all) of
the ideas originally were coming from...

~~~
iLemming
As I said: "CL is Latin of Lisps". If you're a language designer you
definitely should know it.

But using a very dense language with too many features for app development, in
practice, often causes more issues rather than solving problems.

Clojure is opinionated and that's a good thing.

~~~
lispm
Clojure has the 'half' of its features on the Java side. The whole package is
a huge Java infrastructure with zillions of features + Clojure.

Common Lisp was designed to be that on its own, and its actually not that
large anymore - compared to similar options.

Everyone who wants to learn a Lisp which stands on its own feets - for example
SBCL has only a relatively small C core and all the rest is Lisp itself -
should have a look. This has deep effects generally for Lisp: better error
handling, better interactivity, images, simpler debugging, less language
compromises on the low-level, ...

Lisp is also not opinionated. Working in a non-opinionated languages is
different. In Lisp the developer may need to develop his/her own opinions.

Right now you are looking at a shallow image of Lisp.

