Hacker News Reader

Comment by wellpast | Hacker News Reader

Rich comes down hard here on statically typed languages, but before the static typers get too offended, his main attack is on the overuse of ADTs/classes to build information processing systems (i.e., what a majority of us industry programmers are doing; he takes pains to define this arena...see the slides/discussion on what Rich calls "Situated Programs").

So before the static vs dynamic typing debate gets too heated up here, I think we should focus on this point first[1].

For those of you wary of his point here, I think it's worthwhile to go through an exercise, if you have the time to explore this. Write a simple information processing app using two different paradigms:

   - Write it using a statically typed language and a relational database.
   - Then write the same app using some NoSQL store and avoid using ADTs (prefer using just maps of facts). Ideally do this in a dynamic language so the ergonomics are better for you.

And then ask yourself: Which one of these felt safer? More familiar? Which one of these offered more freedom, choice, and speed?

1. I do think that once you come to terms with the problems of ADTs, you are on your way to not needing all the static type verification, but leave that to later.

View on HN

But at its best (as in Haskell), static typing just means that the compiler is enforcing the requirements of your interfaces. Why would you not want to know about these bugs immediately and fix them early in the development process when it's cheap to do? Why wouldn't you want the compiler recheck everything automatically every time you change your interfaces?

Everybody's always fixing bugs. Static typing makes it more likely that the bugs you're working on are closer to the problem domain, instead of being crap work that should have been caught at compilation time with better languages and compilers.

> Why would you not want to know about these bugs immediately and fix them early in the development process?

That's a good question. But enforcing your codebase to be a Rubix cube you have to twist and turn until the static type checker says Yes is not trivial. Its a tax.

The real question is whether that tax is worth it when your goal is purely business delivery and not something else (eg, intellectual stimulation). Is it?

Writing unit tests and code review are other means to root out bugs. But they also come with a tax. When are they worth the tax and when are they not worth the tax?

In some cases we judge they are. In other cases not.

A statically typed language typically asks us to turn off our brain and apply type verification everywhere. In this way, statically typed languages wield type verification more like a religion than a tool.

Honestly I've never understood this argument that choosing types is too complicated. Most often I've seen it come from people without much experience in statically typed languages and imagine that having to determine the type will be difficult.

After becoming familiar with the code base or library, particularly with modern IDE's it's rarely taken more than 10 seconds to choose a type. When reading another person's code, it does take some time to map out the relationship between the classes, but unless your code is in one giant file/function/object you're going to have to figure that out anyway.

I've programmed professionally in statically typed languages for > 15 years. (C#, various VBs, C++, F# (which is rad), and lately TypeScript) I've also dabbled in Haskell, OCaml, Rust, and a whole lot more.

In fact, outside of Clojure, I've never liked a dynamic language (and I've used a few professionally).

So, I'm someone with plenty of static-language experience, and I am in the boat that types are more complicated, in some ways. Just today, I had to figure out how to wrangle TypeScript into a shape I needed (and wound up with a solution that I didn't like but which got me past the compiler errors and on to more important work). There is a cost. There is also a benefit. So the question is, what does the cost/benefit analysis yield?

Regardless, Clojure is worth learning. It's an amazing language.

