Clojure: If Lisp is so great, why do we keep needing new variants?

https://blogs.law.harvard.edu/philg/2015/10/12/clojure-if-lisp-is-so-great-why-do-we-keep-needing-new-variants/

by mhb • 11 years ago

57 73 11 years ago

blogs.law.harvard.edu

macmac3• 11 years ago

The question is its own answer.

mod• 11 years ago

So why are we trying to differentiate lisps, given that they're excellent?

Are they each better for some reason?

Why innovate on perfection? Or, why not improve the existing lisps rather than create new ones?

I understand what you meant, but I don't know the answer to these questions--before or after reading the article.

(I have given clojure a shot, though, and I enjoyed myself!)

zem• 11 years ago

don't think of "lisp" as a language, think of it as another branch in the evolutionary tree of programming languages. the "lisp is great" people are not saying that any given lisp-based language is the be-all and end-all of programming languages, they are saying that the lisp branch is the best branch to explore.

macmac3• 11 years ago

Part of the perfection is that it can relatively easily be reimplemented and varied. Clojure uses this to leverage the JVM and adds support for concurrency etc. When people say Lisp is perfection they don't mean that one particular Lisp is perfection, but the idea of Lisp is perfection - or damn close to it.

ohnomrbill• 11 years ago

So why are we trying to differentiate lisps, given that they're excellent?

I think the best way to look at this question is to think about who "we" is.

Are the sum total of programmers using lisp coordinating to make a final decision on how many lisps there should be? Certainly not. I don't know all the people using lisp, and I never will. So it doesn't make sense that they're trying to do anything. This community isn't defined in such a way that it's meaningful to talk about directed effort.

There are plenty of reasons to make different lisps without implicitly disparaging the functionality of existing lisps. Perhaps you want to learn about how lisps work by implementing your own. None of the existing languages would help you there. Perhaps you simply have a sense of curiosity about a language feature, and want to implement it somewhere. A less mature lisp might help, if the codebase is smaller and easier to reason about. Perhaps you need to use the JVM for business reasons. Perhaps the JVM is too much for the hardware you're running on, and need a C variant. Perhaps there's one with a particularly useful FFI to another language.

echu_marbdan• 11 years ago

Why are Lisps excellent, is a better question. They work well with structure editors, and they allow for very powerful metaprogramming of the language to add in any needed features.

Those forms of excellence do not put Lisp on the JVM, nor give emphasis to multi-threaded, functional programming. Hence, Clojure.

mbil• 11 years ago

Clojure rationale:

"Customers and stakeholders have substantial investments in, and are comfortable with the performance, security and stability of, industry-standard platforms like the JVM. While Java developers may envy the succinctness, flexibility and productivity of dynamic languages, they have concerns about running on customer-approved infrastructure, access to their existing code base and libraries, and performance. In addition, they face ongoing problems dealing with concurrency using native threads and locking. Clojure is an effort in pragmatic dynamic language design in this context. It endeavors to be a general-purpose language suitable in those areas where Java is suitable. It reflects the reality that, for the concurrent programming future, pervasive, unmoderated mutation simply has to go.

Clojure meets its goals by: embracing an industry-standard, open platform - the JVM; modernizing a venerable language - Lisp; fostering functional programming with immutable persistent data structures; and providing built-in concurrency support via software transactional memory and asynchronous agents. The result is robust, practical, and fast."

via http://clojure.org/rationale

zeveb4• 11 years ago

Of course, one can run Common Lisp on the JVM and one can integrate CL with the JVM; one can add immutable persistent data structures to CL (but all the mutable stuff would still be available under the covers). I imagine that it'd be easier to add that stuff to CL than it would be to create a new language from scratch.

I honestly don't know how hard it would be to add software transactional memory and asynchronous agents to CL. I don't think it would be bad, but perhaps the end result would be so unlike CL that it wouldn't be pleasant to work in.

brudgers2• 11 years ago

