21–30 of 240 posts
I really liked Aspect-Oriented Programming, despite its great issues with mutually interfering aspects etc. I wonder if it will make it as a big paradigm, but I hope it does.
[1] https://www.cs.ubc.ca/~gregor/papers/kiczales-ECOOP1997-AOP....
I share this sentiment, and I think a lot of it also comes from Rich Hickey talking about it.
As I relate to what this article expresses, I've noticed that people who write lisp type stuff talk about programming in a different way. In some sense there is an academic feel to it. In another sense there is a maker feel to it.
I think Dan Friedman might have said something similar about static typing not helping too much, but saw dependent types as something interesting
> I have never had a static type checker (regardless of how sophisticated it is) help me prevent anything more than an obvious error (which should be caught in testing anyway). Obvious in retrospect is not the same as obvious. And such errors happen all the time, the same way without syntax checks typos happen all the time. And "caught in testing" is 2 extra steps removed from caught immediately by the syntax checker…
(a minor nit that shouldn't detract from your point - since in a dynamic language, you'd have potential type errors in addition to this sort of thing...)
The author hits on the sore point of available libraries to hit APIs and I would add access to deep learning infrastructure. I use the Hy language (hylang, has a Clojure style syntax) that is built on Python (you can get a copy of my Hy book for free, the minimum price is free https://leanpub.com/hy-lisp-python), but I still like Common Lisp as my main driver.
Anyway, I consider myself to be very fortunate to have about half of my career since 1982 use Lisp languages.
Isn't this just plainly false? With dependent type system wouldn't you be able to encode all such invariants into the types? Curry-Howard isomorphism and so on?
In other words, static typing is pointless. It has, maybe,
some documentary value, but it does not substitute
documentation on other invariants. For example, your
invariant might be something like I’m expecting here a
monotonically increasing array of numbers with a mean
value of such and such and a standard deviation of such
and such. The best any static type checking will let you
do is “array[float]”. The rest of your invariant must be
expressed in words as a documentation of that function.
Yes! Lambda calculus is my "native brain programming language" and I can't find a language the expresses it better than the Lisps. I never have to bend around the language, it feels as if I can always do exactly the method I wanted to solve something.
Another big benefit is the simple syntax makes complex metaprogramming achievable. You just move the s-expressions and atoms around. Unnest and nest them. Like normal code. It makes sense.
In other words, static typing is pointless. It has, maybe, some documentary value, but it does not substitute documentation on other invariants. For example, your invariant might be something like I’m expecting here a monotonically increasing array of numbers with a mean value of such and such and a standard deviation of such and such. The best any static type checking will let you do is “array[float]”. The rest of y…
> I have never had a static type checker (regardless of how sophisticated it is) help me prevent anything more than an obvious error (which should be caught in testing anyway). Obvious in retrospect is not the same as obvious. And such errors happen all the time, the same way without syntax checks typos happen all the time. And "caught in testing" is 2 extra steps removed from caught immediately by the syntax checker…
> What improves (and guarantees) software quality is rigorous testing. To deliver high quality software, there is no other solution. This is 100% false. You can’t inject quality into a bad design via testing. You can’t guarantee quality or correctness through testing. Testing is the second worst place to find errors. You get a MUCH higher roi by producing thoughtful written designs and getting them peer reviewed. And…
Testing tends to validate design from the point of testability. If it feels like the code is resisting testing, that usually ends up being an indicator of bad design (though not always vice versa).