Live data from Hacker News

Diminishing returns of static typing

blog.merovius.de

561–570 of 632 posts

Re: Diminishing returns of static typing

#561

Earlier quoted context omitted.

Dynamic type testing or introspection is not an essential feature of type systems. The fact is, your computing machine is typed. You can not deference a floating point register as an address, for instance.

> Dynamic type testing or introspection is not an essential feature of type systems. I didn't say so. An essential feature of type systems is being able to determine the types of (many) values, statically or dynamically. > You can not deference a floating point register as an address, for instance. So you'd agree that architectures that don't make a distinction between integer and floating point registers are untyped…

> It's just a very very weak one, so weak as to be almost entirely useless.

Weak and strong aren't meaningful terms. A machine ISA might have an inexpressive type system and/or an unsound type system (because it conflates addresses and integers).

> And the reason floating point registers are often separate from integer registers is not to provide this kind of "type safety", it's due to history and architecture.

No, the reason is performance. And we get performance by making statically known distinctions between datatypes, which is what the original poster asked about.

Intermingling the integer and floating point circuitry so they access the same register file would never improve performance over keeping them separate. You'd need longer wires to place them both near the same register files to minimize signal latency, an the added signal delay alone ensures lower performance.

Re: Diminishing returns of static typing

#562
post #539

Earlier quoted context omitted.

The original question asked whether static typing is needed when maximal performance is required. If we understand "maximal" to mean literally, "no more performance can possibly be squeezed out", then it simply is. Static typing might not be sufficient for this case, but it is necessary.

I think those few, crucial pieces of hand-written assembly language one sees from time to time disagree with you. (Modulo your observation that assembly languages are trivially statically typed.)

> I think those few, crucial pieces of hand-written assembly language one sees from time to time disagree with you.

I still don't think so. For example, plenty of silicon is spent on branch predictors simply because addresses and integers aren't distinguished, in general, thus permitting more expressive but costlier code.

Execution would be much faster if integers and addresses were forced to be distinct. Static typing pretty much always improves performance.

Re: Diminishing returns of static typing

#563
post #462

Earlier quoted context omitted.

I’m in the static camp myself, but there are dynamic language JIT runtimes that meet or exceed the performance of many static languages.

Including the Java runtime - the JVM is basically dynamic.

Java is a static language. While there are dynamic languages on the JVM like Jython, JRuby, Groovy, they don't get anywhere near the performance of the static languages.

Re: Diminishing returns of static typing

#564

Earlier quoted context omitted.

> Contracts are useless. No, they are not. 1. If the code doesn't conform to the contract, it will fail on the contract boundary, with a well-defined error. If this is useless, then `assert` is also useless, which it is, of course, not. 2. With a sufficiently well-designed language and sufficiently smart compiler, you can move some contract checks to compile-time. See Racket. 3. If your language supports both static…

0. Trapping the error doesn't make your program any less wrong. I agree that `assert` is equally useless. 1. With pencil and paper, you don't need to wait for a smart compiler - you can get started proving things about your programs today! 2. I can totally see what's coming next: “Being wrong is dual to being right, so being wrong is another possibility worth exploring”. Right? > Meta: (slander) No comment.

> No comment.

But why? You were able to "comment" on the work of Felleisen and colleagues on contracts, declaring their effort of many years useless, yet you can't answer why did you do it?

Your utter lack of respect for people who happen to hold an opinion different than yours is typical, in my experience, for static-typing fans; as is your apparent - and wrong - belief that static typing was proven to be "better" (for some value(s) of "better") than dynamic typing.

There are certain groups of people where the above traits are overrepresented. I think there is a high probability that preference for static-typing correlates positively with belonging to these groups - and I wrote that much. Is that really a "slander"?

Sorry for focusing on that part, but your 0-2 points are too wrong to correct in a few paragraphs, and I don't have the time for writing more than this.

Re: Diminishing returns of static typing

#565

Earlier quoted context omitted.

What does “somewhat sound” mean?

I think he refers to some of the usual criticisms of Common Lisp: 1. The language specification is very big. This is true, it is a very big specification. On the other hand, this is mostly caused because the language spec also includes the spec for its own "standard library", unlike what happens in C or Java, for example, where the Std. lib is specified elsewhere. CL's "standard library" is very big, because there ar…

ANSI CL is what some 1100-something pages?

JavaScript is up to 885 pages. https://www.ecma-international.org/publications/files/ECMA-S...

