What to Know Before Debating Type Systems (2008)

https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/

by furcyd • 7 years ago

190 131 7 years ago

cdsmith.wordpress.com

jononor• 7 years ago

Note that the original is back up again now (at new location). Linked in first paragraph.

sctb• 7 years ago

Thanks! We've updated the link from http://blog.steveklabnik.com/posts/2010-07-17-what-to-know-b....

saagarjha• 7 years ago

It seems like the link has been silently updated.

Edit: Not quite silently, it's just that I clicked it while sctb was typing out his comment.

weinzierl• 7 years ago

Chris Smith - who wrote the original piece years ago - added a current prologue to the text. I think part of it is an excellent summary so I quote this part here:

If pressed for an answer, though, yes I still do believe in the central conclusions of the article. Namely:
That “static typing” and “dynamic typing” are two concepts that are fundamentally unrelated to each other, and just happen to share a word.
That “static types” are, at their core a tool for writing and maintaining computer-checked proofs about code
That “dynamic types” are, at their core, there to make unit testing less tedious, and are a tool for finding bugs.
That the two are related in the way I outline: that one establishes lower bounds on correctness of code, while the other establishes upper bounds, and that questions about their real world use should come down to the possibility and effectiveness of addressing certain kinds of bugs by either computer-checked proof, or testing.

EDIT: When I wrote this comment the post linked to Steve Klabnik's 'reprint' of the temporary lost original article. Currently it links to the original. The 'reprint' missed the prologue.

draw_down• 7 years ago

... “dynamic types” are, at their core, there to make unit testing less tedious, and are a tool for finding bugs.

I don't think this is a good description of dynamic typing. I'd probably go with something more like, dynamic typing is a way to defer until runtime typing aspects of the program's implementation. I suppose dynamic typing does make unit testing easier, among other things, but it feels wrong to say it's "for" that. A car is for getting one or more people from point A to B. It also has a radio, but a car is not "for" listening to the radio.

naasking9• 7 years ago

I suppose dynamic typing does make unit testing easier, among other things, but it feels wrong to say it's "for" that.

The summary is trying to say that that's dynamic typing's primary advantage. Any other advantage you'd care to ascribe to dynamic typing is not intrinsic to dynamic typing itself.

dllthomas7• 7 years ago

dynamic typing is a way to defer until runtime typing aspects of the program's implementation

That's more of a "how", where the bit you quoted seemed to be speaking to "why", IMO.

msla4• 7 years ago

> That “dynamic types” are, at their core, there to make unit testing less tedious, and are a tool for finding bugs.

To the extent this is true, it's true because modern dynamic type systems are fairly strong. They enforce a contract about what operations are valid on a given type, and you can't usually get out of the contract. If you can cast in Python like you can cast in C, I don't know about it.

Part of the problem is that we've lost a whole quadrant of languages in the static-dynamic weak-strong graph: Weak dynamic typing is nonexistent these days.

We used to have it. B and Bliss were both weakly dynamically typed languages. Extremely so, in that they only had one datatype: The machine word. Since literally any operation was valid to perform on a machine word, there was no way for the type system to disallow anything, so it faded into irrelevance. Much like Bliss, in fact.

That's taking it to an extreme, shoving the "weak" part of weakly-typed so far that the language is untyped, like assembly language is usually regarded as being.

saghm• 7 years ago

Weak dynamic typing is nonexistent these days

Is JavaScript not considered to be at least partially on the weak side of the spectrum? Things like using the `+` operator on arrays and objects and getting back numbers and integers seems to be to be weak typing.

DonaldPShimoda13• 7 years ago

If you can cast in Python like you can cast in C, I don't know about it.

Note that "cast" and "coerce" are different. Python supports coercion but not casting. Casting is an operation done in static type systems where you tell the compiler "I know this has type X, but pretend it has type Y". Coercion is a run-time operation which moves data from a box of one type into a box of a new type (i.e., a new object is allocated).

Part of the problem is that we've lost a whole quadrant of languages in the static-dynamic weak-strong graph: Weak dynamic typing is nonexistent these days.

I'm not sure what you mean by "the problem" here. Weak dynamic type systems are, in my opinion, the worst of all worlds. They provide neither compile-time checks nor runtime checks that really amount to much. I don't know why you would ever prefer a weak dynamic type system in a language.

