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

111–120 of 137 posts

Re: Revenge of the Types

#111

Post by Joeri »

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?

C99 and C++11 have several compliant implementations, as does ECMAScript 5 (javascript).

The benefit of a spec is not so much that all implementations are necessarily completely compliant, it's that you know what the behavior is supposed to be so you can implement to the spec and work around any differences in implementation. Plus, you can report bugs without them being closed as "by design".

Re: Revenge of the Types

#112

Post by marcosdumay »

gaius wrote: post #77
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…

Absolutely - like the NoSQL guys don't realize that a DB enforcing a schema is helping you.

About this... Some types are more important than others. And the NoSQL guys usualy choose the most important ones to throw away.

Static vs. dynamic typing in languages are orders of magnitude less relevant, and one can choose to trade safety for other features much easily on this domain.

Re: Revenge of the Types

#113

Post by Joeri »

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…

In my opinion the trick to large-scale software architecture is to build small software systems tied together by strictly defined interfaces. There are many ways to ensure the strictness of the interface: having strict typing and a compilation step, unit tests, static code validation (compiling without compiling), and even hungarian notation and systematic code reviews. Those are not mutually exclusive tools; quality improves with each one added, but none are mandatory.

My personal experience working on large systems without unit tests (among others a 200.000 line javascript codebase) is that as long as you adopt good coding practices around how you define clearly typed interfaces the lack of unit tests doesn't hurt you that badly and there is no wild-growth of bugs. Using the jetbrains IDE's also made a big difference for me due to the static code checking. I want to see the little code quality box at the top of the scrollbar turn green, and the process of doing that tends to weed out a lot of those bugs that a unit test or a strict type system would catch.

I do think that if you're building large-scale or long-lived systems, it is not any faster to use a dynamically typed language. I've written lots of code in both strictly typed and loosely typed languages, and I find that while I enjoy a loosely typed language more, I am equally productive in the strictly typed environment because strict typing makes it easier to write reliable code from the outset.

Re: Revenge of the Types

#114

Post by Joeri »

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

Programmers write the same number of debugged lines (or expressions) of code per day, regardless of the language they write in. A language only enables faster development if it requires fewer expressions to say the same thing. That is why high-level languages trounce low-level languages when it comes to productivity. I admit to not being very familiar with Haskell, but if it is not more concise it's not likely to be more productive.

Re: Revenge of the Types

#115

Post by loup-vaillant »

bunderbunder wrote: post #107
jshen wrote: post #95

Earlier quoted context omitted.

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…

> Most people just don't naturally think of processes as a composition of mappings from values in a domain to values in a codomain.

This is most difficult to accept, because I do.

It's like programmers are divided into two camps: those who think procedurally, and those who think mathematically. I have noticed lately how this can influence API design, down to things as simple as this:

    void        latin9_to_utf8(      std::string& latin9str);
    std::string latin9_to_utf8(const std::string& latin9str);
The first interface is a design mistake: it encourages side effects, and requires more code to use in practice. But it is also a very natural one: you want to convert strings, so you write a function that converts strings (KISS). The second interface is better, but more convoluted: instead of just converting strings, it returns converted strings.

Guess which ended up in a real program I worked on…

Re: Revenge of the Types

#116

Post by NateDad »

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?

Go has gc and gccgo. They made two implementations to keep the spec honest and not just "whatever the compiler does".

Re: Revenge of the Types

#117

Post by bunderbunder »

loup-vaillant wrote: post #115
bunderbunder wrote: post #107

Earlier quoted context omitted.

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…

> Most people just don't naturally think of processes as a composition of mappings from values in a domain to values in a codomain. This is most difficult to accept, because I do. It's like programmers are divided into two camps: those who think procedurally, and those who think mathematically. I have noticed lately how this can influence API design, down to things as simple as this: void latin9_to_utf8( std::string&…

Cases like that are fairly straightforward.

Where things really fall apart is using recursion instead of loops. Especially when the time comes to mention tail recursion.

Re: Revenge of the Types

#118

Post by NateDad »

Joeri wrote: post #114
jshen wrote: post #95

Earlier quoted context omitted.

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

Programmers write the same number of debugged lines (or expressions) of code per day, regardless of the language they write in. A language only enables faster development if it requires fewer expressions to say the same thing. That is why high-level languages trounce low-level languages when it comes to productivity. I admit to not being very familiar with Haskell, but if it is not more concise it's not likely to be…

I don't believe that. The speed of producing code is not relative to typing speed. LOC per day depends on the complexity of the lines. I can write 500 simple lines or 50 complex lines of code in a day. I'd agree that higher level languages deal with some of the complexity for you, like memory management. But I bet the business logic takes a similar amount of time in almost any language, assuming the developer has the same amount of experience in each language.

Re: Revenge of the Types

#120

Post by wirrbel »

rurban wrote: post #99
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…

You are right about optimizations, there are a lot of situations where type annotations could greatly help the compiler. I just do not have the feeling that performance optimizations in CPython are the reason for Guido's proposal. It rather seems to be motivated for development tooling.

Is `for i in xrange(10000):` especially optimized in python at the moment? I doubt it and those low hanging fruits could be tackled with some explicit pattern matching. (I probably should do my homework now and dive into the python source code).

Post reply on HN