The End of Dynamic Languages
elbenshira.com
The End of Dynamic Languages
1–10 of 30 posts
Re: The End of Dynamic Languages
#2I agree with the author. Even in a "statically typed" language like Go, which has a simple type system, compared to languages like Scala or Haskell, the benefits of static typing are very real and enables a lot of extremely useful tools (code completion, refactoring, linting, whole program analysis, etc.).
Re: The End of Dynamic Languages
#3I think Hiccup is way better than separate HTML templates, much less noisy.
Re: The End of Dynamic Languages
#4I agree with the author. Even in a "statically typed" language like Go, which has a simple type system, compared to languages like Scala or Haskell, the benefits of static typing are very real and enables a lot of extremely useful tools (code completion, refactoring, linting, whole program analysis, etc.).
Code completion, refactoring aids, linting, and whole program analysis also exist in dynamic languages. Take a look at emacs with anaconda-mode for python or cider for clojure. IntelliJ in the forms of Cursive and PyCharm (or the Python IDEA plugin) also support all of these. Even vim can do this stuff (python-mode, fireplace.vim). I don't Ruby very often, but I suspect these tools exist here too.
Re: The End of Dynamic Languages
#5I think Hiccup is way better than separate HTML templates, much less noisy.
Hiccup is different than HTML templates. Hiccup is trivially composable because it's a library based around native data structures. If you want something your designers don't have to think about, Enlive (uses HTML as templates and provides a jQuery-esque transform system) and Selmer (Jinja2 or Handlebars, mixing HTML and a template language) both exist and are well-tested.
Re: The End of Dynamic Languages
#6The author seems to have missed the Ring Spec [1]. It provides a complete breakdown of what is in a ring response and a ring request for the core spec.
The middleware (at least those that ship with ring) are all documented in docstrings explaining the keys they add or work on. This is available in the repl via `clojure.repl/doc` or inspective `(:doc (meta foo))`. It's available in your editor if your editor has clojure support (I only use vim and emacs, and both of these can search/display docs on clojure code). There is also nicely formatted api docs at [2].
[1] - https://github.com/ring-clojure/ring/blob/master/SPEC [2] - http://ring-clojure.github.io/ring/index.html
That said, it would be nice if more of clojure was documented using an executable schema or type system, ala Schema or core.typed. The author would have done well to pick less well-documented libraries though.
Re: The End of Dynamic Languages
#7> that we disdain verbosity
Dynamic languages show there's a tradeoff. Repeating yourself is often useful, when maintenance is expected and code is cheap to produce, without having to worry about strict typing.
Re: The End of Dynamic Languages
#8A completely contrary case can be made where static typing is doomed because hardware is getting more and more powerful, JIT and tracing is getting better and dynamic typing is convenient to the programmer while static typing is very convenient to the compiler and the processor.
It's nonsense, both ways. Both static and dynamic type systems have their uses and, unless we substantially change the way we use computers (which is plausible) I don't see either side wiping out the other.
Re: The End of Dynamic Languages
#9The author seems to have missed the Ring Spec [1]. It provides a complete breakdown of what is in a ring response and a ring request for the core spec. The middleware (at least those that ship with ring) are all documented in docstrings explaining the keys they add or work on. This is available in the repl via `clojure.repl/doc` or inspective `(:doc (meta foo))`. It's available in your editor if your editor has cloju…
Yes, I did miss the ring spec. But as a beginner to ring, I'm not sure how I was suppose to know that such a document exist.
For the most part, Ring is well-documented. But, as you noted, human-typed doc strings go only so far. I applaud the writers of ring in their discipline, but certainly we can do better than depending on human discipline.
You even noted, I picked "less well-documented libraries." I didn't pick them because they were not well-documented—I picked them because I'm using them!
Re: The End of Dynamic Languages
#10The author seems to have missed the Ring Spec [1]. It provides a complete breakdown of what is in a ring response and a ring request for the core spec. The middleware (at least those that ship with ring) are all documented in docstrings explaining the keys they add or work on. This is available in the repl via `clojure.repl/doc` or inspective `(:doc (meta foo))`. It's available in your editor if your editor has cloju…
Yes, I did miss the ring spec. But as a beginner to ring, I'm not sure how I was suppose to know that such a document exist. For the most part, Ring is well-documented. But, as you noted, human-typed doc strings go only so far. I applaud the writers of ring in their discipline, but certainly we can do better than depending on human discipline. You even noted, I picked "less well-documented libraries." I didn't pick t…
I suspect you might have encountered the SPEC if you opened the README of the ring project or visited its github page (which displays the README by default). It's mentioned and linked in that README:
From https://github.com/ring-clojure/ring:
Ring is a Clojure web applications library inspired by Python's WSGI and Ruby's Rack. By abstracting the details of HTTP into a simple, unified API, Ring allows web applications to be constructed of modular components that can be shared among a variety of applications, web servers, and web frameworks.
The SPEC file at the root of this distribution provides a complete description of the Ring interface.