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

91–100 of 103 posts

Re: Why Type Systems Matter

#91

Post by dmux »

I'd be interested in hearing what the community has to say regarding static types and whether or not they're compatible with object-oriented programming. I've posted this link a couple times before, but it hasn't been actively discussed: https://essencesharp.wordpress.com/2014/07/17/static-typing-...

From that article:

"Static typing inhibits interoperability. It does so between class libraries and their clients, and also between programming languages.

The reason is simply because static typing violates encapsulation in general, and improperly propagates constraints that aren’t justifiable as architectural, design or implementation requirements in particular. It does so either by binding too early, or by binding (requiring) more than it should."

Re: Why Type Systems Matter

#92

Post by mcphage »

sqeaky wrote: post #80
mcphage wrote: post #73

Earlier quoted context omitted.

It is two separate operations, but in many other languages the compiler is smart enough to figure out that they'll be the same type (and allow you to specify it when they're not) That's what I mean—Java's type system is verbose and clumsy, because it doesn't bother trying to figure out things it could figure out, forcing the programmer to be redundant and repeat themselves all over the place. The fact that it's 2 sep…

I agree it could be more clean, but the way it is designed allows for immediately understandable semantics when dealing with inherited types (which everyone though was the future during Java's Formative years). This makes operations like this intuitive: Animal results = new Dog("Lassie");

It does, but they should have found a solution which allowed that, as well as not be redundant in the more common case where the two classes are the same. Hence Java's type system being verbose and clumsy.

Re: Why Type Systems Matter

#93

Post by evincarofautumn »

dmux wrote: post #91

I'd be interested in hearing what the community has to say regarding static types and whether or not they're compatible with object-oriented programming. I've posted this link a couple times before, but it hasn't been actively discussed: https://essencesharp.wordpress.com/2014/07/17/static-typing-... From that article: "Static typing inhibits interoperability. It does so between class libraries and their clients, and…

Many OOP languages don’t make it easy to achieve encapsulation and composability in the presence of their particular static type systems. It sounds like he’s just arguing that nominal typing is worse than structural typing, and early binding is worse than late binding; the comparison to static type systems is a false equivalence.

Re: Why Type Systems Matter

#94

Post by shakna »

gumby wrote: post #87
shakna wrote: post #39

Earlier quoted context omitted.

C++ is in this boat now. Most of the time I'd recommend the new type-safe union std::variant, but std::any is there. It is kinda a static type, but as a container-type of anything in the type system, it may as well be a dynamic type. --- > 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. Typed Racket use…

> Most of the time I'd recommend the new type-safe union std::variant Neither g++ 7 nor Clang/LLVM 4.0.1 support std::variant yet :-(. We started a new (blank buffer) codebase earlier this year and decided to use C++17 as the implementation language, which has exposed us to the gaps...which are surprisingly few! But sadly this is one of them.

> Neither g++ 7

Eh? I've been using it a hell of a lot!

std::variant is listed on GCC 7's page [0], and I know that is there in at least 7.1

I don't use clang much, but they list it as supported [1], and I believe the patch [2] landed in 5.0

[0] https://gcc.gnu.org/gcc-7/changes.html

[1] https://libcxx.llvm.org/cxx1z_status.html

[2] https://reviews.llvm.org/rL288547

Re: Why Type Systems Matter

#95

Post by juki »

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…

Common Lisp does allow one to declare types in order to have the compiler optimize the code. SBCL[0] in particular is known to be pretty good at that. Macsyma also lives on in Common Lisp as Maxima[1].

[0]: http://sbcl.org/ [1]: http://maxima.sourceforge.net/

Re: Why Type Systems Matter

#96

Post by lispm »

juki wrote: post #95
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…

Common Lisp does allow one to declare types in order to have the compiler optimize the code. SBCL[0] in particular is known to be pretty good at that. Macsyma also lives on in Common Lisp as Maxima[1]. [0]: http://sbcl.org/ [1]: http://maxima.sourceforge.net/

Though it does not really 'live', the Symbolics Macsyma also has been ported to Common Lisp in the 80s.

Re: Why Type Systems Matter

#97

Post by blauditore »

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.

As others have mentioned, there's the diamond operator which has been around since Java 7.

> if you don't care what the type of map is

You can use raw types, it works perfectly fine (just generates a compiler warning). For explicitly being unspecific, you can also use a type wildcard (`?`).

Re: Why Type Systems Matter

#98

Post by ziotom78 »

oconnor663 wrote: post #7
shalabhc wrote: post #6

Earlier quoted context omitted.

I wish this was adopted more broadly, e.g. by Rust and other newer languages.

What would the semantics of that be? Something like "this function contains a type error, so if you call it your code will just panic?"

If I understand well, Ada packages provide the necessary architecture for this kind of stuff. A package is like a Python "module", but it is typically split in two files: a specification, just containing the declaration of all the types and functions exported by the package, and a body, which actually implements the functions working on those types. When writing a program which uses that package, if you only compile it without linking, the compiler will complain about wrong types even if no function has been implemented yet.

A poor man's version of the above schema can be achieved in C/C++ as well. Just declare your functions in a header file and include it in your program, then compile without linking.

Re: Why Type Systems Matter

#99

Post by willtim »

ziotom78 wrote: post #98
oconnor663 wrote: post #7

Earlier quoted context omitted.

What would the semantics of that be? Something like "this function contains a type error, so if you call it your code will just panic?"

If I understand well, Ada packages provide the necessary architecture for this kind of stuff. A package is like a Python "module", but it is typically split in two files: a specification, just containing the declaration of all the types and functions exported by the package, and a body, which actually implements the functions working on those types. When writing a program which uses that package, if you only compile…

This is not the same thing as deferred type errors though. The programs are still type correct, it's just that some of the implementations are missing / producing errors.

Re: Why Type Systems Matter

#100

Post by kazinator »

kazinator wrote: post #85
dozzie wrote: post #63

Earlier quoted context omitted.

> The conflation between 'strong' and 'static', and 'weak' and 'dynamic', is probably terminal at this point, Type system of C is weak and static. Type system of JavaScript is weak and dynamic. Type system of Lisp is strong and dynamic. Type system of OCaml is strong and static. Type system of Python is dynamic. It may be strong or weak, depending on your opinion about duck typing (does it weaken the type system or n…

The "weak" terminology has a flaw because it sometimes means "leaves type errors undetected, with undefined behavior" and sometimes it refers to a situation whereby a character string like "3.14" can be treated as a number and such. Awk and Perl are not weakly typed in the same sense that C is weakly typed.

There is also the related aspect of conversions. Ada is said to be stronger than C even if we ignore the "holes in the type system" of C because it doesn't allow implicit conversions (conversions without an explicit conversion operator or casting syntax). Though C won't treat a "3.14" character string as a number, it implicitly converts among numbers of different kinds, and converts between void * and object pointers. Narrowing conversions silently discard data ("implementation-defined result"), and so do conversions between same size but different signedness. Out-of range conversions between integer and floating-point values can trigger undefined behavior. (These issues are still there when the conversions are explicit, but when the conversion are implicit, the issues can sneak into the code more easily by accident).

Though Lisp was listed in the grandparent posting as "strongly typed", it also has something similar to C's implicit conversions:

  [1]> (sin 42)
  -0.91652155
  [2]> (sin 42.0)
  -0.91652155
  [3]> (+ 1 2.0)
  3.0
Unlike C, it won't go from floating to integer:

  [4]> (evenp 3.0)

  *** - EVENP: 3.0 is not an integer
Whereas if we had an

  bool evenp(int arg);
function in C and called it as

  evenp(3.0);
or even

  evenp(3.1);
it would work.
Post reply on HN