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

151–160 of 226 posts

Re: Clojure will affect the way you think about programming

#151

Post by chpill »

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…

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.

Re: Clojure will affect the way you think about programming

#152

Post by jasonkostempski »

bryanrasmussen wrote: post #97

The problem is that I want to expand my brain, but I also want to get things done and I have a family. I think this is one of those you can choose 2 situations.

Use breaks and sleep less once in a while. It's just what you've got to do if you want to learn new things outside of your current obligations.

Re: Clojure will affect the way you think about programming

#153

Post by didibus »

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…

All the languages you've mentioned will also expand your brain, but in a different direction, mostly related to correctness and provability of specifications.

Clojure will expand it in different ways. Here's some examples:

  - Interactive programming
  - Persistent data structures
  - Immutability
  - Code that writes code
  - Functional programming 
  - Extendable polymorphism
  - Lazy evaluation
  - Eager evaluation
  - Parallel computing
  - Dynamic variable extent
  - Recursion
  - Concurrent programming
  - Declarative programming
  - Aspect oriented programming
  - Logic programming
  - Code as data
  - Software transactional memory
  - Generative testing
  - Contracts guards
  - Optional type systems
  - Conditional restarts
  - Monads
  - Variant types
  - Collection abstractions
  - Array programming
  - Map Reduce
  - List comprehensions
  - Reactive programming
  - And more...

Re: Clojure will affect the way you think about programming

#154

Post by KirinDave »

chpill wrote: post #151
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…

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

Re: Clojure will affect the way you think about programming

#155

Post by didibus »

lngnmn wrote: post #28

Why not Common Lisp or Scheme?

Its all explained here: https://clojure.org/about/rationale

Here's an excerpt:

Why did I write yet another programming language? Basically because I wanted:

A Lisp for Functional Programming symbiotic with an established Platform designed for Concurrency and couldn’t find one.

Re: Clojure will affect the way you think about programming

#156

Post by cloudkj »

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 non-author comment is well taken though, as I find Clojure development to have a much higher thinking-to-coding ratio, so when a solution gets translated from the author's head to code, much of the complexity can be hidden due to the conciseness and lack of verbosity. I didn't really find that to be a problem in Perl, however, with the exception of perhaps the (over/ab)use of complicated regular expressions.

Re: Clojure will affect the way you think about programming

#157

Post by didibus »

I started learning Clojure two years ago, and it has expanded my brain in many ways. I love Clojure for the pure joy it gives me on a daily basis.

In those two years, it thought me about:

  - Interactive programming
  - Persistent data structures
  - Immutability
  - Code that writes code
  - Functional programming 
  - Extendable polymorphism
  - Lazy evaluation
  - Eager evaluation
  - Parallel computing
  - Dynamic variable extent
  - Recursion
  - Concurrent programming
  - Declarative programming
  - Aspect oriented programming
  - Logic programming
  - Code as data
  - Software transactional memory
  - Generative testing
  - Contracts guards
  - Optional type systems
  - Conditional restarts
  - Monads
  - Variant types
  - Collection abstractions
  - Array programming
  - Map Reduce
  - List comprehensions
  - Reactive programming
  - S-expressions
  - Destructuring
  - Pattern Matching
  - Prefix operators
  - Closures
  - Data literals
  - And more...

Re: Clojure will affect the way you think about programming

#158

Post by vosper »

throwaway7645 wrote: post #131
aaron-lebo wrote: post #107

Earlier quoted context omitted.

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?

It will eventually use Chez Scheme as a backend since CISCO open sourced it. Chez is really fast and lightweight.

Does that help with the issue of outdated libraries at all (I don't know anything about Chez Scheme)?

Re: Clojure will affect the way you think about programming

#159

Post by weavejester »

lispm wrote: post #150
weavejester wrote: post #141

Earlier quoted context omitted.

> An aspect I don't like. This makes debugging of larger systems more difficult, since maps are maps. Whereas objects have a type tag built in, have a list of allowed fields, etc. etc. They simply have more more explicit and standardized structure to them. You can create explicit and standardised structures for maps in Clojure, or indeed any other data structure: (s/def :foo.student/name string?) (s/def :foo.student/…

> 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 Clojure parlance, "simplicity" refers to interconnectedness. So a box of tools is "simple", because they're not connected, whereas a Swiss army knife would be "complex", even if it might be easier for a novice to use.

Having a bunch of similar tools isn't complex, from Clojure's point of view, as long as they're separate. It may make things more difficult to learn, but that's another problem entirely :)

> I would use a class for that, since something like CLOS supports multiple-inheritance and all the necessary mechanisms for mixins.

Doesn't that mean you'd need a separate class for each way you access the data if you wanted to type that? My knowledge of CLOS is, I'm afraid, rudimentary, but can you say to a method: 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?

Re: Clojure will affect the way you think about programming

#160

Post by specialist »

cnlwsu wrote: post #108
magpi3 wrote: post #89

Earlier quoted context omitted.

> 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 haven't programmed in Java in over ten years, but one if its "advantages" (at least back in the day) was what I called its object-oriented handcuffs, which prevented programmers from being too fancy with their code. Every file had to be a class. Every class was an object. Namespac…

Java still has same issue too with bored engineers. Over engineering happens. AbstractSingletonProxyFactoryBean anyone? But really strongly typed languages like java is easier than most dynamic typing language to jump into _if the project is sane_.

The J2EE culture (for lack of a better perjorative) negatively impacted Java's mindshare.

I still love me some Java for personal projects. But work Java usually means Spring, Hibernate, Maven, and other monstrosities. I'd hate Java too if that's all I knew.

Post reply on HN