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

Clojure and the technology adoption curve

blog.juxt.pro

Post reply on HN
Print view View original

21–30 of 65 posts

Re: Clojure and the technology adoption curve

#21

Post by S4M »

klibertp wrote: post #20
S4M wrote: post #13

Earlier quoted context omitted.

> Many languages have eval() where data can be treated as code. I will just address this point, which IMHO is orthogonal to your question about the benefits of functional programming. Let me give you a simple example of macro: a macro print-variable that takes a variable and prints: "$variable = $value", where $variable is the variable name and $value its corresponding value. I wrote it on my Clojure REPL, and run it…

Your Python example wouldn't work. eval is still scoped lexically. You'd need to get current stack frame, get locals from the previous frame and only eval within these locals. That's what TCL `upvar` does, BTW. Macros let you avoid this kind of problems when meta-programming (but then they bring their own problems: hygiene, for example).

Good point, I haven't really thought the Python example through. I can't find a quick fix now, so I leave it as an illustrative code (even that failing code is an inferior version of the macro, so...).

Re: Clojure and the technology adoption curve

#22

Post by pjmlp »

PaulHoule wrote: post #2

In my mind you are not leaving OO behind when you get into Clojure, but the big conceptual challenges revolve around doing things in an immutable way. It is obvious how to do some things and not to do others.

One cannot leave OO behind in a language that by definition, supports OO via protocols and multi-methods.

Re: Clojure and the technology adoption curve

#23

Post by falcolas »

nickbauman wrote: post #11

It is a myth that you have to be a genius programmer to pick up Lisp dialects like Clojure. I think it's the opposite: the cognitive load of more complex languages that are "easier to learn" than Clojure (like Scala or even Java itself, for instance), a complexity I consider accidental and not essential to whatever problem you are solving, is more difficult. The hard part of Clojure really boils down to one thing: yo…

The tradeoff for anything "simple" is that you are then left to pick up the pieces (with libraries or your own code) if you want to do anything "complex".

