6 ms·

Started looking at getting into Racket and CL after reading up on lisp and there is something about it that really bugs me, in a good way. Sadly the train seems

Started looking at getting into Racket and CL after reading up on lisp and there is something about it that really bugs me, in a good way. Sadly the train seems to have left the station regarding positions where you use lisp where I live. All is java and C-flavors.

TeMPOraL 9y ago
> All is java Possible tip: sneak in ABCL when they're not looking. ABCL is a Common Lisp implementation for JVM, with (what seems like) relatively OK interop between Lisp and Java code.
- toisanji 9y ago
  Seems dead
  - kgwgk 9y ago
    > Seems dead The latest release (1.5) was earlier this month.
  - cat199 9y ago
    plus: it's common lisp. if the language spec hasn't changed, and your code works, you don't really need to change the interpreter.
    - iak8god 9y ago
      ABCL's interoperability with Java is not part of the CL spec, but an add-on. This can make it easy to quickly get things done in a situation where Java libraries are the best tool for the task, but at the cost of portability between CL implementations.
- nikofeyn 9y ago
  why would one do that instead of using clojure?
  - klibertp 9y ago
    Because, despite both being Lisps, Clojure and Common Lisp are vastly different languages, with different pros and cons.
    - nikofeyn 9y ago
      of course they're different. i didn't say or imply otherwise. the original parent mentioned both racket and common lisp, again different languages, so it was clear they weren't looking just for common lisp and were more generally wanting for some lisp or scheme type of job. and i was asking a legitimate and honest question, as i see ABCL to be a much more esoteric and hard sell than clojure to a place heavy on java development.
      - klibertp 9y ago
        You asked, "why would one use [ABCL]?" What I implied in my response (sorry for not stating it directly) was that one may prefer the particular feature set of CL over Clojure's. As for being a hard sell - my personal experience is that if you're in a position that allows you to choose your implementation language, in most cases you can choose Brainfuck and nobody will care. As an example, I introduced F#, Erlang, Elixir and a bit of Prolog to a Python shop that way: all that mattered in these cases was whether the code worked, and it did, so no one complained. The Erlang microservice actually outlived the project it was written for by a year and a half. On the other hand (still, in my experience) if you're not in a position where you can choose your language you're basically screwed, and should stop trying to convince your team to switch to something else. You have almost no chance of succeeding and a high chance of disrupting teamwork by pushing your opinions on others. So I was thinking about the former situation, where you have some degree of freedom of choice and can decide the language on technical merits alone.
  - TeMPOraL 9y ago
    Because as 'klibertp wrote, they're two vastly different languages, with different design decisions. The whole thread is about primarily Common Lisp; people who enjoy the design choices made by the CL standardization committee and subsequent evolution of the language's ecosystem would most likely want to know that there exists a proper CL implementation for JVM.
- dancing_shark 9y ago
  Something makes me think they'll notice all the parens during a code review...
  - TeMPOraL 9y ago
    Write a reader macro that treats all [ ], { } and < > as if they were ( ), and the only thing they'll notice is that there's less parens/brackets than there should be in regular Java code...
    - arethuza 9y ago
      There have been efforts to do something similar to create more "readable" S-expressions. I did work in Common Lisp for a number of years and didn't have any issues with the syntax but I rather like this idea: http://readable.sourceforge.net/ http://readable.sourceforge.net/
