4 ms·

This is not like the clojure is to java, it's only a syntax transformation, superficial. Usually lisp and FP means that you get immutable data structures and a

This is not like the clojure is to java, it's only a syntax transformation, superficial. Usually lisp and FP means that you get immutable data structures and a good concurrency system, both of which you get in clojure. I looked at this a while ago and figured it's not useful for production, but an interesting project none the less.

JasonFruit 7y ago
Or rather, it isn't useful in production in any way Python is not, and there's little reason to choose a weird stunted Lisp that offers few advantages over its host, an established language with a huge community.
- Zak 7y ago
  Syntax transformation via macros can be a significant advantage when the semantics of the language don't support an abstraction that's shaped like your problem.
  - cat199 7y ago
    totally agree with this. I can see even in larger python codebases some places where e.g. support for some s-exp minilanguage could be useful and implemented rather trivially via Hy, or also to embed some processing kernel which is well suited to being written in lispy semantics (e.g. symbolic programming, etc). Another use could be to define core primitives in python and glue them together using a heirarchy of configuration+Hy macros to generate specialized '__main__' programs for task-specific use cases.
  - JasonFruit 7y ago
    That is true; Hy has macros and Python doesn't. Thus "few advantages".
yosefk 7y ago
FP certainly means that you get immutable data structures (and that you don't get or at least don't use mutable data structures, by the definition of FP); Lisp - I dunno, CL has setf (and singly linked lists made of cons cells which can share a tail where you can modify the shared tail when working with of one of the lists and the other will get modified as well). As to a "good" concurrency system, that's a bit harder to define.
wirrbel 7y ago
This is certainly true if you are used to clojure. But interestingly enough, idiomatic common lisp code can be roughly play in the same field as Python in terms of "purity". Also, lot's of scheme code is almost imperative in nature, if you look at it from the perspective of a Clojure or Haskell programmer. This is why Paul Graham once gave the advice to use Python if you cannot use Common Lisp. I think Richard P. Gabriel wrote a "complaint" about functional programming being redefined by the research/types/ML crowd (he wasn't so much complaining about them striving for purer FP, but for taking over the conferences, etc. driving out the more traditional FP traditions from the lisp communities). Anyways, what I wanted to say is: FP is fairly broad as a topic, a lot can fall under it or out of it depending where you draw the line. That's not a bad thing and there is space for mutable lisps. The other aspect is: If you have Python, there is not much to gain from s-expressions alone. sure you get macros, but otherwise you already have a lot of the benefits you get from Lisp over let's say C++ (dynamic typing).
- fhennig 7y ago
  Interesting; functional programming was introduced to me through dr. racket scheme, and the core concept in there was that there is no mutable state. To me, having mutable state makes it imperative, you're not evaluating functions/expressions, you're executing statements that modify a state.
  - fiddlerwoaroof 7y ago
    Racket originally had mutable cons cells but they got rid of them sometime while it still was called MzScheme. One of the reasons they rebranded to Racket was that they no longer implemented scheme as specified.
  - cygx 7y ago
    As I see it, there are two orthogonal roots to functional programming: Mathematical functions on the one hand, and lambda expressions/closure/higher-order functions/... on the other. The former implies immutability and technically belongs to the declarative side of things: A mathematical function declares a relation between input and output, but I say technically because functional code can read rather algorithmic. The latter can be added to imperative languages that do feature mutable state. Depending on the language, I might still classify it as functional, but impure.
