Live data from Hacker News

Clojure will affect the way you think about programming

eli.thegreenplace.net

141–150 of 226 posts

Re: Clojure will affect the way you think about programming

#141
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…

> 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/score nat-int?)
    (s/def :foo/student (s/keys :req [:foo.student/name :foo.student/score]))

    (def example-student
      #:foo.student{:name "Alice", :score 30})
However, Clojure takes a somewhat divergent philosophy, as it encourages writing schema for individual fields, rather than a schema for a grouping of fields (such as an object).

For example:

    {:foo.person/name "Alice"
     :foo.student/id  "xyz123456"}
The namespaces of each keyword are different, but they're grouped in the same map as they happen to refer to the same entity.

So rather than operating on a fixed type like `Student`, a function would request that it requires a data structure that has a person's name and a student ID:

    (s/fdef enrol
      :args (s/cat :student (s/keys :req [:foo.person/name :foo.student/id])))
We're still validating (albeit dynamically), but we can be more flexible in what data we ask for. This ties in with Clojure's idea of simplicity; a function shouldn't know about data it doesn't intend to use.

Re: Clojure will affect the way you think about programming

#142
post #76

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

Re: Clojure will affect the way you think about programming

#143

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…

Know what you mean RE transducers. I still haven't come to a point where using the transducer pattern is more convenient than just (partial map f) tbh.

Yet to dare clojure spec but it feels likely that the next mind blowing journey will be therein.

Re: Clojure will affect the way you think about programming

#144

Earlier quoted context omitted.

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…

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

Re: Clojure will affect the way you think about programming

#145
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…

I think people should learn both Haskell and Clojure :). However, while Haskell is very obvious in its differences with more commonly used languages, I feel that Clojure is more subtle.

I felt like an idiot while I was learning Haskell; but in Clojure I only realised my idiocy after perhaps a year of working in it. Clojure feels deceptively close to more standard languages, but in its own way is as different to them as Haskell. It just isn't as immediately obvious.

Re: Clojure will affect the way you think about programming

#146
post #89
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…

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

Yeah, sorry, but having had to try and work with 10,000 line Java classes, I still disagree. (And don't even get me started on some of the abomination .jsp files I've encountered!)

Maybe there's more whitespace and boilerplate in Java, but it's just as possible for lazy programmers to not split their code into modules, or write horrible spaghetti code.

Object oriented languages also introduce an entire different class of potential problems too. Pointless interfaces and abstract classes, terrible sprawling inheritance hierarchies...

Oh, and I've also seen horrible walls of text written in PHP too! And JavaScript... and C#...

Re: Clojure will affect the way you think about programming

#147
post #108
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_.

Yeah, typing usually helps. Hiring and training programmers to follow good practices (like not doing what grandparent claims only happens in Clojure) helps even more :)

Re: Clojure will affect the way you think about programming

#148

Earlier quoted context omitted.

hmm sexy idea to have spec help for stacktrace. I expect something cute like elm error messages. About the parens, it's true it's one great thing, every construct has a value [1]. It's funny because You hear about object orientation where things are uncoupled and standalone yet the language isn't this way. Lisp has this, it's the incarnation of its own idea. But it looks silly if you're in it for the syntactic appeal…

stack traces still suck as far as I've seen on the 1.9 alpha branch. And while clojure spec is pretty neat, the barge-load of information it dumps on a spec failure is overwhelming. That said, the info it dumps is in the form of clojure data structures. In my own programs, I've added code to refine this output to something useable, but it's particular to my project and I don't think generally useful. There are other…

Expound recently made my life a lot better by cutting through one of those ridiculous spec errors and telling me exactly what was wrong! I was really impressed.

Re: Clojure will affect the way you think about programming

#149
post #17

I have to say after diving into ClojureScript I came away thinking differently about a number of things - state management, how to program functionally when you are more constrained than in more permissive languages. It was a real learning experience.

This ^ right here, is what gets lost in all the squabbling over functional purity and parenthesis hate.

For a huge number of developers coming from the Javascript/web side of things, Clojurescript is poised so perfectly to usher them into thinking about composing your programs as pure functions, immutable data structures and organizing your state such that it is easy to reason about.

Eventually, Clojure led me to Haskell, and even back to how Javascript ought to be written (i.e. fantasy-land specs). This has been the single most eye opening learning effort that I have ever had the joy of undertaking since I started programming.

Re: Clojure will affect the way you think about programming

#150
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…

> 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 these methods then is supported by the organization in generic functions and hierarchical classes.

Post reply on HN