JavaScript is essentially weak and dynamically typed. The weak part comes from all the implicit coercions the language inserts to ensure your code nearly always produces some result. This is terrible because it makes identifying errors exceptionally more difficult than in a strong or static type system.

DiseasedBadger• 7 years ago

Maybe I agree?

To me, the purpose of those proofs, is to tell the compiler about all the programs I'm not writing. So that it doesn't emit them.

Also: documentation.

VectorLock• 7 years ago

"Dynamic types are, at their core, there to remove the incredible tedium of things like generics or templated types."

jimmaswell5• 7 years ago

I've never felt like templated types or generics are tedious.

StefanKarpinski• 7 years ago

Doesn’t hold water, imo. If dynamic and static typing were really independent concepts, then why are languages only one or the other, never both? I explained my take on dynamic versus static typing here:

https://stackoverflow.com/a/28096079

The primary difference between static and dynamic languages, in my view, is this: in static languages, expressions have types; in dynamic languages, values have types.

Read the rest of the answer for more details in the context of Julia, which, as a dynamic language with a sophisticated type system, really crystallizes the distinction.

andrewflnr• 7 years ago

in static languages, expressions have types; in dynamic languages, values have types

This kind of agrees with OP in practical terms, despite using opposite terminology. A type applied to an expression (syntax) is expressed as a proof about that syntax, and a type of a value at runtime is expressed in code that can safely crash in the face of an ill-typed operation. They both constrain program behavior, but do it with such radically different mechanisms that it's easy to argue they're fundamentally different. It depends on whether "fundamental" should be about mechanism or purpose. Let us know when you've solved that problem. :)

Julia's type inference can be seen as finding proofs of the properties of certain expressions and, if it finds them, using them to optimize the dynamic typing code, basically eliminating dead branches for type checks that can't fail. I'm tempted to think of languages with nominal subtyping as being hybrids as well: the base class is the static type, and the runtime class is the dynamic type.

sgeisenh• 7 years ago

Who said languages were only ever or the other?

All languages have some notion of static types and dynamic types. They're most easily bucketed by whether they consider more than one type.

C is statically multityped but dynamically unityped. Python is statically unityped but dynamically multityped. Haskell, since it uses lazy evaluation, is statically multityped and dynamically multityped.

The main issue with static unityping is that insufficient testing can easily lead to type errors in production (or worse). And static multitypes help static analysis tools reason about code more easily.

Introducing a new type that is intended for use in a specific context that can easily be tracked is tremendously useful when programming at scale.

ken• 7 years ago

As explained in the article:

"The dichotomy between static and dynamic types is somewhat misleading. Most languages, even when they claim to be dynamically typed, have some static typing features. As far as I’m aware, all languages have some dynamic typing features. However, most languages can be characterized as choosing one or the other. Why? Because of the first of the four facts listed above: many of the problems solved by these features overlap, so building in strong versions of both provides little benefit, and significant cost."

It's a bit like asking: If electric and gasoline motors are independent concepts, then why are cars only one or the other, not both? Well, some are, to varying degrees. Most aren't, because it adds a lot of complexity. I don't see any inherent contradiction here, nor do I even find the relative unpopularity of hybrid systems terribly surprising.

Tomte• 7 years ago

But C++ has static and dynamic types, and a C++ programmer needs to understand both.

For example, in inherited methods the selection of the method implementation is based on the dynamic type of the (pointer) value, but the selection of the default arguments is based on the static type of the value.

jcelerier2• 7 years ago

then why are languages only one or the other, never both?

what do you mean by that ? multiple statically-typed languages have "var" or "any" types which can be used to go from the static to the dynamic typing world.

vraid• 7 years ago

Typed racket has both dynamic types and static typechecking.

https://docs.racket-lang.org/ts-guide/

Your objection doesn't really hold water..

thesz• 7 years ago

Given algebraic type (as in Haskell - data List a = Nil | Cons a (List a)), you can have static type verification (map :: (a -> b) -> List a -> List b) and dynamic dispatching for situation in concrete part of a program:

  pairwiseReduce :: (a -> a -> a) -> List a -> List a
  pairwiseReduce f (Cons a1 (Const a2 as)) = Cons (f a1 a2) (pairwiseReduce f as)
  pairwiseReduce f as = as

We fix the type, but concrete instantiation of a type may vary in run-time, so we pattern-match: the list can have at least two elements (first case) and we reduce them and the rest of the list or it has less than two elements and we leave it as it is.