As an example: C doesn't have the complication to the language of having "built in" types for hashes or lists. This makes the language easier, since you don't have to learn the extra syntax and grow the mental model of how they were implemented. On the other hand, if you need a hash or list - you need to create your own (or adopt someone else's implementation via a library).

C is a simple and powerful language, but there's so much you have to do yourself, that it's easy to get something wrong.

Clojure (and lisps in general) hide their complexity in macros. This level of abstraction can be great, until you have to dive into the macro and see exactly how it's manipulating your code. Or write your own and troubleshoot the resulting dynamic code.

Re: Clojure and the technology adoption curve

#24

Post by pjmlp »

evgen wrote: post #7

Probably worth noting that a lot of the companies with an interest in Clojure cited as Early Majority are simply non-Clojure companies that picked up an Early Adopter startup as an acquisition and need to continue development and does not necessarily represent greenfield Clojure development at that company (I know this for a fact regarding one of the companies cited on the list, suspect the same for a few of the othe…

Here in Germany I only see Clojure ads in relation to big data startups[0].

Very seldom do classic companies ask for anything other than JavaScript on the browser or Java on the JVM.

[0] Same applies to other FP languages on the JVM.

Re: Clojure and the technology adoption curve

#25

Post by nickbauman »

bad_user wrote: post #19
nickbauman wrote: post #11

It is a myth that you have to be a genius programmer to pick up Lisp dialects like Clojure. I think it's the opposite: the cognitive load of more complex languages that are "easier to learn" than Clojure (like Scala or even Java itself, for instance), a complexity I consider accidental and not essential to whatever problem you are solving, is more difficult. The hard part of Clojure really boils down to one thing: yo…

> you do not have an assignment operator Except that you do have assignment. Even more so, every def is a Var, defn definitions themselves being vars that can be redefined, in true Lisp tradition and you also have atoms and you can use mutable arrays or any mutable collections you like, with people doing plenty of that. The emphasis on its simplicity is also misleading. For example Clojure developers pride themselves…

Not in any way that matters to people who use the assignment operator in other languages. Of course what you're saying is correct but pointing this out to beginners is like explaining that the steering wheel of the car can be removed and used as a lethal weapon. It's pedantic and misleading.

I don't say and I don't see others saying "Clojure does not do OOP". If you notice this feel free to point this out; even ask me for support. Our community should be exemplary of keeping these things consistent. We all need to do our part.

Re: Clojure and the technology adoption curve

#26

Post by nickbauman »

falcolas wrote: post #23
nickbauman wrote: post #11

It is a myth that you have to be a genius programmer to pick up Lisp dialects like Clojure. I think it's the opposite: the cognitive load of more complex languages that are "easier to learn" than Clojure (like Scala or even Java itself, for instance), a complexity I consider accidental and not essential to whatever problem you are solving, is more difficult. The hard part of Clojure really boils down to one thing: yo…

The tradeoff for anything "simple" is that you are then left to pick up the pieces (with libraries or your own code) if you want to do anything "complex". As an example: C doesn't have the complication to the language of having "built in" types for hashes or lists. This makes the language easier, since you don't have to learn the extra syntax and grow the mental model of how they were implemented. On the other hand,…

The tradeoff you're referring to is summarized "Powerful but doesn't provide much." JavaScript comes to mind. This is not the case with Clojure. Most macros are basic and straightforward. Their power is, of course, unparalleled in other languages feature sets. With great power comes great responsibility, eh? And you don't have to use macros. Not that much is implemented in macros. I think you have some valid insights but you may be overstating your case.

Re: Clojure and the technology adoption curve

#27

Post by baldfat »

nickbauman wrote: post #11

It is a myth that you have to be a genius programmer to pick up Lisp dialects like Clojure. I think it's the opposite: the cognitive load of more complex languages that are "easier to learn" than Clojure (like Scala or even Java itself, for instance), a complexity I consider accidental and not essential to whatever problem you are solving, is more difficult. The hard part of Clojure really boils down to one thing: yo…

> It is a myth that you have to be a genius programmer to pick up Lisp dialects like Clojure. I think it's the opposite:

People should learn first through Racket and its awesome DrRacket. I wish I first learned programming in Racket and not Basic and Assembly.

My kids will go through Racket in a few years.

Re: Clojure and the technology adoption curve

#28

Post by msluyter »

Let's say I'm sold on Clojure (I am; I think it's awesome) and I want to convince my boss to convert a crufty Java 7 enterprise app to a better alternative. What is the argument for Clojure compared to, say, Kotlin? How difficult is a complete conversion to Clojure compared to other JVM alternatives. My guess, in terms of ease of transition:

  Java 8 > Kotlin > Scala > Clojure
That's just my impression, especially if you're risk averse and want to make improvements as incrementally as possible. But I could be wrong. Anyone have a good counterexample?

Re: Clojure and the technology adoption curve

#29

Post by falcolas »

nickbauman wrote: post #26
falcolas wrote: post #23

Earlier quoted context omitted.

The tradeoff for anything "simple" is that you are then left to pick up the pieces (with libraries or your own code) if you want to do anything "complex". As an example: C doesn't have the complication to the language of having "built in" types for hashes or lists. This makes the language easier, since you don't have to learn the extra syntax and grow the mental model of how they were implemented. On the other hand,…

The tradeoff you're referring to is summarized "Powerful but doesn't provide much." JavaScript comes to mind. This is not the case with Clojure. Most macros are basic and straightforward. Their power is, of course, unparalleled in other languages feature sets. With great power comes great responsibility, eh? And you don't have to use macros. Not that much is implemented in macros. I think you have some valid insights…

> This is not the case with Clojure.

Well, it actually is the case, it's just that they've built out the core library with a ton of functionality; intermingling the actual Clojure keywords (there's only ~17 of them) with the convenience macros and functions built up from those two primitives. Someone wrote all of those functions and macros. Hundreds of functions and macros were built by the language creators to give the functionality of a complex language.

> Not that much is implemented in macros.

74 of the functions exposed in the core api alone are macros. Perhaps the most often used one is "defn" (and somewhat ironically "defmacro").

Re: Clojure and the technology adoption curve

#30

Post by ddellacosta »

pjmlp wrote: post #22
PaulHoule wrote: post #2

In my mind you are not leaving OO behind when you get into Clojure, but the big conceptual challenges revolve around doing things in an immutable way. It is obvious how to do some things and not to do others.

One cannot leave OO behind in a language that by definition, supports OO via protocols and multi-methods.

How are protocols and multi-methods OO?
Post reply on HN