Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ferret – A free software Clojure implementation

ferret-lang.org

Post reply on HN
Print view View original

61–70 of 83 posts

Re: Ferret – A free software Clojure implementation

#61

Post by vertex-four »

nakkaya wrote: post #48
zaszrespawned wrote: post #36

The favicon.ico of this site - looks exactly like half life logo. http://ferret-lang.org/ferret-styles/favicon.ico https://www.google.co.in/search?q=half+life+logo&oq=half+lif... What is that all about...

Author here. It is the Half-Life logo. I wanted a lambda symbol for a favicon, love the game too so I settled on a open licensed logo.

I'll point out that the Half-Life logo is trademarked in the EU in several situations related to video games, including the programming of video games. Be careful attaching it to e.g. a tutorial on using Ferret to write a game, or an integration with a game engine, etc.

Re: Ferret – A free software Clojure implementation

#62

Post by vanderZwan »

I wonder if it could also somehow lift the reactive synchronous concurrency bits from Céu[0] in a library. Céu is probably my favourite embeddded language to program in from a "thinking about concurrency" perspective. I'm not sure how one would go about it though, since Céu is imperative, and I'm not sure if that imperative aspect is fundamental to its type of concurrency or if it clashes with idiomatic Clojure.

If it would be possible you'd probably have everything I could want in one embedded language.

[0] http://www.ceu-lang.org/

Re: Ferret – A free software Clojure implementation

#63

Post by penpapersw »

vturner wrote: post #54
penpapersw wrote: post #35

Having written Clojure full-time for the past 5 years while writing cleancoders.com has really spoiled me. Clojure's introspective nature makes for some amazingly fast productivity because you can hook up your IDE to the REPL and have a kind of super-REPL, which can really speed up development a ton if you design your system it right. I'm not sure if this project can keep that aspect because of how it compiles to C++…

Curious what IDE you have set up to do the REPL driven development you mentioned? I'm just starting out in learning Clojure and am finding various options out there with vigorous proponents of each. I am wondering what someone's real-world experience is after 5 years. It's hard sometimes to find the editors/IDEs that might suite one particularly well since the vast community is attached to a given platform.

Emacs + CIDER. It's extraordinarily fast, if you're willing to get used to Emacs :)

Re: Ferret – A free software Clojure implementation

#64

Post by swlkr »

vturner wrote: post #54
penpapersw wrote: post #35

Having written Clojure full-time for the past 5 years while writing cleancoders.com has really spoiled me. Clojure's introspective nature makes for some amazingly fast productivity because you can hook up your IDE to the REPL and have a kind of super-REPL, which can really speed up development a ton if you design your system it right. I'm not sure if this project can keep that aspect because of how it compiles to C++…

Curious what IDE you have set up to do the REPL driven development you mentioned? I'm just starting out in learning Clojure and am finding various options out there with vigorous proponents of each. I am wondering what someone's real-world experience is after 5 years. It's hard sometimes to find the editors/IDEs that might suite one particularly well since the vast community is attached to a given platform.

I use IntelliJ with Cursive, I have had to do zero configuration, it just works with lein projects.

I will eventually switch to Spacemacs and CIDER once I've really honed my Clojure skills, but for starting out Cursive was what allowed me to learn Clojure in the first place.

Re: Ferret – A free software Clojure implementation

#65

Post by kbp »

christophilus wrote: post #5
gleenn wrote: post #2

Seems like a cool project if you already know Clojure and hate the start up time, but also seems like it sidesteps one of the main benefits of Clojure which is Java interop obviously... Which Clojure has to do a fair number of handsprings to accomplish. Begs the question, why pick Clojure as the lisp to compile to C++? Why not Racket or Common Lisp etc?

I like Clojure for its encouragement of functional, immutable-first programming. That, and I find its syntax for function parameters, data-structure literals, etc to be preferable.

Why not Racket? It has a similar emphasis on immutable, functional programming, it's also a Lisp-1 (I assume that's what you mean by "syntax for function parameters"), and the different syntax for data-structure literals I have to imagine is a pretty minor point.

Re: Ferret – A free software Clojure implementation

#66

Post by gizmo385 »

chipset wrote: post #32
jzelinskie wrote: post #17

Earlier quoted context omitted.

Aren't most of these environments low on memory and thus it doesn't really make sense for them to use Clojure's persistent data structures? Kinda related is this awesome paper: https://blog.acolyer.org/2015/11/27/hamt/

I'm not sure how it's implemented in Ferret but Clojure's data structures are implemented as trees so there's structural sharing that happens when a vector or hash map is updated or when a new version is produced. So the whole data structure isn't copied but only the relevant parts are added / updated in the tree and the rest is shared with the "new" data structure. Mutable data structures are still more memory effec…

It's so interesting watching Rich talk. He has such a breadth and depth of knowledge and you can tell that he really took his time when designing the language.

Re: Ferret – A free software Clojure implementation

#67

Post by lispm »

kazinator wrote: post #25
gleenn wrote: post #2