> Just today, I had to figure out how to wrangle TypeScript into a shape I needed (and wound up with a solution that I didn't like but which got me past the compiler errors and on to more important work).

It would be really interesting, and indeed probably the most valuable contribution to this whole discussion, if you could write up what the problem was and why it wouldn't have occurred in Clojure!

From Rich's talk: "Now at this point I was an expert C++ user and really loved C++, for some value of love."

Rich has had many years of experience in statically typed language.

Please don't use C++ as an exemplar of static typing. There are much more powerful and congenial alternatives.

It would be just as unfair if one were to claim that dynamic typing is bad because assembly language tends to be buggy and expensive to maintain.

The type system of something like C++ and Java are so far removed from the type systems of Haskell or Idris, that it is silly to compare these two.

You can fix your interface bugs early in the development process with the aid of a compiler, or you can fix them later manually at much greater expense. When the "tax" is so much cheaper than the consequences, not paying the tax is crazy.

But "interface bugs" are the least of our problems. As evidenced by most bug queues that I've peeked at.

No true. I have to try and reverse engineer types whenever I use JSON APIs. The documentation provides only "samples". I literally have to experiment to find out what works with no guarantee it will keep working.

I don't know about that. How about the simple interface of "shouldn't be null".

If null pointer exceptions are the most of your problems then I think you're doing pretty well.

In my experience NPEs are the easiest bugs to root out and fix.

The point is that NPEs are a solved problem, just not in Java and Clojure. I am better able to stay focused on the real problems, as I never have to root out and fix bugs like this.

Not to mention that the ease of fixing the bug has little to do with the cost of the bug showing up in production.

I can do all kinds of things to prevent bugs showing up in production. I once worked on a mission-critical piece of software in which the entire team was brought in to do a page-by-page code review for all newly written code.

Of course, the cost outweighs the benefit in this case for most industry software that can afford a few bugs at the extreme expense of (this kind of) code review.

Now the question is: are the static verification methods you're using (null-checking, type-checking, range-checking, what-have-you) worth the effort it takes to apply them over time?

And if you say yes, do you believe they are so worth it that they should be applied across your codebase always, without discretion? Most static programming languages force you (or make it hard for you not) to do this verification across the board.

> And if you say yes, do you believe they are so worth it that they should be applied across your codebase always, without discretion? Most static programming languages force you (or make it hard for you not) to do this verification across the board.

Yes, actually, I don't find these things to be a particularly high burden, and the benefit, in my experience, easily outweighs it.

When you're writing code, you have to think about what kinds of things will be passed to a given function, whether the compiler checks it or not. So I find having the compiler check mundane things like this lowers my cognitive load, because I don't have to worry so much about what to do if I get a null (fail, handle it in some way, etc.).

I will agree, though, that the style of programming with maps so prevalent in Clojure makes a lot of sense in some programs. However, even then, there is a typing discipline that fits (row types).

> Now the question is: are the static verification methods you're using (null-checking, type-checking, range-checking, what-have-you) worth the effort it takes to apply them over time?

Yes!

> And if you say yes, do you believe they are so worth it that they should be applied across your codebase always, without discretion?

Oh god yes! Simple Hindley-Milner typing is so cheap to use it's almost free!

> Most static programming languages force you (or make it hard for you not) to do this verification across the board.

Well, not really. In Haskell, for better or for worse, you can still use `fromJust` even if it is considered rather naughty.

Honest question: have you ever written a large computer program in a programming language descended from ML (SML, OCaml, Haskell, &c.)?

No I haven't. And, depending on how long life turns out to be, maybe I'll get to.

But.

I have built plenty of large software systems. And the source of cost in those systems is always -- by at least a factor of a 100 -- was coupling and imprecise semantics.

These two problems are a function of the experience and training (and value system) of the programmer building them, and programming languages can do very little to save a system from these plights. (It might be that a static programming language can help here inasmuch as it slows down the programmer from producing too much code, but I realize that's arguable and also that I'm making a wicked joke.)

Still.

All computers ask is for semantic precision and you don't need a static type verification to get precision. So clearly static type verification is unnecessary for producing programs that work. And clearly statically-typed everywhere PLs are asking the programmer to do extra work. That's prima facie true. So the burden is really on the MLer/Haskeller to prove that that extra work is giving overall delivery throughput to the programming team. Maybe it is, maybe it isn't. But I'm waiting for the clearly thought out justification. Haven't heard it yet.

> And clearly statically-typed everywhere PLs are asking the programmer to do extra work.

I'm not convinced this is entirely true. The kinds of information that you encode in types is the kind of information that's useful to anyone reading the code. And if that information isn't written down somewhere, then the person reading the code (maybe you sometime later) has to reconstruct it themselves. And if it's useful to write that kind of information down, why not have the computer check that it's consistent?

> All computers ask is for semantic precision and you don't need a static type verification to get precision. So clearly static type verification is unnecessary for producing programs that work

That's a bit contrived. No matter which language you write in, at some step a type check will happen. For dynamic types its at runtime and for static types its at compile time.

> And clearly statically-typed everywhere PLs are asking the programmer to do extra work. That's prima facie true. So the burden is really on the MLer/Haskeller to prove that that extra work is giving overall delivery throughput to the programming team. Maybe it is, maybe it isn't. But I'm waiting for the clearly thought out justification. Haven't heard it yet.

Here are just a few of the real world accounts of using Haskell in production, you can check out:

- The Joy and Agony of Haskell in Production: http://www.stephendiehl.com/posts/production.html

- Haskell is Not For Production and Other Tales: https://www.youtube.com/watch?v=mlTO510zO78

- Production Haskell - Reid Draper: https://www.youtube.com/watch?v=AZQLkkDXy68

If these didn't convince you, there are tons of Haskellers that will attest that the type system in the long run has quite substantial benefits.

> I have built plenty of large software systems. And the source of cost in those systems is always -- by at least a factor of a 100 -- was coupling and imprecise semantics.

This is a wonderfully, astonishingly, gobsmackingly interesting comment for me to read! In my experience of large systems (Haskell-style) types are exactly the thing you need to tame coupling and imprecise semantics.

To take one arbitrary but notable example, in a previous job we found several bugs in large industry XML schema^ by converting the schema to Haskell types and noticing, via type errors, that some things didn't match up.

^I forget if the bugs were in the schema itself or in the Java implementation that another team was using. I think a little bit of the former and a lot of the latter.

> I have built plenty of large software systems. And the source of cost in those systems is always -- by at least a factor of a 100 -- was coupling and imprecise semantics.

One thing I find interesting about this is that a good type system, combined with something like OCaml's module system, is that you can force decoupling. In OCaml, you can create an abstract type, which cannot be used in any way that isn't specified through the interface. You don't have to wrap the runtime value in anything, it's purely a compile time abstraction.

> A statically typed language typically asks us to turn off our brain and apply type verification everywhere

No, it doesn't.

People are not using Haskell because they want to turn off their brain.

Let me rephrase:

A statically typed language typically asks us to redirect our brains from asking the question, "Is type verification really needed in this particular instance to deliver my business value?" to instead solving the type-checker puzzle du jour.

Plenty of modern statically-typed languages have dynamic escape valves (and plenty of dynamically typed languages have opt-in static validation.)

It's true that choosing to use a static language without a dynamic escape valve for a component constitutes making the decision that, for the pieces of that component, dynamic freedom isn't an option that needs further considered.

This is effortless once you have experience[1]. Besides, understanding the type of your data is beneficial, and so is it to be able to use types as an exploratory tool in a codebase you don't know.

[1] Just like having experience in editor shortcuts bear an initial cost to make you more productive forever...

Which part is effortless? Solving the type checker puzzle, or asking whether type verification is truly needed in a particular given instance?

Thinking in types. 95% of the time, the type checker silently validates my input and the remaining 5% of the time, the trouble I get is understanding valuable information.

There is no such thing as type checker puzzle once you have learned types, just like you don't stop on each word once you're literate.

Lots of valid code, won't pass the type checker. That is the problem with static type checkers. You have to adapt your code to satisfy the type checker even when you know your logic is right.

Static type checking also significantly complicated meta programming, macros and code generation.

But hey I like statically typed languages too. A big fan of Swift which has borrowed many functional ideas. I just don't think static typing is the silver bullet that many of its proponents think.

It works well for some problems, but not all. E.g. I can't think of any statically typed language which can compete with Julia for numerical work and data science.

Haskell e.g. is just terrible at doing numerical work, as it poor at mutation. You can work effectively with lots of big matrices if you don't allow easy access to mutation.

> Lots of valid code, won't pass the type checker

Perhaps you could give us an example of code you want to write that doesn't pass the type checker.

We already know about the case of maps, but it's been pointed out that is solved by row types. A different example would be good.

> Lots of valid code, won't pass the type checker. That is the problem with static type checkers.

I fail to see this as a problem. It's pretty much a feature, just as you don't expect object oriented languages to tolerate any shit you throw at them when you use the OO model.

> I just don't think static typing is the silver bullet that many of its proponents think.

You're the one making the case here, before answering it.

> Haskell e.g. is just terrible at doing numerical work

I've had good experience with https://wiki.haskell.org/Numeric_Haskell:_A_Repa_Tutorial

> There is no such thing as type checker puzzle once you have learned types, just like you don't stop on each word once you're literate.

Your analogy doesn't apply.

I can read a book in O(n) time, where n is the number of words in the book. I can read a single word in O(1) time.

When I get a type error, that is not a O(1) fix. The type error is connected to my program in the large and I have to understand/process more than just the single line where the error is called out. The worst case, obviously, is O(n).

Using a static type checker means that an error doesn't creep across all my code. The worst case you describe pretty much never happens, and the smaller instances I get are reified to a generic form I am trained to analyze and solve quickly.

> Your analogy doesn't apply.

One would think I am well placed to describe my own experience of interacting with a type system.

The worst case for the number of places I have to go fix is O(n). I.e., the verification half is O(n). The solution search side ("solving the puzzle") may be worse, because I have to generate/find the code that fits the type checker.

> turn off our brain and apply type verification everywhere ... type verification more like a religion than a tool.

A statically typed language can allow us to use dynamic typing if we want. For example, using a map of variants as a query result. Programming with maps of variants is even perfectly possible and pleasant in Haskell. Dynamic typing is not unique to dynamic languages!

I see the value of statically typed languages as I've used Swift quite a lot and quite like it. It is way more strict than say Java and C++. However when I compare my coding with Swift to the dynamic language Julia, it is way more fun and fast to write Julia code. Up to a certain point of course. As I pass about 1000 lines of code I start feeling a bit uncomfortable about the lack of static type checking to catch my changes.

However this is mostly down to me being lazy and not bothering to write tests.

I've spend some time with Haskell, and tried writing some code for a simple geometry library in Haskell. Quite cool language, but I could write the same code in much fewer lines in Julia and much faster.

Haskell has just too much mental overhead. It requires far more investment than other languages to learn and I've learned plenty. Nothing has required as much effort as Haskell. Despite the effort I never felt like I could write any real and practical programs with it.

I honestly think the Haskell fan club is slightly deluded. If Haskell was truly as amazing as they think, we ought to have seen a lot more amazing software being made in Haskell. We don't. Far more interesting things seems to have been done in newer languages such as Go, Rust, Swift and Julia. That ought to be a hint that Haskell isn't quite the silver bullet that the fan club thinks it is.

> Up to a certain point of course. As I pass about 1000 lines of code I start feeling a bit uncomfortable about the lack of static type checking to catch my changes.

This is indeed where statically typed languages come in to shine - refactoring and maintenance. With a powerful type system you can be much more assured that your refactors or small/big changes here and there don't break the whole system or unexercised parts of it.

> It requires far more investment than other languages to learn and I've learned plenty. Nothing has required as much effort as Haskell. Despite the effort I never felt like I could write any real and practical programs with it.

That's often attributed to the fact that Haskell isn't just another syntax slapped on an Algol-like language. It's not just different syntax (ML-style), but an entirely different approach to programming. This often leaves experienced programmers frustrated with the experience that they are starting from scratch (without realising that, that is what they are doing).

Some nice advice is giving by Gabriel Gonzales here http://www.haskellforall.com/2017/10/advice-for-haskell-begi....

> I honestly think the Haskell fan club is slightly deluded. If Haskell was truly as amazing as they think, we ought to have seen a lot more amazing software being made in Haskell

We have a lot of amazing software in Haskell already, e.g. Facebooks Haxl, Pandoc, QuickCheck, Yesod, Servant and many more.

The argument that Haskell isn't doing stuff right because we don't see it everywhere is quite silly. By that metric PHP would be the best designed language ever...

Can I just touch on the relational vs nosql comment? I'd like to point out that data almost always has a schema, and it's almost always relational. Most of the time when people use nosql with map of maps, they are simply refusing to recognize and formalize the structure of the data that is already there. This absolutely leads to errors and performance problems. There is a small class of problems where specialized databases do excel, but it's definitely not the common case.

"and it's almost always relational"

this is a bit backward, and not very accurate

there is no such thing as relational data and non relational data, its the other way around, there is a relational model, which promises to model any set of related data

so you can fit, any set of related data into a relational model, and this is a feature of the model, not the data

the key value, of relational models, is the promise of integrity, once you model your data into a relational model, and then only access your data through it, you are guaranteed integrity

the key issue with relational models is that they are static, so if your data change, your model need to change, and once your model changed, now you have to deal with two models .. and this is where things start to get hard .. and this is when people start to use other models .. it is not because they cannot fit their data into a relational model anymore, its because they dont want or dont know how to deal with two relational models

You are conflating two separate things. First, your comment on changing data relates to schema, not the relational model. Using a nosql database where you don't bother writing the schema down certainly means that you don't have to worry about updating your schema as the data changes. But you still need to worry about updating your code, and since you have no schema written down you run the risk of data inconsistency as you write updated code.

As for the relational model, you are correct in that it's a model for storing data. However, I will go further and also argue that it can be a property of the data itself. Consider a simple case of users and posts. This data is fundamentally 'relational' in the sense that there are two related items. No matter how you try to store this data, the relationship between users and posts will _always_ be there. You can either recognize it explicitly via the relational model or otherwise, or you can pretend it's not there which is what many people using nosql do.

Say you stored users and posts each as maps in a key value store or document store. One key per user and one key per post. Now, imagine getting all the users and their posts. In a relational database you'd do a join. In the nosql scenario you need to do multiple queries. The latter is essentially doing what the relational database is doing, but you are doing it manually via a for loop.

In short, what I'm arguing is that relationships in data are a property of the data.

I think Rich is talking more about data structures than data abstractions here. In particular, he's saying that he favors sound data models (RDF, datalog, relational) to manipulate information in our programs over specific data structures.

To me it is related to Alan Perlis's saying on the power you get from uniformity:

"It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures."

I totally agree with him on this point and I also agree that for some of us a lot of our programs are about manipulating static information structures. But let's not reduce programming to that.

Aren't statically typed languages "sound models"? Aren't ADTs a form of data structure?

I think his point is much more in the realm of abstraction. RH always seems to be trying to minimize the delta between thinking and coding/problem-solving. ADTs are in most cases cumbersome. Static languages introduce more impedance and coupling than benefit to the industry business problems we're solving via code. These are arguments against certain attempts at abstraction, it seems to me. But I may be missing what you're saying.

Actually, this talk mostly convinced me that dynamic typing is not just an anachronism and really is the right choice for some domains.

Then again, now I wonder if statically typed languages could get the benefits Hickey talks about just by having convenient Map and Keyword types like in Clojure and using them where appropriate.

An interesting thought I got out of this talk is the reminder that most (nearly all?) statically typed languages are really just "mandated type verification" (not RH's terminology, btw). But, in the talk, Rich isn't anti- type verification. He says, like any tool, type verification should be used consciously, it should be a la carte (his term); that is what clojure.spec is all about, as I understand it.

>I do think that once you come to terms with the problems of ADTs, you are on your way to not needing all the static type verification, but leave that to later.

Excellent thought.

Also, as a side note, people that criticize Clojure for its lack of static type enforcement, forget the fact that Rich Hickey had good previous experience in C++, so it's not as if he hadn't tried a statically-typed language before.

While that is true, it's not like C++ and Java are the torchbearers of static typing.

Much better type systems exist than those of C++ and Java and basing your worldview of static typing just on the experience with these two is shortsighted.

Right, but most of the statically typed code in the world is written in C++, Java, etc. If you're presenting Clojure to your organization, the choice isn't going to be Clojure vs Haskell/Idris, it's going to be Clojure vs Java. The sort of boosters for static typing in this domain are the AbstractSingletonProxyFactoryBean people. I think defenders of static typing have at least some burden to defend "actual existing type systems" rather than immediately falling back to "well, in Haskell..."

Even if we assume that your point is true, Hickey wasn't comparing Clojure's type system specifically with only C++/Java. He was making a general point about static vs dynamic typing. He even mentioned Haskell and C++ in the same sentence to make a point about statically typed languages.

When you are comparing the best of dynamic typing, you should compare that with the best of static typing else the competition is lopsided by specification.

And it's not a fallback on "well, in Haskell". It's not like more "hip" languages can't adopt some of the best ideas from Haskell and OCaml to make their type systems better. Modern languages have already started doing this - Rust for example.

It's about learning from research and making the consumer product better. It's a fact that Haskell/OCaml will never be on the top of the TIOBE index, but they can certainly influence those who are.

Making ill-informed (I can only assume ignorance at best here) blanket statements like Hickey did in _this_ particular talk doesn't help the programming language community.

What makes you assume Haskell is somehow more niche than Clojure? I would say it depends on the domain. Haskell is certainly more mature (~30 years) and has a lot more tutorials and literature.

I totally agree that it depends on domain, but I think that's part of the point -- making these comparisons, i.e. Clojure vs Haskell in the abstract aren't particularly interesting, as it seems obvious that no general purpose language is perfectly general for every purpose.

It runs on the Java runtime and interops seamlessly with Java which are two big factors in its favor.

> Haskell is certainly more mature (~30 years) and has a lot more tutorials and literature.

and yet, still, nobody outside the gated community has any idea wtf a monad is. :(

I was surprised to see Haskell in widespread use at several large enterprise companies in Singapore.

Yes 40+ fulltime Haskell devs in London and Singapore at Standard Chartered, with many other users writing Haskell.

Many universities outside of the US teach functional programming and Haskell. The community is open, international and a healthy mix between industry and academia.

C++, Java, and C# if I recall correctly

I do agree that there are problems where the "maps of facts" approach is better suited than ADTs. I'm not sure if those are the majority of problems we're solving. You can still do all that in a typed language, using dictionaries. You can be as precise as you want. In some sense you lose that without a type-checker.

I only have my experience (which is about 1/4 of his) to lean on. And I've only had problems when protocols are not well understood by all parties, never the opposite. Talking in the level of ADTs (or some representation that is equally precise) tends to either clear things up, or uncover problems that were not obvious in informal discussion.

> Talking in the level of ADTs (or some representation that is equally precise)

I will argue that ADTs offer no more precision than first-class properties and first-class properties are much more aligned with human beings natural way of thinking.

I.e., "name" is semantically strong/precise, I don't need to enslave it to a Person class. I can give a Cat a name, a building a name, etc.

ADTs are trying to bundle properties together when those properties should/could have strong enough semantics on their own and be much more "composable" (RH's term) and freer to use.

Maybe we have to dig into the specifics: there's a lot of things that can be done with Name, regardless of where the name belongs, is that what you mean? If so, most typed languages let you say that Person can be a thing with a Name. I don't have Clojure experience so we might be talking past each other here.

What resonates most with me is that traditionally ADTs make the properties second-class citizen to the ADT/class.

First-class properties are strong enough semantics and bundling them together in an ADT is almost always introducing coupling and rigidity with no real benefit.

Why do we need the Person class? Why do we need to taxonomize like that? The answer is we don't. All the Person class brings to the table is straight-jacketing and a false sense of order and security.

I haven't watched the full video, but here are some things that a hypothetical Person class brings to the table that you might be missing:

1) A Person class can guarantee that a Person can not exist unless it is fully specified. E.g. you prevent Persons from being created that don't have a date of birth.

2) A Person class provides a syntactically nice place to put pieces of code that rely on the instance fields. E.g. a function like Person(...).computeAge(DateTime.now)

3) A Person class can be a nice place to put inter-field validations. E.g. Maybe you don't want to allow Persons to be constructed if their last name is the same as their first name

4) A Person class can bring clarity to function signatures that depend on it. Basically resolving the problems that Duck-typing introduces

