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

41–50 of 65 posts

Re: Clojure and the technology adoption curve

#41

Post by e12e »

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…

I can't seem to find it now, but I remember reading an essay, probably by Joel Spolsky -- on mentoring a newly hired junior Cprogrammer. The programmer had implemented some functionality in C, and had written lots of tiny function calls, with descriptive names, that composed to form the solution. The author called the programmer into the office, and berated the coding style, citing "efficiency" as a reason for why the program was an example of poor coding style.

The main point of the article, was that the junior programmer was right: well structured, self-documenting code is always better than fast code. If it ends up being too slow, and (in the case of C) can't be fixed with "inline" and "-O2", then, and only then, move towards a different, hopefully more efficient solution.

Now, obviously, writing functional-style C isn't the only (or perhaps even the best) way of writing structural, clean, C code.

But functional composition, especially with help from the underlying programming language, can be compact, and very easy to reason about.

Never mind the fact that approximately half of Haskell (and some clojure?) programmers appear to think that "f a b" is more readable than "scaleVector Vector Factor". Conciseness can be a weakness as well as a strength.

Re: Clojure and the technology adoption curve

#42

Post by sdegutis »

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 hard part of Clojure really boils down to one thing: you do not have an assignment operator.

Nah. You have `let` which is exactly that.

Re: Clojure and the technology adoption curve

#43

Post by siegecraft »

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 start getting into macro characters, and then the dispatch macro, and then the regex dispatch macro. I think you could write perfectly fine clojure code without knowing the details of all of these, but it can be frustrating to not know if your code is idiomatic clojure or merely badly translated from another language.

Re: Clojure and the technology adoption curve

#44

Post by sotojuan »

baldfat wrote: post #27
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.

I agree. In our Programming Languages class the professor used Racket when introducing functional programming. It worked very well.

Re: Clojure and the technology adoption curve

#45

Post by hatmatrix »

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…

I think the idea behind homoiconicity is that you can generate and modify code using the same tools you would use on data; not string functions and regular expressions to manipulate the text you would call eval() on. Trying to understand semantics of code blocks this way is like parsing html with regular expressions. I used to modify built-in functions in emacs lisp by calling a modifying function (though later I was told the canonical way to do it was just to copy the function elsewhere, modify it, and evaluate it after the built-in was loaded).

Re: Clojure and the technology adoption curve

#46

Post by akmiller »

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…

Rich Hickey had a talk (not sure which one it is at the moment) about how we used to refer to programmers as data processors as the core of your job was reading data from somewhere, processing that data, then moving that data somewhere else. We've moved away from that definition but the fact is, at its core, we are still data processors.

Once you've convinced yourself of that and you look at Clojure through that lens you will find immense power in that language, as everything is built around data transformations.

I do think the move away from data processors as a title is more of an ego thing...none of us probably wants to be called a data processor.

Re: Clojure and the technology adoption curve

#47

Post by sbov »

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…

For myself, there are a couple things that make Clojure difficult. I believe they all stem in part from the language being simple.

First, there seems to be at least two ways to do things: the verbose way and the succinct way. This creates more things beginners have to memorize.

Second, so many :keywords. Presumably some function/macro needed to be made more flexible and/or more succinct for certain circumstances so they add magical (from this beginner's POV) :keywords to make it translate their arguments in different ways. Clojure functions seem more like Unix commands rather than functions in most programming languages I'm used to.

And finally, an imperative programmer's tendency to create long functions. As a beginner my brain starts to shutoff once I encounter a Clojure function that reaches 5-10 lines. But 5-10 lines in an imperative language is pretty short.

Clojure is a simpler language, but because of that it doesn't benefit from the syntax highlighting more complex languages may have. This makes it more difficult (for me) to parse similarly lengthed Clojure programs. Of course similarly lengthed Clojure programs can do more than an imperative language, so it should probably be split into more functions, which would make it easier for me, as a beginner, to read.

I feel like people tout the succinctness of Clojure as a benefit because you can write shorter programs. I've come to think it's a benefit because you can section off more of your code into descriptive functions without exploding your code length, which make the program easier to read. When I start to use that succinctness to write less code it quickly becomes unreadable if I revisit it in a month.

Re: Clojure and the technology adoption curve

#48

Post by pjmlp »

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

They are also used by Dylan, the Lisp with Algol like syntax developed by Apple,

Protocols provide the same type of polymorphism offered by Objective-C protocols, Java/C# interfaces, Go interfaces, ...

Many mainstream developers might only know one way of doing OO, but back in the day we could choose between Smalltalk, Lisp, Beta, Eiffel, Sather, C++, Modula-3, Oberon, Component Pascal, SELF, .....

Each had their own view how encapsulation, polymorphism, message dispatch, type extensions should take place.

So it is kind of funny to have some in FP languages bashing OO, while successful FP languages are actually hybrid. At the same time having people in teh OO side bashing FP, while their languages keep absorbing FP concepts.

Eventually we will get back to Smalltalk and Lisp, which already provided both ways in the late 70's.

Re: Clojure and the technology adoption curve

#49

Post by hellofunk »

pjmlp wrote: post #48
ddellacosta wrote: post #30

Earlier quoted context omitted.

How are protocols and multi-methods OO?

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 the two are isolated from each other and not attached in any way. That's quite different from OO in general, don't you think?

Re: Clojure and the technology adoption curve

#50

Post by dmichulke »

nickbauman wrote: post #14
dmichulke wrote: post #9

Earlier quoted context omitted.

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

Exactly this. The amount of code to do things is shockingly small. When I was first learning Clojure I stumbled on a "lack of good documentation" in third party libraries. I'd google around for something that solved the problem I was trying to solve so I wouldn't reinvent the wheel. I'd find, say, a github repo that had a couple of sentences in its README that purported to solve my problem and then nothing else. What…

I also use several libraries that don't have a decent (or any) doc, just docstrings in source code and I kind of got used to it now, or, as Emacs puts it:

Code never lies, comments sometimes do (Charles de Gaulle)

Post reply on HN