It's not so much that Common Lisp couldn't be implemented on the JVM and with transactional memory, it's that if one is going to do that much work, why not tune the language for that environment and for the programmers who live there? And once you do that, then picking a semantics for \.\ becomes a point of interest. Does one pick Common Lisp's or Java's usage for clarity , or the third option of complexity by overloading it?

PuercoPop• 11 years ago

FYI: STM is available for Common Lisp, including in the JVM

https://github.com/cosmos72/stmx

codemac• 11 years ago

S-expressions != "lisp"

There is the Common Lisp standard, and those variants really are managed like C compilers are. It's pretty great, and the differences are tiny.

Scheme has standards -- but yes, due to the language's easy implementation many people have made implementations of varying adherence to that standard. This is a good problem, it means people are able to implement their own languages.

Finally - clojure's rationale is pretty straight forward, and has obviously met an incredible niche in the PL space. I don't think it's that controversial of an implementation of S-exps.

Skunkleton• 11 years ago

I have always been a doubter of lisp likes and even I think this article makes no sense. If you are going to lump CL, Scheme, Clojure, etc together, then the list of "C" like languages is much much longer than the three they have in the article.

redahs3• 11 years ago

Because Lisp doesn't have a flat memory model, you can't directly produce a binary array suitable for direct copying to output device memory (ex. network card, GPU, etc) by simply expanding expressions using the built in syntax.

This means it's necessary for LISPers to continually reinvent the input-output layer and add non referentially transparent features to the language borrowed from Java or C in order to do any useful work.

Doing so is also contrary to the ideals of functional programming however, so they will continually overthrow the established LISP to invent a new one.

edit: to downvoters, replace "you" with "language runtime implementers", and understand that this is not a normative assertion, but a descriptive theory to explain why we have seen a huge number of non-interoperable Lisp\Scheme implementations with minor differences over the years.

zeveb4• 11 years ago

Because Lisp doesn't have a flat memory model, you can't directly produce a binary array suitable for direct copying to output device memory (ex. network card, GPU, etc) by simply expanding expressions using the built in syntax.

