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

Revenge of the Types

lucumr.pocoo.org

Post reply on HN
Print view View original

51–60 of 137 posts

Re: Revenge of the Types

#51

Post by bjz_ »

the_mitsuhiko wrote: post #9
pjungwir wrote: post #7

Random question for the type experts out there: is there any language that lets me track the units of my numeric variables? For instance, something like this: float drop(float x0, float duration) { float x = x0; float t = 0; float v = 0; float g = -10; float dt = 0.01; while (t /1000 ); // abbrev for a cast: (float ).001 } Then I want the compiler to check that I'm not mixing up my units. It seems like this would be…

In theory you can do that in any language that allows you to override operators. It's definitely being done in Rust. For instance you sleep for `Duration::milliseconds(10)`.

Statically checked dimensional analysis is a great deal trickier though.

Re: Revenge of the Types

#52

Post by rdtsc »

MetaCosm wrote: post #50
jshen wrote: post #39

Earlier quoted context omitted.

"But for building a robust application that will have to be maintained a long-time, you have to religiously write tests in these languages or you'll be buried in bugs. And even then, you still may be buried in bugs that a static, strongly-typed language would have detected." People make this sort of claim all the time, but my personal experience has not borne it out, and I have seen no data to backup this claim which…

I agree with you on one part, writing static language INITIAL code, does generally take more time. Depending on the language, it can vary from slightly more in something like Go (where composition is valued over type hierarchies) to a great deal longer in languages that encourage lots of castle building and type relationships. That said, I have been in industry for over a decade in a half, and the most miserable, hel…

I have also been in the industry for about as much and noticed:

* Sometimes, the time it takes to build something in a statically typed language is much longer. Long enough that by the time it is built it might not matter because somebody would have built it in node.js, ruby, or python. I really depends on the market.

* Type mismatches in a Python program are not the biggest and deadliest bugs. Unit tests and integration tests (that should be there anyway) should catch those well.

* Often static type languages that have pointers (C, C++) hide much deadlier and dangerous types of bugs -- pointer bugs like "wild pointers".

* Static type language that don't offer protocol checks also can't easily detect bugs where you open a file handle, close it, then read from it. It knows it is a FILE or some iostream but it doesn't help much there. I've heard other more advanced languages have something in place to handle that.

* The above point coupled with being able to use the REPL on a production system and code has saved significant debugging time. In a complex system there could be an interaction that is hard to reproduce and this one system is in that funky state. Can log in via SSH into it, edit the code to add some debug statements and reproduce it again.

In summary, I would like Python to have a standard type annotation syntax that good linters will be able to check for and IDEs will know how to read and use. But it would not be at the top of the list of features I would like Python to have next.

EDIT: (sorry, last sentence should have said "it would not be" instead of "it would be")

Re: Revenge of the Types

#53

Post by rdtsc »

ak217 wrote: post #46

Of all Armin's articles to date, this one I agree the most with. > Python is a language that suffers from not having a language specification ... There are so many quirks and odd little behaviors that the only thing a language specification would ever produce, is a textual description of the CPython interpreter... Keeping a language lean and well defined seems to be very much worth the troubles. Future language desig…

> Any such bizarre behaviors need to be treated as a bug, and eliminated in the next release.

Going back in time (sorry for the long story).

From what I observed, there seems to have been a split in the community. The split is between the importance for PyPy and its future vs the "core" CPython.

When PyPy was making very fast progress there was a feeling that maybe in the next big release PyPy will merge into CPython. So maybe if you downloaded python 3.0 you'd just get PyPy with it. There was a lot of hype and hope. And I think at some level the old guard (Guido and some other core developers) saw that as bit of threat and they made public remarks that I understood to mean: "CPython is not PyPy", "it won't be merged in any time soon", "CPython is fast enough".

So why all this background? Well that might explain why there would be resistance to modifying CPython to "help out" PyPy.

Re: Revenge of the Types

#54

Post by eru »

rdtsc wrote: post #52
MetaCosm wrote: post #50

Earlier quoted context omitted.

I agree with you on one part, writing static language INITIAL code, does generally take more time. Depending on the language, it can vary from slightly more in something like Go (where composition is valued over type hierarchies) to a great deal longer in languages that encourage lots of castle building and type relationships. That said, I have been in industry for over a decade in a half, and the most miserable, hel…

I have also been in the industry for about as much and noticed: * Sometimes, the time it takes to build something in a statically typed language is much longer. Long enough that by the time it is built it might not matter because somebody would have built it in node.js, ruby, or python. I really depends on the market. * Type mismatches in a Python program are not the biggest and deadliest bugs. Unit tests and integra…

> * Static type language that don't offer protocol checks also can't easily detect bugs where you open a file handle, close it, then read from it. It knows it is a FILE or some iostream but it doesn't help much there. I've heard other more advanced languages have something in place to handle that.

You can fix catch these errors with a suitably advance type system; but often a simple construct like Python's with-statement works well for most cases, too. (If you have higher order functions or macros or RAII, that kind of construct doesn't need to be build into the language, even.)

