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

191–200 of 226 posts

Re: Clojure will affect the way you think about programming

#191

Post by KirinDave »

flavio81 wrote: post #186
bpicolo wrote: post #136

Earlier quoted context omitted.

> How many Clojurists (is that a word?) can you find to work on the project? You don't need to look for Clojurians, you just need to look for developers. Getting to write in some slightly off-the-standard languages is a big draw for a lot of competent devs

> You don't need to look for Clojurians, you just need to look for developers. One of the best comments in HN in a long time, deserves its own article. So true. A programmer should be able to learn any other new language quickly.

You know, I agree with this. But recently I was challenged by someone outside our industry that said, "Well why do you all give javascript's ecosystem such a hard time for cycling frameworks every 2 years or so?"

I don't have an answer. It feels different to me, though. And to me learning a new thing is just part of the job. But many engineers I talk to act like it's something you're forced into, not a thing you should embrace. Because of opportunity costs, etc.

Re: Clojure will affect the way you think about programming

#192

Post by KirinDave »

arximboldi wrote: post #162
KirinDave wrote: post #114

Earlier quoted context omitted.

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

> they seem to me more implementable in C++ than in Haskell

If you don't mind the overhead, it's ContT wrapping some base monad. Or you could make it integral. That is more specific than transducers, I grant. But there's not much they can do that ContT over like Array does not.

I think it's too bad they were invented in Clojure, because they're brutally hard to use right and write in clojure.

I have some interesting work I could share in private on using them to provide stream fusion properties to pipelines of channels. Hit me up on keybase if you'd like to see. I don't want to open source it because then people will expect me to explain them and maintain them and I don't feel like it :)

Re: Clojure will affect the way you think about programming

#193

Post by KirinDave »

arximboldi wrote: post #168
KirinDave wrote: post #154

Earlier quoted context omitted.

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

So either I'd rather talk about the COMPUTATION and resource safety rather than the channel, as in Pipes/Conduit/Streaming from haskell.

OR, I'd rather deal with a direct actor model a la Erlang, Pony and Cloud Haskell.

Go's experience is so goddamn miserable it should just put the entire notion of async channels as a higher level programming library to bed. As a low-level primitive, it's okay but not fundamental.

Re: Clojure will affect the way you think about programming

#194

Post by kazinator »

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…

> To pull a value out, you can evaluate (:c map1) which will return "taco".

Not (map1 :c)? A bit odd.

Re: Clojure will affect the way you think about programming

#195

Post by kazinator »

lispm wrote: post #126

> Clojure is a dynamic language. Dynamically typed. As a dynamic language Clojure is less capable than many other Lisp implementations/languages. See for example 'late binding'. In Clojure you either need to define a function before its use or need declare it. Not that 'dynamic'. In a typical Lisp dialect the order of definitions makes much less a difference, since functions can be called late-bound. For an interpret…

> Actually objects in the early Lisp were simply symbols with their property lists.

I was quite surprised to see that this already existed, together with the "property" terminology, in McCarthy's primordial "pre-LISP" list processing system described in AN ALGEBRAIC LANGUAGE FOR THE MANIPULATION OF SYMBOLIC EXPRESSIONS. Basically any time we say that an object has properties, we are referring to that.

Re: Clojure will affect the way you think about programming

#196

Post by [deleted] »

flavio81 wrote: post #187
lispm wrote: post #126

> Clojure is a dynamic language. Dynamically typed. As a dynamic language Clojure is less capable than many other Lisp implementations/languages. See for example 'late binding'. In Clojure you either need to define a function before its use or need declare it. Not that 'dynamic'. In a typical Lisp dialect the order of definitions makes much less a difference, since functions can be called late-bound. For an interpret…

> Historically, Lisp programmers weren't the biggest proponents of OOP Yes, this is totally misleading... Lisp had OOP before Common Lisp existed, for example the Flavors OOP system through the '70s. This, of course, is before C++ was even a thought in the mind of Bjarne Strostroup. Also, interesting fact: Common Lisp was the first Object-Oriented language to get an ANSI standard.

[deleted]

Re: Clojure will affect the way you think about programming

#197

Post by shadowmint »

Our experiences with clojure are clearly different.

There have been plenty of people who have built successful businesses with perl too. /shrug

I'm still going to recommend people not use either language, because I've personally encountered the downsides of 'when things go wrong'; and it's been significantly worse than in other languages.

> Are we doing opinion threads now? Okay. I can do one too!

That's a bit of a flip off isn't it?

What I have to say is based on my professional experience. Don't like it? Tough. Luck. You had a different experience? fair enough. You want to call it an opinion thread? Well, you know what they say. Opinions are like assholes, everyone has one...

Re: Clojure will affect the way you think about programming

#198

Post by arximboldi »

KirinDave wrote: post #192
arximboldi wrote: post #162

Earlier quoted context omitted.

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

> they seem to me more implementable in C++ than in Haskell If you don't mind the overhead, it's ContT wrapping some base monad. Or you could make it integral. That is more specific than transducers, I grant. But there's not much they can do that ContT over like Array does not. I think it's too bad they were invented in Clojure, because they're brutally hard to use right and write in clojure. I have some interesting…

Sorry, I actually meant "than in Clojure". You are right about the ContT. I'm actually curious about your transducer based stream fusion stuff... I'll hit you up later about it :-)

Re: Clojure will affect the way you think about programming

#199

Post by christophilus »

_t0du wrote: post #124
keymone wrote: post #20

Clojure is the language where LISP clicked for me. Can't recommend it enough, it's got all of it - immutable datastructures, convenient data literals, simple and composable concurrency primitives, very thin interface to host VM. Just put enough effort to get beyond that "omg parenthesis" barrier and it will be a delight. It's like that Half-life joke: there are two kinds of people, those that finished Half-life many…

I keep hearing this sentiment, moreso than I've ever seen for any other language. Once you "get into" Clojure, you're both A.) Extremely productive with it, and B.) in love with Clojure. How does it hold up for those of us that really love static typing and compilers?

I love static typing. I really dislike almost every dynamic language I've ever worked with. But Clojure is currently my favorite language. I've done C#, F#, Go, JS, Ruby, Dart, C, C++, dabbled in Haskell, OCaml, purescript, D, Nim... (I like programming.) Anyway, once I dove into Clojure, I couldn't go back to any other language. I do wish it was more general purpose (not so slow to boot, had a decent native / non JVM, non JS target.)

Re: Clojure will affect the way you think about programming

#200

Post by christophilus »

KirinDave wrote: post #121
shadowmint wrote: post #65

I don't like working with clojure. Its basically modern perl. I've worked with both professionally, and the outstanding point with both has been: - 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. - code is a nightmare to maintain for non-author - non-authors working on code r…

Are we doing opinion threads now? Okay. I can do one too! I do like working with clojure. It's my favorite dynamically typed programming language by an easy margin. It's basically everything that was a good idea in Python and Ruby brought under the unifying role of a Lisp syntax, with a good Java FFI. This makes it slightly harder to learn (it's very difficult to learn Clojure if you don't at least know Java). It has…

I don't know Java (I've avoided Java work as intentionally as I've avoided SharePoint work). Clojure was not hard at all for me to pick up.
Post reply on HN