The C++ 17 draft: 1623 pages. https://www.ecma-international.org/publications/files/ECMA-S...

C, which "is not a big language, and is not well served by a big book", according to Thompson and Ritchie's 1988 introduction in the K&R2, is up to 683 pages in C11. Almost triple the size of C90's 230 pages.

How about something non-language? USB 3.2 spec (just released Sep 22): 100+ megabyte .zip file download. Up from 2.0's 73.

Re: Diminishing returns of static typing

#566

Earlier quoted context omitted.

0. There is nothing wrong with big standard libraries, so long as they are not redundant and the core language is small. 1. This is a serious criticism, but it has nothing to do with soundness. 2. There is absolutely nothing wrong with a language being designed by a committee, so long as the committee's members are all competent. 3. Back to 0.

>2. There is absolutely nothing wrong with a language being designed by a committee It sort of has a bad stigma, because two well-known, unloved languages were designed by committee: COBOL and PL/I.

Today, those roles are played by C++17 and C11.

Re: Diminishing returns of static typing

#567
post #472

Earlier quoted context omitted.

Right, but you are addressing only part of the story to side-effects. IO is another story, which rust doesn't address.

The standard library doesn't, and most crates don't, but I'm pretty sure nothing prevents you from writing libraries in a style where all IO requires mutable access to some explicit unique "World" object, similar to Clean. Passing a unique world object around is effectively the same as composing with the IO monad, and borrowing 'f(&mut world)' is basically equivalent to 'let world = f(world)'. Maybe someone will one…

It is not going to be convenient because rust doesn't have higher kinds. I see people making this argument in other language contexts e.g. Ocaml; but they have no typeclasses, which make writing monadic style code extremely inconvenient.

Re: Diminishing returns of static typing

#568
post #563

Earlier quoted context omitted.

Including the Java runtime - the JVM is basically dynamic.

Java is a static language. While there are dynamic languages on the JVM like Jython, JRuby, Groovy, they don't get anywhere near the performance of the static languages.

Oh, sure it's statically typed language with all things being constantly cast to and from Object. (Have you ever used collections? Have you ever heard of "type erasure" term?)

Re: Diminishing returns of static typing

#569

There are 3 main areas of interest in the discussion of benefits of static vs dynamic typing. - Quality (How many bugs) - Dev time (How fast to develop) - Maintainability (how easy to maintain and adapt for years, by others than the authors) The argument is often that there is no formal evidence for static typing one way or the other. Proponents of dynamic typing often argue that Quality is not demonstrably worse, wh…

10-20 years?! Holy Cow! Other than huge software projects (like Word or Mac OS - and even then...) is there really software that still has that kind of maintenance window? I've worked for a Fortune 150 company for nearly 2 decades. There is not a single piece of software at the company that has not been rewritten from scratch (usually due to business changes) at least once every 10 years. I can't even imagine somethi…

Parasolid [1] is 30 years old and is the dominant B-rep solid modeling kernel powering Solidworks, Siemens NX and Solid Edge. It's very difficult to see it being replaced as it is so entrenched.

Parasolid (written in a C dialect) was a rewrite of Romulus (written in Fortran) and that goes back to 1974. And that was a rewrite of Build that originated from Ian Braid's PhD thesis. [2]

I know people who are still working on the same Parasolid code after 30 years. Some of them

Disclaimer: Parasolid dev 1989-1995

[1] https://en.wikipedia.org/wiki/Parasolid

[2] http://solidmodeling.org/awards/bezier-award/i-braid-a-graye...

Re: Diminishing returns of static typing

#570
post #311

Earlier quoted context omitted.

> Automated refactoring was invented in Smalltalk, claiming it's a benefit only static typing provides is to not know history. History: In Bill Opdyke's thesis work, the tooling was written for C++ and written in CLOS. http://www.laputan.org/pub/papers/opdyke-thesis.pdf

Ralph Johnson, a prominent Smalltalk'er, was advisor on that paper and was the creator of the first Smalltalk refactoring browser and that paper is littered with references to how things are done in Smalltalk. I was unaware a C++ was involved, but I still think Smalltalk had the first commercial refactoring browser. A research paper is not a product, however, thanks for the ref.

Do you think having "the first commercial refactoring browser" is the same as "[a]utomated refactoring was invented in Smalltalk" ;-)

Incidentally, what's your source for "Ralph Johnson… was the creator of the first Smalltalk refactoring browser" ?

Post reply on HN