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

101–110 of 137 posts

Re: Revenge of the Types

#101

Post by calinet6 »

jshen wrote: post #96
calinet6 wrote: post #90

Earlier quoted context omitted.

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.

Trust me, I've been doing this longer than you. Or maybe I'm just smarter, but you'll understand one day. Why be so condescending? Why assume things you have no way of knowing?

Told you it was a cop-out argument. I'm just telling you what my experience was when encountering this topic, and then my conclusion after revisiting it many times over the course of a dozen years or so.

Re: Revenge of the Types

#102

Post by OzzyB »

Cyther606 wrote: post #45

I've been using Nimrod to replace Python on a Bitcoin project. elliptic.nim: https://github.com/def-/bigints/blob/master/examples/ellipti... elliptic.py: https://github.com/wobine/blackboard101/blob/master/Elliptic... Nimrod looks and feels like python, but it compiles to C. It's like C except with Pythonic syntax and with Boehm GC optional. In addition, Nimrod has a burgeoning NPM-like module ecosystem developing, a…

Thanks for posting this, was not aware.

Spent much of Sunday reading the language docs and I must say, as a "die-hard Pythonista", this is really cool stuff.

Will definitely keep an eye on this one.

Re: Revenge of the Types

#103

Post by bunderbunder »

e12e wrote: post #84
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 so…

It's probably not an insurmountable obstacle, but getting over it is by no means trivial. Exhibit A: None of the alternative Python implementations are 100% compatible with CPython. I get the impression that, in practice, the "Python spec" is something that can only be approached asymptotically.

Re: Revenge of the Types

#104

Post by the_af »

rurban wrote: post #98
aidenn0 wrote: post #65

Earlier quoted context omitted.

If you have ever programmed in a language with strict enforcement of something like a "maybe" or "option" type then you'll see that it's fairly trivial to have a separate type for a nullable pointer and a non-nullable pointer. It is essentially brain-dead that the type Foo really means "Either a Foo, or null" Failure to properly check for null is a source of many, many bugs, and there is an almost trivial way (assumi…

I don't see the issue. Armin went completely insane IMHO. This problem is usually solved by expressing the type "Foo or Null" as Foo? in such a gradually typed language. Maybe the critics should lookup the basic type literature first. Such posts will kill python. And this type of type critic already did kill python for Google. (And kept perl 10 years behind)

If when the type of a function F is "Foo or Null", you can express it as something like

F(...): Foo?

and if you're later forced to deal with such a value, Null cannot catch you by surprise, then haven't you just rediscovered Option types?

If, on the other hand, "?" is just an operator you use on values that can be null, to guard against an exception, this seems less useful. Are you going to wrap every return value of every function call with it? What happens if you forget? How can you know, at a glance, if a function may return a null value?

Re: Revenge of the Types

#105

Post by int_19h »

andreif wrote: post #81
randlet wrote: post #43

Earlier quoted context omitted.

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.

PTVS supports it, as well. Basically, this is the way to go if you want cross-IDE type hints right now.

Re: Revenge of the Types

#106

Post by AnimalMuppet »

jshen wrote: post #97
stettix wrote: post #79

Earlier quoted context omitted.

"I have seen no data to backup this claim which would override my personal experience" There have been attempts at measuring the effect of type systems, see for example this excellent presentation for some references: http://www.slideshare.net/Felienne/putting-the-science-in-co... . One of the studies mentioned here does claim that, other things being equal, static typing helps find bugs quicker.

Thanks for the link. I've read a lot of research papers along these lines. The results vary a lot.

The problem was in the phrase "other things being equal". Other things are never equal. Studies try to make them as equal as they can, and wind up differing as to which things are more important to get equal, and wind up with different results.

Re: Revenge of the Types

#107

Post by bunderbunder »

jshen wrote: post #95
loup-vaillant wrote: post #82

Earlier quoted context omitted.

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

I always wonder, if languages like Haskell are so good, why don't we see a lot of amazing open source projects built with these languages? If you can get things done faster with fewer bugs it should be reflected in real life code bases. Yet I haven't seen it. "The only arguments that hold water, in terms of programming language suitability, are bold, finished projects." http://t.co/ahOBAnXZ18

I think maybe it's just another example of the worse-is-better principle.

Great as it is, the language itself (and functional programming in general) tends to be pretty opaque to most programmers. Purity is powerful; we've all heard it before so I'll spare us yet another apologia. But, as my time spent TAing an introductory course in Scheme taught me in agonizing detail, purity is painful, too. Most people just don't naturally think of processes as a composition of mappings from values in a domain to values in a codomain. For better or for worse, the "process as widget-fiddling" way of thinking comes much more easily.

Re: Revenge of the Types

#108

Post by rcthompson »

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…

What are good examples of languages with specifications and at least two implementations that fully implement the spec?

Re: Revenge of the Types

#109

Post by ssmoot »

jshen wrote: post #95
loup-vaillant wrote: post #82

Earlier quoted context omitted.

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

I always wonder, if languages like Haskell are so good, why don't we see a lot of amazing open source projects built with these languages? If you can get things done faster with fewer bugs it should be reflected in real life code bases. Yet I haven't seen it. "The only arguments that hold water, in terms of programming language suitability, are bold, finished projects." http://t.co/ahOBAnXZ18

I think maybe you do.

The size of Sonatype Snapshots and Central is roughly around Rubygems.org size I think. But so so so many Ruby projects are half baked, while so many public JARs are so much more mature (if often not very pleasant to work with).

Re: Revenge of the Types

#110

Post by CountSessine »

rcthompson wrote: post #108
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…

What are good examples of languages with specifications and at least two implementations that fully implement the spec?

Given how complicated any specification for a non-trivial language is, I wonder if there are any. But I think this is beside the point.

Not having a specification for a language pushes every language feature discussion down onto application and library developers 'in situ'. When a developer or library maintainer stumbles onto unexpected interpreter or compiler behavior in a language without a specification, it means that in the short term there's no guidance about how they should deal with it. Do I hack this for Visual C++ in a way that can be removed eventually or do I really have to assume going forward that variadic templates aren't going to be available?

Post reply on HN