I took my time and read about Julia's type system. It is really the worst from both worlds: it does not allow for tagged unions (like List I declared above), it does not allow for adhoc polymorphism (1+2 gives error for floating type and evaluates for integers), there are no type classes (that adhoc polymorphism thing) and, thus, no good guarantees for whatever substitution for GADTs Julia has. And it also has inheritance which makes type inference exponentially harder in simple cases.

So I urge you to take your time and read about Haskell's type system. It really allows you to have static and dynamic types and vary their presence and utility as you see fit.

namelosw• 7 years ago

That “static types” are, at their core a tool for writing and maintaining computer-checked proofs about code
That “dynamic types” are, at their core, there to make unit testing less tedious, and are a tool for finding bugs.

They are not rival. Imagine a gradual typing design, it has a statically typed system, but it won't stop you from running it. The type errors would only be suggested in IDEs and stop building on CI environment but you can run it anyway. Then you can have both checked proofs and debugging advantages. (Dialyzer for Erlang is an example but there could be more strict typing)

Another similar topic is 'compiled' and 'interpreted', instead of static and dynamic types. 'Compiled' is runtime favored because the code was compiled is ready to be executed a lot of times, while 'interpreted' was executed once on demand because you may change your code at any time, so there's no point compile it for one person. Plus source code is much easier to debug than byte code.

It would be interesting to see languages could have solid static/dynamic/compiled/interpreted at the same time. Elixir/TypeScript/F#, etc. are good examples but this idea can definitely go further.

_hardwaregeek3• 7 years ago

It's quite interesting seeing the polarization of people's opinions on type systems. I have friends who adamantly argue that static types slow them down and prevent them from adapting quickly. On the flip side I have friends who claim they cannot write code without static types and that JavaScript is unusable.

When really, both styles have their value. Static types are very useful and do provide some nice safety. However, static types can also be quite annoying and force you to acquiesce to the type system. You have to learn to "speak" types, which can be very tricky. There's a joy that comes with the freedom of no static types.

maxgiraldo• 7 years ago

IMHO Javascript is "unusable" because you can mutate state (among other things). Rich Hickey has a few other arguments against static typing and OO such as names dominating semantics and "types are an anti-pattern for program maintenance and extensibility because they introduce coupling. They’re also parochial." I think he said that in his talk called "Effective Programs":

https://www.youtube.com/watch?v=2V1FtfBDsLU

McWobbleston2• 7 years ago

As much as I liked Clojure when I dabbled for a few months it didn't really fix my dislike for dynamic languages, but I imagine core.typed / spec would fix that for me if I gave it another shot

I loathed dynamic typing mostly because you had to jump around code to understand what the shape of anything was, and it distracted me from the problem I'm trying to solve

In ML influenced languages types actively help me plan a solution, and rarely get in my way

kraftman• 7 years ago

I have friends who claim they cannot write code without static types and that JavaScript is unusable.

What are their reasons?

DonaldPShimoda13• 7 years ago

Same problem with all dynamically-typed languages, really. It's too easy to write the wrong thing and not find out about it until you've written umpteen unit tests. This can happen due to typos, refactoring, or whatever else. Only JavaScript is worse because it's weakly typed too, so it performs implicit coercions in an effort to make your code always do something (meaning your unit tests have to be very good to really ensure your functions do what you think they do).

A static type system ensures that, at the very least, all the types line up at compile-time. You find type errors much faster than with a dynamically typed language, and this can guide a much less exhausting development cycle.

McWobbleston2• 7 years ago

Personally, I have a bad working memory and struggle to remember the structure of data. I constantly have to jump around and try to find the name of things / recall their hierarchy

With static typing I can just highlight a type / jump to the definition or get intellisense. I also find it useful when I have specific names for data types because I can reason about things / communicate them easier

To me taking the time to specify types or wrangle the type checker is worth the reduced mental burden of having to remember the shape of things, and refactor data structures confidently

DonaldPShimoda13• 7 years ago

You have to learn to "speak" types, which can be very tricky. There's a joy that comes with the freedom of no static types.

If you struggle with "speaking types" then that's an indication that you don't understand the domain of values your code works with. Having a solid plan for exactly what shape your data can take is empowering, not restrictive. To some extent, certain restrictions provide greater freedoms in the sense that you can make more accurate assumptions about your data without needing to perform a bunch of run-time checks or write hundreds of unit tests to ensure your code works in all possible situations.

_hardwaregeek3• 7 years ago

