Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dynamic type systems are not inherently more open

lexi-lambda.github.io

Post reply on HN
Print view View original

151–160 of 286 posts

Re: Dynamic type systems are not inherently more open

#151

Post by mamcx »

This have a mirror with the "sql"/"nosql" debate. Being "schemaless" is supposedly a great advantage of nosql, but the thing is that sql/relational is as schemaless as you want!

The only thing is that rdbms push to create a static modeling of the FINAL STORAGE that is close to be the ideal of it. But anyway, you can create/delete/change tables as you wish (is not impossible to see dbs withs 100/200 tables), and SQL in fact build on the fly relations with the schema you want (SELECT field, field....).

Where is truly weak is that not extend the relational model to INNER values (so you can't "SELECT (SELECT chars FROM name)) but is a limitation of sql, not the relational model.

BTW, I think the relational model is very close to the ideal here? is nominal, is structural, you can re-model data AND types(relations), can have reflection and still see with clarity all the types you have use. What else it need to be useful??.

Re: Dynamic type systems are not inherently more open

#152

Post by weberc2 »

paganel wrote: post #27
MaxBarraclough wrote: post #16

Earlier quoted context omitted.

> This "be liberal in what you accept" idea, applied to modern programming, always struck me as strange. Agreed. There's a reason that serious correctness-oriented languages, like Ada, do not use this approach.

Almost nobody uses Ada, though, while one of the most read programming language-related websites (lambda-the-ultimate) is written in a dynamic language. Also, in the day-to-day interactions of the real world we almost never carry out “validation”, we stop at “parsing” most of the time, otherwise almost nothing will ever be done. In other words “walks like a duck/quacks like a duck” is enough for most of the open worl…

> In the real world we can still use any piece of wood or stone as a table as long as food doesn’t fall off it, because said piece of wood/stone quacks and walks like a table, while Plato or Aristotle or most of the static type proponents would argue that we shouldn’t do that as that piece of stone or wood doesn’t have 4 legs and as such is not really a table/doesn’t correspond to the idea/type of a real table.

You’re advocating for structural typing, which is a property of (many) static type systems. The view you project onto Aristotle/Plato/static-type-advocates is nominal typing, which is just a different kind of static typing. Many languages support both kinds (for example, Go, Rust, and Python’s static type system, Mypy).

Note that languages with structural typing will correctly accept your stone table and reject objects unsuitable for holding food (where “holding food” is the structure a type must implement) while a dynamic type system will happily allow anything to be passed in as the table, including a waterfall or communism and you’ll be none the wiser until your bread is wet or your country is starving.

Re: Dynamic type systems are not inherently more open

#153

Post by msla »

yakshaving_jgt wrote: post #117
jmull wrote: post #97

The author doesn’t really address the issue raised in the first (longer) quoted post. Given a set of reasonable requirements I think pretty much no one would claim a general-purpose language couldn’t satisfy them without too much trouble. In fact, that might be a fair definition of a general-purpose language. I’m fine with strong and expressive static type-checking, but you need to hold the main limitation in mind as…

> I’m fine with strong and expressive static type-checking, but you need to hold the main limitation in mind as you use it in a distributed environment: the guarantees are static. They pertain only to your little binary and don’t say anything about the rest of the system. To argue that a static type system is not valuable because it doesn't enforce constraints on other external systems it doesn't know about is a pret…

Some kinds of static type systems (by which I mean all of the widespread ones which aren't Haskell or similar to Haskell) make extremely specific guarantees static, such that you can't change mere implementation details without rewriting a lot of code. For example, if you're using a library which specifies floats as an input type, and you now need doubles, you're pretty well screwed: You either rewrite and recompile a huge chunk of code or you decide you don't need to expand your precision after all.

Does the library code really need to use 16-bit floating-point values, or does it only use them because someone twenty years ago believed in some superstitions about performance? That information isn't available. It isn't in the type system, so it can only be in the documentation... oh, wait, documentation focuses on How and not Why, doesn't it? Your static type system was made by people who failed to disambiguate between storage size specifications and semantics, so you're left with "16-bit IEEE floating point" as the only semantic information you're ever going to have.

Re: Dynamic type systems are not inherently more open

#154

Post by paganel »

weberc2 wrote: post #152
paganel wrote: post #27

Earlier quoted context omitted.

Almost nobody uses Ada, though, while one of the most read programming language-related websites (lambda-the-ultimate) is written in a dynamic language. Also, in the day-to-day interactions of the real world we almost never carry out “validation”, we stop at “parsing” most of the time, otherwise almost nothing will ever be done. In other words “walks like a duck/quacks like a duck” is enough for most of the open worl…

> In the real world we can still use any piece of wood or stone as a table as long as food doesn’t fall off it, because said piece of wood/stone quacks and walks like a table, while Plato or Aristotle or most of the static type proponents would argue that we shouldn’t do that as that piece of stone or wood doesn’t have 4 legs and as such is not really a table/doesn’t correspond to the idea/type of a real table. You’r…

> (where “holding food” is the structure a type must implement) while

I guess it's turtles all the way down, because (from my pov at least) deciding on what "structures a type must implement" is pretty similar to saying "a table is a table only if it's got 4 legs". Again, from my pov, a dynamic-like language is a lot more tolerant with the unknown unknowns of which the open world is full of, it doesn't depend on any "structure implementation" being defined or on anyone else counting the legs of said table.

Re: Dynamic type systems are not inherently more open

#155

Post by leshow »

capableweb wrote: post #100
pron wrote: post #95

Earlier quoted context omitted.

Not all untyped languages are the same. E.g. Clojure now encourages specifying assumptions with spec annotations, some of them are stronger than those that can be expressed by Haskell's type system: i.e. they can succinctly express more about the "entire code" than Haskell's types. Types are not the only way to write formal assertions and assumptions about code. The difference between the two is in the level of sound…

Also, the following part isn't necessarily because of dynamic typing vs static > what types all the variables are, what expectations are attached to them, what mutation, if any, each method call performs But more about what the language offers. Clojure for example, goes beyond types with it's abstractions (like seq, that can be applied to strings, lists, maps and so on) and normally stays away from mutation, but when…

Commented elsewhere here but static languages can do this also via ad hoc polymorphism or bounded polymorphism.

Re: Dynamic type systems are not inherently more open

#156

Post by dmux »

sethammons wrote: post #61
david_draco wrote: post #10

Earlier quoted context omitted.

Interesting, I would have said static typing allows more technical debt. Illustrating example: Lets say you pass a double variable from some part of your code through 13 layers of APIs until it is actually looked at and acted upon. Now you realise that you not only need a double, but also a boolean. In dynamic typing, you can make a tuple containing both and only modifying the beginning and end points. In static typi…

You'd love Perl. Just pass @_ through your callstack. Want a new value available 20 functions deep that is available at the top? Just toss it in @_ at the top and you are done. The problem? Every one of your 20 levels of functions/subroutines has an unnamed grab bag of variables. You get to keep that in your head. If you want to know if you have a value in a given branch of code, your best bet, aside from reading the…

Isn't passing @_ around similar to a concatenative language pushing and popping things off the stack?

Re: Dynamic type systems are not inherently more open

#157

Post by hhas01 »

nearbuy wrote: post #126
ema wrote: post #5

I've come to the conclusion that the benefit dynamic typing brings to the table is to allow more technical debt. Now of course technical debt should be repaid at an appropriate moment but that appropriate moment isn't always "as soon as possible". Let me illustrate, say you're adding a new feature and create lots of bugs in the process. Static typing will force you to fix some of these bugs before you can test out th…

The trade-off is that the bugs flagged by static type checking are usually quick to fix (eg: function expected an int but was passed a float). With dynamic typing, the subtle bug that arises from the function unexpectedly truncating your float could take an hour to track down and outweigh any time saved from dynamic typing. This applies even when trying out new experimental features.

Depends on the language. I do agree that lossy coercions are a Bad Idea; a [mis]feature added with the best of intentions and inadequate forethought (e.g. AppleScript, JavaScript, PHP).

OTOH, a good [weak] untyped language should accept a float where an int is expected as long as it has no fractional part (otherwise it should throw a runtime type error, not implicitly round). Depending on how weak the language is, it could also accept a string value, as long as it can be reliably parsed into an int (this assumes a canonical representation, e.g. "1.0"; obviously localized representations demand explicit parsing, e.g. "12,000,000.00").

A good rule of thumb, IMO, is: “If a value looks right, it generally† is.” This is particularly true in end-user languages where conceptual overheads need kept to a bare minimum. (Non-programmers have enough trouble with the “value” vs “variable” distinction without piling it with type concepts too.)

--

† Ideally this qualifier wouldn’t be needed, but there may be awkward corner cases where a simpler data type can be promoted to a more complex one without affecting its literal representation. That raises the problem of how to treat the latter when passed to an API that expects the former: throw a type error or break the “no lossy conversion” rule? There’s no easy answer to this. (Personally, I treat it as a type error, taking care in the error message to state the value’s expected vs actual type in addition to displaying the value itself.)

Re: Dynamic type systems are not inherently more open

#158

Post by [deleted] »

pron wrote: post #95
UglyToad wrote: post #29

I think there's a perhaps irreconcilable disconnect between 2 camps here, but I also think that's ok and different people are allowed to like different things. My experience, having gone from dynamic typing to static typing and now pining for more expressive type features in my chosen language is that static typing changes where you have to spend the cognitive complexity budget. To my mind if I return to a piece of d…

Not all untyped languages are the same. E.g. Clojure now encourages specifying assumptions with spec annotations, some of them are stronger than those that can be expressed by Haskell's type system: i.e. they can succinctly express more about the "entire code" than Haskell's types. Types are not the only way to write formal assertions and assumptions about code. The difference between the two is in the level of sound…

[deleted]

Re: Dynamic type systems are not inherently more open

#159

Post by mckinney »

The Manifold project [1] nicely illustrates the author's proposition regarding structural typing and static type systems. Using the Manifold library you can indeed create structural interfaces [2] in Java similar to those in TypeScript. Manifold also enables the use of structural interfaces with Maps, it's pretty amazing.

[1] https://github.com/manifold-systems/manifold [2] https://github.com/manifold-systems/manifold/tree/master/man...

Re: Dynamic type systems are not inherently more open

#160

Post by leshow »

azhenley wrote: post #83
zitterbewegung wrote: post #44

Earlier quoted context omitted.

Using Type inference[1] on a language could be able to figure out types in most situations. [1] https://en.wikipedia.org/wiki/Type_inference

Yes, but "Type inference has usability problems". http://web.eecs.utk.edu/~azh/blog/typeinference.html

I'm curious why you quote this like it's a fact when it's an opinion. The understanding of type inference used as the basis for making the argument in that blog post is superficial. Type inference doesn't just allow you to leave off type information from variables. A good inference engine will infer the most generic type for variables (and functions!), it's a discovery that you can query the compiler for in order to do type driven development.

A full rebuttal of this blog post would take much longer, but suffice to say inference does the exact opposite of what they are claiming; it increases readability and usability.

Post reply on HN