8 ms·

I think you get it backwards. Things are disjointed, loosely coupled because highly dynamic languages have won. The flexibility of dynamic languages, which can

I think you get it backwards. Things are disjointed, loosely coupled because highly dynamic languages have won. The flexibility of dynamic languages, which can be great when working around dynamic corner cases, does not force developers into fixed, well-defined contracts keeping everything loose and disjoint. PHP is highly to blame. PHP, being a scripting language, is easy to deploy and keeps chugging along at all costs. It may do something nonsensical, but it will try to chug along to completion without aborting. It creates a system where it is easy to write and deploy something that usually works.

irjustin 6y ago
I agree with both of you in that I don't think the direction of the origin really matters. The problem is when dealing with other teams/products/api's it's a mess. Varying standards, varying strictness, corner cases everywhere. There are plenty of JAVA, ASP.Net APIs that are absolute nightmares to integrate with despite being strictly typed beginnings. If you have a highly federated space, you control everything and thusly can do cool things like Rust, Lua, what have you. But, most engineers don't get such a luxury. Languages that can be rapidly morphed to accommodate all those situations achieve shipped solutions to business problems faster. In the end, that makes money and that turns our world. Regardless, here's the loosely related XKCD's Standards: https://xkcd.com/927/ https://xkcd.com/927/
- deleted 6y ago
  [deleted]
CraigJPerry 6y ago
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.
raxxorrax 6y ago
If have seen horrible javascript, but I have also seen horrible type-safe examples. It is always a compromise between errors, readability and productivity. Attaching text in form of a script anywhere in the DOM can be abused, but it is also insanely practical. I don't think Javascript is too horrible. I think the whole toolchain to get minimized and bundled JS is. That is why I am wary of TypeScript. Yes, I see its benefits, but I don't like cross-compiling if I can just not do it. Given, I am no web developer and my "projects" on the web are tiny. I completely understand someone who likes to take the increased effort to use TypeScript, especially if your project isn't just making a text blink. If it reaches a certain size, I would probaly look into it too. Webassembly looks interesting, but will take some time to establish itself. There are also disadvantages to that, since it could reduce the openness of the web. All the tracking we are subjected to could only be inspected by network traffic instead of looking into the source.
davedx 6y ago
I completely disagree with this. I work on a large C# platform that interops with a ton of vendor API's, the majority of which are also written in typed languages. The disjointed, loosely coupled nature of web systems is what causes problems. In particular, knowing what a "correct input" is to web systems is very difficult, where correct means: 1) Passes the API's immediate validation 2) Passes validation inside API's longer running processes 3) Passes business rules (it might be correct types, lengths etc, but fails anyway because of an incorrect combination of API calls) Some of our vendors use Elixir, some use PHP, many use C# or Java. I really don't notice any significant difference between them on that account. The issues are all down to the complexity of the software and business requirements and that the whole thing is a giant distributed system.
- Multicomp 6y ago
  > knowing what a "correct input" is to web systems is very difficult I cut my teeth programming an XML web service using soap and while I can't say that it was as drop-dead simple as a restful HTTP web api these days, between the wsdl and the uddi, it sure was convenient to be able to know as a client what methods were being exposed and what inputs they expected. Sometimes I wish the w3c had not required XML for those web services ,so that we could do that with json plus whatever add-ons can make it have an enforceable schema like XML. WSDLs were underrated.
  - davedx 6y ago
    I agree. It was nice being able to grab the WSDL from say, a .NET web service, and run your maven script on your Java app to generate the interop boilerplate and just start coding against a type-safe interface.

irjustin 6y ago

I agree with both of you in that I don't think the direction of the origin really matters. The problem is when dealing with other teams/products/api's it's a mess. Varying standards, varying strictness, corner cases everywhere. There are plenty of JAVA, ASP.Net APIs that are absolute nightmares to integrate with despite being strictly typed beginnings. If you have a highly federated space, you control everything and thusly can do cool things like Rust, Lua, what have you. But, most engineers don't get such a luxury. Languages that can be rapidly morphed to accommodate all those situations achieve shipped solutions to business problems faster. In the end, that makes money and that turns our world. Regardless, here's the loosely related XKCD's Standards: https://xkcd.com/927/ https://xkcd.com/927/

deleted 6y ago
[deleted]

CraigJPerry 6y ago

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.

raxxorrax 6y ago

If have seen horrible javascript, but I have also seen horrible type-safe examples. It is always a compromise between errors, readability and productivity. Attaching text in form of a script anywhere in the DOM can be abused, but it is also insanely practical. I don't think Javascript is too horrible. I think the whole toolchain to get minimized and bundled JS is. That is why I am wary of TypeScript. Yes, I see its benefits, but I don't like cross-compiling if I can just not do it. Given, I am no web developer and my "projects" on the web are tiny. I completely understand someone who likes to take the increased effort to use TypeScript, especially if your project isn't just making a text blink. If it reaches a certain size, I would probaly look into it too. Webassembly looks interesting, but will take some time to establish itself. There are also disadvantages to that, since it could reduce the openness of the web. All the tracking we are subjected to could only be inspected by network traffic instead of looking into the source.

davedx 6y ago

I completely disagree with this. I work on a large C# platform that interops with a ton of vendor API's, the majority of which are also written in typed languages. The disjointed, loosely coupled nature of web systems is what causes problems. In particular, knowing what a "correct input" is to web systems is very difficult, where correct means: 1) Passes the API's immediate validation 2) Passes validation inside API's longer running processes 3) Passes business rules (it might be correct types, lengths etc, but fails anyway because of an incorrect combination of API calls) Some of our vendors use Elixir, some use PHP, many use C# or Java. I really don't notice any significant difference between them on that account. The issues are all down to the complexity of the software and business requirements and that the whole thing is a giant distributed system.

Multicomp 6y ago
> knowing what a "correct input" is to web systems is very difficult I cut my teeth programming an XML web service using soap and while I can't say that it was as drop-dead simple as a restful HTTP web api these days, between the wsdl and the uddi, it sure was convenient to be able to know as a client what methods were being exposed and what inputs they expected. Sometimes I wish the w3c had not required XML for those web services ,so that we could do that with json plus whatever add-ons can make it have an enforceable schema like XML. WSDLs were underrated.
- davedx 6y ago
  I agree. It was nice being able to grab the WSDL from say, a .NET web service, and run your maven script on your Java app to generate the interop boilerplate and just start coding against a type-safe interface.