4 ms·

This article presumes that everybody wants an elaborate type system. I'm not sure that is the case. I still see an elaborate type system as incidental complexit

This article presumes that everybody wants an elaborate type system. I'm not sure that is the case. I still see an elaborate type system as incidental complexity. I may be in the minority and I may not have worked in domains which benefit from such modeling. Maybe I'm stuck in a blub paradigm. Here's my reasoning. I'm a fan of human language & domain ontologies. Word definitions are quite flexible & do not have an elaborate type system. I don't feel the need to have a provably correct logical system to have a useful conceptual tool (i.e. analogies). I enjoy ambiguity. Ambiguity can lead to paradoxes, which in turn leads to exploration & novelty. Strongly typed systems, by default, give me the impression that the domain ontology is figured out on a highly precise level. That is never the case. You can almost always go deeper. Domain language precision is tough to model & express. I prefer data structures to drive operations. I suppose that a schema is often useful, however I don't feel like I need the programming language to enforce the schema. I also like to evolve the design, using tests. Tests are really examples to exercise the program's API with expected I/O. People often equate an evolved programming language/paradigm as being better. In the case of Javascript, they point out that is was created in a few days as evidence that it's "bad". The thing about an evolved language/paradigm is it has evolved down a certain path. That often means restricting the freedom of the programmer to evolve the program down another path. I'm not picking one way to be better than another. However, I do see tradoffs to both approaches. I personally prefer a more flexible language. It can be evolved, as long as the evolution does not restrict my freedom to evolve the program.

djur 12y ago
This is a good argument in favor of dynamic typing, but Go is not dynamically typed. It has a static type system that its critics consider insufficiently powerful.
Perceptes 12y ago
Ambiguity is not something that's generally, if ever, desirable in a program, so if a simpler type system has that to offer, I'm not sure it's a benefit. You could also argue that a more elaborate type system allows you to be more expressive in the design of your programs, rather than restricting you.
Peaker 12y ago
I recommend Dijkstra's paper: "On the foolishness of "natural language programming" [1]. It explains how natural language is a very poor way to express programs, and how it held back science and progress for many centuries. Strong types describe your code precisely. If your code doesn't match the model yet, that's fine. But your code has invariants in it. Things like: "this variable can never be nil, that variable can". These invariants can relatively easily be encoded as static types. Not doing so is just throwing away safety and documentation for virtually no benefit. Other invariants are similar. Instead of documenting them or keeping them in your head, you let your compiler worry about them. And then when you break those invariants, the compiler is your friend! He helps you go and find all the other pieces of code that relied on the broken invariant, so you can fix them. You say you prefer a more flexible language: But Go is extremely inflexible. It has a very primitive set of tools to do everything, clumsily. A language like Haskell, for example, lets you have Go-like coroutines and channels. But it also lets you program with software transactional memory, or use other parallelism constructs. Also, the inability to specify invariants of your program isn't flexibility. The ability to specify them or opt out of specifying them, which is what strong type systems give you, is. 1. https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/E...
- briantakita 12y ago
  > It explains how natural language is a very poor way to express programs, and how it held back science and progress for many centuries. I'm not interested in using natural language to implement the software (write code). I'm interested in using natural/technical language to create an ontology for the architecture. This is where things get gray. When I think of an architecture, I think of something that evolves over time. I think of architecture as a tool to facilitate communication between programmers, designers, project management, domain experts, & users. This ontology evolves over time as the software, understanding of the domain, & the domain itself changes. I see this fuzziness as an accurate model of the conceptual domain, which is ultimately based on the understanding of multiple humans. This understand is fuzzy and heavily dependent on context. And yet, the ontology attempts to coral this fuzziness into more strongly defined concepts, which map to the implementation. The implementation should not be fuzzy at all. > Other invariants are similar. Instead of documenting them or keeping them in your head, you let your compiler worry about them. I usually use guard clauses to protect against nulls. I rely on my tests & production monitoring systems to prove that the implementation is incorrect. When there is such proof, I correct the system. In environments that support rapid feedback & deployment, like the web, this works well. In environments that don't support rapid deployment, iteration, and where lives are at stake, not so well. > But Go is extremely inflexible. It has a very primitive set of tools to do everything, clumsily. A language like Haskell, for example, lets you have Go-like coroutines and channels. But it also lets you program with software transactional memory, or use other parallelism constructs. That sounds good to me. > Also, the inability to specify invariants of your program isn't flexibility. That mostly sounds good. I would want invariants to be optional, which sounds like is the case.

djur 12y ago

This is a good argument in favor of dynamic typing, but Go is not dynamically typed. It has a static type system that its critics consider insufficiently powerful.

Perceptes 12y ago

Ambiguity is not something that's generally, if ever, desirable in a program, so if a simpler type system has that to offer, I'm not sure it's a benefit. You could also argue that a more elaborate type system allows you to be more expressive in the design of your programs, rather than restricting you.

Peaker 12y ago

I recommend Dijkstra's paper: "On the foolishness of "natural language programming" [1]. It explains how natural language is a very poor way to express programs, and how it held back science and progress for many centuries. Strong types describe your code precisely. If your code doesn't match the model yet, that's fine. But your code has invariants in it. Things like: "this variable can never be nil, that variable can". These invariants can relatively easily be encoded as static types. Not doing so is just throwing away safety and documentation for virtually no benefit. Other invariants are similar. Instead of documenting them or keeping them in your head, you let your compiler worry about them. And then when you break those invariants, the compiler is your friend! He helps you go and find all the other pieces of code that relied on the broken invariant, so you can fix them. You say you prefer a more flexible language: But Go is extremely inflexible. It has a very primitive set of tools to do everything, clumsily. A language like Haskell, for example, lets you have Go-like coroutines and channels. But it also lets you program with software transactional memory, or use other parallelism constructs. Also, the inability to specify invariants of your program isn't flexibility. The ability to specify them or opt out of specifying them, which is what strong type systems give you, is. 1. https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/E...

briantakita 12y ago
> It explains how natural language is a very poor way to express programs, and how it held back science and progress for many centuries. I'm not interested in using natural language to implement the software (write code). I'm interested in using natural/technical language to create an ontology for the architecture. This is where things get gray. When I think of an architecture, I think of something that evolves over time. I think of architecture as a tool to facilitate communication between programmers, designers, project management, domain experts, & users. This ontology evolves over time as the software, understanding of the domain, & the domain itself changes. I see this fuzziness as an accurate model of the conceptual domain, which is ultimately based on the understanding of multiple humans. This understand is fuzzy and heavily dependent on context. And yet, the ontology attempts to coral this fuzziness into more strongly defined concepts, which map to the implementation. The implementation should not be fuzzy at all. > Other invariants are similar. Instead of documenting them or keeping them in your head, you let your compiler worry about them. I usually use guard clauses to protect against nulls. I rely on my tests & production monitoring systems to prove that the implementation is incorrect. When there is such proof, I correct the system. In environments that support rapid feedback & deployment, like the web, this works well. In environments that don't support rapid deployment, iteration, and where lives are at stake, not so well. > But Go is extremely inflexible. It has a very primitive set of tools to do everything, clumsily. A language like Haskell, for example, lets you have Go-like coroutines and channels. But it also lets you program with software transactional memory, or use other parallelism constructs. That sounds good to me. > Also, the inability to specify invariants of your program isn't flexibility. That mostly sounds good. I would want invariants to be optional, which sounds like is the case.