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

51–60 of 65 posts

Re: Clojure and the technology adoption curve

#51

Post by KingMob »

emidln wrote: post #37
ddellacosta wrote: post #30

Earlier quoted context omitted.

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

Just a slight addendum: Clojure multimethods can resolve to a concrete method implementation based on any function of their parameters.

So, in addition to single dispatch based on class (a la Java), you could also dispatch based on the classes of multiple parameters or on the value of the field 3 objects deep.

Re: Clojure and the technology adoption curve

#52

Post by tome »

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…

> Many languages have eval() where data can be treated as code.

That's significantly less powerful if you lack structured ways to compose things together before evaling them.

Re: Clojure and the technology adoption curve

#53

Post by pjmlp »

hellofunk wrote: post #49
pjmlp wrote: post #48

Earlier quoted context omitted.

Multi-methods are how Lisp based languages have done OO since the early days. LOOPS in Interlisp-D, here for a time travel to Xerox PARC. http://www.softwarepreservation.org/projects/LISP/interlisp_... Check the "LOOPS, A Friendly Prime" book. Meta-methods are at the core of CLOS, Common Lisp Object System, made famous with the "The Art of Metaobject Protocol" book. http://www.amazon.de/The-Metaobject-Protocol-Gregor…

But protocols and mulitmethods are different from OO in the sense that the functions are decoupled from the state. You don't store state in a protocol, you just define an interface. That's pretty different from the way most people think about OO in c++, java, swift, objective-c, etc. In Clojure, you have Records and maps, which hold your "state" or your values, and you have protocols which define your functions, and…

No, because there isn't one way of doing OO.

Just go read the Xerox PARC papers on how to do OO in Lisp, for example.

Back when OO was new there were multiple ways of how to do OO.

Some languages used the Smalltalk approach.

Others took the Simula approach where objects were an evolution of modules that could be extend and manipulated.

And there were lots of other options scattered around OOPSLA papers.

What happens is that there are now a couple of generations of new developers that didn't live through the procedural to object oriented programming revolution, nor were doing their CS degree in those days, so many understand OO as C++, Java et al do it and think no other way is possible.

The way Lisp does it, is quite common in the OO languages that offer multi-dispatch in method binding.

Since all method arguments types are used in the method resolution, it doesn't make sense to bind the methods to a specific object.

LOOPS and CLOS books/papers are pretty clear that they are doing OOP.

Re: Clojure and the technology adoption curve

#54

Post by SpaceCadetJones »

siegecraft wrote: post #43
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…

I'm not familiar with the myth of having to be a genius to learn clojure. Not having an assignment operator is the same problem anyone would have in trying to move from an imperative to a functional language. You can be productive in clojure, I think, without being extremely fluent. But Clojure does tend to some perl-esque terseness. Browsing down this page ( http://clojure.org/reader ) everything is fine until you s…

I've definitely been experiencing the frustration of not knowing whether or not I'm writing idiomatic Clojure or not. Looking through the actual Clojure + other's source code and occasionally asking on IRC when I feel like I'm doing something wrong has been a big help.

Re: Clojure and the technology adoption curve

#55

Post by SpaceCadetJones »

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…

In a nutshell:

- Functional programming style tends to make your programs easier to reason about, as it avoids state/mutation. This also makes testing your programs much easier, and can also make concurrency easier.

- It's a different way of thinking. Some problems are much easier to solve in a functional fashion, some are much easier in a imperative fashion.

- Functional code can increase code re-usability as it decouples data from its operations

- A lot of functional languages have very advanced type systems compared to say, Java or C++. I'm personally a big fan of static typing and after learning F# I am sorely missing its type system in C#

Re: Clojure and the technology adoption curve

#56

Post by talloaktrees »

dmichulke wrote: post #9
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…

Traverse a hashmap, remove all strings with an even key string size and sort it by the last character in the string, then add the string size to the integer (here you have a list of integers) and sum the product of the numbers at index 0 and n-1, 1 and n-2, ... Compare the the code size in Java and Clojure. If that is not enough, do the same thing but start with java objects (and their clojure equivalent: a hashmap)…

I'd love to see some example code for doing this.

I'm trying to implement it in Kotlin and am curious how it would compare.

Re: Clojure and the technology adoption curve

#57

Post by talloaktrees »

pjmlp wrote: post #24
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.

It's same same in the US outside of SF and NYC

Re: Clojure and the technology adoption curve

#58

Post by juliangamble »

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…

In case you're interested, Lisp can be implemented with 7 primitives (some say 5). So in a sense Clojure went overboard to increase the verbosity of Lisp to make it easier for newcomers: http://stackoverflow.com/questions/3482389/how-many-primitiv...

Re: Clojure and the technology adoption curve

#59

Post by juliangamble »

VLM wrote: post #6
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.

As an example there's an essay at http://www.lispcast.com/solid-principles-in-clojure which elaborates on SOLID OO design in Clojure and provides some code examples. For example there's a pretty clear example of the right way to apply SRP to a functional paradigm. I'd interpret it as you need SOLID to do successful OO (required but not sufficient), but using as much SOLID as reasonably possible under any paradigm als…

(Disclaimer: I'm a huge fan of Eric Normand, and had a couple of dinners with him at Clojure Conj last year.)

I think the value of SOLID is that it gives you tools for thinking about your code.

I think there is lots of room for a critique and even a debunking of SOLID. Indeed, Kevin Henney has done just that. http://yowconference.com.au/slides/yow2013/Henney-SOLIDDecon...

Re: Clojure and the technology adoption curve

#60

Post by sklogic »

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…

> Not that much is implemented in macros.

And this is exactly what is wrong with Clojure and its community. An unexplainable lack of ability to embrace macros and all the power they can bring.

I could never understand a single anti-macro argument, they are all too detached from the reality.

Post reply on HN