mateuszf 9y ago
Or just use Clojure, which is a nice Lisp (not CL) for the JVM
- klibertp 9y ago
  > which is a nice Lisp Well, it's definitely a Lisp; however, I don't think the "nice" qualifier fits here. Clojure has a few interesting features which are well integrated with each other, but it also comes with a lot of opinionated choices one might not like. Another thing - not a language issue per-se - is that relying on Java ecosystem can be painful (and ClojureScript, fortunately finally bootstrapped a while back, is not quite the same language). Personally, I feel that, in pursuit of simplicity, Clojure dropped a lot of useful features. As an example, in both CL and Racket, you have 2-3 times more ways of structuring your code than in Clojure. This is important, because different parts of a codebase benefit from different structuring mechanisms - and the more choice you have, the easier it is to find the right one. In Clojure, all you have are maps and defrecord, with the latter being almost never used. Of course, you have macros to combat this, but then you're put in the shoes of language inventor and implementer, which is a lot more complexity than most programmers would like to fight just to be able to order the function definition the way they want. To summarize: in my opinion, Clojure did some things right but then got locked into that single track and refused to incorporate additional features (and lessons learned) from other Lisps. So no, I don't think it's a "nice Lisp." OTOH, it may well be a good language, especially if your problem and domain are a good fit for it.
  - deleted 9y ago
    [deleted]
  - lispm 9y ago
    It might be a nice language but not an especially nice Lisp. Lots of stuff from Lisp is missing: interpreter and compiler integrated, self hosting compiler written in Lisp, condition system with interactive error handling, nice object-system like CLOS, simpler numeric tower, good error messages, Lisp-like stack traces, image-based development with fast startup times, Tail Call Optimization, continuations, ... plus it has some strange design decisions with basic list data structures. It's 'Lisp'-like where the basic primitive list processing has been replaced with a different higher-level data structure (persistent sequences) built on top of an alien infrastructure which leaks through everywhere and which was not developed for interactive programming (the JVM)... That was one of its original design decisions: being hosted on top of the JVM.
hellofunk 9y ago
I think you will find that Clojure offers many of things that you like about Racket or CL, while also getting rid of a lot of the complexity of CL (CL is not really a functional language, and hardly can be considered an immutable one). Clojurescript, which is nearly identical semantics to Clojure, also is quite a practical skill for front-end development.
- TeMPOraL 9y ago
  > (CL is not really a functional language, and hardly can be considered an immutable one) It's important to note here though that this is a feature, not a bug. CL is a multi-paradigm and extremely pragmatic language.
  - arnsholt 9y ago
    I usually quip that Common Lisp and Perl are basically the same language, bit with different syntax. Not quite correct, obviously, but both languages give me that same pragmatic feel where having several approaches to the same problem is considered something desirable, not a defect.
    - azrazalea 9y ago
      perl also grabbed a lot of things from CL, like moose(their MOP, at least so I hear).
  - hellofunk 9y ago
    > this is a feature, not a bug 1) I never said it was a bug. 2) Whether CL's multi-paradigm nature is an advantage or not is subjective.
    - TeMPOraL 9y ago
      That's all what I meant. I read your comment as implying this is a bug; seems I was wrong.
- ScottBurson 9y ago
lisper 9y ago
> positions where you use lisp where I live Where do you live?

TeMPOraL 9y ago

> All is java Possible tip: sneak in ABCL when they're not looking. ABCL is a Common Lisp implementation for JVM, with (what seems like) relatively OK interop between Lisp and Java code.

toisanji 9y ago
Seems dead
- kgwgk 9y ago
  > Seems dead The latest release (1.5) was earlier this month.
- cat199 9y ago
  plus: it's common lisp. if the language spec hasn't changed, and your code works, you don't really need to change the interpreter.
  - iak8god 9y ago
    ABCL's interoperability with Java is not part of the CL spec, but an add-on. This can make it easy to quickly get things done in a situation where Java libraries are the best tool for the task, but at the cost of portability between CL implementations.
nikofeyn 9y ago
why would one do that instead of using clojure?
- klibertp 9y ago
  Because, despite both being Lisps, Clojure and Common Lisp are vastly different languages, with different pros and cons.
  - nikofeyn 9y ago
    of course they're different. i didn't say or imply otherwise. the original parent mentioned both racket and common lisp, again different languages, so it was clear they weren't looking just for common lisp and were more generally wanting for some lisp or scheme type of job. and i was asking a legitimate and honest question, as i see ABCL to be a much more esoteric and hard sell than clojure to a place heavy on java development.
    - klibertp 9y ago
      You asked, "why would one use [ABCL]?" What I implied in my response (sorry for not stating it directly) was that one may prefer the particular feature set of CL over Clojure's. As for being a hard sell - my personal experience is that if you're in a position that allows you to choose your implementation language, in most cases you can choose Brainfuck and nobody will care. As an example, I introduced F#, Erlang, Elixir and a bit of Prolog to a Python shop that way: all that mattered in these cases was whether the code worked, and it did, so no one complained. The Erlang microservice actually outlived the project it was written for by a year and a half. On the other hand (still, in my experience) if you're not in a position where you can choose your language you're basically screwed, and should stop trying to convince your team to switch to something else. You have almost no chance of succeeding and a high chance of disrupting teamwork by pushing your opinions on others. So I was thinking about the former situation, where you have some degree of freedom of choice and can decide the language on technical merits alone.
