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

171–180 of 226 posts

Re: Clojure will affect the way you think about programming

#171

Post by yogthos »

tigershark wrote: post #142
yogthos wrote: post #76

Earlier quoted context omitted.

I've been working with Clojure professionally for the past 6 years, and this is completely contrary to my experience. Clojure is the first language I've used where I'm able to easily read through libraries and understand them. Clojure uses a small number of common patterns that are applied to solving a wide variety of problems. Most code in the wild that I've seen tends to actually look very similar, and follows comm…

Maybe you didn't have much experience in programming before learning clojure? I never had any problems in understanding how a library worked in a language that I knew. And I have looked at the source code of quite big libraries in my life.

I've worked with Java for over a decade in the enterprise before I started using Clojure.

Re: Clojure will affect the way you think about programming

#172

Post by taktoa »

ohyes wrote: post #40
cderwin wrote: post #26

If "expanding your brain" is really what we want to optimize, why not learn Haskell? Or for that matter, why not learn something even more strongly typed, like Agda or Idris? Or even a theorem prover like Lean? Most of the reasons the author presents would either be expanded in one of those languages, or is immaterial to the goal of maximizing learning. After reading the article I have no more reason to consider lear…

They're not lisps, and do not have proper macros.

What's "improper" about Template Haskell, other than the easily-avoided phase restriction?

Re: Clojure will affect the way you think about programming

#173

Post by lispm »

weavejester wrote: post #159
lispm wrote: post #150

Earlier quoted context omitted.

> standardised structures for maps Then there are defstruct and deftype. So it has maps, struct-maps, records, deftypes, Java classes, ... a whole bunch. 'simplicity'? > This ties in with Clojure's idea of simplicity; a function shouldn't know about data it doesn't intend to use. I would use a class for that, since something like CLOS supports multiple-inheritance and all the necessary mechanisms for mixins. Finding…

> Then there are defstruct and deftype. So it has maps, struct-maps, records, deftypes, Java classes, ... a whole bunch. defstruct has been deprecated for years. deftype and Java classes are primarily for JVM interop and language extensions. Outside of calling Java libraries there are just maps, which you're going to be using 95% of the time, and records, which are maps with efficient polymorphism. > 'simplicity'? In…

> In Clojure parlance, "simplicity" refers to interconnectedness

Clojure tends to redefine words describing concepts with a new or restricted meaning. Typically a general concept like 'simplicity' would have more than one dimension.

> take as as argument an object that has the "id" field from the "Student" class, and the "email" field from the "User" class. Or would you have to explicitly pre-define mixins like HasStudentId and HasUserEmail?

I would not do this at all. Having slots or not are low-level artefacts and writing methods which are fine-grained to slots of an objects don't expose the domain-level.

I would use methods for domain level classes which have the necessary slots either local or inherited.

Re: Clojure will affect the way you think about programming

#174

Post by keymone »

_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?

the static typing part - yeah, you just have to try and let go. there is typed.clojure for gradual typing though last time i checked it was quite slow. clojure.spec is a great attempt at bringing some discipline and provides quite a bit more than your usual typing system can do, though not entirely on compilation level.

as for compiler part - you're in for a treat. clojure is a compiled language - everything compiles down to jvm bytecode. the surprise part is that due to homoiconicity you get a compiler that's happy to let you hook into particular pieces of your code and (since code is literally represented as usual clojure data structures - lists/maps/vectors/etc) modify it on the fly before compiling. you basically define `f(code) -> other_code` - the ultimate metaprogramming.

Re: Clojure will affect the way you think about programming

#175

Post by hellofunk »

LyndsySimon wrote: post #144
hellofunk wrote: post #133

Earlier quoted context omitted.

> it's very difficult to learn Clojure if you don't at least know Java I'm curious why you think this is. As I've noted elsewhere in this thread, I've never written a line of Java in my life, and have worked as a Clojure dev since 2014. I also never write any code that interoperates with Java. Seems to be a very common misconception that you must know Java to use Clojure.

The very first thing I needed to do in Clojure was to deal with JWTs, which required using its Java interop. Decoding error messages sent me digging into the Java library's documentation. It wasn't hard per se, and I didn't know Java, but I do see the disruption of my Clojure "flow" when I have to deal with Java interop as a big reason I'm not more of a proponent of the language.

I personally do not like the experience of interop in any language, or using FFIs. Perhaps that is why on any project I've had, I make sure to use high-level Clojure libraries that handle all the interop for me. So far, after nearly 4 years, that has not been a problem.

But then again, all my projects have been raw Clojure from the start, and never projects where I had to deal with an existing Java code base or handle internal Java APIs at a company, etc.

If you approach Clojure for a fresh project with the plan that it will just be a Clojure project, as I have, you will rarely if ever need to know a thing about Java.

This is slightly less true for ClojureScript where some knowledge of JS can come in handy if you want to use JS libraries (which nearly all front-end developers eventually require). But even there, most needs are already wrapped up in Clojure libraries.

Re: Clojure will affect the way you think about programming

#176

Post by peatmoss »

aaron-lebo wrote: post #107
peatmoss wrote: post #59

Earlier quoted context omitted.

I can occasionally get away with writing Clojure for "real" work, but for hobbying (and inshallah for real work someday) my goto is Racket. I feel like Racket is something of an optimum among the lisps in terms of brain expanding, modernity, tooling, libraries, docs, and community.

I tried Googling bcrypt; one C wrapper that hasn't been updated in 3 years pops for Racket, there's at least 3 recently updated libraries for Clojure. I'd suspect the library availability is gonna be similarly tilted in Clojure's favor in most domains. Clojure has lots of compelling and new stuff - Figwheel, re-frame, Neanderthal. What's Racket's killer library that's doing something no one else is?

