Live data from Hacker News

Why I am excited about Clojure

blog.txus.io

131–140 of 173 posts

Re: Why I am excited about Clojure

#131

Earlier quoted context omitted.

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?

Not quite what you asked, but I found people recommending this.

https://github.com/ninjudd/drip

Re: Why I am excited about Clojure

#132
post #87
post #76

Earlier quoted context omitted.

I agree, though one has to compare apples and apples. experienced programmer vs inexperienced programmer is not fair. Of course if one is unfamiliar with how to build a flexible type safe systems, (newbies), there could be these sorts of issues. But for experienced programmers, not really.

though one has to compare apples and apples. experienced programmer vs inexperienced programmer is not fair. Oh, definitely. I just feel that far too many people focus on programming languages that are good for beginners without really thinking about them from an experienced programmer's perspective. What may be good for a beginner can often be terrible for an expert. What may be hard to understand for a beginner can…

I could argue that for most people, it is only when they start bumping into the limits of the beginner's tool that they see the point of the more advanced tool.

Re: Why I am excited about Clojure

#133

Earlier quoted context omitted.

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,…

> 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.

In a production server I'm running right now, I've used three java libs, wrapped them very nicely and neatly, and they work great.

> 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.

For my current app, I just need to do: lein ring uberwar, copy to tomcat directory. done.

The rest I can't speak towards as I don't know Haskell. Also, it should be noted, I'm only offering counterpoints because I don't want people to not use clojure because of some of the incorrect claims. I guess we've had different experiences with clojure. :)

Re: Why I am excited about Clojure

#134
> When I start using a language, there are usually some situations where I can't understand why my code isn't doing what I expect it to do. When that happens to me in a language like JavaScript, for example, finding out what the problem was is generally a very frustrating experience

This is a very weird paragraph to me because I've experienced the exact opposite. You can see my frustration in this stack overflow question I titled "How do I get better feedback from Clojure errors?": http://stackoverflow.com/questions/16901836/how-do-i-get-bet...

While I agree that JavaScript has tons of "Wat" quirks that shouldn't be there, I rarely run into them. And more importantly, when I get errors in JavaScript, the cause is relatively easy to track down.

With Clojure on the other hand, it is really difficult for me to figure out why I'm getting the error. Yes, I get the error because I "was doing it wrong", but the errors don't help me figure out what I was doing wrong.

-------------

> With Clojure your editor (be it Vim, Emacs, Light Table...) is permanently connected to a live REPL. You continually develop, test and modify functions with subsecond feedback. Continuously. All the cores in your brain are lit, as you have literally no time to think about anything else. That's not only deeply satisfying, but also leads you to certain thought paths that slow feedback and its inevitable lower focus would have simply blocked. That's one of my favorite parts of Clojure.

This is very useful when you're writing new code, but I found myself scratching my head when I had to go back and modify already existing code to add a feature. As a workflow, I don't "get" when/how you're supposed to add automated tests when you're using REPL driven development. But, once I went back to my code, I always wished they were there.

You see, I'd modify the code and break something and then the problem I described above made fixing it very time consuming. Usually the cause of my problem was my simple functions wouldn't integrate together the way I expected. The REPL gave me the quick feedback to say that "increment-number" worked, but I would accidentally pass in a String or a vector into the function.

Re: Why I am excited about Clojure

#135
post #87

Earlier quoted context omitted.

though one has to compare apples and apples. experienced programmer vs inexperienced programmer is not fair. Oh, definitely. I just feel that far too many people focus on programming languages that are good for beginners without really thinking about them from an experienced programmer's perspective. What may be good for a beginner can often be terrible for an expert. What may be hard to understand for a beginner can…

I could argue that for most people, it is only when they start bumping into the limits of the beginner's tool that they see the point of the more advanced tool.

I think this is a very limiting approach to life. It leaves one open to the Blub Paradox[0] (or more generally the Dunning-Kruger effect[1]). My personal approach is to keep an open mind and assume that there's always a better way to do something than what I am doing now.

Edit:

[0] http://www.c2.com/cgi/wiki?BlubParadox

[1] http://en.wikipedia.org/wiki/Dunning-kruger_effect

Re: Why I am excited about Clojure

#136
post #134

> When I start using a language, there are usually some situations where I can't understand why my code isn't doing what I expect it to do. When that happens to me in a language like JavaScript, for example, finding out what the problem was is generally a very frustrating experience This is a very weird paragraph to me because I've experienced the exact opposite. You can see my frustration in this stack overflow ques…

I've done a lot of Clojure. For iterative/REPL-driven development I find Haskell a lot more pleasant. The types drive how I think, provide way-way-way better feedback on mistakes, and provide a new modality for querying my code in the REPL.

As a bonus, the UX to ghci is better than using nrepl/cider in Emacs. Reload "just works" and works more quickly than reloading namespaces in Clojure. I was gobsmacked when I saw how much better ":r" worked in ghci than reloading in the Clojure REPL.

Re: Why I am excited about Clojure

#137
post #84

Earlier quoted context omitted.

I'm a C# guy at work too. I can't say I've touched much C++ outside of college also a while ago, but I've been studying functional programming for a while and really enjoying the new concepts it teaches. It can be a bit humbling at times though. I got some good perspective with https://www.coursera.org/course/proglang and you could do worse than taking grossman's excellent course. It helps to have some structure and…

For some reason the Programming Languages class is offline now.

That sucks, sometimes the just let you watch all the videos even if the course isn't running. Wonder why different courses have different policies

Re: Why I am excited about Clojure

#138
post #134

> When I start using a language, there are usually some situations where I can't understand why my code isn't doing what I expect it to do. When that happens to me in a language like JavaScript, for example, finding out what the problem was is generally a very frustrating experience This is a very weird paragraph to me because I've experienced the exact opposite. You can see my frustration in this stack overflow ques…

I have been working in both clojure and javascript for a while. When I encounter bugs in javascript assuming it does not crash, it can become difficult to track down the source due to the lack of name-spacing, mutability of variables that allow for race conditions, and unintended changes upstream if you're not careful.

Where as in clojure, the scope of name spaces is generally smaller, while the errors are more cryptic, I agree. The line number that it points you to and use of the repl allows one to dissect the function in great detail and by checking the incoming data and outgoing data, the bug becomes much clear. At least in my experience.

Re: Why I am excited about Clojure

#139
post #78

Earlier quoted context omitted.

Which kind of libraries are you thinking of that are missing?

imap library with idle support. haskellnet and imapget don't mention idle from what I can see. javamail does.

haskellnet looks like it does polling, but i gather its not quite the same thing. looks like you're right. I wonder how hard it would be to implement such a thing.

Re: Why I am excited about Clojure

#140
post #138
post #134

> When I start using a language, there are usually some situations where I can't understand why my code isn't doing what I expect it to do. When that happens to me in a language like JavaScript, for example, finding out what the problem was is generally a very frustrating experience This is a very weird paragraph to me because I've experienced the exact opposite. You can see my frustration in this stack overflow ques…

I have been working in both clojure and javascript for a while. When I encounter bugs in javascript assuming it does not crash, it can become difficult to track down the source due to the lack of name-spacing, mutability of variables that allow for race conditions, and unintended changes upstream if you're not careful. Where as in clojure, the scope of name spaces is generally smaller, while the errors are more crypt…

shrug Just different experiences I guess. I should note this isn't exactly an apples to apples comparison. I am using a lot of discipline in my JS project. I'm writing the code test-first most of the time, and I only have one global variable in the whole project.
Post reply on HN