- TeMPOraL 9y ago
  Because as 'klibertp wrote, they're two vastly different languages, with different design decisions. The whole thread is about primarily Common Lisp; people who enjoy the design choices made by the CL standardization committee and subsequent evolution of the language's ecosystem would most likely want to know that there exists a proper CL implementation for JVM.
dancing_shark 9y ago
Something makes me think they'll notice all the parens during a code review...
- TeMPOraL 9y ago
  Write a reader macro that treats all [ ], { } and < > as if they were ( ), and the only thing they'll notice is that there's less parens/brackets than there should be in regular Java code...
  - arethuza 9y ago
    There have been efforts to do something similar to create more "readable" S-expressions. I did work in Common Lisp for a number of years and didn't have any issues with the syntax but I rather like this idea: http://readable.sourceforge.net/ http://readable.sourceforge.net/

mateuszf 9y ago

Or just use Clojure, which is a nice Lisp (not CL) for the JVM

klibertp 9y ago
> which is a nice Lisp Well, it's definitely a Lisp; however, I don't think the "nice" qualifier fits here. Clojure has a few interesting features which are well integrated with each other, but it also comes with a lot of opinionated choices one might not like. Another thing - not a language issue per-se - is that relying on Java ecosystem can be painful (and ClojureScript, fortunately finally bootstrapped a while back, is not quite the same language). Personally, I feel that, in pursuit of simplicity, Clojure dropped a lot of useful features. As an example, in both CL and Racket, you have 2-3 times more ways of structuring your code than in Clojure. This is important, because different parts of a codebase benefit from different structuring mechanisms - and the more choice you have, the easier it is to find the right one. In Clojure, all you have are maps and defrecord, with the latter being almost never used. Of course, you have macros to combat this, but then you're put in the shoes of language inventor and implementer, which is a lot more complexity than most programmers would like to fight just to be able to order the function definition the way they want. To summarize: in my opinion, Clojure did some things right but then got locked into that single track and refused to incorporate additional features (and lessons learned) from other Lisps. So no, I don't think it's a "nice Lisp." OTOH, it may well be a good language, especially if your problem and domain are a good fit for it.
- deleted 9y ago
  [deleted]
- lispm 9y ago
  It might be a nice language but not an especially nice Lisp. Lots of stuff from Lisp is missing: interpreter and compiler integrated, self hosting compiler written in Lisp, condition system with interactive error handling, nice object-system like CLOS, simpler numeric tower, good error messages, Lisp-like stack traces, image-based development with fast startup times, Tail Call Optimization, continuations, ... plus it has some strange design decisions with basic list data structures. It's 'Lisp'-like where the basic primitive list processing has been replaced with a different higher-level data structure (persistent sequences) built on top of an alien infrastructure which leaks through everywhere and which was not developed for interactive programming (the JVM)... That was one of its original design decisions: being hosted on top of the JVM.

hellofunk 9y ago

I think you will find that Clojure offers many of things that you like about Racket or CL, while also getting rid of a lot of the complexity of CL (CL is not really a functional language, and hardly can be considered an immutable one). Clojurescript, which is nearly identical semantics to Clojure, also is quite a practical skill for front-end development.

TeMPOraL 9y ago
> (CL is not really a functional language, and hardly can be considered an immutable one) It's important to note here though that this is a feature, not a bug. CL is a multi-paradigm and extremely pragmatic language.
- arnsholt 9y ago
  I usually quip that Common Lisp and Perl are basically the same language, bit with different syntax. Not quite correct, obviously, but both languages give me that same pragmatic feel where having several approaches to the same problem is considered something desirable, not a defect.
  - azrazalea 9y ago
    perl also grabbed a lot of things from CL, like moose(their MOP, at least so I hear).
- hellofunk 9y ago
  > this is a feature, not a bug 1) I never said it was a bug. 2) Whether CL's multi-paradigm nature is an advantage or not is subjective.
  - TeMPOraL 9y ago
    That's all what I meant. I read your comment as implying this is a bug; seems I was wrong.
ScottBurson 9y ago

lisper 9y ago

> positions where you use lisp where I live Where do you live?