nerdponx 7y ago
This is not like the clojure is to java, it's only a syntax transformation, superficial. Python doesn't implement a standard virtual machine. The best you could do is some kind of translation to CPython bytecode, which doesn't really buy you much (and loses compatibility with other Python implementations like PyPy).
coldtea 7y ago
>Usually lisp and FP means that you get immutable data structures and a good concurrency system, both of which you get in clojure. No, Lisp and FP wasn't traditionally tied to "immutable data structures and a good concurrency system". That's something that got in fashion much later (let's say < 15 years ago). In discussion pre-2010 for FP in HN, few mentioned immutability, or "good concurrency" as typical FP traits, if they were even mentioned at all. The same is true for old Paul Graham posts on Lisp. Those were just another tool in the toolbox, not something inherently FP. Haskell wasn't what "FP is really about" either. FP back then was all about first class functions, map/reduce/filter/and co, homoiconicity, code as data, macros, and DSLs.
- UnprovableTruth 7y ago
  Homoiconity, code as data, maros and DSLs aren't FP topics, but Lisp topics. FP has always been about preserving referential transparency when possible. That philosophy is pretty evident in the difference between the more FP oriented Scheme and Lisp. Paul Graham is also a pretty poor example in my opinion. He has traditionally used a very Scheme like Lisp style. In 'On Lisp' he starts off by advising the reader to structure their programs by trying to keep side effects mostly in the outer layer of the program. He's not a FP purist who considers destructive procedures a sin, but he definitely advocated for immutability (just not under that name).
  - coldtea 7y ago
    >Homoiconity, code as data, maros and DSLs aren't FP topics, but Lisp topics. FP discussion outside of the academic context (and especially on HN) before a certain date in the past 1-2 decades were all about Lisp(s) - and to a lesser degree Scheme(s). Doesn't matter whether that was "really FP" (real Scotsman), that what was was discussed, advocated, and practiced by most as "functional programming". ML(s) played very little into the discussion, and purity/immutability was discussed but not as the most important thing (rather as the more pure/mathematical version of FP, but not necessarily practical for professional programming, that came later, and Haskell and then Clojure popularized it).
BeetleB 7y ago
>Usually lisp and FP means that you get immutable data structures and a good concurrency system, both of which you get in clojure. FP, yes. Lisp? No. Lisp data structures are generally mutable, and I don't think concurrency is a key aspect of Lisp (just look at Emacs Lisp for something with much worse concurrency than Python).

JasonFruit 7y ago

Or rather, it isn't useful in production in any way Python is not, and there's little reason to choose a weird stunted Lisp that offers few advantages over its host, an established language with a huge community.

Zak 7y ago
Syntax transformation via macros can be a significant advantage when the semantics of the language don't support an abstraction that's shaped like your problem.
- cat199 7y ago
  totally agree with this. I can see even in larger python codebases some places where e.g. support for some s-exp minilanguage could be useful and implemented rather trivially via Hy, or also to embed some processing kernel which is well suited to being written in lispy semantics (e.g. symbolic programming, etc). Another use could be to define core primitives in python and glue them together using a heirarchy of configuration+Hy macros to generate specialized '__main__' programs for task-specific use cases.
- JasonFruit 7y ago
  That is true; Hy has macros and Python doesn't. Thus "few advantages".

yosefk 7y ago

FP certainly means that you get immutable data structures (and that you don't get or at least don't use mutable data structures, by the definition of FP); Lisp - I dunno, CL has setf (and singly linked lists made of cons cells which can share a tail where you can modify the shared tail when working with of one of the lists and the other will get modified as well). As to a "good" concurrency system, that's a bit harder to define.

wirrbel 7y ago

This is certainly true if you are used to clojure. But interestingly enough, idiomatic common lisp code can be roughly play in the same field as Python in terms of "purity". Also, lot's of scheme code is almost imperative in nature, if you look at it from the perspective of a Clojure or Haskell programmer. This is why Paul Graham once gave the advice to use Python if you cannot use Common Lisp. I think Richard P. Gabriel wrote a "complaint" about functional programming being redefined by the research/types/ML crowd (he wasn't so much complaining about them striving for purer FP, but for taking over the conferences, etc. driving out the more traditional FP traditions from the lisp communities). Anyways, what I wanted to say is: FP is fairly broad as a topic, a lot can fall under it or out of it depending where you draw the line. That's not a bad thing and there is space for mutable lisps. The other aspect is: If you have Python, there is not much to gain from s-expressions alone. sure you get macros, but otherwise you already have a lot of the benefits you get from Lisp over let's say C++ (dynamic typing).

fhennig 7y ago
Interesting; functional programming was introduced to me through dr. racket scheme, and the core concept in there was that there is no mutable state. To me, having mutable state makes it imperative, you're not evaluating functions/expressions, you're executing statements that modify a state.
- fiddlerwoaroof 7y ago
  Racket originally had mutable cons cells but they got rid of them sometime while it still was called MzScheme. One of the reasons they rebranded to Racket was that they no longer implemented scheme as specified.
- cygx 7y ago
  As I see it, there are two orthogonal roots to functional programming: Mathematical functions on the one hand, and lambda expressions/closure/higher-order functions/... on the other. The former implies immutability and technically belongs to the declarative side of things: A mathematical function declares a relation between input and output, but I say technically because functional code can read rather algorithmic. The latter can be added to imperative languages that do feature mutable state. Depending on the language, I might still classify it as functional, but impure.

nerdponx 7y ago

This is not like the clojure is to java, it's only a syntax transformation, superficial. Python doesn't implement a standard virtual machine. The best you could do is some kind of translation to CPython bytecode, which doesn't really buy you much (and loses compatibility with other Python implementations like PyPy).

coldtea 7y ago

>Usually lisp and FP means that you get immutable data structures and a good concurrency system, both of which you get in clojure. No, Lisp and FP wasn't traditionally tied to "immutable data structures and a good concurrency system". That's something that got in fashion much later (let's say < 15 years ago). In discussion pre-2010 for FP in HN, few mentioned immutability, or "good concurrency" as typical FP traits, if they were even mentioned at all. The same is true for old Paul Graham posts on Lisp. Those were just another tool in the toolbox, not something inherently FP. Haskell wasn't what "FP is really about" either. FP back then was all about first class functions, map/reduce/filter/and co, homoiconicity, code as data, macros, and DSLs.

UnprovableTruth 7y ago
Homoiconity, code as data, maros and DSLs aren't FP topics, but Lisp topics. FP has always been about preserving referential transparency when possible. That philosophy is pretty evident in the difference between the more FP oriented Scheme and Lisp. Paul Graham is also a pretty poor example in my opinion. He has traditionally used a very Scheme like Lisp style. In 'On Lisp' he starts off by advising the reader to structure their programs by trying to keep side effects mostly in the outer layer of the program. He's not a FP purist who considers destructive procedures a sin, but he definitely advocated for immutability (just not under that name).
- coldtea 7y ago
  >Homoiconity, code as data, maros and DSLs aren't FP topics, but Lisp topics. FP discussion outside of the academic context (and especially on HN) before a certain date in the past 1-2 decades were all about Lisp(s) - and to a lesser degree Scheme(s). Doesn't matter whether that was "really FP" (real Scotsman), that what was was discussed, advocated, and practiced by most as "functional programming". ML(s) played very little into the discussion, and purity/immutability was discussed but not as the most important thing (rather as the more pure/mathematical version of FP, but not necessarily practical for professional programming, that came later, and Haskell and then Clojure popularized it).

BeetleB 7y ago

>Usually lisp and FP means that you get immutable data structures and a good concurrency system, both of which you get in clojure. FP, yes. Lisp? No. Lisp data structures are generally mutable, and I don't think concurrency is a key aspect of Lisp (just look at Emacs Lisp for something with much worse concurrency than Python).