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

Clojure: A Lisp that wants to spread

simongray.github.io

Post reply on HN
Print view View original

131–140 of 306 posts

Re: Clojure: A Lisp that wants to spread

#131

Post by billfruit »

tensor wrote: post #26

Startup time isn't what is holding the language back. In my opinion it's: 1. Tooling. You end up spending way more time getting your tooling setup than it should be. 2. Difficulty in learning. 3. Clear best practices and frameworks. The philosophy of composing libraries is extremely powerful, but to gain broader adoption you still need straight forward frameworks and opinionated best practices. The last point has man…

And poor tooling support on MS Windows. Leiningen does not even have a proper installer on Windows, last time I checked.

Having leiningen not bundled into the clojure distribution, is in strong contrast to the "batteries included" approach of python.

There were also complexities in including local jars into projects, as it required setting up a local maven repository, which is tedious job.

Also when exeptions occur clojure does not give an interactive repl like other lisps.

Re: Clojure: A Lisp that wants to spread

#132

Post by iLemming »

svnpenn wrote: post #35

The situation with windows is weird. You have to run a powershell script to install. They should just offer a Zip or Exe like every other programming language. https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Wind...

> The situation with windows is weird.

Isn't it always? Basically anything that's not related to .NET has its warts in Windows. Erlang for example.

Re: Clojure: A Lisp that wants to spread

#133

Post by patrec »

ska wrote: post #29
lgessler wrote: post #28

Earlier quoted context omitted.

In the abstract you're right that equality is subtle and complicated, but it seems to me that in practice, most practicing software engineers just want value-equality on garden-variety data structures most of the time (remember == for Strings in Java?), and that for this use-case, a leaky abstraction is fine--preferable, even. At least, the alternative--forcing users to consider the subtleties of equality even in cir…

I'm not really saying any of those choices is wrong (although clearly you can make design mistakes that make the leaks problematic, if you pick (c)). It's more that none of them are clearly right. Really I'm rejecting the idea that that equality as presented in CL was any of: wrong, design by committee, or something we have learned do better since '84. There are historical artifacts in CL that aren't great (cf filesy…

Yeah, equalp is a really useful abstraction. Deep equality mashed together with case-folding. Something I've always wanted.

Re: Clojure: A Lisp that wants to spread

#134

Post by ivan4th »

codr7 wrote: post #55
armitron wrote: post #22

Earlier quoted context omitted.

Many lisp fans do in fact use Common Lisp. Freenode #lisp, the term Lisp, Reddit lisp all primarily refer to and are about Common Lisp. Additionally, there are many Lisp old timers that do not consider Clojure a Lisp.

I'm curious, what features are missing that stops Clojure from being considered a proper Lisp? From my brief experience it can do most of the same things except reader macros.

While this is not directly related to being a proper Lisp, one of the reasons (not the only one, of course) some people may prefer CL is CLOS.

Re: Clojure: A Lisp that wants to spread

#135

Post by patrec »

patrec wrote: post #133
ska wrote: post #29

Earlier quoted context omitted.

I'm not really saying any of those choices is wrong (although clearly you can make design mistakes that make the leaks problematic, if you pick (c)). It's more that none of them are clearly right. Really I'm rejecting the idea that that equality as presented in CL was any of: wrong, design by committee, or something we have learned do better since '84. There are historical artifacts in CL that aren't great (cf filesy…

Yeah, equalp is a really useful abstraction. Deep equality mashed together with case-folding. Something I've always wanted.

Of course in the rare cases I want deep equality without case (and number) folding, I can always implement it myself using... ooops!

Re: Clojure: A Lisp that wants to spread

#136

Post by stingraycharles »

billfruit wrote: post #131
tensor wrote: post #26

Startup time isn't what is holding the language back. In my opinion it's: 1. Tooling. You end up spending way more time getting your tooling setup than it should be. 2. Difficulty in learning. 3. Clear best practices and frameworks. The philosophy of composing libraries is extremely powerful, but to gain broader adoption you still need straight forward frameworks and opinionated best practices. The last point has man…

And poor tooling support on MS Windows. Leiningen does not even have a proper installer on Windows, last time I checked. Having leiningen not bundled into the clojure distribution, is in strong contrast to the "batteries included" approach of python. There were also complexities in including local jars into projects, as it required setting up a local maven repository, which is tedious job. Also when exeptions occur c…