If you struggle with "speaking types" then that's an indication that you don't understand the domain of values your code works with.

I'm not sure I agree. I've met intelligent programmers who can elucidate the domain of values which their code is utilizing, but simply cannot do so in the framework of a given type system. Or perhaps they just find it difficult or painful to conform their description to the grammar of the type system. Understanding the data domain and being able to describe it in a specific type system are different skills.

Even if one is completely in favor of static types, it's important to be sympathetic to this point of view so that we can design better, more friendly type systems going forward.

danmaz743• 7 years ago

Most often in imdustry, you have to begin any complex project without a deep understanding of your domain values, because that understanding only comes iteratively. In my experience, the biggest drawback of static typing is that it forces you to design your types when you still don't have enough knowledge, and changing it later is painful.

mercer• 7 years ago

My background is php and then javascript. My first experience with 'types' was learning that apparently javascript's implicit type conversion was not normal and actually pretty bad. That made sense to me.

Then I learned about explicit types via TypeScript, and that made sense to me too, although I could imagine how this could explicit typing could get in the way of my prototyping, small projects, or REPL-driven development.

Now, a few years later, and having learned a bunch of new languages, both explicitly and implicitly typed, I'm mostly wondering why I'd go for anything that isn't gradually typed as an ideal approach.

I get the impression that the core discussion is explicit vs implicit (correct me if I'm wrong), and I can see how in some cases enforcing explicit typing is worthwhile, but for most of the work I actually do, it seems like the best solution is something gradual and flexible. Typescript, or perhaps some (improved) version of Elixir/Erlang's Dialyzer, or Clojure's spec: flexible enough to allow for said prototyping, small projects, and REPL-driven development, but gradually rigid enough to be useful when things grow larger and more solidified.

munificent2• 7 years ago

I'm mostly wondering why I'd go for anything that isn't gradually typed as an ideal approach.

In some ways, gradual or optional types give you the best of both worlds. You aren't obligated to submit to the whims of the type checker when you don't want to, but you can elect to get the safety of types where it matters. You can get the brevity of dynamic typing and the safety of static types.

But, in other ways, they give you the worst of both worlds. If you have any sufficient fraction of typed code in your program, then you will feel pressure to structure even the untyped parts of your program in ways that play nice with static typing. Some API design choices are more "typable" than others, and having static types at all discourages you from some interesting API choices.

In order to play nice with untyped code, most gradual and optionally typed languages are deliberately unsound. There are holes in the type system that can't be closed. That means compilers cannot rely on types for optimization purposes.

You end up with the rigidity of static types and the performance of dynamic types.

bjourne2• 7 years ago

If you haven't already, you should see this paper from 2017 about sound gradual typing: https://www.cs.cornell.edu/~ross/publications/nomalive/nomal... The performance and rigidity issues you mention are solvable. Although the research is pretty cutting-edge and not implemented in many programming languages yet.

revvx4• 7 years ago

I wonder if coming from the other way would be acceptable for fans of dynamic typing.

Instead of adding types gradually to a dynamic language (like Typescript sorta does with Javascript), we could add type-checking features that enable a kind of "statically-checked duck typing". Complete inference (like Elm, Crystal or Haskell) gets you halfway there – most of the time you don't have to write method/function signatures.

Then add structural typing like Extensible Rows [1] or Elm Records [2], or something that type-checks based on the structure instead of classes, and it allows you to have the compile-time type-checking of Interfaces or Generics/Templates without the extra typing. Then you can add explicit generics/templates later if you want.

Both Crystal and Elm get very close to that for me, but not 100%. I honestly think that this is a safer bet than gradual typing that could lead to very similar results, but I don't know how feasible or acceptable to mainstream programmers this is.

[1] https://github.com/tomprimozic/type-systems/tree/master/exte...

[2] https://elm-lang.org/docs/records

ergothus2• 7 years ago

As someone working in dynamic languages for years, I've noticed a certain trend in arguing about type systems.

People will ARGUE about the benefits of compile-time checking.

However, when people point to concrete benefits, they tend to point to TOOLING communication. (e.g. IDEs supplying functions/variables that provide the necessary type) during writing.

Rarely do they notice these two are not the same thing.

I'm not in a place to say which is objectively correct (I'm both biased and without the right kind of data), but I've seen this distinction come up time and time again. I think it's the most interesting part (also the only part that is interesting) about typing disputes.

naasking9• 7 years ago

Rarely do they notice these two are not the same thing.