I don't think anyone will claim that any JVM language or node doesn't handily best Racket in terms of sheer numbers of libraries. What Racket does have are solid core libraries with good docs.

I don't know about "killer" but Racket's continuation based web server was / is novel (maybe first?). https://docs.racket-lang.org/web-server/

Also, it's not a library, but the whole #lang thing seems to be the coolest game in town for implementing DSLs and other more fully featured languages.

Re: Clojure will affect the way you think about programming

#177

Post by bhnmmhmd »

KirinDave wrote: post #139
bhnmmhmd wrote: post #135

Earlier quoted context omitted.

>> ...the bank announced they have decided to kill it because they don't like it, but that's got little to do with Clojure... I think that had something to do with Clojure. The thing is, businesses usually follow best-practices and choosing a language like Clojure is certainly not a best-practice (even if developers had really good reasons to use it). For example, who maintains the code? How many Clojurists (is that…

> I think that had something to do with Clojure. Were you on the Level team at Capital One? If so, oh hai and I hope all is well. Given all the changes there, you may want to be careful. You gotta know this is against policy if it goes much further. I know because I got in trouble over violating said policy once... If not: no. You're wrong. Headcount issues were largely unrelated to Clojure. Also, please stop pretend…

> ... Also, please stop pretending your best guess is some sort of calculus over complex corporate politics...

I think you should try to be more civil on HN. You can't just bash someone because of their guess.

> The converse of this that is equally true: Just because you don't feel capable of doing it doesn't mean I should not.

I don't want to get into some argument with someone who feels he is the only guy capable of achieving a failure.

Re: Clojure will affect the way you think about programming

#178

Post by weavejester »

lispm wrote: post #173
weavejester wrote: post #159

Earlier quoted context omitted.

> Then there are defstruct and deftype. So it has maps, struct-maps, records, deftypes, Java classes, ... a whole bunch. defstruct has been deprecated for years. deftype and Java classes are primarily for JVM interop and language extensions. Outside of calling Java libraries there are just maps, which you're going to be using 95% of the time, and records, which are maps with efficient polymorphism. > 'simplicity'? In…

> In Clojure parlance, "simplicity" refers to interconnectedness Clojure tends to redefine words describing concepts with a new or restricted meaning. Typically a general concept like 'simplicity' would have more than one dimension. > take as as argument an object that has the "id" field from the "Student" class, and the "email" field from the "User" class. Or would you have to explicitly pre-define mixins like HasSt…

> Clojure tends to redefine words describing concepts with a new or restricted meaning. Typically a general concept like 'simplicity' would have more than one dimension.

Sure, but that happens all the time in programming. When we talk about "objects" we don't mean "a material thing that can be seen and touched".

> I would not do this at all. Having slots or not are low-level artefacts and writing methods which are fine-grained to slots of an objects don't expose the domain-level.

I guess because it's not at all idiomatic, even in an object system as rich as CLOS.

But in Clojure it is idiomatic, and to my mind it leads to a more precise definition of what a function wants. We don't say, "this is a method that operates on a Student object"; we say, "this is a function that takes data that includes a student's email and enrolment date".

Again, I hasten to add that my experience with CLOS is virtually non-existent, but compared to the OOP languages I am familiar with, Clojure has a far richer way of describing the structure of data.

Re: Clojure will affect the way you think about programming

#179

Post by KirinDave »

bhnmmhmd wrote: post #177
KirinDave wrote: post #139

Earlier quoted context omitted.

> I think that had something to do with Clojure. Were you on the Level team at Capital One? If so, oh hai and I hope all is well. Given all the changes there, you may want to be careful. You gotta know this is against policy if it goes much further. I know because I got in trouble over violating said policy once... If not: no. You're wrong. Headcount issues were largely unrelated to Clojure. Also, please stop pretend…

> ... Also, please stop pretending your best guess is some sort of calculus over complex corporate politics... I think you should try to be more civil on HN. You can't just bash someone because of their guess . > The converse of this that is equally true: Just because you don't feel capable of doing it doesn't mean I should not. I don't want to get into some argument with someone who feels he is the only guy capable…

> I think you should try to be more civil on HN. You can't just bash someone because of their guess.

I asked politely, my friend. I'm suggesting your guess, leveled as an authoritative position, is misleading. Its you, taking my story away from me, asserting your narrative based strictly on preference. It's a narrative I disagree with, so I'm not inclined to let it slide.

It's crass to do this. There are many, MANY other ways you could have decided to open this subject. You could have related to YOUR experience, you could have asked for explanation of how these problems are perceived or surmounted. You could have simply expressed skepticism about the team size.

But you didn't. Here we are, on the wrong foot.

> I don't want to get into some argument with someone who feels he is the only guy capable of achieving a failure.

Then worry not! I am not: a guy, the only one capable of achieving, nor do I consider the product that made me a millionaire a failure.

Re: Clojure will affect the way you think about programming

#180

Post by vgy7ujm »

cloudkj wrote: post #156
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…

I've also worked with both Perl and Clojure professionally. I think Clojure code, by nature, has a higher chance at being "beautiful" or elegant, or at the very least as a close proxy, minimal. I feel that doing a lot with a little is easier in Clojure, and it makes these "beautiful" code snippets less likely to be mysterious and more likely to be understood by maintainers down the line, even sans documentation. The…

Remove regex abuse and newb/non-programmer code structure and Perl as written by a knowledgeable person is a most beautiful language. When yourself are knowledgeable and understand the "magic" it is beautiful beyond most languages.
Post reply on HN