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

Clojure will affect the way you think about programming

eli.thegreenplace.net

Post reply on HN
Print view View original

81–90 of 226 posts

Re: Clojure will affect the way you think about programming

#81

Post by shadowmint »

davedx wrote: post #69
shadowmint wrote: post #65

I don't like working with clojure. Its basically modern perl. I've worked with both professionally, and the outstanding point with both has been: - programmers try to be clever in their code, write one giant file full of complicated specialized 'beautiful' code, forget everything they know about breaking big tasks into simple small ones. - code is a nightmare to maintain for non-author - non-authors working on code r…

> - programmers try to be clever in their code, write one giant file full of complicated specialized 'beautiful' code, forget everything they know about breaking big tasks into simple small ones. What on earth does this have to do with clojure? Programmers will do this in any language, there's nothing special about clojure here. I personally don't find LISP languages to be the most readable, but I'm fairly sure it's…

Rubbish. I've worked with a dozen languages, and its unquestionable that certain ones attact a high ratio of terse complicated code.

Clojure is specifically renouned (and celebrated) for its low LOC counts; people go as far as saying (literally on /r/clojure) given a choice of library, pick the one with a lower LOC.

That's not because people write simple pointless libs like lpad; its because the community actively encourages terse complicated code.

Re: Clojure will affect the way you think about programming

#82

Post by yogthos »

hellofunk wrote: post #73

By far the most incredible thing for me was to see how far a few characters of code can go. Clojure is a very tight language where you can accomplish a lot in just one line of code. You end up suddenly having all this new, extra time to just think about your problem instead of coding it.

Another interesting side-effect of tight code, is that you become a lot less attached to it. When I worked in Java, it would often take 100s of lines of code to solve a simple problem, and once I wrote that code I'd be very hesitant to throw away or refactor it.

With Clojure, it often takes 10 lines or less to solve problems that take 100s of lines of Java. This encourages a lot more experimentation and refactoring in my experience.

Also, since you're always working in the REPL, you can always run the code after you change it and see that it's doing what you want immediately.

Re: Clojure will affect the way you think about programming

#83

Post by flavio81 »

vosper wrote: post #27

