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.
Revenge of the Types
31–40 of 137 posts
Re: Revenge of the Types
#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.
Re: Revenge of the Types
#33Python's API structure may be fast and loose, but that is a feature, I think. Its type system may have some threadbare implementation spots – the _sre example from the standard library, for instance – but there are some compelling examples as well.
I, for one, have been working on an app implemented mostly with PyObjC, the bridge between Python and Objective-C. I had all but written off PyObjC as a bizarre yet unuseful language mule... but lately I had the occasion to read through the PyObjC source code base, in service of my project. Did you know that when you subclass a wrapped Objective-C type in Python, an all-new Objective-C class is created and wrapped as the descendant class, behind the scenes? That blew my mind.
That happens transparently, in concordance with Python's type heiarchy and runtime ABI. As it turns out, PyObjC predates Mac OS X, and the authors have put a lot of work into mitigating things like the GIL and system events.
I am also a fan of Django's field type system, as the author mentioned – and I am curious about what he thinks about descriptors (which he mentioned one but did not address) – I think descriptors are an amazing addition to the duck-typing regime in Pythonville.
Re: Revenge of the Types
#34Armin 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…
I think Armin didn't address these valid points, because as he points out,
"The first one is that I barely understand them[type systems] at all myself."
Re: Revenge of the Types
#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 even talking about Haskell or something really sophisticated: I see the advantages even in old plain Java or C++ (so much that, in fact, most of my gripes about Java are about its type system not being complex enough).
Also, being "unrestricted" is far from being an universally good thing, since it also means many more opportunities for mistakes. I know for a fact that I make more mistakes in languages without static typing, but well, I guess it's just me.
Re: Revenge of the Types
#36Not 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…
What exact niche is that? Unless you mean "dynamically typed" (in which case that begs the question), I don't know what niche you think it couldn't occupy with static types. Not even arguing for static types: your comment is just really unclear.
Re: Revenge of the Types
#37"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 analysis and writing quick one-time data munging scripts (and yes, I realize that Python can be considered strongly-typed).
On the other hand, I've now been exposed to languages like OCaml and Rust, and have had time to think about Java, and I now have a different attitude when I'm building a large application that will have to be maintained. I'm beginning to feel extremely vulnerable when I use a language like Python or (worse yet) Javascript to build such applications.
It's not that I'm not a Javascript hater. I like Javascript in general -- it has a kind of functional feel to it, it's easy to prototype quickly, you can use it client and server, nice ecosystem, and unlike so many I actually enjoy async programming. And I've long enjoyed Python for similar reasons.
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. For this reason, I'm looking hard for an static, strongly-typed alternative to Javascript for the browser (i.e., a language compiling to JS) for building large applications. And Ocaml's js_of_ocaml is definitely on my list of things to evaluate.
So the programming language philosophy that I adhere to now is encapsulated in the hackneyed old saying "use the right tool for the job".
Re: Revenge of the Types
#38Random 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…
I'm not sure why, but your examples aren't working with me...
1 *| meter |+| 35 *| centi meter
1.35 m
1 meter
: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:
No instance for (Fractional f0) arising from a use of `meter'
The type variable `f0' is ambiguous
Possible fix: add a type signature that fixes these type variable(s)
Note: there are several potential instances:
instance Fractional Double -- Defined in `GHC.Float'
instance Fractional Float -- Defined in `GHC.Float'
instance Integral a => Fractional (GHC.Real.Ratio a)
-- Defined in `GHC.Real'
...plus four others
In the first argument of `1', namely `meter'
In the expression: 1 meter
In an equation for `it': it = 1 meterRe: Revenge of the Types
#39"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…
"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 would override my personal experience.
First, I find I have to write tests nearly as religiously in statically types languages, so I don't find that a convincing argument.
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. On this point there is even some data that backs up my personal experience (http://vimeo.com/74354480).
Third, writing code with a static language takes more time in my experience. Maybe it prevents a tiny fraction of bugs, but for most things I'll take saving significant time and cost over preventing 3% of bugs (I made up that number).
In short, I'm not sold on these arguments for static typing.
Re: Revenge of the Types
#40Random 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…
Frink is a programming language that is all about keeping track of units: