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

Why I am excited about Clojure

blog.txus.io

Post reply on HN
Print view View original

111–120 of 173 posts

Re: Why I am excited about Clojure

#111

Post by zck »

seacious wrote: post #44
astine wrote: post #34

Earlier quoted context omitted.

That's the neat thing about Lisp-style macros. You have to sacrifice a little bit of the syntactical sugar that you are used to in most languages, but in return you have the ability to add almost any possible construct to the language natively. It makes it much easier to extend the language as you don't need to hack an interpreter written in C or Java. Half of the core language is already written in macros.

Not having to memorize an operator precedence table makes me more than willing to give up syntactic sugar. This is one of the things that I dislike most about haskell. I wish liskell or one of the other projects trying to bring S-expressions to haskell had taken off.

There's a common complaint in this thread that is basically "just write your code better, then it'll be readable." There's also a common praise of Haskell that says that its type system eliminates entire classes of errors. It's not accepted by people who use Haskell that "if you use another language and just write your code better, you don't need a type system."

Having to explicitly indicate the precedence of operators -- as in Lisp's prefix notation -- completely eliminates precedence errors, both in writing and in reading. This is true even though "well-written"^1 code using implicit infix notation is readable.

[1] Note also that the level of implicit precedence that you're comfortable with might be different from mine.

Re: Why I am excited about Clojure

#112

Post by rossjudson »

wtetzner wrote: post #65
jhh wrote: post #40

Earlier quoted context omitted.

I'll try to dispel some of the concerns about Clojure. 1) Stacktraces in JVM may be ugly, but the amount of insight into runtime issues that the JVM offers you is generally way higher than in runtimes like cpython or MRI. 2) Clojure gives you a rather elegant way to work with the different JVM number types as it offers literals for those. I think Java Longs (the integer default) should be long enough as it's a 64 bit…

One thing I've noticed is that the JVM startup time is actually pretty small. What's slow is waiting for Clojure to bootstrap itself.

Detailed discussion on startup times at http://nicholaskariniemi.github.io/2014/02/11/jvm-slow-start... (and subsequent articles by the same author).

Re: Why I am excited about Clojure

#113

Post by astine »

DigitalJack wrote: post #95
astine wrote: post #14

That last feature is certainly one of my favorite parts about Clojure. It's one of my favorite parts about Lisps in general actually, but Clojure has a very good handle on it. Having to compile a program before seeing if the changes you made work can be a nuisance. Interpreted programs are slightly better, but being able to make micro-changes to a running instance of a program and seeing in real-time how it affects t…

I admit to still not understanding what goes on with function definitions in clojure, but this idea of just making a micro change in clojure and evaling that and seeing the real time effects never seems to pan out for me. I do lots of small functions that build on each other. If I make a change to one of the base functions, the higher functions seem to hold a reference to the old definition and I end up having to re-…

If macros are used properly, they should make the code easier to read, not harder. If you can't figure out what it does from it's signature and docstring (maybe with a reference to some documentation for more complex or abstract things,) there's a problem. You shouldn't have to read a macro's definition to be able to use it.

Also, redefining a function should cause every function which directly references it to use the new version. You can sometimes run into issues if the functions are defined in separate namespaces or if the redefined function was passed to the other as a higher order function during the latter's definition.

If it's a macro you're redefining, yes you'll have to redefine functions which depend on it, but you should be defining too many macros.

Re: Why I am excited about Clojure

#114

Post by mduerksen »

wtetzner wrote: post #65
jhh wrote: post #40

Earlier quoted context omitted.

I'll try to dispel some of the concerns about Clojure. 1) Stacktraces in JVM may be ugly, but the amount of insight into runtime issues that the JVM offers you is generally way higher than in runtimes like cpython or MRI. 2) Clojure gives you a rather elegant way to work with the different JVM number types as it offers literals for those. I think Java Longs (the integer default) should be long enough as it's a 64 bit…

One thing I've noticed is that the JVM startup time is actually pretty small. What's slow is waiting for Clojure to bootstrap itself.

JVM Feature Request: The ability to preserve a complete JVM state (in this case with loaded Clojure stuff) and quickly start from there.

Does anybody know if something like that is possible/already exists?

Re: Why I am excited about Clojure

#115

Post by Totient »

Clojure feels like a 'compromise' Haskell, but I mean that in a good way. Haskell really wants to pretend that everything is a pure function. But I think this is a case where the conceptually simpler thing (i.e. no state) is just too hard to reason about.

Clojure backs off the 'referential transparency ONLY' philosophy, and merely discourages mutability. In my (limited) experience, this gives almost all of the advantages of Haskell, but an environment that's easier to program in.

So yeah, I'm excited about Clojure too. I just wish we could port it off the JVM...

Re: Why I am excited about Clojure

#116

Post by dllthomas »

astine wrote: post #113
DigitalJack wrote: post #95

Earlier quoted context omitted.

I admit to still not understanding what goes on with function definitions in clojure, but this idea of just making a micro change in clojure and evaling that and seeing the real time effects never seems to pan out for me. I do lots of small functions that build on each other. If I make a change to one of the base functions, the higher functions seem to hold a reference to the old definition and I end up having to re-…

If macros are used properly, they should make the code easier to read, not harder. If you can't figure out what it does from it's signature and docstring (maybe with a reference to some documentation for more complex or abstract things,) there's a problem. You shouldn't have to read a macro's definition to be able to use it. Also, redefining a function should cause every function which directly references it to use t…

"If macros are used properly, they should make the code easier to read, not harder."

Well, I think macros often play the role of jargon. They let you spell out a particular concept succinctly and precisely and make the whole much easier to follow once you are familiar with the jargon, but people unfamiliar won't fully understand.

Much like jargon in spoken language in any field it can be picked such that those otherwise familiar with the language draw conclusions (that are hopefully correct), or picked so that they recognize that they are unable to draw substantial conclusions (which may be incorrect). There are upsides and downsides to both approaches (which isn't to say one doesn't dominate, but from my limited perspective it's not clear).

I should note that, to some extent, this is true of most kinds of abstraction.

Re: Why I am excited about Clojure

#118

Post by yogsototh »

erichmond wrote: post #64
yogsototh wrote: post #47

Earlier quoted context omitted.

So the two languages have all their strength and weaknesses. I start with Haskell, and I try Clojure, time to time. After working a while, I finally give a clear advantage to Haskell. Yes, Math people are chatty in Haskell, but you can do _a lot_ with very few Math. In fact, with Haskell, the more your project growth, the more time you spend on interesting things. While in Clojure (and most dynamic languages), you'll…

I'm curious how Haskell could be a clear winner for production code, particularly as it pertains to efficiency and time. Clojure sits on top of the JVM, and as such, has the benefit of interop with some of the most robust software packages in the world. Unless I'm missing something, you'd need to roll your own packages in Haskell for all this functionality. I would argue that the most efficient code is well maintaine…

One of little secret of Clojure is that you almost never use Java based library. Because it forces you not to use idiomatic Clojure. So, most library you'll use in Clojure are in fact Clojure made. From this point of view of number of libraries, Haskell and Clojure are in fact at the same level.

I was sold in part by the JVM argument. But in reality, in practice, I found it to be more a burden than a delight. First, the stack trace errors. To deploy your application, it is not just a "copy your jar in Tomcat". You have to serve using Clojure. So in reality, you don't get all advantages provided by the JVM environment, only some.

Clojure is fast, but, Haskell is at least as fast as Clojure.

Up until here, I had all packages I needed. There are all here[1]. I made mostly Web oriented programming, but using MongoDB worked extremely well for example.

And the most important aspect (from my experience):

When your program growth, in Clojure the time you spend to add another feature growth rapidly (it is better in clojure than most other languages thought), but in Haskell, each new feature doesn't cost so much, even in a medium to big project.

So when you need to change something fast without breaking something (the without breaking something is the important part), nothing beat the Haskell type system (or may be Idris, but I didn't played with it enough).

Furthermore, the ability to minimize the number of bugs, gives me a good feeling about the quality of the libraries. Of course, Haskell is not magic, you still have to pay attention to bugs, to test your code. But Haskell helps a lot in not falling into dumb bugs.

[1]: http://hackage.haskell.org

Re: Why I am excited about Clojure

#119

Post by guiomie »

eronhp wrote: post #59
guiomie wrote: post #55

I'm a C# guy at work, I also do some front-end in javascript (with angularjs sometimes). For side-projects I like to use node.js. I want to learn another language, and I've been wondering wether I should go with Clojure or C++ ? My dilenma is "Do I want to learn more about programming style running on VMs (functional) or do I want to dive into barebone high performance code ?" I've done C and Java at university, but…

Did you take a look at F#?

Yes, but I'd like to get off the CLR.

Re: Why I am excited about Clojure

#120

Post by hibikir »

the_watcher wrote: post #66
dopamean wrote: post #2

What is it about Clojure that Rubyists love? I am a Rubyist who is new to Clojure (I love it) and I cant explain it myself. Clojure was suggested to me by several other Rubyists. I find myself suggesting it to other Rubyists as well....

I remember reading one of PG's essays about Lisp being the most powerful language, and he made a list of characteristics defending his position. He implied that the new languages that are becoming popular simply move closer to being a Lisp. My guess is that Clojure is the Lisp that emerges most directly from someone who learned about languages from Ruby. I've only ever hacked with Ruby, if I can find a good intro ser…

Lisp has a lot of strengths, don't get me wrong. But it is an ancient language, and despite its age, it never managed to catch on in a big way. It is true that many more popular languages keep stealing Lisp concepts, but that doesn't tell me that Lisp is amazing, but that despite all of its strengths, it must have some terrible weakness that makes it relatively uncompetitive in the general programming population.

My opinion is that it crosses a syntactic threshold of abstraction, after which a language just loses. s-expressions are extremely powerful, but also the language's Achilles heel.

This resembles how there is a 'happy medium' for writing human languages. We could write all of our text in morse code, but we don't. We know that too many glyphs, like in Chinese, slow down learning too, as the effort to remember them all takes lots of practice.

So just like Scalaz's operators are so arcane that us mere mortals are better served by using words instead of , a world of s-expressions makes it harder to find your way precisely because of excessive syntax homogeneity.

Still, I think Lisps are worth learning, it's just that I think the ideal language steals much from Lisp, including most of what s expressions are used for in practice, but it doesn't go all the way.

Post reply on HN