Having spent some time programming in Clojure, for the purpose of expanding my brain, I suspect a better Lisp to start with might be one of the classics - Racket, Common Lisp, etc... One of the reasons I gave up on Clojure was the lack of documentation of libraries, the bad debugging experience (those stack traces!) and the fact that there's no avoiding the JVM. They're all distractions to the learning (that was 2 ye…

I fully agree, and there are already great books for easily entering those worlds:

Scheme:

The Little Schemer (a classic)

Common Lisp:

Land of Lisp (a truly remarkable, quaint book: learn Common Lisp by programming classic games; full with really funny cartoons.)

Practical Common Lisp (really excellent way to learn quickly, modern. Freely available.)

Re: Clojure will affect the way you think about programming

#84

Post by miguelrochefort »

shadowmint wrote: post #65

I don't like working with clojure. Its basically modern perl. I've worked with both professionally, and the outstanding point with both has been: - programmers try to be clever in their code, write one giant file full of complicated specialized 'beautiful' code, forget everything they know about breaking big tasks into simple small ones. - code is a nightmare to maintain for non-author - non-authors working on code r…

I think that's true for most languages that are dynamically typed and let you effortlessly implement your own DSLs.

Re: Clojure will affect the way you think about programming

#85

Post by agentultra »

cgore wrote: post #54
lngnmn wrote: post #28

Why not Common Lisp or Scheme?

I did Common Lisp back in college for several years, it's a great language. But good luck getting a job with it. Clojure on the other hand, I've been paying my bills with that for the last few years. The main difference is a much larger community, and therefore lots more libraries for real-world stuff, and sitting on the JVM you have a lot of options integrating with existing corporate stuff.

There's a Common Lisp implementation that sits on the JVM. It's called ABCL. It provides a Java API for loading and calling Lisp code as well as a Lisp API for calling Java code (although it is quite a bit more verbose than that provided in Clojure... nothing a few macros couldn't solve if it became a nuisance).

The community is what does it. I tried for years to get commercial work in Common Lisp. It never happened.

Re: Clojure will affect the way you think about programming

#86

Post by yogthos »

flavio81 wrote: post #70
lngnmn wrote: post #28

Why not Common Lisp or Scheme?

I wonder the same. And the author writes: >"and Clojure is the first Lisp I'd consider using in production". I can't really understand the logic in this. If anything, CL has more going for it for production​ usage, like ANSI standarization and many high-performance compilers.

Clojure has the advantage of targeting the JVM and Js runtimes. These are two most popular runtimes for writing web apps currently. Clojure can also be easily integrated into existing projects on these platforms.

Re: Clojure will affect the way you think about programming

#87

Post by yogthos »

shadowmint wrote: post #81
davedx wrote: post #69

Earlier quoted context omitted.

> - programmers try to be clever in their code, write one giant file full of complicated specialized 'beautiful' code, forget everything they know about breaking big tasks into simple small ones. What on earth does this have to do with clojure? Programmers will do this in any language, there's nothing special about clojure here. I personally don't find LISP languages to be the most readable, but I'm fairly sure it's…

Rubbish. I've worked with a dozen languages, and its unquestionable that certain ones attact a high ratio of terse complicated code. Clojure is specifically renouned (and celebrated) for its low LOC counts; people go as far as saying (literally on /r/clojure) given a choice of library, pick the one with a lower LOC. That's not because people write simple pointless libs like lpad; its because the community actively en…

This is demonstrably false.

Re: Clojure will affect the way you think about programming

#88

Post by lvh »

flavio81 wrote: post #41
grouchoboy wrote: post #9

Earlier quoted context omitted.

The perfect language to expand your brain. In a world dominated by java, php, c++,... In my opinion yes, Clojure could the perfect language to continue learning concepts, at same level would be Haskell.

> The perfect language to expand your brain. Clojure is still restricted/limited compared to Common Lisp.

In what ways, specifically? Building binaries?

Re: Clojure will affect the way you think about programming

#89

Post by magpi3 »

davedx wrote: post #69
shadowmint wrote: post #65

I don't like working with clojure. Its basically modern perl. I've worked with both professionally, and the outstanding point with both has been: - programmers try to be clever in their code, write one giant file full of complicated specialized 'beautiful' code, forget everything they know about breaking big tasks into simple small ones. - code is a nightmare to maintain for non-author - non-authors working on code r…

> - programmers try to be clever in their code, write one giant file full of complicated specialized 'beautiful' code, forget everything they know about breaking big tasks into simple small ones. What on earth does this have to do with clojure? Programmers will do this in any language, there's nothing special about clojure here. I personally don't find LISP languages to be the most readable, but I'm fairly sure it's…

> What on earth does this have to do with clojure? Programmers will do this in any language, there's nothing special about clojure here.

I haven't programmed in Java in over ten years, but one if its "advantages" (at least back in the day) was what I called its object-oriented handcuffs, which prevented programmers from being too fancy with their code. Every file had to be a class. Every class was an object. Namespaces were clearly and rigidly defined. Setters and getters were standard for defining properties of an object. Etc.

The net result was frustration for programmers who detested such rigidity, but relief for any new programmer coming into a project because Java made it very difficult to write the kind of "specialized beautiful code' that shadowmint laments.

Lisps in particular allow the kind of freedom that programmers love and project managers hate. And I say that as someone who loves writing code in lisp (racket in particular).

Re: Clojure will affect the way you think about programming

#90

Post by DalekBaldwin »

drawnwren wrote: post #35
yogthos wrote: post #32

Earlier quoted context omitted.

One huge difference is the workflow you have in Clojure. REPL driven development is an experience unique to Lisps. When you're working with Clojure, any code can be run in the context of the live app straight from the editor as you write it. This is an amazing experience and very mind expanding in what a development process can look like. Also, anybody who wants to try FP style programming, but isn't interested in st…

Is there something about clj's repl that makes it any different from ghci's?

When the experience is amplified by homoiconic data structures and structural editing, yes -- exploratory, ephemeral metaprogramming is a breeze. Compound Clojure data literals have a fully readable print representation that can be generically manipulated by built-in core library functions. Say I have a DSL that takes a bunch of nested maps and vectors as an input spec and compiles them to nested closures, and I want to create a large spec derived from some other source satisfying certain constraints, but it's not worth defining yet a higher-level DSL for a one-off definition that I intend to commit to source control. I can generate that data structure any way I like and spit the result out at the REPL or in an interactive buffer, then effortlessly plop that structure or any of its substructures into an EDN file or just inside a `def` or `let` binding in a regular Clojure file, which I then pass to the DSL compiler. It's much simpler than manipulating things like GADTs in Haskell. Even in Common Lisp, it might require some ad-hoc parsing code to accomplish the same thing.
Post reply on HN