Live data from Hacker News

Clojure by Example (2015)

kimh.github.io

1–10 of 46 posts

Re: Clojure by Example (2015)

#4
> I don't like reading thick O'Reilly books when I start learning new programming languages. Rather, I like starting by writing small and dirty code.

Virtually every O'Reilly book starts out with small (and sometimes dirty) code examples.

Re: Clojure by Example (2015)

#6
Learning a new language by mapping constructs from another language you know better is certainly expedient.

But the trade off is you short change yourself on learning core philosophical beliefs underpinning the design of the language. Understanding these poorly means you will not exploit the language very well and arguably should just stick with the prior language.

Clojure more than most languages is built around some unconventional philosophical beliefs. So for example “reduce” becomes more than just another sequence function; in clojure it is an important way to build up a result in the absence of mutable variables (which in another language you could use to build up a result within an arbitrary type of loop). You really don’t get that from reading this cheat sheet. But if you took some time to read a slower introduction this will be made clear (“reduce” is prominent in Clojure for the Brave and True for example).

Similarly recursion becomes much more important in clojure due this same constraint.

As a lisp, clojure offers the opportunity to use macros, which come with tremendous power but also some important gotchas. You won’t get much here on when to use and not use macros, just a quick walkthrough of defmacro and friends.

I could go on. Clojure’s powerful concurrency primitives, its a-la-carte approach to polymorphism and inheritance, its emphasis on plain maps — all these types of things warrant a deeper rethinking of how you solve programming problems which you’re not going to get by just diving in (rushing in really) to some coding.

I’m not trying to knock this guide, it’s fine, but it does show the limits of the very approach it celebrates. It’s fine if you’re jumping from say python to ruby or Java to C# but Clojure would be near the bottom of the list of languages to learn this way.

Re: Clojure by Example (2015)

#7
post #5

> Clojure doesn't provide built-in function for exponential operation It does actually: (Math/pow 2 3) ;;=> 8

“Math” here is short for “java.lang.Math” though. Technically that’s interop rather than Clojure per se.

/pedantic

Re: Clojure by Example (2015)

#8
post #5

> Clojure doesn't provide built-in function for exponential operation It does actually: (Math/pow 2 3) ;;=> 8

The very next sentence of the article points out that you can leverage Clojure's interop to invoke Math.pow(), but that's still limited to casting its arguments down to java.lang.Double and suffering the limits therein

If you instead used the library org.clojure/math.numeric-tower [1] you can get much more precise answers, for example

  # start a repl with an extra dep
  $ clj -Sdeps '{:deps {org.clojure/math.numeric-tower {:mvn/version "0.0.4"}}}'
  user=> (require 'clojure.math.numeric-tower)
  nil
  
  user=> (Math/pow 33 33)
  1.2911004008776103E50
  user=> (type *1)
  java.lang.Double
  
  user=> (clojure.math.numeric-tower/expt 33 33)
  129110040087761027839616029934664535539337183380513N
  user=> (type *1)
  clojure.lang.BigInt

[1] https://github.com/clojure/math.numeric-tower

Re: Clojure by Example (2015)

#9
post #7
post #5

> Clojure doesn't provide built-in function for exponential operation It does actually: (Math/pow 2 3) ;;=> 8

“Math” here is short for “java.lang.Math” though. Technically that’s interop rather than Clojure per se. /pedantic

If you remove the Java SDK from Clojure's foundation, you're losing a lot of its power. The interop is part of that foundation.

Re: Clojure by Example (2015)

#10
post #7

Earlier quoted context omitted.

“Math” here is short for “java.lang.Math” though. Technically that’s interop rather than Clojure per se. /pedantic

If you remove the Java SDK from Clojure's foundation, you're losing a lot of its power. The interop is part of that foundation.

For sure, but “Clojure doesn't provide built-in function for exponential operation” is still an objectively true assertion.

If your point is that it’s wrong in spirit, I totally agree, and I think this is yet another example of the limits of this “cheat sheet” approach. If you’re coming from another language, the concept of easy, well integrated interop with a host language platform would be fairly foreign, so the importance of an available Java method, and the fact that such methods are frequently used as core parts of the language, would be totally lost on you.

Post reply on HN