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

161–170 of 226 posts

Re: Clojure will affect the way you think about programming

#161

Post by lgas »

KirinDave wrote: post #114
arximboldi wrote: post #55

Earlier quoted context omitted.

There are many things to love in Clojure, like core.async, the lispyness, etc. But for me, their biggest breakthrough is with no doubt the data-structures. Clojure default of immutable hash maps and vectors was really bold. They had to innovate by giving a twist to Bagwell's great research on data-structures, and they managed to build what in my opinion are the first set of general data-structures suitable of represe…

> In the past I also did some other work on bringing Clojure Transducers to C++ ... consider it a much less important effort---without the data-structures the other parts of Clojure feel almost like just sugar. Very few clojure programmers consider Transducers very important even in Clojure. While they're convenient for implementing Clojure's stdlib and they have some nice properties, they're very difficult to work w…

You might find this work on composable well-typed transducers in Idris interesting: https://deque.blog/2017/08/04/transducers-in-idris-2/

Re: Clojure will affect the way you think about programming

#162

Post by arximboldi »

KirinDave wrote: post #114
arximboldi wrote: post #55

Earlier quoted context omitted.

There are many things to love in Clojure, like core.async, the lispyness, etc. But for me, their biggest breakthrough is with no doubt the data-structures. Clojure default of immutable hash maps and vectors was really bold. They had to innovate by giving a twist to Bagwell's great research on data-structures, and they managed to build what in my opinion are the first set of general data-structures suitable of represe…

> In the past I also did some other work on bringing Clojure Transducers to C++ ... consider it a much less important effort---without the data-structures the other parts of Clojure feel almost like just sugar. Very few clojure programmers consider Transducers very important even in Clojure. While they're convenient for implementing Clojure's stdlib and they have some nice properties, they're very difficult to work w…

Yeah, I agree!

Actually one of the things I found during my work on transducers is that actually they seem to me more implementable in C++ than in Haskell. For example, you can implement state-less transducers with almost zero overhead, something that in Clojure is definitely not true (so the standard transducers do hide state inside the closure of the reducing functions). It is also easier to do n-ary transducers for zipping and unzipping and everything, as you intuit, is type checked.

Still, I agree that transducers are most useful when you have libraries that make sense of them. For example, you could implement a lot of "Rx" using transducers. Ideally I see a user never writing a transducer, and occasionally passing one to some library that provides "higher order" reactive collections (channels, observables, etc.) that can be transformed with transducers. For example, my motivation to implement them in C++ was to build "observable/reactive lenses" (something like "cursors" in Om) [1] where you could use transducers to specify how you "zoom" into the virtual sequence of state values...

Anyways, they are an interesting coding tool, but they don't really influence the architecture of the application.

[1] atria::funken https://github.com/Ableton/atria

Re: Clojure will affect the way you think about programming

#163

Post by lgas »

eliben wrote: post #11
jrs95 wrote: post #4

I just saw an article recently about core.async and the "go" macro, which seems to effectively give you goroutines in Clojure. I'd be very tempted to use it for that reason alone. I love Go's concurrency, but it can be a little on the verbose side. Good for some projects, but not all of them.

Go is verbose ? I'm surprised to hear that, to be honest. Can you say what it's verbose in comparison to? What production language/framework has terser concurrency with the same expressiveness?

Haskell would be an example of a language that is terser and more expressive with comparable concurrency primitives.

Re: Clojure will affect the way you think about programming

#164

Post by arximboldi »

tome wrote: post #78
arximboldi wrote: post #55

Earlier quoted context omitted.

There are many things to love in Clojure, like core.async, the lispyness, etc. But for me, their biggest breakthrough is with no doubt the data-structures. Clojure default of immutable hash maps and vectors was really bold. They had to innovate by giving a twist to Bagwell's great research on data-structures, and they managed to build what in my opinion are the first set of general data-structures suitable of represe…

Do you know of a good resource for reading about their data-structures, especially anything Haskell doesn't have?

Search "Phil Bagwell", most of his papers are quite interesting.