Re: Revenge of the Types

#55

Post by eru »

aikah wrote: post #42

We live in that wonderfull time in development,where a lot of things are questioned.A lot of languages that used to rule everywhere are questioned,like the OP,and devs try to come up with the ultimate language that would solve every use case. There is,of course, no such a language but future languages wether they are dynamic or static ,strong or weak (type wise) will certainly not make the same mistake as their ances…

You probably also want sum types (or generally Algebraic Data Types) with your unicorn language.

Re: Revenge of the Types

#56

Post by gizmo686 »

berdario wrote: post #38
tikhonj wrote: post #25

Earlier quoted context omitted.

Haskell has a few libraries to do this. I particularly like unittyped[1], which not only keeps track of units but also converts among compatible ones automatically. So 1 meter + 1 inch would typecheck and be converted automatically, but 1 meter + 1 second would give you a type error. The wiki page[2] has a bunch of examples, which I find pretty compelling. The one problem is that error messages are ugly, but they're…

I'm not sure why, but your examples aren't working with me... 1 *| meter |+| 35 *| centi meter 1.35 m works, but 1 meter fails with :42:1: No instance for (Num (Value LengthDimension (U Meter) f0 -> t0)) arising from the literal `1' Possible fix: add an instance declaration for (Num (Value LengthDimension (U Meter) f0 -> t0)) In the expression: 1 In the expression: 1 meter In an equation for `it': it = 1 meter :42:3:…

Try running "import UnitTyped.NoPrelude" first.

  EDIT: you may also want to start ghci with the "-XNoImplicitPrelude" flag, or explicitly disambiguate operations such as "*" with "UnitTyped.NoPrelude.*" or "Prelude.*"

Re: Revenge of the Types

#57

Post by eru »

tikhonj wrote: post #25
pjungwir wrote: post #7

Random question for the type experts out there: is there any language that lets me track the units of my numeric variables? For instance, something like this: float drop(float x0, float duration) { float x = x0; float t = 0; float v = 0; float g = -10; float dt = 0.01; while (t /1000 ); // abbrev for a cast: (float ).001 } Then I want the compiler to check that I'm not mixing up my units. It seems like this would be…

Haskell has a few libraries to do this. I particularly like unittyped[1], which not only keeps track of units but also converts among compatible ones automatically. So 1 meter + 1 inch would typecheck and be converted automatically, but 1 meter + 1 second would give you a type error. The wiki page[2] has a bunch of examples, which I find pretty compelling. The one problem is that error messages are ugly, but they're…

> Haskell is really good at dealing with numeric types in general.

I just wish they had based the numbers on mathematical concepts like rings and fields, instead of this weird Num thing.

Re: Revenge of the Types

#58

Post by radlad »

ivoras wrote: post #23

Not only that, but look at the niche Python is occupying. It's a well established and respected niche to which, by definition, the language is suited very well. By adding static types, the focus of the language would move to a different niche, which would probably be already occupied by some competitor language(s) which do(es) types much better. If you want sort-of Python-ish syntax with elaborate types, just use Nim…

And this argument would be why PHP is in the shape it is today.

Re: Revenge of the Types

#59

Post by keypusher »

eric_bullington wrote: post #37
gordaco wrote: post #35

"Because there is basically no type system that fights against you, you are unrestricted in what you can do, which allows you to implement very nice APIs." If you feel like the type system fights against you, chances are that you are doing something wrong. When I program, the type system definitely fights for me. It gives me a lot of guarantees, plus it's a really convenient way of self-documentation. I mean, I'm not…

>If you feel like the type system fights against you, chances are that you are doing something wrong. Like most things, I think this depends on context. Doing exploratory data analysis in a static, strongly-typed language, for example, is extremely painful. And writing quick, one-time scripts in such languages is usually more trouble than it's worth. For this reason, Python is a wonderful language for doing data anal…

Dart is a language worth considering if you want something with static types that compiles to js.

Re: Revenge of the Types

#60

Post by radlad »

ayrx wrote: post #31
mmagin wrote: post #6

I didn't know Python users hate static typing so much.

I don't "hate" static typing. I dislike the current proposal though, because the proposed syntax is a horrible wart on top of a very elegant language.

Do you mean aesthetically or the proposed specifications?
Post reply on HN