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

81–90 of 137 posts

Re: Revenge of the Types

#81

Post by andreif »

randlet wrote: post #43
bjourne wrote: post #11

Armin didn't address what I belive is the main point of adding type annotations to Python: compiler checkable documentation and as hints to IDE:s. Seen in that perspective, a sucky type system is good enough because it's use isn't to verify program correctness. Personally, I think a standardized format for describing types in docstrings would be 100x better but that's not the way the Python core devs have choosen. An…

On the topic of IDE's, WingIDE has an interesting approach where you can add `assert isinstance(your_var, SomeClass) to the beginning of your functions to help Wing analyse your code[1]. It's more verbose than type annotations and doesn't feel very idiomatic sprinkling asserts all through your code but I recall it being pretty helpful (I haven't used Wing in years now). [1] https://wingware.com/doc/edit/helping-wing-…

Sometimes I do it in PyCharm as well when it has troubles auto-detecting types.

Re: Revenge of the Types

#82

Post by loup-vaillant »

jshen wrote: post #39
eric_bullington wrote: post #37

Earlier quoted context omitted.

>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…

"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…

Funnily enough, my experience has been quite the opposite.

I never felt the need for TDD or such… until I used Lua. I was drowning in bugs for a tiny 200 lines program! I just couldn't finish. Then I wrote some visualization code, then more of it, until I had the equivalent of a domain specific debugger. It worked. I found my mistakes, and corrected them. Then I though "that is where TDD comes from".

A statically typed languages such as Ocaml or Haskell would have caught the vast majority of my mistakes right away. Heck, even C++ would have helped. In my experience, writing code that "mostly works" is faster with a statically typed language. So many trivial tests you don't have to write, so much debugging you don't have to do…

> Second, most bugs I've experienced in large code bases using a dynamic language are not the sort that would be caught by most typed languages.

So, no Null pointer bug?

Also don't underestimate the number of domain logic errors that could have prevented by encoding the domain logic into the type system. Type systems can encode many invariants, they're not limited to "this is a bool, I wanted an int".

Re: Revenge of the Types

#83

Post by kd0amg »

eru wrote: post #54
rdtsc wrote: post #52

Earlier quoted context omitted.

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-state…

You can fix catch these errors with a suitably advance type system

Not that it matters in most cases though. A programmer picking a language for a project does not realistically have access to the full design space of type systems. If the only implementation of a language with some type system feature is an interpreter for a core calculus written in Agda and not touched for the past several years, that feature is effectively unavailable. Most programmers are not in the business of designing and implementing custom type systems (and associated languages) and probably wouldn't gain enough from it for it to be worth the work of learning how anyway.

Re: Revenge of the Types

#84

Post by e12e »

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…

A language spec (other than "cpython is the spec") would probably be good. But I know of jython, iron python, stackless python and micro python, in addition to pypy -- that are all more or less complete and/or alive as alternative implementations. I'm not sure of the .net variant (iron python) -- I've heard rumours that it's dead. So it's not like the lack of a spec is an insurmountable obstacle, nor like it's not something that no-one is working on...

Re: Revenge of the Types

#85

Post by tiffanyh »

Lua

The more I read Armin's posts, the more I believe he should switch to Lua. It has all the core features he wants:

- simple design

- fast

- consistent behavior

In addition to what's mentioned above, LuaJIT is a marvelously designed JIT (please donate to the project [1]. Let's keep allowing Mike Pall to have a livelihood)

[1] http://luajit.org/sponsors.html

Re: Revenge of the Types

#86

Post by klibertp »

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…

> Personally I want ...

Julia, maybe?

Re: Revenge of the Types

#87

Post by ayrx »

radlad wrote: post #60
ayrx wrote: post #31

Earlier quoted context omitted.

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?

Little bit of both actually.

If the primary motivation behind optional type checking is IDE hinting and compile time checks I'd actually prefer a standard docstring format instead of annotations.

Re: Revenge of the Types

#88

Post by dbaupp »

TD-Linux wrote: post #61
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…

I think Python had one chance to do what you suggest - remove bizarre behaviors. This chance was Python 3. This is also one of the things that bothers me a bit about Rust. The complexity of the compiler means that writing an actual language spec is hard, and the spec is very much tied to "what rustc's borrow checker is capable of".

There is a relative formal document describing the borrow checker's behaviour: http://doc.rust-lang.org/master/rustc/middle/borrowck/doc/

Re: Revenge of the Types

#89

Post by eru »

kd0amg wrote: post #83
eru wrote: post #54

Earlier quoted context omitted.

> * 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-state…

You can fix catch these errors with a suitably advance type system Not that it matters in most cases though. A programmer picking a language for a project does not realistically have access to the full design space of type systems. If the only implementation of a language with some type system feature is an interpreter for a core calculus written in Agda and not touched for the past several years, that feature is eff…

Yes. Though you can get pretty far with the extensions built into a mainstream compiler like ghc these days. If you are already doing Haskell, then the investment necessary for getting familiar with these is lower.

Re: Revenge of the Types

#90

Post by calinet6 »

jshen wrote: post #39
eric_bullington wrote: post #37

Earlier quoted context omitted.

>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…

"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 know that this is a cop out argument, but trust me, we all went through this phase. Eventually you'll see static typing as another tool in the box, that is only helpful and doesn't get in your way.
Post reply on HN