
A tool for thought - dgellow
https://swannodette.github.io/2016/06/03/tools-for-thought
======
hkjgkjy
I do Clojure and Clojurescript full time. Love the ideas, but we as a
community need to step up our game when it comes to how easy and fun it is to
get started. Setting up a Clojurescript project is even worse than "modern
javascript".

The only worthwhile way is using Martin Klepsch's "Tenzing" template, but
using a template is not a solution.

[https://github.com/martinklepsch/tenzing](https://github.com/martinklepsch/tenzing)

I worry about this since the power of Lisp and Clojure is how easy it is to
experiment. Starting a C project is just doing a basic Makefile, a javascript
project is just `npm init`.

~~~
jyriand
It seems to me that setting up clojurescript project is extremely easy.
Basically you need to know only one "build" system(leiningen/boot), as for
javascript you would have to know at least few(broccoli/npm/bower/gulp etc).
And with leiningen you can do `lein new` as well, although I prefer boot and
creating my own files:

    
    
      ├── README.md
      ├── build.boot
      ├── resources
      │   ├── index.html
      ├── src
      │   └── cljs
      │       ├── sample
      │       │   ├── core.cljs
      │       └── main.cljs.edn
      └── test
          └── cljs
              └── sample
                  └── core_test.cljs

~~~
unwind
As an (embedded at the moment, but I've been around) C and sometimes C++
developer, considering that tree to be "easy" just seems absurd.

I'm sure everybody knows this, but here's "hello world" on the command line
using GCC in e.g. Linux:

    
    
        $ echo -e '#include <stdio.h>\nint main(void) { printf("hello, world!\\n"); return 0; }' > hello.c && gcc -o hello hello.c && ./hello
    

The most complicated thing here is probably the bash quoting/escaping (which
explains the double backslash inside printf()'s arguments).

The above command line spawns two processes, one of which is a full C
compiler, and it runs in _3 milliseconds_ on my embarassingly old home laptop
(Core-I5 M480 at 2.7 GHz).

I'm not trying to be the old fart claiming that everything was better back in
the day, but this (to me) almost makes C seem as approachable as BASIC on the
old 8-bit machines, when looking at the relative complexity.

~~~
swannodette
Compiling trivial programs with ClojureScript is equally trivial:

    
    
        java -cp cljs.jar clojure.main -e '(require (quote [cljs.build.api :as b])) (b/build (quote [(ns foo) (js/console.log "Hello world!")]) {:optimizations :advanced})'
    

But I'm not sure this is actually telling us anything.

------
pka
It's interesting to observe how almost all mainstream dynamic languages move
from "who needs types? types are very very bad and just get in the way!" to
some sort of gradual typing or runtime type validation.

* Javascript has Flow/TypeScript

* Python has PEP 484

* Perl6 has some sort of types

* Clojure/Script has core.typed, schema and now clojure.spec

* Don't know about Ruby, but I've seen articles on type checking/annotations

* Erland has Dialyzer (although this is not a recent development)

~~~
protomyth
I have a bit of a theory on that, which I bet will be a bit unpopular but is
based on some social things I have seen. A dynamic language gets popular[1].
As more people show up, they want to bring their way of doing things (e.g.
"prototypes are stupid, we need classes") instead of fully adopting the
language. Improvements are cool but some of the changes alter things in a
fundamental way (e.g. dynamic to static). Sometimes it leads to second systems
(e.g. Objective-C to Swift) and is often accompanied by "the need to grow up".
Then we get a new language.

1) could actually be any language that doesn't fit the mainstream mold

~~~
slowmovintarget
Which is why what Rich Hickey did with clojure.spec is so important...

He acknowledged the deficiency, but worked through it to understand what the
problem actually is. Then he created a solution that solves the real problem,
in a way that avoids diminishing the character of the language.

Have a read through the rationale on the design of clojure.spec to see what I
mean.

[http://clojure.org/about/spec](http://clojure.org/about/spec)

------
conaws
The fact that folks in the comments are complaining here about Clojure's error
messages here tells me that the implications of this post might not be
obvious. Up to this point, it has been really really hard to give good error
messages from macros, and a lot of the core functionality of Clojure (let,
defn etc etc) are from macros. What Clojure.spec means (if I'm correct) is
that in the future, not only will the Clojure language itself be able to have
sane error messages, you'll be able to easily create sane error messages for
yourself from your own code. This is a HUGE HUGE deal. It is quite possibly
BETTER than any type system.
[http://clojure.org/about/spec](http://clojure.org/about/spec) Also, the idea
that you'll be able to get generative testing FOR FREE, is just totally
insane.

------
n72
I hate to harp on this issue, but I tried Clojure for about a year on and off.
I just couldn't get over the really crappy stack traces. I would break
something and then spend 10 minutes tracking down whatever I broke. I'm happy
with Kotlin for the moment, but would love to get back into Clojure if only it
would get sane error messages.

~~~
cle
Clojure is designed to be a practical language. Part of that is interop with
the host VM (JVM in Clojure's case). The "crappy" stack traces are definitely
NOT crappy when you're using Clojure in a complex JVM ecosystem. The raw-ness
and simplicity of it is actually refreshing. The Clojure Java source is
remarkably simple, and it doesn't take much time to get used to and appreciate
the Java stack traces when writing non-trivial Clojure code in a Java world.

~~~
n72
I just don't see how it's remarkably simple. In other langs with good stack
traces I get exactly the error at exactly the line on which it occurred. In
Clojure, I quite simply don't. I do absolutely love the rest of Clojure. I
also realize there are tradeoffs to being hosted. Nevertheless, to deny that
the fact that the stack traces aren't ideal seems a bit of a stretch.

~~~
cle
I'm not claiming they're "ideal", which is a really loaded word. Just that
they're practical, and in my opinion they make the right tradeoffs.

------
agentultra
I appreciate what clojure.spec is trying to do and think it's a good step! If
this kind of thing interests you though I suggest looking beyond the code and
learn the mathematics -- logic, predicate calculus, and the ideas behind
formal methods! It's a wonderful tool for thinking and well worth encouraging.

Try looking up TLA+, Event B, Unity, etc, etc. They've been working on some
neat maths and the tooling around it these days is amazing!

For more hybrid language/spec approaches Agda and Idris are super fascinating.

------
makmanalp
Another "tool for thought" essay, about J: www.jsoftware.com/papers/tot.htm

~~~
jxy
I guess different people speak different languages and have different tools of
thought.

------
conaws
"In my humble opinion clojure.spec is the most VPRI-worthy feature Rich Hickey
has shipped since delivering fast persistent data structures." Love this quote

------
auvrw
i often like dnolen's blog posts for the links as much as the nominal content
..

i thought "tools for thought was a dennet ref, but no,

[http://www.rheingold.com/texts/tft/](http://www.rheingold.com/texts/tft/)

also, i'm now aware of

[https://github.com/ghcjs/ghcjs](https://github.com/ghcjs/ghcjs)

although uncertain how to compare it to purescript..

~~~
_mhr_
I believe that "tools for thought" as a phrase comes from Ken Iverson's
"Notation as a tool for thought" paper.

------
draw_down
Hmm, I wonder what all this means.

~~~
conaws
It means you may soon have amazing error messages when working with Clojure.
You'll also be able to write your code in such a way that it gives you amazing
error messages when some part of it breaks.

