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

Why Type Systems Matter

matthias-endler.de

Post reply on HN
Print view View original

51–60 of 103 posts

Re: Why Type Systems Matter

#51

Post by shock »

mcphage wrote: post #36
blauditore wrote: post #32

I thought this was quite clear, and it's what I've always been missing in languages like Python or JS. Yet I meet many devs, especially coming from such languages, making fun of Java for its verbosity and clumsiness. On the other hand, it leads to some people abusing the static type system: They just randomly change types until it somehow compiles, without thinking about what their doing.

> making fun of Java for its verbosity and clumsiness Java has a particularly verbose and clumsy type system.

What do you mean it has a verbose type system?

Re: Why Type Systems Matter

#52

Post by shakna »

thanatropism wrote: post #38
dragonwriter wrote: post #35

Earlier quoted context omitted.

Haskell types don't exist at runtime. If you use a static analyzer like mypy, Python types are “static” in the same sense as Haskell (statically verified as correct in advance), though mypy’s type system is less robust than Haskell’s.

I'm not knowledgeable of this stuff, but I'll keep taxing your patience until you tell me to stop. Haskell types don't exist at runtime... because Haskell code (like with any other compiled language) gets translated to a lower-level machine language that works with untyped memory addresses? Or are you saying that (for example) Fortran types are closer to the metal somehow?

Haskell types don't exist at runtime, because you can't check a type at runtime.

Any type-checking has to happen at compile time, because that information doesn't make it through.

So, something like Python's isinstance or type functions can't exist.

Re: Why Type Systems Matter

#53

Post by kuschku »

ardit33 wrote: post #41
blauditore wrote: post #32

I thought this was quite clear, and it's what I've always been missing in languages like Python or JS. Yet I meet many devs, especially coming from such languages, making fun of Java for its verbosity and clumsiness. On the other hand, it leads to some people abusing the static type system: They just randomly change types until it somehow compiles, without thinking about what their doing.

Java is notorious as it has very clumsy syntax. Simple arraylist of dictionaries declaration looks like this: ArrayList > myArrayList = new ArrayList >(); Could have been just: ArrayList > myArrayList = new(); or even better: ArrayList = new(); <- if you don't care what the type of map is.

That is almost literally what Java does.

ArrayList myArrayList = new ArrayList(); works already today.

Re: Why Type Systems Matter

#54

Post by zodmaner »

gumby wrote: post #16

Some languages mix static and dynamic typing. For example MACLISP used this to great effect to make MACSYMA super fast. All the numeric code was statically typed and the compiler built code that was as fast as hand crafted assembly. Yet you could write conventional Lisp code that called this static code just like any other code. MACLISP derivatives like lisp machine lisp also implemented this stuff and used it for sy…

> All that survived into Common Lisp but I am not up on the current state of lisp implementations and have no idea if people bother to take advantage of it any more.

There are implementations of Common Lisp, most notably CMU CL and SBCL, that take advantage of the (optional) type declaration of Common Lisp to increase efficiency and provide type checking.

Re: Why Type Systems Matter

#55

Post by argv_empty »

rocky1138 wrote: post #50
seanwilson wrote: post #11

Earlier quoted context omitted.

Can you give an example? I don't find this personally. I find static strong typing speeds me up because I don't have to restart the app, click some buttons etc. to figure out some code was wrong. This is true even for prototypes. Most of the time any type declarations you need are straightforward and once you know your code better you can start introducing more exotic types to capture more errors later.

A really basic example would be the "as GameObject" part of this statement in C#: `GameObject gameObject = GameObject.Instantiate(MyGameObject, Vector3.zero, Quaternion.Identity) as GameObject;". It's annoying to have to type "as GameObject" when very clearly I am creating a GameObject type (the first thing in the entire statement). Programming languages should be smart enough to figure out that's what I'm trying to…

Like GP, I often wonder what untyped languages offer over typed languages for prototyping, and this "soooo much annotation!" thing just isn't a satisfying answer anymore. "Typed" does not mean "as verbose as C#/Java."

Re: Why Type Systems Matter

#56

Post by mcphage »

shock wrote: post #51
mcphage wrote: post #36

Earlier quoted context omitted.

> making fun of Java for its verbosity and clumsiness Java has a particularly verbose and clumsy type system.

What do you mean it has a verbose type system?

Person myPerson = new Person("My", "Name")

You need to specify the class twice on the same line, because Java can't figure it out on its own.

Re: Why Type Systems Matter

#57

Post by zaphar »

falcolas wrote: post #33

There is never a person more zealous (and vocal in their zealotry) than a new convert. You don't see the bad points, just the good. That's how this post comes across: "Types are so awesome, let me show you how awesome types are!" Come back in two years, show us how the types feel after the honeymoon is over.

7 years after I first learned to love type systems and the honeymoon hasn't worn off.

They definitely have some tradeoffs. Depending on the type system sometimes something I think should be expressible in a particular way isn't and I have to do it differently. There is some extra cognitive load forced on me when reading the code.

But the upside is huge. Refactoring is easier and safer. The production launch of the application is less scary. I'm even faster at end to end development with a type system backing me up.

Re: Why Type Systems Matter

#58

Post by willtim »

gertef wrote: post #26
willtim wrote: post #4

Earlier quoted context omitted.

There's no reason why static type errors can't be deferred until runtime, GHC Haskell can do this. Personally I find types invaluable when prototyping. I often fill in the implementations after I work out the types.

> I often fill in the implementations after I work out the types. OK, but that's the opposite of deffering type errors until runtime. Using "undefined"/bottom as the implemenation of a function is how we wrote Haskell before GHC added support for deferring type-errors.

Yes I don't use deferred type errors much. But the parent poster wanted the option to avoid worrying about type correct programs.

Re: Why Type Systems Matter

#59

Post by jmull »

mixedCase wrote: post #13
rocky1138 wrote: post #2

Strong typing is great when I've already made sense of how the logic should flow and I'm ready to solidify my work into something stable and extensible over time. It's not so great when I'm trying something new and am still trying to work out if what I want to do is even possible, since I find myself trying to identify the right type to use in a given situation rather than proving that I'm even able to do it. A lot o…

With a good type system, instead of writing algorithms first you would write data structures that convey the ideas behind the software's intent clearly. Then you start writing the algorithms that manipulate these data structures. If what you're trying to do is viable, then you'll be able to express it in the domain model.

I usually start design with a domain model, whatever the type system I'll be working with.

(Just pointing out you can go this route regardless of your type system.)

Re: Why Type Systems Matter

#60

Post by andrewflnr »

shock wrote: post #51
mcphage wrote: post #36

Earlier quoted context omitted.

> making fun of Java for its verbosity and clumsiness Java has a particularly verbose and clumsy type system.

What do you mean it has a verbose type system?

Nice static type systems don't make you write out nearly as much crap as Java's does. It's pretty common for them to be able to completely infer the type of every expression in the program. If you're worried about the mere coherency of the concept of a "verbose type system", well, it was just a clever turn of phrase.
Post reply on HN