Live data from Hacker News

Summer of Programming Languages

existentialtype.wordpress.com

31–40 of 78 posts

Re: Summer of Programming Languages

#31
post #9

Why do programming languages researchers seem so enamored with type-safe languages? It seems to be a given in academia that type-safe languages are not just superior, but significantly superior to type-unsafe languages.

I would say its because academic researchers don't spend nearly enough time actually using these languages industriously in the worst-case scenarios. If more effort was spent in understanding how, for example, SIL-4 (safety integrity level 4) development is done with non-type-safe languages (hint: code coverage tests, tests, tests..), then there would (imho) be less motivation to continually churn out 'new solutions…

>* If more effort was spent in understanding how, for example, SIL-4 (safety integrity level 4) development is done with non-type-safe languages (hint: code coverage tests, tests, tests..), then there would (imho) be less motivation to continually churn out 'new solutions to old problems' .. which have been solved, already.*

Because ad-hoc tests, tests, tests, ... with the verbosity they add (tons of uneeded tests that could be type checked instead), and the arbitrariness (you have to remember to add a test -- instead type checks are always run) and checking only some code paths (type checks propagate everywhere) are in any way better?

Not to mention that you can have type checks AND (less, complimentary) tests at the same time.

Re: Summer of Programming Languages

#32
post #10
post #9

Why do programming languages researchers seem so enamored with type-safe languages? It seems to be a given in academia that type-safe languages are not just superior, but significantly superior to type-unsafe languages.

Academics don't care so much about things like programming speed. And the academic environment focusses on proof; a type-safety property will seem much better than a unit test even when both took the same amount of time and have the same practical value. (For all that, I agree with them though. Maybe the reason programming languages researchers think that is because it's true? Do you have reason to believe they're wr…

>Academics don't care so much about things like programming speed.

I don't know. Haskell and OccamL, for one, are much, much faster than Python and Ruby.

Re: Summer of Programming Languages

#33
post #32
post #10

Earlier quoted context omitted.

Academics don't care so much about things like programming speed. And the academic environment focusses on proof; a type-safety property will seem much better than a unit test even when both took the same amount of time and have the same practical value. (For all that, I agree with them though. Maybe the reason programming languages researchers think that is because it's true? Do you have reason to believe they're wr…

> Academics don't care so much about things like programming speed. I don't know. Haskell and OccamL, for one, are much, much faster than Python and Ruby.

Citation needed. The argument for Haskell is usually about correctness; industry perception and my experience is that writing a Haskell version of a program will usually take longer than an "acceptably buggy" Python or Ruby equivalent.

Re: Summer of Programming Languages

#34
post #9

Why do programming languages researchers seem so enamored with type-safe languages? It seems to be a given in academia that type-safe languages are not just superior, but significantly superior to type-unsafe languages.

Types are the world's most popular verification technique. The whole intent of types is to automate many of the proofs required to guarantee the correctness of the program rather than having the human operator get bogged down in verifying the details themselves. Now yes, you can't verify all aspects of the program but types can still get you quite a distance of the way there at comparatively very little cost compared to more heavy formal verification techniques.

Re: Summer of Programming Languages

#35

Earlier quoted context omitted.

"Statically-typed" and "type-safe" don't mean the same thing. "Type-safe" means that the type of a value is always correct. For example, if I have a function of type Int -> String, a type-safe language will not let me pass it a Float argument, no matter what I do. A type-unsafe language might let me, if I can "cast" the value to a new type without changing its representation (ie. it's still a Float, but the type-chec…

Well, to people like Bob Harper, there is no such thing as a dynamic "type" (they are tags instead). The argument over terminology appears on comp.types every once in awhile. Then there are people into dynamic languages who swear they have more than one type and actually check these types at run type. Then the static type theorists say...you are just checking tags, and the DL people are like...what's the difference?

> DL people are like...what's the difference

The dynamic typing folks don't care to provide a definition of types and overload the term to mean many things, the static typing folks have a rigorous one.

Re: Summer of Programming Languages

#36
post #33
post #32

Earlier quoted context omitted.

> Academics don't care so much about things like programming speed. I don't know. Haskell and OccamL, for one, are much, much faster than Python and Ruby.

Citation needed. The argument for Haskell is usually about correctness; industry perception and my experience is that writing a Haskell version of a program will usually take longer than an "acceptably buggy" Python or Ruby equivalent.

[deleted]

Re: Summer of Programming Languages

#37
post #35

Earlier quoted context omitted.

Well, to people like Bob Harper, there is no such thing as a dynamic "type" (they are tags instead). The argument over terminology appears on comp.types every once in awhile. Then there are people into dynamic languages who swear they have more than one type and actually check these types at run type. Then the static type theorists say...you are just checking tags, and the DL people are like...what's the difference?

> DL people are like...what's the difference The dynamic typing folks don't care to provide a definition of types and overload the term to mean many things, the static typing folks have a rigorous one.

[deleted]

Re: Summer of Programming Languages

#38
post #23
post #9

Why do programming languages researchers seem so enamored with type-safe languages? It seems to be a given in academia that type-safe languages are not just superior, but significantly superior to type-unsafe languages.

Types are no silver bullet, however one important point missed by all the other replies is that static types check all paths through the program, including rare/untested/error paths. You can sometimes make up for this with lots of testing and detailed code coverage analysis, but that can be a huge amount of effort, and might be impossible in some cases (for example: how do you easily test that your program behaves we…

There are cases you cannot really exclude by testing. For example, guaranteeing that certain function never receives a null value.

Re: Summer of Programming Languages

#39
post #35

Earlier quoted context omitted.

Well, to people like Bob Harper, there is no such thing as a dynamic "type" (they are tags instead). The argument over terminology appears on comp.types every once in awhile. Then there are people into dynamic languages who swear they have more than one type and actually check these types at run type. Then the static type theorists say...you are just checking tags, and the DL people are like...what's the difference?

> DL people are like...what's the difference The dynamic typing folks don't care to provide a definition of types and overload the term to mean many things, the static typing folks have a rigorous one.

I see no definitions of type in the dictionary that specifically refer to static type theory...

Definition of type (n)

category or kind: a group made up of individuals or items that have strongly marked and readily defined similarities

person or thing: somebody or something regarded as belonging to a group or category by virtue of having the main qualities associated with it

particular kind of person: a person regarded as having a particular temperament or characteristics.

Re: Summer of Programming Languages

#40
post #36
post #33

Earlier quoted context omitted.

Citation needed. The argument for Haskell is usually about correctness; industry perception and my experience is that writing a Haskell version of a program will usually take longer than an "acceptably buggy" Python or Ruby equivalent.

[deleted]

All of that's about runtime performance, not programming time.
Post reply on HN