> Having leiningen not bundled into the clojure distribution, is in strong contrast to the "batteries included" approach of python.

The problem is that Cognitect (the company behind Clojure) don’t use Leiningen themselves, and instead have released their own tool called deps.edn.

This has only fragmented the community even further, making it even more difficult for newcomers, with questionable benefits.

Re: Clojure: A Lisp that wants to spread

#137

Post by didibus »

iLemming wrote: post #130
didibus wrote: post #89

Earlier quoted context omitted.

So, my first answer is that you shouldn't have too, and if you do, you might not be writing proper Clojure code. The most fundamental concept in Clojure, from the famous Rich Hickey talk Simple Made Easy ( https://www.infoq.com/presentations/Simple-Made-Easy/ ) is that your code should strive to be decomplected. That means that your program should be made of parts that when modified do not break anything else. This,…

> Prefer functions which take their input as separate parameters. In practice, it's better to avoid positional arguments and extensively use maps and destructuring. Of course, there's a risk of not properly passing a key in the map, but in practice that doesn't happen too often. Besides - Spec, Orchestra, tests and linters help to mitigate that risk.

> In practice, it's better to avoid positional arguments and extensively use maps and destructuring

We can agree to disagree I guess. In my experience, especially in the context of refactoring, extensive use of maps as arguments causes quite a lot of problems. Linters also do nothing for that.

Positional arguments have the benefit of being compile errors if called with wrong arity. I actually consider extensive use of maps a Clojure anti-pattern personally. Especially if you go with the style of having all your functions take a map and return a map. Now, sometimes, this is a great pattern, but one needs to be careful not to abuse it. Certain use case and scenarios benefit from this pattern, especially when the usage will be a clear data-flow of transforms over the map. If done too much though, all over the app, for everything, and especially when a function takes a map and passes it down the stack, I think it becomes an anti-pattern.

If you look at Clojure's core APIs for example, you'll see maps as arguments are only used for options. Performance is another consideration for this.

Doesn't mean you should always go positional, if you have a function taking too many arguments, or easy to mix up args, you probably want to go with named parameters instead.

Re: Clojure: A Lisp that wants to spread

#138

Post by stingraycharles »

_fbpt wrote: post #65
rubyn00bie wrote: post #7

Earlier quoted context omitted.

For anyone else wondering, "holy crap, WTF does -client do?" here you go: https://stackoverflow.com/a/198651/931209 And to save folks a click: > The Client VM compiler does not try to execute many of the more complex optimizations performed by the compiler in the Server VM, but in exchange, it requires less time to analyze and compile a piece of code. This means the Client VM can start up faster and requires a smalle…

> A 64-bit capable JDK currently ignores this option and instead uses the Java Hotspot Server VM.

This is an extremely important detail, as I expect pretty much everyone to run the 64bit version of the JVM.

Re: Clojure: A Lisp that wants to spread

#139

Post by pjmlp »

iLemming wrote: post #132
svnpenn wrote: post #35

The situation with windows is weird. You have to run a powershell script to install. They should just offer a Zip or Exe like every other programming language. https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Wind...

> The situation with windows is weird. Isn't it always? Basically anything that's not related to .NET has its warts in Windows. Erlang for example.

Delphi, Python, Ruby, C++, Qt, Perl, nodejs, Java, Pharo/Smalltalk, Eiffel, Common Lisp, Ada do pretty well on Windows, without being .NET related.

Re: Clojure: A Lisp that wants to spread

#140

Post by pjmlp »

peatmoss wrote: post #19
gentleman11 wrote: post #8

Why don’t lisp fans use older lisp implementations like Common Lisp or scheme? Is it just a lack of libraries and frameworks?

Some of it is libraries and frameworks. Some of it is the attention Clojure has paid to ergonomics. A lot of Clojure’s libraries seem to have been built by smart people for mediocre programmers (like me!). Elsewhere in lisp land it can feel like smart people wrote libraries for themselves. For me Racket is probably the closest thing to a decent end-to-end modern lisp experience with decent libraries outside Clojure.…

> decent end-to-end modern lisp experience with decent libraries outside Clojure

Those are still LispWorks and Allegro Common Lisp.

Post reply on HN