This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-13
Channels
- # aleph (1)
- # announcements (14)
- # aws (8)
- # babashka (3)
- # beginners (49)
- # cider (6)
- # clara (7)
- # clj-kondo (58)
- # cljs-dev (17)
- # clojure (65)
- # clojure-dev (45)
- # clojure-europe (5)
- # clojure-italy (4)
- # clojure-nl (25)
- # clojure-norway (3)
- # clojure-uk (68)
- # clojurescript (10)
- # cursive (5)
- # datomic (12)
- # emacs (24)
- # fulcro (149)
- # hoplon (56)
- # kaocha (2)
- # luminus (18)
- # malli (7)
- # off-topic (12)
- # other-languages (82)
- # reagent (16)
- # reitit (7)
- # shadow-cljs (44)
- # spacemacs (4)
- # tools-deps (48)
- # xtdb (17)
If we want to discuss the pros and cons of static typing vs dynamic typing đ
I wrote the question in the Clojure channel because the documentation suggest that you should avoid type hints without any reason given
Right, and you got an answer from one of the core Clojure team on that.
In Clojure, type hints serve to avoid reflection (and improve performance) in some situations. But they are not like type declarations in other languages. They are just hints for the compiler.
https://binged.it/370ZmtD Rich Hickey Maybe Not
Thanks đ
In general I do think it's nice to avoid reflection. Sooner or later you want that anyway is my experience. It also works better if you're going to run the code through GraalVM
There is a flag *warn-on-reflection*
which you can set. Then the compiler will warn you if it cannot infer the types it needs to avoid reflection.
In general, discussions about static vs dynamic typing are a bit pointless because most of the discussion is subjective: some developers prefer static typing because they believe the restrictions it places on your code are worth the avoidance of certain errors; other developers prefer to avoid those restrictions in exchange for losing the ability of the compiler to detect certain possible errors.
It's worth noting that static typing tends to prevent you from writing a certain class of programs that are correct at runtime but fail at compile time due to type checking.
Can you give one/two concrete examples? Where can I read more on this? I have a feeling this is true, but cannot think of good examples.
@UJRDALZA5 https://courses.cs.washington.edu/courses/cse341/04wi/lectures/13-dynamic-vs-static-types.html -- that course ran on Coursera for several years as "Programming Languages" (I took it back in 2012 out of curiosity and then I was a Community Teaching Assistant for it for several more runs).
Well I like to have a high level of IDE support, and I am rather disappointed with the tools I have tried to set up for that (in VSCode)
@jakob.riishede.moller Have you tried Calva?
Clojure has core.typed
(aka Typed Clojure) that provides an optional static type checker based on annotations being added to the code. It's kind of painful to use tho' and there are certainly Clojure idioms that core.typed
won't accept: you have to refactor to code that can be annotated to satisfy the type checker.
I use calva - I find it a little buggy
You can also try Cursive / IntelliJ, it's been around for a while and is the most IDE-like. Disclaimer: I don't personally use it.
Most editor integrations rely on runtime inspection -- code completion, docstrings, etc. But most editor integrations can also run static code checkers (linters) like Joker and clj-kondo.
Oh - nice to know đ
Yeah, Cursive is the most IDE-like in terms of the features it provides -- but most Clojure developers prefer lighterweight editors (Emacs, vim, Atom, VS Code)
@jakob.riishede.moller An interesting podcast to listen to: S2 E2 - REPL with Stuart Halloway https://clojurescriptpodcast.com/ There one of the Clojure core team members explain sophisticated IDE tooling vs spartan tooling and why you need very little with Clojure oftentimes
https://www.surveymonkey.com/results/SM-S9JVNXNQV/ covers the State of Clojure results for 2019 -- Q12 shows the breakdown by editor choice
It's probably a different philosophy: Clojure is a pretty minimal language with a small set of features that compose nicely. Compare that to e.g. Scala or C++ which is quite impossible to use without an IDE
Java is also virtually impossible to write without IDE support (totally agree on Scala and C++ too).
The difference between these languages is also: Clojure is interactive, the REPL is your main tool, whereas with the other languages you have a write / compile / run cycle which gets tedious and you depend on external tooling to get things right before you can even run something
@U050MP39D I wonder how much that 30% overlaps with the 30% that came to Clojure from Java?
well. with an intermediate stop at lighttable and getting burned developing a bunch of plugins etc for a small editor that got abandoned đ
My arc was pretty much Java -> Groovy -> Scala -> Clojure with Eclipse as my primary IDE until I got to Clojure.
@jakob.riishede.moller If you want to get the most leverage out of Clojure without depending on other tools, learn to use the REPL well: https://clojure.org/guides/repl/introduction
I will try to - I'm not used to that though (programming PHP at work đŤ)
(and Clojure's REPL is fundamentally different to other languages' REPLs by the way -- in Clojure, the semantics of compilation match the semantics of the REPL: you could feed your entire program to the REPL in the appropriate order and it would be identical to how Clojure compiles the code from disk).
I think Stu talks about the semantics compared to other languages in his REPL-Driven Development talk (given to the Chicago Clojure meetup a few years ago)...
He specifically compares Clojure's REPL to Java "new" shell on one slide.
I have bookmarked it đ
Even in languages that have some sort of add-on REPL (which is usually an interpreter, rather than compiled like regular code), the typical workflow is still edit-compile-test. In Clojure, the REPL makes it possible to edit & test your code in an expression-by-expression workflow: the tightest feedback loop possible.
@jakob.riishede.moller Other than PHP in your day job, what other languages have you worked in fairly extensively? Curious to draw comparisons with Clojure.
Well - it may look curious, but in later PHP versions some level of type hinting is supported and can be utilized for dependency injection and good IDE support
And I dont do the usual Laravel
Yeah, I remember PHP starting to develop a type system (I did a fair bit of PHP in the 3.x and 4.x days and stopped just into the 5.x days, if I remember correctly).
Now it is 7.3
A friend of mine became a PHP developer just as 7.x was coming along and his code looks a lot more Java-y than any PHP I ever wrote.
Well, Java that has been completely peppered with additional punctuation "noise" đ
I think, it requires a lot of discipline to use PHP in a sound way
Clojure requires discipline too -- but it also makes it hard to write imperative, mutable code so that's definitely a win. Some people run into NPEs (null pointer exceptions) a lot in Clojure but I think that depends on coding style -- I run into that sometimes but nowhere near as often as I did when I first learned Clojure back in 2010.
I heard a rumour that Robert C. Martin spend 5 years getting happy with Clojure?
Uncle Bob loves Clojure đ
Oh I meant spent - not spend
It's definitely got a learning curve -- and a lot of people never get comfortable with it. I've used dozens of languages over my 35 year professional career and I enjoy Clojure more than any other language.
And, in addition to the dozen or so languages I've used in production, I try to learn a new language for fun every year or two.
I'm a little familiar with TypeScript too
(I am a web-developer, but have spent most of the time doing backend stuff)
Elm is a great frontend alternative to JS. It achieves its guarantees by being very opinionated about architecture and generally very restrictive overall via types and the deliberate design constraints in the language.
Yes - I am impressed by the little I know about Elm
If I had to do frontend work, I'd probably go with ClojureScript so I could share code between the front and back end (and share data easily too as EDN). But if I wasn't doing Clojure on the backend and needed to do frontend stuff, I might consider Elm (although when I built a little web app to monitor my solar panel system, I did get pretty frustrated with how restrictive Elm feels to me).
Why not TypeScript?
If I couldn't do Clojure on the backend and still wanted to be on the JVM, I'd probably go to Kotlin. I've done Scala and wouldn't really want to go back to that.
Because TS is JS + types and I absolutely detest JS as a language.
I know how you feel
(my background is in language design and compiler/interpreter systems so I tend to have very strong feelings about languages đ )
I think TypeScript is an improvement though
But the webpack circus...
Oh sure... almost anything is an improvement on JS đ I mean, CoffeeScript is an improvement too but I still find CS horrible to write programs in!
In some ways, I'd have liked Haskell to take over the world as the #1 mainstream language -- because my PhD work was on ML-family syntax languages and type inference -- and then we probably wouldn't be having any of these discussions :rolling_on_the_floor_laughing:
Can you imagine a compiler from Clojure to webassembly?
But I also grew to love Lisp back at university so I would always have had a soft spot for something like Clojure too...
I am a Ph.D. in applied probability - so - I like the functional approach
Does WebAssembly have managed GC yet? That seemed to be the stumbling block when Clojure to wasm has been discussed in the past...
I don't know - I just find the idea to replace JS promising đ
@jakob.riishede.moller Considering your background, maybe https://probprog.github.io/anglican/ is interesting to play with
https://github.com/WebAssembly/gc/issues/36 -- fascinating read, and includes feedback from the Scala.js and Elm maintainers.
It was great chatting - but I have some housekeeping to do (I am single đ) and it is 10pm in Denmark
@jakob.riishede.moller Greetings from The Netherlands (same timezone)!