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

41–50 of 137 posts

Re: Revenge of the Types

#41

Post by the_af »

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.

What are nulls extremely useful for in programming languages?

At least one serious problem with nulls in many languages is that you can get one somewhere you are not expecting it, and you won't handle it correctly, resulting in an null pointer exception (if you're lucky) or a crash (if you're unlucky). That's why alternatives like Option types are so useful: you really cannot ignore them, so they won't catch you by surprise. And at the same time, you can often handle them in pretty painless ways.

Re: Revenge of the Types

#42

Post by aikah »

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 ancestors.

Personally I want a scripting language,with type inference but real strong static typing, that can be easily interfaced with C++, that handles concurrency the right way(ie not like javascript callbacks),that is trully multipurpose(like python) elegant(a bit like ruby), 00 with composition and strong encapsulation in mind and access modifiers, with immutable structures and variables by default but not limited to it,with some functional features without looking like Haskell,resonably fast for GUI dev,scientif computation and non trivial web apps,easy to deploy on a server, with sane error handling,IO streams everywhere, a clear syntax(no unreachable characters on non english keyboards everywhere),with a good package manager, an interactive repl(like IPython or the tool for swift,I forgot the name) and with battery included.

So we are definetly living in an exciting period.

Re: Revenge of the Types

#43

Post by randlet »

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-analyze-code

Re: Revenge of the Types

#44

Post by ZenoArrow »

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…

Haxe (pronounced "hex") is pretty close to what you want... http://haxe.org/ http://en.m.wikipedia.org/wiki/Haxe

Re: Revenge of the Types

#45

Post by Cyther606 »

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, albeit in the early stages.

    import rdstdin, strutils
    
    let
      time24 = readLineFromStdin("Enter a 24-hour time: ").split(':').map(parseInt)
      hours24 = time24[0]
      minutes24 = time24[1]
      flights: array[8, tuple[since: int,
                              depart: string,
                              arrive: string]] = [(480, "8:00 a.m.", "10:16 a.m."),
                                                  (583, "9:43 a.m.", "11:52 a.m."),
                                                  (679, "11:19 a.m.", "1:31 p.m."),
                                                  (767, "12:47 p.m.", "3:00 p.m."),
                                                  (840, "2:00 p.m.", "4:08 p.m."),
                                                  (945, "3:45 p.m.", "5:55 p.m."),
                                                  (1140, "7:00 p.m.", "9:20 p.m."),
                                                  (1305, "9:45 p.m.", "11:58 p.m.")]
    
    proc minutesSinceMidnight(hours: int = hours24, minutes: int = minutes24): int =
      hours * 60 + minutes
    
    proc cmpFlights(m = minutesSinceMidnight()): seq[int] =
      result = newSeq[int](flights.len)
      for i in 0 ..

Re: Revenge of the Types

#46

Post by ak217 »

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 designers definitely should not make the mistake that PHP, Python and Ruby did, where the language's behavior ends up being "whatever the interpreter does".

This is an incredibly important point. The rise of PyPy is just one compelling illustration of how Python is at a point where a language specification is needed, and these crazy CPython-specific bugs need to be purged.

> I think for Python this is very unlikely to ever change at this point, because the time and work required to clean up language and interpreter outweighs the benefits.

I would disagree - I think it's possible for Python to change this. Any such bizarre behaviors need to be treated as a bug, and eliminated in the next release.

Re: Revenge of the Types

#47

Post by 1_player »

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…

I don't think C++ interface is easily feasible, as far as I know no language managed to do that yet, probably because of the wildly different ABI between C++ compilers.

Anyway, I would add to your list Go concurrency constructs (channels, "go"-like statements), polymorphic types, and, personally, significant whitespace for indentation, like Python.

Rust is a big step in the right direction, although it's a bit too complex|heavy for scripts.

Re: Revenge of the Types

#50

Post by MetaCosm »

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 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, hellish experience I ever had was dealing with a large (100k+) non-trivial consumer facing Python application. It was a special type of pain, with novel errors happening in production on a regular basis 4+ years into the project. Refactoring was horrifically risky, and the analysis tooling stack is AWFUL... to the point that when used, it was often outright wrong.

I will gladly give up those cost savings on the leading edge, to have a product I can actually maintain in the long term. I suspect this inability to maintain apps writing in certain dynamic languages is why they have culture bias towards starting over (and being proud of it, "version 2.0, rewritten from scratch!")... which I found a bit shocking at first versus C, which would trend far more toward refactoring.

Post reply on HN