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

91–100 of 137 posts

Re: Revenge of the Types

#91

Post by tel »

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…

> Doing exploratory data analysis in a static, strongly-typed language, for example, is extremely painful.

As bullish as I normally am on static typing, I agree with that wholeheartedly—today.

I'm also completely convinced that a language with good enough record row-subtyping will take over as being far better for EDA than any dynamic language within the next 5 years.

That's the thing about research in types—it's almost always about discovering new techniques to appropriately structure and represent more complex programming techniques. It can lag for reasons of sophistication, but once it's in place it'll be hard to beat.

Already I feel it's absolutely the case that good static types (Haskell I'm most familiar with, but I imagine it's the case with Scala, OCaml, F#) are a win for short, one-off scripts. The difference is that the types you use are looser than the ones you'd use for a super robust application. The typing ends up looking a lot more like the typing you'd implicitly apply to a Python program [0].

So, "use the right tool for the job" applies to typing technology as well. Static types, I believe, will eat the use cases of dynamic types.

[0] This is essentially an extension of the "unityped argument". If you program in Haskell in a "always IO, frequently ambiguous" fashion then you can get all the flexibility you're used to in scripting in Python with little overhead.

Re: Revenge of the Types

#92

Post by tel »

berdario wrote: post #70
gizmo686 wrote: post #56

Earlier quoted context omitted.

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.*"

Thanks, but that's not enough. The error seems due to the fact that `meter` is passed as an argument to `1` which is not a function, and indeed I don't see how that could be valid haskell code (unless there's some language flag I should enable, but unfortunately the wiki/docs of unittyped doesn't seem to be comprehensive enough)

1 absolutely could be a function—all you need is a function type to instantiate Num.

Re: Revenge of the Types

#93

Post by cygx »

I find it interesting that this is exactly what Perl6 tried to handle gracefully, both on the technical side (a type system that supports both static and dynamic typing) as well as on the practical side (a re-implementation from scratch with some measure of interoperability).

However, they did not set out to just design the next version of Perl, but the last version, reasoning that if you have proper extension mechanism in place, you won't have to do a reboot ever again.

This resulted in gradual typing (which sometimes needs to fall-back to runtime checks), a pluggable syntax with extensible grammar, a flexible meta-object protocol, default numeric types that are objects (rationals or bigints), lazy list, reified language construct (variables as container objects) and other stuff that makes a straight-forward implementation horribly slow.

Re: Revenge of the Types

#94

Post by bunderbunder »

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 have seen no data to backup this claim which would override my personal experience.

I think that there are two reasons why good data on this is not forthcoming.

The first is that for a long time the dominant statically typed languages have been C++, which forfeits most of the potential advantages of static typing by also being weakly typed, and Java, which handles types somewhat better (while by no means being state-of-the-art) but brings its own productivity challenges.

The second is, the kinds of enormous long-lived maintained-by-50-full-timers hoary old enterprise applications that I think most fans of static typing have in mind when they say, "I wouldn't want to maintain that in a dynamic language!" aren't often written in dynamic languages. This in and of itself could be seen as evidence that dynamic languages really are unsuited to the task.

Perhaps the more interesting evidence, though, is the tendency of what few larger- and longer-lived dynamic projects there are to become famous for messy code. This hits at what I think fans of static typing are really talking about - that doing any sort of large-scale refactor in a dynamic language is a terrifyingly error-prone experience. You need to rely on ever-fallible humans to have written tests that exercise all relevant code paths in order to verify that the refactor was successful in even the most basic terms. For someone who's used to having the compiler quickly, reliably and exhaustively provide the same feedback, having to fall back on the source of all known bugs (programmers) to do the same job leaves one feeling a bit exposed.

Re: Revenge of the Types

#95

Post by jshen »

loup-vaillant wrote: post #82
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…

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

Re: Revenge of the Types

#96

Post by jshen »

calinet6 wrote: post #90
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 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?

Re: Revenge of the Types

#97

Post by jshen »

stettix wrote: post #79
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 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.

Re: Revenge of the Types

#98

Post by rurban »

aidenn0 wrote: post #65
jimmaswell wrote: post #32

>So what's the solution? Not having null references and having explicitly typed arrays. Throwing the baby out with the bath water. Null types are extremely useful. I don't get why the author claims the null type in C# is a form of "damage". It's just said that it's bad, not why. The problem with None in python was that you can't tell what it's supposed to be. In C# you know what type the null is meant to be.

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)

Re: Revenge of the Types

#99

Post by rurban »

wirrbel wrote: post #71

This is a very nice article showing some of the issues troubling python and the proposed type anotations. I would summarize my view of the type annotation proposal as follows: Statically typed languages can introduce inference heuristics that minimize the amount of type declarations. They can "jump" into the dynamically typed world more easily. The other way around is a lot harder. Not only are all those type annotat…

No, it's a horrible article. And no, they cannot. I implemented such a type inferencer for perl (B::CC), which has the exact same problem.

With a highly dynamic run-time which changes the types at will, the compiler will never be able to do proper optimizations without explicitly forbidding certain coercions. The inferencer has to give up in 90% of all cases.

Only with optional explicit types, esp. for loop counters and array members, those operations can be efficiently optimized. Up to 2000% for the typical array or loop benchmarks.

And no, a v8-style tracing jit also does not help in all cases. This kind of run-time type caching has a huge overhead, and will always need an explicit run-time check, and does not catch the typical type errors writing programs. It helps with simple scripts, but not with programs.

You don't have to worry. If you don't like to use types, don't use it. Nothing will change. It will only compile-time optimize and check the cases where someone added the types.

Of course the standard library is free to add type-optimized versions later, as e.g some Common Lisp's did with their arrays and vectors. But this was done mostly in the compiler, not in the library itself.

Re: Revenge of the Types

#100

Post by ForHackernews »

Can somebody explain in greater detail what this means:

> This is true for the CPython interpreter world, but not true for Python the language. That these are not the same things is disappointing but generally the case.

My understanding was that the CPython interpreter is considered the "reference" implementation of Python, and that (except for bugs) it defined Correct Behavior for Python-the-language.

Post reply on HN