If you allow me another shameless plug, I also compiled a good bunch of references in the "Related Work" section of my own paper on immutable vectors: https://public.sinusoid.es/misc/immer/immer-icfp17.pdf

Re: Clojure will affect the way you think about programming

#165

Post by specialist »

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…

Hearing you on FM. (Totally agree with you.)

But honest question: Does where you work in the stack, meaning the level of abstraction, matter for language choice? Or vice versa?

I've written a few parsers in Java. Not terrific but not terrible either.

My (future) interest in Clojure is CSP. Mostly because I'm tired of wrestling with concurrency. But I'm not sure I'd want to be doing data processing with it.

Re: Clojure will affect the way you think about programming

#166

Post by lgas »

moomin wrote: post #56

Clojure will affect the way you think about programming. It's led a number of people I know to start taking Haskell seriously after their Clojure phase.

This seems somewhat surprising to me since they are, in some sense, at opposite ends of the functional programming spectrum... but it's the path I took.

Re: Clojure will affect the way you think about programming

#167

Post by arximboldi »

KirinDave wrote: post #115
tome wrote: post #78

Earlier quoted context omitted.

Do you know of a good resource for reading about their data-structures, especially anything Haskell doesn't have?

Folks have linked you to the paper and mentioned tutorials. You might also Okasaki's Purely Functional Data Structures, which ends up in the citations for a lot of these.

Okasaki's work is really interesting, and it is quite mind-blowing the theoretical properties he achieves by exploiting laziness and so on. At the same time: those data-structures have one fundamental flaws they have high constant factors, specially outside of Haskell. That was Phil Bagwell + Rich Hickey revolutionary contribution in my opinion... finding data-structures that are rather simple yet but work well in practice because they make the right engineering trade-offs and work well with CPU caches, etc.

Re: Clojure will affect the way you think about programming

#168

Post by arximboldi »

KirinDave wrote: post #154
chpill wrote: post #151

Earlier quoted context omitted.

Writing your own transducers is hard and error prone, but I think using and composing the ones given you by clojure.core is actually rather easy (Especially using the 3 arity of `into`). I don't use so many `->>` anymore thanks to them.

I dunno. Except for one very specific project, I've yet to see a "Wow!" use case for transducers. The only place where they really shine is working with channels, but I think channels are a big design mistake (after extensive work trying to tame them).

Interesting! Why do you think they are a big design mistake? I can understand how they can be misused, but I find myself missing them in every language I used that doesn't have them...

Re: Clojure will affect the way you think about programming

#169

Post by madmax96 »

DigitalJack wrote: post #93
tome wrote: post #78

Earlier quoted context omitted.

Do you know of a good resource for reading about their data-structures, especially anything Haskell doesn't have?

Any book on clojure and website too will go over them. They are fundamental to using clojure. I don't know enough about haskell to say what it does or doesn't have in relation to clojure. However, it's not simply the data structures, but how the language is built to interact with them from a programmers perspective. From a user interface to the language point of view, I find the ways of interacting with maps to be ve…

>Many Lisp traditionalists are bothered by the use of curly braces for maps and square brackets for vectors

I have definitely seen this. I'm not sure that I understand this sentiment. The only thing that Clojure is missing is the "system" feel that Common Lisp provides, with things like character macros, symbol macros, etc.

That being said, I definitely appreciate how thought through Clojure is, especially when compared to CL. Several things are missing/don't feel well thought out in CL (notion of a `calleable` type is gone, `nth` isn't defined on vectors or strings (but you can still `length` them!) nor is `first` and `rest`) That provides a great deal of friction.

Re: Clojure will affect the way you think about programming

#170

Post by droidist2 »

delegate wrote: post #119

I agree with the article, but would also like to mention that it has a very steep learning curve. 1.5 months after my first line of Swift I had my app in the app store (granted I was proficient in Objective-C). 2 years since I've started learning Clojure and a couple of months since I'm working professionally with it and I'm still quite shaky. Luckily, it's not difficult to begin - you can start hacking small program…

It's a bit of a change from most mainstream languages, but still way easier than Haskell though.
Post reply on HN