5 ms·

Applying a schema doesn’t fix an architecture problem. Describing those fixed well defined contracts on top of the architurally absurd stack that is TCP/DNS/TL

Applying a schema doesn’t fix an architecture problem. Describing those fixed well defined contracts on top of the architurally absurd stack that is TCP/DNS/TLS/HTTP/Ajax/Dom/JS engine/Server side graphql/rpc/rest / database... doesnt by you anything but slower iteration speed and an unwieldy schema. These components don’t have the same impedance, the same flavour to their design. Necessarily their schema would be a mess. Also, what stops something like function add(int a, int b) -> int { return a-b; } Typing is overrated. It has productive use cases for sure, but only in specific scenarios. It is no panacea. What would be nice is typing like typescript - optional typing. Where i can provide a typings binding separate from the code (in the way that i can bring my own tests without changing anything of production code if you’ve made an unholy mess of testing). Same argument for optional typing outside the main source code - odds on you’re going to misunderstand or misuse types, I’d like to use them where they make sense and ignore your steaming pile of types. Impossible in a language like haskell where types are inline rather than annotations attached to code.

uryga 6y ago
> Also, what stops something like [defining add as subtraction] cmon... "it doesn't guard you against every logic error under the sun" isn't a great argument
- jashmatthews 6y ago
  There's no strong evidence that static typing helps reduce application logic bugs https://danluu.com/empirical-pl/ https://danluu.com/empirical-pl/ Under the same pressures it's pretty likely that the same teams that deploy dynamic language code to production and get an unexpected nil deploy statically typed code to production which unwraps an unexpected None and throws exceptions or panics.
  - ImprobableTruth 6y ago
    >There's no strong evidence that static typing helps reduce application logic bugs https://danluu.com/empirical-pl/ https://danluu.com/empirical-pl/ There's no evidence proving the opposite either. We can't say anything beyond that the existing studies don't really show anything. I think it's pretty obvious that the limit of static typing reduces logic bugs (since it can actually be used to prove statements about the logic), but beyond that everything is kind of up in the air. >Under the same pressures it's pretty likely that the same teams that deploy dynamic language code to production and get an unexpected nil deploy statically typed code to production which unwraps an unexpected None and throws exceptions or panics. There's nothing to support that that this is 'pretty likely'. As far as we know, it could very well be that statically typed languages push you in the direction of handling it the right way. Or hell, it could be that a team using a dynamic language is more cautious and conscious of edge cases.
knubie 6y ago
> What would be nice is typing like typescript - optional typing. Where i can provide a typings binding separate from the code (in the way that i can bring my own tests without changing anything of production code if you’ve made an unholy mess of testing). A contract system like clojure's spec sounds close to what you're describing.
ImprobableTruth 6y ago
I don't understand this reasoning at all. You have some form of contracts, whether you specify them or not. If it's too messy to formalize, that's still going to be an issue when you're working on it in an untyped language. At best you're just sweeping all those ugly edge cases under the rug. >Also, what stops something like having a more precise specification. E.g. adding a commutativity requirement would eliminate your example.

uryga 6y ago

> Also, what stops something like [defining add as subtraction] cmon... "it doesn't guard you against every logic error under the sun" isn't a great argument

jashmatthews 6y ago
There's no strong evidence that static typing helps reduce application logic bugs https://danluu.com/empirical-pl/ https://danluu.com/empirical-pl/ Under the same pressures it's pretty likely that the same teams that deploy dynamic language code to production and get an unexpected nil deploy statically typed code to production which unwraps an unexpected None and throws exceptions or panics.
- ImprobableTruth 6y ago
  >There's no strong evidence that static typing helps reduce application logic bugs https://danluu.com/empirical-pl/ https://danluu.com/empirical-pl/ There's no evidence proving the opposite either. We can't say anything beyond that the existing studies don't really show anything. I think it's pretty obvious that the limit of static typing reduces logic bugs (since it can actually be used to prove statements about the logic), but beyond that everything is kind of up in the air. >Under the same pressures it's pretty likely that the same teams that deploy dynamic language code to production and get an unexpected nil deploy statically typed code to production which unwraps an unexpected None and throws exceptions or panics. There's nothing to support that that this is 'pretty likely'. As far as we know, it could very well be that statically typed languages push you in the direction of handling it the right way. Or hell, it could be that a team using a dynamic language is more cautious and conscious of edge cases.

knubie 6y ago

> What would be nice is typing like typescript - optional typing. Where i can provide a typings binding separate from the code (in the way that i can bring my own tests without changing anything of production code if you’ve made an unholy mess of testing). A contract system like clojure's spec sounds close to what you're describing.

ImprobableTruth 6y ago

I don't understand this reasoning at all. You have some form of contracts, whether you specify them or not. If it's too messy to formalize, that's still going to be an issue when you're working on it in an untyped language. At best you're just sweeping all those ugly edge cases under the rug. >Also, what stops something like having a more precise specification. E.g. adding a commutativity requirement would eliminate your example.