A tool for thought
swannodette.github.io
swannodette.github.io
The only worthwhile way is using Martin Klepsch's "Tenzing" template, but using a template is not a solution.
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`.
I've tried so many times to get started with Clojure and Clojurescript, and when I'm trying to set up the environment from scratch (because to learn it I have to understand how all pieces fit together) I just get hopelessly lost. Broken deps, files to edit to make the Emacs REPL work correctly, snippets of code I have to add here and there to create a simple project.
And last time I checked, now there's this Boot tool to learn, to choose and to understand (and to debug its stacktraces) instead of Leiningein -- ARGH.
I grok a fair share of languages but there's nothing like Clojure, ClojureScript and Javascript to make me feel like an _idiot_. I don't like that feeling.
For the love of $DEITY, language designers, learn from Go: they have an up-to-date spec, an up-to-date "Effective $LANG" document and one (1) simple, official and maintained build tool. Otherwise you're just, as we'd say in Italy, brushing dolls.
I made it to show how easy it is to get started with clj / cljs web development. It uses closp, which covers everyhting from configuration to front / backend work, migration, tests, selenium tests, template generation and so on. Also have a look at the intro: http://closp.net/pages/closp-intro/ which shows how you can get started with 5 commands in the console (given you have leiningen / jdk installed, which would be two more steps, if not).
There is also the possibility to run lein uberjar from the project and get a standalone jar with webserver and compiled clojurescript generated.
Then there is luminus which is somewhat similar and provides much of the same featureset and has a great documentation: http://luminusweb.net
Regarding boot I agree with you, its confusing to have two build tools. It adds some features that leiningen does not provide and for which there was a need. That said, the number one build tool is still leiningen.
Stacktraces are aweful, agreed too, there is no satisfying solution to it that I know.
Well, Go, does it have generics? :D
├── README.md
├── build.boot
├── resources
│ ├── index.html
├── src
│ └── cljs
│ ├── sample
│ │ ├── core.cljs
│ └── main.cljs.edn
└── test
└── cljs
└── sample
└── core_test.cljsProvide all the features of lein-ring, lein-figwheel, and lein-cljsbuild with a simpler setup and no clojure neccessary in a clojurescript project.
Serving compiled clojurescript, reloading cljs and css, with a browser repl, is really simple in boot. The boot tools work together better than the leiningen tools do.
If you look at the Tenzing template's build.boot, which doesn't have a lot going on, you'll see how straightforward the meat of it is, without ending up with other JVMs.
https://github.com/martinklepsch/tenzing/blob/master/resourc...
lein new tenzing some-project
emacs some-project/build.boot
M-x cider-jack-in
// switch to repl:
(boot (dev))
M-x cider-replicate-connection
// switch to new repl
(start-repl)
I stress again that the template really doesn't do a heck of a lot and the build.boot, the filesystem layout, and the way boot works is really the whole of the story. I wish Boot were better documented/marketted, so I could've switched to it long ago.
I am heavily thinking of implementing a language that is inspired by Clojure, but native to the JS land. It would use npm, Mori for data structures and browserify (if not on Node.js) under the hood for requiring libraries. Basically a transpiler from Lisp style code to JS, with better data structures.
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 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.
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})'
Where it regards ClojureScript specifically, doing a simple MVP/PoC web project or a Cordova app is just way faster to get going in vanilla JavaScript.
As to Clojure, every time I have to invoke lein it feels very much like this:
I'm happy to hear why you believe otherwise.
Follow along, hacker news comment reader! This only takes a second!
1. Download and install http://racket-lang.org/
2. Open Racket
3. Type the following into the top text box and click "Run":
#lang web-server/insta
;; A "hello world" web server
(define (start request)
(response/xexpr
'(html
(body "Hello World"))))
Everything builds off of that.
No need to putz with the command line (but you can $ racket that-file.rkt if you want to). No need to fight with Homebrew and Racket's package manager (but there is a package manager if you want it). No need to install support for your own text editor (but if you don't want to use DrRacket, you are more than welcome to Emacs-Major-Mode it up if you want).
Depending on your definition of experiment I think Clojure has a MUCH better story for getting to a good beginner setup with live reloading than webpack/react
* 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)
This is not an example of language moving to gradual typing. Typescript is an entirely new language.
1) could actually be any language that doesn't fit the mainstream mold
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.
- lexical closures
- common set of base types (lists; dicts; sets)
- literals for said types
- immutability
- generators
- asynchrony
So yes, types do get in the way while prototyping but it's great to have them available when refining code.
And types can also help you prototype and then polish rough ideas. For example, I'm exploring a programming style where no unreachable code paths are allowed: in a circumstance where you'd throw an exception or return an error sentinel, I'd refactor the code to eliminate the unreachable branch. This means that abstractions must have the “right shape” (that is, not leak), and types are fundamental to make this work.
When I start adding type annotations, I'm usually aiming for a speed-up but more often it leads to reorganization and rationalization of the code. The code becomes more streamlined and beautiful.
The post below resonates with me. He calls it 'programming by teaching', where you gradually shape a program to solve your problem. I think of it as 'programming by learning', where the Lisp way of developing helps me learn about my problem. It's only when you have the final version of your code that you fully understand the problem by seeing its solution in front of you.
(0) Nominal types correspond to primitive domain entities.
(1) Structural types correspond to compound entities, built from simpler ones.
(2) Abstract types regulate the interaction between different subdomains of a larger domain.
The net result is that the REPL's feedback helps me identify those parts of the problem domain where my understanding is weak. Not only the REPL's feedback, of course. For instance, if my program contains unreachable code paths, it means that I haven't yet found the right abstractions.
The philosophy behind this methodology is that:
(0) The cost of having a wrong program is actually larger than that of having no program, because it takes too much effort to identify the wrong parts so that one can fix them.
(1) When the size a program exceeds a certain threshold, it becomes impossible for ordinary human reasoning to determine with full certainty that a program contains no errors. Only formal logic can help, and only machines can do formal logic at a large scale.
(2) It isn't practical to tackle large problems without a properly enforced separation of concerns.
---
By the way, ironically, I never make an explicit type annotation, except perhaps, perhaaaps, at module boundaries. Figuring out the boring details of how to connect the pieces of a puzzle is a job for computers (type inference), not humans.
The good: it uses a structural type system. For someone who got the good old 'JavaScript is a toy language you should try Java or C#' at university, this feels really refreshing. It mostly works as JS and you get some nice auto complete. So it feels dynamic and not clunky, like the aforementioned 2 'true' languages.
The bad: the tools seem to work random. Sometimes they pick up the definitions, next time you open a file, 'cannot find module 'react'' or numbers in import paths break the auto complete etc. also often you don't find type definitions for you libs and as a type-n00b you often lack the skills to create good ones yourself.
Anyway, I hope with TS 2.0 things will get better. Especially with strict null checks, which hopefully will be a giant win.
But this is the beautiful thing of Clojures hosted nature. Clojure is just a library, that can be dropped into a project. Thinking about it like that made me appreciate the traces.
I used Clojure for a while and we didn't get along despite my attraction to the language, and the hype, I guess. Clojure makes a lot of trade offs to run how it does and where it does and those choices don't necessarily add up to the experience I, or others who seem to crop up here, prefer.
While I haven't tried Kotlin, I'm aware of it and know that it isn't all that different from Scala, which is a bit more my style.
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.
i thought "tools for thought was a dennet ref, but no,
http://www.rheingold.com/texts/tft/
also, i'm now aware of
https://github.com/ghcjs/ghcjs
although uncertain how to compare it to purescript..