3 ms·

This is definitely the best argument for dynamically typed languages I've seen yet, but I think I have an answer. I've been reading a book on Idris called "Type

This is definitely the best argument for dynamically typed languages I've seen yet, but I think I have an answer. I've been reading a book on Idris called "Type-Driven Development", and I think that Idris has this exact issue figured out. Instead of developing normally, writing code, then compiling, then testing, then raising a CR, you work with a REPL that helps you fill out parts of the code as you go. So what you can do is just type `> :t what_is_this_type?` where what_is_this_type is a hole for the thing you don't know how to type yet. So with this REPL based development you don't even have to try to figure out the type. So IMHO, it fundamentally comes down to the power of the statically typed language. If you're working with Java, C++, C#, etc, type inference can help a lot but ultimately can't give you everything you want. Precisely because of that dynamic, runtime input. But if you have a functional language, like Haskell, Idris, or Clojure, you actually can precisely type that input and have something reasonable looking come out at the other end.

jiggawatts 5y ago
Precisely. I've been thinking of making a "toy" programming language, and that Idris feature gave me some ideas. I like to use the select/project operator as an example precisely because it is so basic, yet so revealing of the gaps in modern programming languages (static typed or dynamic). It really is very fundamental to not just verification of correctness, but also performance, data security, API surface design, and a whole host of things that are causing a lot of grief for a lot of programmers. The "ORM impedance mismatch" is in no small part caused by this issue. Imagine a not-so-hypothetical scenario of wanting to make a Web API for something like "get cloud virtual machine". A virtual machine might have hundreds of properties! Everything from creation time, licensing mode, SKU, status, etc, etc... So of course, for efficiency, you want the API to only return the relevant columns, right? Currently, there is no way to do this in most programming languages without reams and reams of dynamic typing of some sort, somewhere. One way or another you will be explicitly treating the returned rows as hashtables, arrays of "object", or something. More than likely, you'll have to dynamically generate the SQL/NoSQL query as text. You'll have to write nested loops to handle the rows and columns. Then all of this will have to be repeated on the client side, but likely with different languages. There's a decent chance that the trivial operation of "select {set of columns} from table" will end up executing a hundred megabytes of code in the end-to-end path and take multiple seconds to return a couple of kilobytes of data. It's madness.

jiggawatts 5y ago

Precisely. I've been thinking of making a "toy" programming language, and that Idris feature gave me some ideas. I like to use the select/project operator as an example precisely because it is so basic, yet so revealing of the gaps in modern programming languages (static typed or dynamic). It really is very fundamental to not just verification of correctness, but also performance, data security, API surface design, and a whole host of things that are causing a lot of grief for a lot of programmers. The "ORM impedance mismatch" is in no small part caused by this issue. Imagine a not-so-hypothetical scenario of wanting to make a Web API for something like "get cloud virtual machine". A virtual machine might have hundreds of properties! Everything from creation time, licensing mode, SKU, status, etc, etc... So of course, for efficiency, you want the API to only return the relevant columns, right? Currently, there is no way to do this in most programming languages without reams and reams of dynamic typing of some sort, somewhere. One way or another you will be explicitly treating the returned rows as hashtables, arrays of "object", or something. More than likely, you'll have to dynamically generate the SQL/NoSQL query as text. You'll have to write nested loops to handle the rows and columns. Then all of this will have to be repeated on the client side, but likely with different languages. There's a decent chance that the trivial operation of "select {set of columns} from table" will end up executing a hundred megabytes of code in the end-to-end path and take multiple seconds to return a couple of kilobytes of data. It's madness.