Types enable better tooling. That's why people mention tooling when types come up.

munificent2• 7 years ago

Static types enable better static tooling. Dynamic types enable better dynamic tooling. :)

These days, most programmers are very familiar with high quality static tooling (IDEs) but less familiar with high quality dynamic tooling.

ergothus2• 7 years ago

My point being that when I ask why static is better (from people arguing that), they'll talk about compile-time checks, they won't talk about the tooling.

When I ask them to show me examples, they don't point to bugs that were prevented by compile-time checks, they'll point to how they find it easier to write code because the IDE suggests things.

Gibbon1• 7 years ago

Tooling in this case replaces a lot of boiler plate unit tests. The stronger and more rigorous the typing the fewer ad hoc tests that need to be hand written. I think the cost is the tooling becomes more finicky about what you feed it.

C weakly typed -> compile -> run-> crash -> WTF?!!!

Rust strongly typed -> WTF? Why no compile!!

skybrian• 7 years ago

An intermediate goal when using static types is that the checked-in code should have type annotations that are guaranteed correct, so you can rely on them when reasoning about the code, either manually (just by reading it) or automatically (using tools).

Traditionally this is done in a compiler, but it could also be done in another tool like some kind of linter, provided that it's always run before committing a patch and/or as part of a continuous build.

revvx4• 7 years ago

Can I try giving a non-IDE example?

I rarely use IDEs, but compile-time checks are super useful for me during refactoring.

Sometimes I need to rename a class, a method name or a method signature that is used all over the program. I could use tests, but the compiler is much faster and much more comprehensive. So I change everything in one go and then only run the tests after that.

The speed in itself is great, and helps me get much faster feedback than I can get with tests. It's also great during explorational programming, or during the prototype phase: some errors can be detected during compilation, so I'm not greeted with an easily avoidable runtime error.

As for an example of a bug that would have been prevented by compile-time checking, I had one happen just last week. It was in a project with 100% test coverage, but we had undetected refactoring errors due to a lack of integration testing: there were (good) unit tests with mocks, but we missed them during refactoring, triggering a runtime error in production. We fixed that by writing a few simple integration tests and fixed the code. This happened just last week. No biggie, but would be avoided by a compiler.

latch• 7 years ago

Your first example has _nothing_ to do with static or dynamic typing. There are plenty of dynamic languages that will fail to compile or bootup with a helpful error message on a failed rename.

This is what's frustrating about trying to have this discussion (and it's covered in the article): "The problem, in this case, is that most programmers have limited experience, and haven’t tried a lot of languages."

If you've used JavaScript and you assign all of the challenges of writing JavaScript to dynamic typing, then ya, dynamic typing sucks. But the problem isn't dynamic typing, the problem is JavaScript.

dang3• 7 years ago

Posted at least 20 times but here are the discussions:

2015: https://news.ycombinator.com/item?id=9777485

2011: https://news.ycombinator.com/item?id=2093926

2009: https://news.ycombinator.com/item?id=849726