Seems like a cool project if you already know Clojure and hate the start up time, but also seems like it sidesteps one of the main benefits of Clojure which is Java interop obviously... Which Clojure has to do a fair number of handsprings to accomplish. Begs the question, why pick Clojure as the lisp to compile to C++? Why not Racket or Common Lisp etc?

The relationship with Java is both a benefit and a disadvantage of Clojure. > Why not Racket or Common Lisp etc? These already have solutions in the compilation space. Kyoto Common Lisp (KCL), a fairly old implementation tracing back to the 1980's, and its descendant GNU Common Lisp (GCL) compile to C. Embeddable Common Lisp (ECL) also contains a Lisp to C compiler. Of course, numerous CL implementations compile to n…

Btw: ECL is also a descendant of KCL. Like AKCL, MKCL, Delphi CL, Ibuki CL, GCL.

Other Lisp-to-C compilers like CLICC, mocl, Thinlisp, and a few others are not descendants of KCL.

Re: Ferret – A free software Clojure implementation

#68

Post by dkersten »

vturner wrote: post #54
penpapersw wrote: post #35

Having written Clojure full-time for the past 5 years while writing cleancoders.com has really spoiled me. Clojure's introspective nature makes for some amazingly fast productivity because you can hook up your IDE to the REPL and have a kind of super-REPL, which can really speed up development a ton if you design your system it right. I'm not sure if this project can keep that aspect because of how it compiles to C++…

Curious what IDE you have set up to do the REPL driven development you mentioned? I'm just starting out in learning Clojure and am finding various options out there with vigorous proponents of each. I am wondering what someone's real-world experience is after 5 years. It's hard sometimes to find the editors/IDEs that might suite one particularly well since the vast community is attached to a given platform.

So far I've used vim, neovim, cursive and spacemacs and all have solid repl integration. I am generally a vim/neovim user and have been using that for years. It's good. Recently, I've been using spacemacs and like it better. Cursive is pretty solid too though if you're an IntelliJ user.

Re: Ferret – A free software Clojure implementation

#69

Post by dkersten »

e12e wrote: post #58
nakkaya wrote: post #50

Earlier quoted context omitted.

Author here. I am actually curious about this myself. I originally released it under GPL but then on another HN thread someone said anything compiled with it also ends up being GPL, so I switched to BSD 2 Clause. I have not copy pasted code from Clojure compiler BUT in order to keep the Ferret semantics the same as Clojure semantics algorithms are identical. [1] shows + function in Ferret and Clojure. As for data str…

Nothing wrong with BSD - but as for a GPL compiler with a run-time, you could also look at the GCC/GNU libc licensing (GPL/LGPG). I do think it's important people are aware that GPL on things with a run-time should probably have an exception/use something like the LGPL - as you generally don't want "documents"/artifacts produced with a tool, to forcefully inherit the license of the tool used for creating them (eg: Yo…

LGPL isn't enough for a runtime unless your entire runtime is dynamically linked. Either GPL or LGPL with runtime exception works fine though (that's what libc and others have, I believe).

That is, they added an exception saying that if you use it in a certain way (unmodified, runtime for compiled code), then it's exempt from many of the GPL's clauses. Used in any other way, however, and you must comply with the (L)GPL

Re: Ferret – A free software Clojure implementation

#70

Post by rrix2 »

nakkaya wrote: post #50
dantiberian wrote: post #22

Does anyone have any insight on the legal status of this project? It’s licensed as BSD 2 Clause, but looks to be heavily derived from Clojure which is EPL. AFAIK the EPL is copyleft and doesn’t permit relicensing without the copyright holders’ permission.

Author here. I am actually curious about this myself. I originally released it under GPL but then on another HN thread someone said anything compiled with it also ends up being GPL, so I switched to BSD 2 Clause. I have not copy pasted code from Clojure compiler BUT in order to keep the Ferret semantics the same as Clojure semantics algorithms are identical. [1] shows + function in Ferret and Clojure. As for data str…

I'm not a lawyer but my understanding is that copying semantics could still be argued as creating a derivative work. This is what e.g. Whisper Systems claimed before publishing an axolotl spec, that anyone implementing the spec was doing so by deducing the semantic meaning of a copyleft piece of software and thus was a derivative work of said copyleft piece of software. This meant that the resulting binary was covered under the copyleft license (GPLv3 in that case, but my understanding of EPL is similar) https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7

I don't know if Rich or the other Clojure copyright holders care enough to ever make trouble, but I'm pretty sure most companies with a decent legal team would think thrice before offering a piece of code built using Ferret

GCC has already solved the problem the other commenter you mention brings up with the runtime library exception https://www.gnu.org/licenses/gcc-exception-faq.html but I don't know if you can tack this on to the clojure-derived parts of ferret. I sure wish SFLC or someone was able to do legal counselling for new/small projects like this, I feel like a big reason people shy away from copyleft isn't the hippie dippie bullshit but because these interactions are impossible to reason about by laypersons

Post reply on HN