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

31–40 of 65 posts

Re: Clojure and the technology adoption curve

#31

Post by nickbauman »

falcolas wrote: post #29
nickbauman wrote: post #26

Earlier quoted context omitted.

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…

... so it sounds like we're in violent agreement.

Re: Clojure and the technology adoption curve

#32

Post by [deleted] »

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

[deleted]

Re: Clojure and the technology adoption curve

#33

Post by astine »

falcolas wrote: post #29
nickbauman wrote: post #26

Earlier quoted context omitted.

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…

    intermingling the actual Clojure keywords (there's only ~17 of them) with the convenience macros and functions built up from those two primitives.
It sounds like you are drawing a distinction between the core Clojure language and the macros and functions in the core Clojure namespace. This is not really a valid distinction. That's the thing about Lisps, that much of the language is implemented in the language itself. Macros make the language easier to extend by both the language designer and random developers and users in appropriate cases. You can keep special forms to a minimum. Those those functions and macros are considered part of the core language even if they aren't special forms.

Re: Clojure and the technology adoption curve

#35

Post by agumonkey »

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…

Very simple way to put it. Probably why people argue that it's a question of nurture. When introduce to the bliss(at first) of mutable memory it a bit complicated to ask people to twist their brain, until late down the road. Now taught without this unfair comparison point, people will quickly find the "mutation free" easy to deal with with proper basic principles.

Re: Clojure and the technology adoption curve

#36

Post by astine »

msluyter wrote: post #28

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

Clojure's strongest selling point as compared to other JVM languages is probably its concurrency story. If your enterprise app is of any sort of size, you've probably run into concurrency related bugs.

Another strong advantage is the development lifecycle. It's much tighter thanks to the live coding built right in. This should make it much faster to catch bugs or feel out new code. You can also use this to implement zero-downtime deploys and patching.

Re: Clojure and the technology adoption curve

#37

Post by emidln »

ddellacosta wrote: post #30
pjmlp wrote: post #22

Earlier quoted context omitted.

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?

multi-methods at least are isa?-based. This implies that they obey ad-hoc hierarchies created via derive as well as traditional java inheritance hierarchies.

protocols are little more than open-ended interfaces (i.e. I can extend them at run-time to my things and to other things).

Re: Clojure and the technology adoption curve

#38

Post by hellofunk »

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.

OO is such an overloaded term, it's not possible to really draw the line in any concrete way. Much in the way that "functional programming" tends to mean different things to different people... but OO is even more varied in its actual meaning, in general.

Re: Clojure and the technology adoption curve

#39

Post by ajuc »

ddellacosta wrote: post #30
pjmlp wrote: post #22

Earlier quoted context omitted.

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?

According to Alan Key, who invented the term:

> OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them. [1]

You can do this easily with multimethods, in fact they allow for significantly "later" binding than traditional OO languages like Java or C++.

[1] http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...

Re: Clojure and the technology adoption curve

#40

Post by hellofunk »

simula67 wrote: post #4

I am having a lot of trouble trying to understand the hype behind functional programming. I have read McCarthy's paper on LISP, completed Odersky's course on Scala etc. No revelation so far ( yes, maybe I am stupid, but I won't admit it ). Is it only useful for study as a model that inspired modern programming languages ? For example : "obvious power of code becoming data." Many languages have eval() where data can b…

A dense functional language like Clojure or Haskell has about a 10x reduction in lines of code once you get rid of all the OO boilerplate and replace it with composable, higher-order functions. I used to write c++ for a living and when I switched to Clojure, my days are still full of the same level of development work, but the amount of code that I actually write is dramatically less. In a functional language, a lot more goes into the thought process of how to construct algorithms rather than in meeting the demands of the OO environment you work in. In some languages you have no choice but to make classes for even the tiniest of tasks, which is a limiting requirement to put in the hands of someone trying to creatively solve a problem from any angle without preconceived design patterns influencing the approach. FP instead lets you concentrate on other matters and usually use your brain for the fun stuff more often.
Post reply on HN