What's a "first-class property"?

   class Person {
      def age;
   }

There is a second-class "age" property: the only way to specify it or use it is to first declare the ADT/Person class. (In this example, I use a dynamic language; that is, the property can be given any type of value.)

Here is the usage of a first-class age property:

   public boolean isOld(Map<String, Object> entity) {
      return entity.getAs("age", int.class) > 30;
   }

Note that in this example, age's semantics are independent of any Person/ADT. Now a statically-typed language that would let me define a vocabulary that include "age" and its type independent of an ADT would be supporting first-class properties.

I could cheat and do this in a typed language like Java like so:

   class Age { int val; } // using class to define a property
   class Entity { Age age; ...and list all other properties here... }

But this is absurdly cumbersome and obviously Java isn't conducive to this.

> Note that in this example, age's semantics are independent of any Person/ADT. Now a statically-typed language that would let me define a vocabulary that include "age" and its type independent of an ADT would be supporting first-class properties.

What you're referring to is known as row polymorphism or structural typing and it exists in languages such as Elm, Purescript, Scala and Go (and I believe Haskell has these as an extension). For instance, this is valid Scala:

    def isOld(thing: {def age: Int}): Boolean =
      thing.age > 30

    case class Person(name: String, age: Int)
    case class Dog(age: Int)
    println(isOld(Person("Jim", 25))
    println(isOld(Dog(31))

And here's Elm:

    isOld : {age: Int | a} -> Bool
    isOld thing = thing.age > 30

    Debug.log (isOld {name: "Jim", age: 42})
    Debug.log (isOld {age: 10})

This is pretty cool. The Scala version is a little weird. Why do I need a separate Person and Dog class? Can't a dog have a name as well? Why do I need to declare that upfront or ensure that no other part of code can give a Dog a name? That's the problem with ADTs; there's all this impedance.

The Elm version is much better. Except of course I have to upfront at the method signature declare my property requirements -- while that is also a burden, it is a much lesser burden than having ADT/taxonomy of Person, Dog, etc.

I think the Scala version does exactly what you want it to do, but you seem to be confused about something that I can't really pin-point.

> Why do I need a separate Person and Dog class?

You don't. It's an example.

> Can't a dog have a name as well?

It can.

> Why do I need to declare that upfront or ensure that no other part of code can give a Dog a name?

I have trouble understanding the meaning of that sentence.

> The Elm version is much better. Except of course I have to upfront at the method signature declare my property requirements -- while that is also a burden, it is a much lesser burden than having ADT/taxonomy of Person, Dog, etc.

Elm (and Purescript) should be able to fully infer the type of that function w/o forcing you to declare which fields you want to use up-front.

How would it infer:

   isOld(parseJson(json))

When parseJson may or may not produce an entity with the "age" property?

Sorry, I wasn't clear. My point was that you don't have to declare the type of `thing` up front in that example. It would be able to infer that it's a record with an `age` field from the function's definition.

In your example, `parseJson` would have to return a record with an age field, otherwise the compiler would complain. Personally, I think that represents a reasonable tradeoff in ease of use for safety.

> I believe Haskell has these as an extension

Not really ... Haskell has libraries that claim to implement this but we Haskellers have to admit Haskell's support for row types is pretty poor. A Clojurist's objections to Haskell on those grounds are valid (in practice though not in theory).

Does this meet your criteria of "first-class" property? It works on any entity that "has" and "age", at least according to my definition of those things!

    -- The class definition can often be entirely elided
    -- with Generics or Template Haskell.  Instance   
    -- definitions can generally require minimal or no
    -- implementation either
    class HasAge r age | r -> age where
        getAge :: r -> age
        setAge :: r -> age -> r
    
    isOld :: HasAge r => r -> Bool
    isOld r = getAge r > 30

Firs-class generally means something you can put in a variable and compose with higher order operations. Think first class functions.

> I do agree that there are problems where the "maps of facts" approach is better suited than ADTs. I'm not sure if those are the majority of problems we're solving.

This also seems like the kind of thing where row-types would allow for statically typed, fully inferred programs that are written in the style Rich is advocating.

Classes and ADTs are both examples of Nominal typing, but Structural typing would offer a better fit for your example. Structural types can give types to queries without requiring any declaration or naming of the result type. Correctness in terms of the assumed fields can still be verified. Most of the anti-modular and boilerplate criticisms of static types do not consider structural typing, perhaps because industry has yet to discover them.

TypeScript is structurally typed and is pretty popular. The industry has discovered this. It's still more painful than ClojureScript in many ways (and less painful in other ways). To me, having written a fair bit of both, it's not clear which is best. Both are good. ClojureScript is far more elegant.

PureScript is probably the most interesting statically-typed language I've seen in a long time. But for some reason, powerful static typing never seems to gain much traction.

So, if I had to choose between the most popular statically typed languages or Clojure, Clojure wins hands down.

I am a dynamic language fan but I would actually disagree. I prefer the Julia programming language and there I see a lot of benefits from working with types.

I've always had a fascination for LISP, but every time I've tried using it after learning Julia, I've found the lack of type focus limiting and in the way.

Types makes it easier to build abstractions. I can write several functions which look the same but act different depending on the type of the arguments.

The way in which types get in your way in statically typed languages is pretty much gone in Julia as you can so easily and fluidly deal with types as they are just objects at runtime which you can pass around freely.

Julia already has most of the things I like about LISP: everything is an expression, and it is really easy to write macros.

> I've always had a fascination for LISP, but every time I've tried using it after learning Julia, I've found the lack of type focus limiting and in the way.

> Types makes it easier to build abstractions. I can write several functions which look the same but act different depending on the type of the arguments.

You can do this in Lisp:

    CL-USER> (defclass my-class () ())
    #<STANDARD-CLASS COMMON-LISP-USER::MY-CLASS>
    CL-USER> (defmethod identify ((mc my-class)) "This is my class")
    #<STANDARD-METHOD COMMON-LISP-USER::IDENTIFY (MY-CLASS) {1005BDFFB3}>
    CL-USER> (defmethod identify ((n fixnum)) "This is a fixnum")
    #<STANDARD-METHOD COMMON-LISP-USER::IDENTIFY (FIXNUM) {1005C984F3}>
    CL-USER> (identify (make-instance 'my-class))
    "This is my class"
    CL-USER> (identify 3)
    "This is a fixnum"

> The way in which types get in your way in statically typed languages is pretty much gone in Julia as you can so easily and fluidly deal with types as they are just objects at runtime which you can pass around freely.

Did you notice how DEFCLASS returned a class object earlier? It's a first class value in Lisp:

    CL-USER> (defvar *c* (find-class 'my-class))
    *C*
    CL-USER> (type-of *c*)
    STANDARD-CLASS
    CL-USER> (make-instance *c*)
    #<MY-CLASS {1005E38AA3}>
    CL-USER> (typep (make-instance 'my-class) *c*)
    T
    CL-USER> (subtypep (defclass derived-class (my-class) ()) *c*)
    T

Reply on news.ycombinator.com