What are you talking about? Common Lisp has built-in support for vectors:

    (let ((vector (make-array length :element-type 'unsigned-byte)))
      ;; do stuff with that flat array of bytes
      ;; …
      (replace ext:gpu vector))

(In this example, EXT:GPU is a chunk of memory which is overwritten by VECTOR; one might conceivably use COPY-SEQ instead of MAKE-ARRAY, and one might of course just operate on EXT:GPU)

Doing so is also contrary to the ideals of functional programming

Lisp isn't about functional programming; Lisp is a multi-paradigm language, supporting imperative, functional and OO programming out of the box (and can of course be extended to support aspect-oriented programming, table-oriented programming or what-have-you).

redahs3• 11 years ago

I would argue that a significant number of people were attracted to Lisp\Scheme variants over the years because of the promise of functional programming and the theoretical advantages of being to design programs using functional principles.

The problem with your example is that evaluation of the expression performs a side effect on an internal machine specific to the implementation of Common Lisp, and that it is not a portable and abstract expression defining a return value.

Ideally we would be able to define a return value as a variable length sequence of constituent elements through recursive evaluation, where the process of evaluation is guaranteed to compactly allocate all of the constituent elements contiguously on the same location of the stack.

This would allow the runtime implementation to directly copy the contents of a value of an arbitrary size to a necessary output device, so long as the runtime had access to a portable and functional definition of the value to be copied.

Because the Lisp language family does not provide for this, there has been a need to continually invent new implementation variants which each model different internal machines for performing these tasks.

time_is_scary2• 11 years ago

I'm getting hung-up on the word "need".

pekk2• 11 years ago

In what way? Either there is a need for variants, or there is no need for variants but it is perfectly okay to make them, or there is no need and it's not okay to make them.

time_is_scary2• 11 years ago

If there is a need, then they should be made. If there is no need, then they can still be made (maybe even revealing a new need in the process).

I guess it seems like a non-issue to me.

Then again, applying my own reasoning:

There is no need to ask this question, but it's fine to ask it anyways.

reilly3000• 11 years ago

There is a difference between language and execution. I can put together a clojure server and have it deployed virtually anywhere in about 10 minutes. I have never tried to deploy a CL app but I imagine it must be a little more complicated than making an Uberjar. The semantics of Lisp are beautiful. Why do we need to force them into a single language when it's best strength is portable symbolic logic?

mateuszf• 11 years ago

I'm not Common Lisper, but actually CL distribution is trivial compared to JVM (for user applications, not servers). It's possible to create native executables, which don't need any frameworks to exist on the target systems. So deploying CL may take more work (making multiple executables), but the programs itself don't need users to have some frameworks installed before.

pekk2• 11 years ago

It's not a binary, either/or choice between "Lisp is perfect" and "we need a new variant of Lisp". Here's a map of possible attitudes toward Lisp. Take your pick.

On the Lisp-affinity axis,

1. Lisp is almost perfect as-is, we don't need new variants which will only adulterate the purity and greatness of Lisp as it already exists.

2. Lisp is great, and my favorite variant (e.g. Scheme) is the greatest variant because it is the purest available representation of the Lisp concept.

3. Lisp is mostly great, it just needs features x, y, z... which are provided by my favorite variant (e.g. Clojure).

4. Lisp is great, but really only for particular things, and its variants might be great for slightly different things.

5. Lisp isn't so great at all, and making new variants is just putting lipstick on a pig. Use a functional language other than Lisp (e.g. Haskell).

6. Functional programming as a whole sucks. Use a mixed-paradigm or imperative language (Java, C#, Perl, etc.)

7. High-level programming sucks. Use something without mandatory garbage collection (C++, Rust, C, Assembly).

On the intolerance-to-tolerance axis,

1. Lisp is almost perfect as-is, we don't need new variants which will only adulterate the purity and greatness of Lisp as it already exists.

2. Lisp is great as-is, so we don't really need new variants, but since they are also Lisp, they are also great.

3. Lisp is great, but some other languages are also great.

n. It doesn't matter what language you use, all language differences are only cosmetic.

kaffeemitsahne• 11 years ago

This could be a nice xkcd-style infographic hehe.

weavejester• 11 years ago

This is more nomenclature than anything. We have a broad definition of what a lisp is, but a fairly narrow definition of what a C variant is. I'd argue that C++ and Java have more in common with each other than, say, Shen and Emacs Lisp.

prospero2• 11 years ago

Clojure isn't a minor variation on earlier Lisps, it's something that uses s-expressions with a significantly different set of default data structures, core library functions, and platforms.

This is like asking why we needed C when we already had ALGOL.

nickpsecurity8• 11 years ago

First point is true. Second point isn't: BCPL was created solely because they couldn't build an improved ALGOL (CDL) on a 1950's computer. Took out every good feature the hunk of junk couldn't compile. C was modified BCPL/B to do that on a PDP-11 w/ UNIX a watered-down MULTICS for same reason.

A comparison would be LISP 1.x vs modern Scheme or Common LISP. And only using LISP 1.x because you had to work with a microcontroller instead of a PC. ;)

prospero2• 11 years ago

My point was that treating a language as just a few implementation details atop its syntactic heritage is overly reductive (as you demonstrated).

rayiner• 11 years ago

Nobody bases their "something better" on something they don't think is already great.

atomicbeanie2• 11 years ago

And if antibiotics are so great, why do we keep needing more of them?

atomicbeanie2• 11 years ago

And if antibiotics are so great, why do we keep needing new kinds?

davidrupp• 11 years ago

The major contribution of Clojure is not that it's a Lisp; it's that its model of immutability-by-default eliminates whole categories of errors due to shared mutable state. I personally also enjoy having non-parenthesized literals for things like maps and sets, but those are incidental benefits.

lisper3• 11 years ago

And why hasn’t the C world turned into a similar Tower of Babel?

Because it's much harder to produce a variant of C than it is to produce a variant of Lisp. Producing a variant of Lisp in Lisp (a.k.a. writing a macro) is a trivial exercise that anyone can do in a matter of minutes. Producing a variant of Lisp from scratch is an elementary exercise that an undergrad can do in a couple of hours. Producing a variant of C is an advanced exercise that would take even the most skilled programmer many days.

tormeh4• 11 years ago

... Because so many languages are made in a matter of hours or days. Can we please drop the machismo? Making a language takes about a decade, with multiple people involved. A prototype one without a library can be made in a matter of months, but nobody would want to use those. I find it plausible that making a lisp is easier, especially if it's interpreted, but it's not that easy.

mlieberman85• 11 years ago

I think you misunderstood. A dialect of lisp is a fairly trivial exercise. We were able to do it in a single lecture back in college. Now that dialect had trivial and essentially useless functionality but allowed us to easily build on and create new languages, but lisp was designed to allow for these dialects to be made and to be made easily.

nickpsecurity8• 11 years ago

As a personal exercise, you should compare making a LISP interpreter or compiler to Wirth's treatment on doing an imperative language sometime. The difference is a 100-200 pages of work. Plus, the LISP can self-modify during compile to add any subsequent feature.

It's not machismo: it's just the design of LISP. Easy to parse, easy to modify, easy to evaluate, data as code, basic primitives that express anything else at least acceptably, and on 50's-60's hardware.

Additionally, building a useful LISP (esp Scheme) is an academic exercise done all over the world that's fairly easy even for amateurs. Building a useful, non-optimizing C++ compiler with only a subset of LISP capabilities is an exercise only undertaken by masochists very dedicated to compiler design. Even a prototype is easier for LISP (a few pages of code) while a prototype of C++ or even C's semantics is much more challenging. So, the empirical evidence counters your claim in terms of completed projects, their complexity, and features received in return.

kornish• 11 years ago

I find it plausible that making a lisp is easier, especially if it's interpreted, but it's not that easy.

As an example, here's a guide for writing a Scheme interpreter in a matter of hours: https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_...

It definitely doesn't take it months to walk away with a working implementation. Whether or not the language you've just written is actually useful or preferable to alternatives is a different question, and there I agree with you that communities, libraries, and language maturity can take a long time to build.

Lisp's simple syntax makes it a prime target for creating new dialects (like Clojure) to experiment with semantics.

Sanddancer• 11 years ago

I disagree there pretty heavily. There are a lot of C implementations out there -- gcc, clang, msc, icc, keil, cscript, tcc, pcc, etcetc. The big reason C hasn't turned into a similar Tower of Babel is that the various stakeholders in C recognize that it's a living language, and get together regularly to help work out methods that aren't useful anymore and add features to the specification to reflect what modern programmers want. If C had stopped standardization when ANSI C was released, you'd see a similar number of variants.

nickpsecurity8• 11 years ago

The prior point still stands if you compare the number of LISP modifications... basically every program with macros + interpreters + compilers... to the few things you've cited which were often a lot of work and hard to change. GCC particularly.

I agree the C crowd is more unified and that has huge impact. I'd go further to suggest that the legacy effect of UNIX and all the C libraries keep thing compatible. The C crowd is always sort of in maintenance mode for their language to keep everything working. While the LISP crowd rarely keeps anything and is often developing forms of the language. A subset are more practical with something long-term for real world use but most aren't. This difference between C use cases and LISP is worth exploring in answering these questions.

informatimago• 11 years ago

I disagree there pretty heavily. There are a lot of C variants over there: Objective-C, C++, Pro*C, etc. (There are a lot of software projects that actually include a specific C pre-processor of some kind, check, eg. the C sources of emacs lisp, of GNU clisp, etc). As soon as you write a new front-end to C, you get a C variant, just like as soon as you write a DSL in Lisp you get a Lisp variant (and vice-versa).

The C world is a Tower of Babel.

Now, it's true that it's easier to do in lisp than in C, since in C the tools are external (you have to use flex/bison to implement the pre-processor) while in Lisp the tools are internal, and you just need to write a single defmacro to introduce your variant.

kazinator5• 11 years ago

Producing a crappy interpreter for a toy C-like language is about the same as producing a crappy interpreter for a toy Lisp language.

C did turned into a Tower of Babel: in the libraries. For instance Win32 is essentially one language, POSIX another. Portability among Unix systems alone used to be a mess of #ifdef directives through the 1980's and 1990's.

lisper3• 11 years ago

Producing a crappy interpreter for a toy C-like language is about the same as producing a crappy interpreter for a toy Lisp language.

Ab-initio perhaps (and even that isn't clear because parsing sexprs is a lot easier than parsing C). But producing a production-compiler for a non-toy Lisp-like language given a compiler for Lisp is a heck of a lot easier than producing a production-quality compiler for a non-toy C-like language given a compiler for C.

C did turned into a Tower of Babel: in the libraries.

Sure, and for the same reason: it's easy to write library code in C. In fact, that's the only thing that's easy to do in C. So that's what C programmers do: they write library code. They don't, as a general rule, write compilers. So the compilers stay stable and the libraries don't.

Mikeb85• 11 years ago

Not sure I'd say new variants are 'needed'. But the fact that Lisp languages are so easy to write encourages people to write them.

Besides, Clojure has some fairly modern and novel stuff going on when it comes to concurrency, in addition to being a wholly modern Lisp.

TazeTSchnitzel• 11 years ago

Clojure isn't a lisp, it doesn't have conses.

fiatmoney• 11 years ago

"If English is so great, why do we keep inventing new slang?"

dragonwriter• 11 years ago

Lisp is not a language like C (Common Lisp is, but Lisp is broader).

Lisp is a language family, sort of like you might have a family of languages with Algol-derived syntax.

And, you know, we see new members of the latter family all the time; they're just so dominant among programming languages that we don't even talk about them as a related group.

bunderbunder• 11 years ago

I think the question is framed poorly, and on that ground I'd challenge it from two angles:

First, one could argue that there are all sorts of additional C-like languages that weren't listed - Java, C#, Rust, Go, etc.

One could also argue that "Lisp" is a more fundamental category of languages than "C", so it's not an apples-to-apples comparison. Exhibit A: the author's list of Lisps included both dynamic and static languages, whereas the list of C's included only statically typed ones. It captures the idea of a functional language with a unified representation for both code and data. C-like, on the other hand, seems to specifically mean C and its superset languages (a much smaller family than its descendants) according to the author's usage.

lispm• 11 years ago

Since Clojure is not a Lisp in the narrow sense, this is a useless question.

If Lisp means something broad, then we would list very different languages: Logo, Dylan, Julia, R, Javascript, Racket, ACL2, ... - again that would be a useless question.

Also, if GNU/Linux is so great, why do we keep needing new distributions... if Perl is so great, why do we keep needing new scripting languages? ... if the Porsche 911 is so great, why do we keep needing new variants?

GigaMos• 11 years ago

because "LISP can learn a lesson from all the languages that borrowed ideas from LISP. It is nature's way."

from http://blog.samibadawi.com/2013/05/lisp-prolog-and-evolution...

rubiquity• 11 years ago

The difference is that Lisp is a proud heritage for a language to have. So when you make a Lisp, you naturally tell everyone you made a Lisp. When you go out and make the next twist on C, which is what Java and Go originally were/are, you keep that skeleton in the closet.

brudgers2• 11 years ago

In a sense, this is like asking "If Turing machines are so great, why do we keep needing new variants?"

Lisps are lisps because to some degree they express a particular model for computation. What makes them seem more alike than the varieties of stack based system is that the first pass at a notation for ordering application (parenthesis) is recommended by its similarity to the mathematical notation for ordering application. In other words, languages modelled [more or less] on lambda-calculus look like "a thing" by the accident of similar notation, whereas languages modelled [more or less] on Turing machines don't look like "a thing" by virtue of the diversity of notation.

In practice, this means that Scheme and Common Lisp and Clojure get lumped together while Forth and Cobol and C# don't, even though there is as much variation between the execution model in the first group as the second.

amirouche• 11 years ago

“If Lisp is so great, why did this guy have to build a slightly different version instead of building a popular application program in an existing version of Lisp, such as Common Lisp?”

copsarebastards• 11 years ago

It's the thinking and core idea of Lisp that is great, not the implementation. Every implementation includes tradeoffs, hacks and compromises.

Clojure's success is largely due to the fact that they've made a set of tradeoffs, hacks, and compromises that makes it usable in a lot of business contexts. Running on the JVM means giving up some really core Lisp ideas (like tail call elimination) but it also means that you can distribute a JAR file and nobody will know you didn't write it in Enterprise SafeAndTrustworthy Java.

We don't keep needing different variants, we keep needing different implementations.

sbochins• 11 years ago

It seems like the author is conflating two things, Lisp not being popular and there being many Lisps. As others have stated, the reason there are many Lisps is because it is very easy to make a Lisp. You can check on github for Lisp implementations and find very many. The reason why it isn't popular is something I don't really want to get into. But, I will say that modern languages are transitioning much closer to Lisp than they are backtracking to languages like C.

nickpsecurity8• 11 years ago

Well, you first need to understand the history of C to fully get why it's such a terrible language. I have link (below) with both a long video and a brief summary in numbered points. I think the arguments against using it today are solid and conclusive if you're not forced to for some pragmatic reason.

http://pastebin.com/UAQaWuWG

Nonetheless, C got a lot of use via network effects. There actually have been many C dialects out there: compiler variants, extensions for specific systems, safe/secure versions of it, parallel/concurrent versions, hardware languages... the list goes on. Probably dozens of C variants appeared and mostly failed. The main reason is legacy: whatever replacement exists must support the existing C language usage and codebase. Any fixes that break apps or require rewrites are rejected. Marketing and community effects are another issue.

Now, we have to ask what is LISP. I think Graham said it best in that it's an axiomatization of computation itself:

http://www.paulgraham.com/rootsoflisp.html

So, LISP is that concept and core. Its nature lets you express various constructs however you want to. You break the problem into smaller pieces while simultaneously modifying the language to better express their solution. What's best way of expressing a problem naturally varies from programmer to programmer. The LISP variants therefore are the many ways different people (or communities) looked at solving a problem within the LISP core and philsophy. Some stay purely in it, some diverge wildly from it, and some are in the middle. The fundamental concept and approach, though, with many interpretations on expressing it are why there are so many LISP's, though.

Clojure, a new expression of the LISP concept/core, has advantages expressed well in the first paragraphs of the rationale:

http://clojure.org/rationale?responseToken=894e644e3f4488b17...

This philosophy and use of DSL's for expression is no longer unique to LISP. One can see it in REBOL/Red quite directly with some takeup in languages such as Haskell and Julia. Forth also does this sort of thing with stack operations. So, we're seeing uptake of the idea even in mainstream with them recognizing the benefits. All started with McCarthy's reducing all computation down to some primitive, consistent elements that were shown to express or adapt to anything.

kazinator5• 11 years ago

* We accept the proposition that C is feeble and yet there are only three major variants of C: C, C++, and Objective-C. *

C90, GNU C, C99, C11, C++98, C++05, C++11, C++14, ...

kazinator5• 11 years ago

Lisp inspires some people to work at the implementation level.

My TXR Lisp (http://www.nongnu.org/txr) has strong ties to Common Lisp, but it does certain things which I've been able to do easily due to working at the implementation level.

For instance, I have regular cons cells as well as lazy cons cells, both of which satisfy the consp function, and are recognized by all the library functions, from car and cdr onward. If this were develpeed in an existing Lisp, it would require rewriting the library from scratch. E.g. not using the standard car, cdr, mapcar and so on.

Another example is that forms can optionally express Lisp-1 style evaluation for those arguments which are symbols. This is sugared over with square brackets.

  ;; list is in the function namespace, but resolved
  [mapcar list whatever]

Implementing this correctly means writing your own code walker; it's not just "add a macro and hand off the code to Lisp's evaluator/compiler". The exact rule is that the closest lexical binding of the identifier is used, whether it is a function or variable; and if there is no lexical binding, then the global one is used. If both a function and variable of the same name exist globally, then preference is given to the variable binding. It doesn't end there: symbol macros have to be handled properly: in [a b], a or b or both could be symbol macros. But they get shadowed by function bindings which are lexically inner:

  (defsymacro ((m whatever))
    (flet ((m () ...))
       (m ...) ;; unambiguously function
       (list m) ;; expanded as symbol macro
       [m ... m ...])) ;; function everywhere

Lisp has always been a family of languages. From almost the very beginning, there were numerous dialects. Every major institution that had Lisp activity had its own dialect!

It is in recognition of this that the late John MacCarthy expressed his wish that no dialect be just called "Lisp".

Forty years ago you could have said, "if Lisp is go great, why do we have MacLisp, InterLisp, BBN Lisp, ..."

Part of the reason Lisp is great is that it teaches programmers to fish.

klibertp2• 11 years ago

Hi, I just wanted to tell you that I'm learning TXR right now (https://klibert.pl/output/this_week_on_polyglot.html) and I like it very much. My current goal is to write a tutorial for it: the docs are good and pretty detailed, but they aren't exactly friendly to new users. I hope I'll manage to finish this, I think TXR deserves much wider recognition.

Anyway, thanks for your work on TXR and thanks for making it available. Great job!

kazinator5• 11 years ago

Hi. I think your code snippet:

  @  (block cd)
  @    (bind v @(get-string (open-command `cd @path && git remote -v`)))
  @    (next :string `@v`)
  @      (skip)
  vps@a(fetch)
  @      (bind url @(trim-str a))
  @  (end)

probably just wants to be something like perhaps this:

  @(next `!cd @path && git remote -v`)
  vps@\t@url (fetch)

Match directly into the output of the git command with @(next ...), and extract the url directly: it is delimited by tab from the remote name (which we can use literally or represent using @\t) and by a space from the (fetch) or (push) keyword. Thus we can eliminate the trim-str extra step and variable.

Also if v holds a string, `@v` simplifies to v!

Another thing is that if we are just marching through data to produce output, and don't actually need to collect anything to analyze, we can convert this structure:

  @(collect)
  ...match...
  @(end)
  @(output)
  @  (repeat)
  ...spew...
  @  (end)
  @(end)

into:

  @(repeat)
  ...match...
  @  (output)
  ...spew...
  @  (end)
  @(end)

It's not just shorter, but efficient too if the data is large (it doesn't hang on to collected data as it marches through it).

Cheers ...

kazinator5• 11 years ago

The thing about Lisp-like languages is that they have some superficial similarities which get them lumped together, because programmers expect to be able to classify programming languages based on superficial similarities. If it has symbols encased in parentheses, it's some kind of Lisp (even if the authors don't use that word in the name).

They are not all the same any more than languages which have braces for block structure and f(x, y) function calls are the same!

Languages which have a complicated surface syntax tend to distinguish themselves sharply on that syntax. Thus we can regard PL/I, Pascal, C, Ada, Rust, Go and Java to be semantic offshoots of the Algol family: new dialects of Algol.

If you invent a new dialect of Algol with new keywords and new syntactic gadgets for declaring, calling, throwing, catching, structuring, flowing, and so on --- old semantics with a new skin --- nobody accuses you of making just a dialect of Algol.

If you make a new language with S-expressions for its syntax, but new semantics under the hood, it is "just another Lisp" that some university kids can throw together in an afternoon.

Syntax is semantics is the popular view; you can't possibly have new semantics if you don't look different. And the presence of some old semantics exhibited in a few examples of course confirms that you don't have new semantics. Hey look, functions look the same, and there is let and lambda. Same old junk!

Clojure: If Lisp is so great, why do we keep needing new variants?

Related Stories