What are your thoughts surrounding static and dynamic typing?
There's a new development[0] within Common Lisp that aims to support static type checking.
My experiences with static type checking have been annoying at best.
Here are some supplemental statements[1], which I hope will serve as a springboard for further discussion.
~Static Typing~
Advantages:
- More errors are caught
- One can refactor with greater confidence
- Can ease the mental burden of writing programs
- Types serve as documentation
Disadvantages:
- Time investment
- The actual error report is vague at best
- Suffocating
- Boilerplate
- Difficult & choice fatigue
[0]: https://github.com/coalton-lang/coalton
[1]: https://pchiusano.github.io/2016-09-15/static-vs-dynamic.html
As you say there is pros and cons. I am not adverse to static typing but it depends on the circumstances. For a short/mid-length script it's pretty much overkill. For larger projects i prefer the clarity of static types as it not only enables the compiler to catch stupid errors but also reminds you of what kind of data your dealing with. Obviously you can also have static types that are mostly meaningless (like passing around pointers to char/uint8_t representing binary blobs of some magical size - don't do it's impossible to define a meaningful type...) but if care is taken the result is quite helpful when reading the resulting code.
>>1,2
You can statically infer types ala SML, but you have to limit expressiveness of the type system. With full type inference you would struggle to implement an object system for example. Alternatively the route of Idris is to ignore inference for the sake of having a very expressive type system (e.g. dependent types) such that it can express constraints which are more meaningful, and less suffocating. Often languages achieve neither however and chart a route in the middle, having types which can be inferred, while most type them explicitly, and with limited expressiveness.
"Static" implies stagnation and lack of progress. "Dynamic" represents constant change, activity, progress, vigor, and new ideas. Therefore, dynamic is better than static.
OCaml has an object system with type inference.
>>4
This is strangely accurate.
Recently I explored alternatives to Lisp - one contender was Nim.
But because of their syntax tree as well as typing, the macros weren't as powerful. It's a great contender still, but nevertheless.
It'll be interesting to see how this coalton development takes off, but c'est la vie. Dynamic just works.
>>4
That's why people move to California, they prefer "dynamic" buildings.
>>5
iirc OCaml has many constructs which can't be infered.
>>8
Please try to remember, I would be interested to see some.
>>9
I haven't looked at OCaml in years, what I was recalling was this chapter from the manual: https://ocaml.org/manual/polymorphism.html Declaring a module requires typing each function interface (once again iirc), and in general OCaml programmers type every function rather than having the types inferred.
What compels someone to write a web server in Haskell and deploy it with Nix?
https://github.com/digitallyinduced/ihp
Someone here recently mentioned Guix. It doesn't seem there's an easy way to port it to Mac so I looked at Nix for a bit too. A lot has changed.
But what's more strange is a bunch of people obsessed with Nix - like it's their main interest.
What causes this fanaticism...
Well, if I look at its WP description:
Nix is a cross-platform package manager that utilizes a purely functional
deployment model where software is installed into unique directories generated
through cryptographic hashes. It is also the name of the tool's programming
language. A package's hash takes into account the dependencies, which is claimed
to eliminate dependency hell.This package management model advertises more
reliable, reproducible, and portable packages.
There are so many words there that people get fanatical about.
>>11
There are various themes of "safety" in that system. For the case of the Haskell language, there's the safety of the language and also the safety of the language paradigm of being purely functional. For the case of Nix, there's the safety relating to the deployment of the binaries, system extensions, and system configuration being purely functional. Having a (reliably) reproducible system deployment is a very convenient way to reason the correctness of the system functions. This kind of correctness is useful everywhere but is also highly useful for the public facing service that is the web server.
>>11
I just find it strange that people dedicate their time toward package management, but I guess it is a real difference from the usual way of things.
I'm glad there are people out there interested in this stuff, so I can conveniently fetch things
>>13
Now I feel naked with my dynamic languages and deployment systems.
Is it worth integrating such complex deployments for, say, a Lisp web server?
>>14
If you're writing your own custom web server for your own purposes, there probably isn't a need to manage the system through a purely functional system packager like Nix or Guix. The reason is that I expect you to have a complete understanding of your web server so you can control every part of it when things go wrong. Having said that, I think the benefits of the purely functional system packager (like Nix and Guix) are compelling enough to take on the burden of studying them. These packaging systems are significantly more sophisticated than other packaging systems and so it's easy to lose motivation to get through the very high learning threshold.
I just find it strange that people dedicate their time toward package management,
I'm glad there are people out there interested in this stuff, so I can conveniently fetch things
"Types are Anti-Modular"
https://gbracha.blogspot.com/2011/06/types-are-anti-modular.html
"Types Considered Harmful" by Benjamin C. Pierce.
https://www.cis.upenn.edu/~bcpierce/papers/harmful-mfps.pdf
Down with types!
Scheme is the optimal programming language!
How can you even type without moving?
I think a lot about this (and I'm new - is it comfy here?)
With apologies for ignoring whatever OP was writing about, a while
ago someone published an article about their port of ACL2 guards
to common lisp and I assume it's pretty much that.
Now I perceive three problems. The first is that the distinction
between #'compile and #'compile-file is very important already,
and it seems like the type people pretty much are noticing that
#'compile-file is important and forgetting that it's not always
what you're doing.
At least the ACL2 guards but for common lisp approach also uses
a tool that was not made with CLOS in mind-
Or the MOP, which is the third problem.
My conclusion is that this ouevre of deviations from the standard
probably have a place in specific contexts but they are not
improvements to the standard as such.
lisp24lyfe