As for year, 2008 is an upper bound (https://web.archive.org/web/20080802234250/http://www.pphsg....), so we'll put that above unless someone finds it earlier.

ryandvm2• 7 years ago

Super offtopic, but I'm curious why y'all haven't taken the dev time to implement even primitive dupe detection/reposting/re-linking on HN.

Writing scripts to do repetitive human tasks is sort of hacker 101 isn't it?

ginnungagap• 7 years ago

I suppose it's because reposting is not considered an issue if some time has passed since the last submission

afureta• 7 years ago

Hacker News definitely does duplicate detection, but if enough time has passed then duplicates are allowed.

dang3• 7 years ago

Other users have already answered this, but I have a question: what made you think we haven't?

(I often link to earlier discussions from comments in the threads, but that is purely to satisfy the curiosity of those curious to look at them.)

codr7• 7 years ago

I recently implemented a simple object system [0] using only closures and macros in a Lisp-dialect [1] I'm working on.

One thing that struck me is how little it bothers me that objects look like functions from the outside, and that any callable value could be used in their place.

It helps that the whole thing is quarantined in a separate library and that objects live in a separate namespace. And that it rests on top of a strongly typed environment.

Judging a type system outside of its context based on some arbitrary check list is pretty useless from my experience.

[0] https://github.com/codr7/g-fu/blob/master/v1/doc/functional_...

[1] https://github.com/codr7/g-fu/tree/master/v1

apo• 7 years ago

Fallacy: Dynamically typed languages provide no way to find bugs
A common argument leveled at dynamically typed languages is that failures will occur for the customer, rather than the developer. The problem with this argument is that it very rarely occurs in reality, so it’s not very convincing. Programs written in dynamically typed languages don’t have far higher defect rates than programs written in languages like C++ and Java.

Having written software for paid work in both Java (static typing) and JavaScript (dynamic typing), I agree. A statically typed language does not improve the quality of the software that gets written, assuming equal skill in both languages.

The kinds of bugs that get caught by a static type system are also caught by a good suite of automated tests, where every test is written before the production code that makes it pass.

The article doesn't mention refactoring, but this is where a static type system really shines. The ability to refactor an entire code base with confidence at the click of a button is extremely useful and the thing I miss most when using dynamically typed languages. You can get some of that with modern editors, but it's just a pale shadow of what you get with static typing.

viraptor3• 7 years ago

The kinds of bugs that get caught by a static type system are also caught by a good suite of automated

This is correct in theory, but to get the same benefit you'll need to write all the tests that the static language would guarantee. That's both relying on the programmer being always correct and that they think the time writing those tests is worth it.

arwhatever• 7 years ago

Stating typing you have to explicitly opt out of, and automated tests you have to go to quite some effort to explicitly opt into, and most teams I've been on have been quite poor at this opting in.

duiker101• 7 years ago

The kinds of bugs that get caught by a static type system are also caught by a good suite of automated tests, where every test is written before the production code that makes it pass.

That's not a small thing though. It's one extra thing that you just have with static typing. Not that you don't need tests but at least you will have already some bases covered.

For me a big reason of why I like static types it's the ease of reading even if a developer was sloppy. I have read dynamically typed code where the same parameter can be a string or an array or an object depending on what's the weather like outside when a dev needs to call a function. This sort of confusion makes it exponentially harder to read and understand code IMHO.

marcosdumay3• 7 years ago

Code is worked out until it has few enough bugs for the customer to accept it. A program bug count is a function of how it will be used, and how sloppy the developers (or their company) thinks they can get away with, it's almost no sensitive to how easy or hard it is to find and correct the bugs.

That said, Java's type system sucks, you can not extrapolate its problems into a general concept.

dllthomas7• 7 years ago

The kinds of bugs that get caught by a static type system are also caught by a good suite of automated tests, where every test is written before the production code that makes it pass.

Mostly, but it depends how you're using the type system. I have a talk (slides at https://dlthomas.github.io/using-c-types-talk/slides/slides....) that ends with enlisting the C type system to statically catch a "you called this from the wrong thread" error - with no run-time overhead.

grumdan2• 7 years ago

The kinds of bugs that get caught by a static type system are also caught by a good suite of automated tests, where every test is written before the production code that makes it pass.

To make matters worse, one would also have to write tests that cover every possible path through the function to ensure none of them change a value into a shape the rest of the code doesn't expected. This gets very tedious if it has to be done for every function.

noego• 7 years ago

Programs written in dynamically typed languages don’t have far higher defect rates than programs written in languages like C++ and Java.

They have done a study which found that strong/static type checks can reduce your number of bugs by 15%

https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q...

I would consider that to be quite significant

jolmg• 7 years ago

I give the following general definitions for strong and weak typing, at least when used as absolutes:
Strong typing: A type system that I like and feel comfortable with
Weak typing: A type system that worries me, or makes me feel uncomfortable

What is he talking about? Is he trying to make a point? I always understood the difference to be mostly about implicit type conversions. I think weak-typing is also likeable.

dllthomas7• 7 years ago

I think he's trying to say that "strong-typing", in practice, as used by some speakers implies a static type system. And when used by other speakers does not imply a static type system.

bartimus• 7 years ago

For some languages it's more about providing features for the IDE and less about providing features for the language itself. It's probably the main reason Microsoft started working on TypeScript for example.

neilwilson• 7 years ago

There is an argument that a static type system is a set of built in unit tests, that you can activate by adding a command word in a particular position.

And that the test harness on code in a dynamic languages is a domain specific compiler.

The problems come when you want to turn off specific type tests for a particular bit of code because it is deliberately bending the rules (I see this a lot in Go), or the domain specific compiler you've built isn't comprehensive in its coverage not just of lines of code, but the structural complexity of the code.

What to Know Before Debating Type Systems (2008)

Related Stories