Revenge of the Types • Hacker News Board

Re: Revenge of the Types

#121

Post by Joeri » Mon, Aug 25, 2014, 8:56 PM UTC

NateDad wrote: post #118

Joeri wrote: post #114

Earlier quoted context omitted.

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…

I don't think typing speed factors into it. It's more a factor of cognitive load. While programming you are working at the level of "expressions", and your speed is limited to how quickly you can turn business logic into appropriate sets of expressions. Programming languages that are lower level require more expressions to say the same thing, hence are slower to program in. I don't think it's a controversial notion to say that assembly is less productive than C, which is less productive than Python. The reason is the number of lines (or rather expressions) needed to achieve a piece of functionality. The business logic most definitely does not take the same amount of time when written in assembly compared to python. The higher level languages tend to be more productive, but it is only a given if the higher level language is actually more concise.

Here are some papers that underbuild this argument: http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprt_computer... https://files.ifi.uzh.ch/rerg/amadeus/teaching/seminars/semi...

Re: Revenge of the Types

#122

Post by chaoky » Mon, Aug 25, 2014, 10:08 PM UTC

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?

Common Lisp, for sure

Re: Revenge of the Types

#123

Post by jshen » Mon, Aug 25, 2014, 10:24 PM UTC

calinet6 wrote: post #101

jshen wrote: post #96

Earlier quoted context omitted.

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.

You also made major condescending assumptions. Why?

Re: Revenge of the Types

#124

Post by loup-vaillant » Tue, Aug 26, 2014, 12:14 AM UTC

bunderbunder wrote: post #117

loup-vaillant wrote: post #115

Earlier quoted context omitted.

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

Case like that are straightforward, and people still manage to botch them. Which is why I suspect there is something deeply wrong, or at least fundamentally different, about the minds that produce such mistakes.

Though for this particular mistake, it may have come from some misguided notion about performance (like perceived overhead of constructing a string then passing it up the stack).

As for things like recursion and closures… I just avoid them because I know my colleagues will recoil in horror with such uselessly indecipherable excess of cleverness.

Re: Revenge of the Types

#125

Post by eric_bullington » Tue, Aug 26, 2014, 1:36 AM UTC

keypusher wrote: post #59

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…

Dart is a language worth considering if you want something with static types that compiles to js.

Alas, Dart is pretty much a dynamic language with optional (and intentionally unsound) static typing. I understand why they've made some of the decisions they did, but it doesn't appeal to me much as a Javascript alternative, since it's not going to catch most of the errors that a proper statically-typed language would.

It is a very nice Javascript-without-all-the-weirdness, however.

Re: Revenge of the Types

#126

Post by jshen » Tue, Aug 26, 2014, 1:58 AM UTC

NateDad wrote: post #118

Joeri wrote: post #114

Earlier quoted context omitted.

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…

The way to reduce lines of code is to create good abstractions. Some languages may be better at this than others, and I think this is more important than the type system of the language.

Re: Revenge of the Types

#127

Post by emmanueloga_ » Tue, Aug 26, 2014, 4:11 AM UTC

pjungwir wrote: post #7

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

Jav^H^H^H errr... I mean, Xtend [1] :). It does this through a mechanism called "extension methods" [2]. Kotlin has something similar called "extension functions", so I'm guessing it should be possible with it too.

1: https://github.com/eclipse/xtext/blob/master/examples/org.ec...

2: http://www.eclipse.org/xtend/documentation.html#extensionMet...

3: http://confluence.jetbrains.com/display/Kotlin/Extension+fun...

Re: Revenge of the Types

#128

Post by catwell » Tue, Aug 26, 2014, 6:39 AM UTC

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?

In Lua the user manual is the reference, so if the language does something different, it is considered a bug. If something is not described in the manual then it is an implementation detail (unspecified) and code that relies on it is broken.

This led to several alternative implementations, among which at least one (LuaJIT) implements completely a version of the language (Lua 5.1).

Re: Revenge of the Types

#129

Post by catwell » Tue, Aug 26, 2014, 7:00 AM UTC

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…

It is interesting that I often see people coming primarily from a strongly typed language say this kind of thing, whereas people used to working in dynamic languages rarely make obvious type errors.

This says something about what tooling does to people. Haskell people say they think in types but this make it look wrong. It would appear they are less good with types when you take their tools away. People working primarily in dynamic language probably end up writing programs that are mostly correct in that respect because they have no other choice to become productive.

This looks similar to how people who are raised in clean environments are more vulnerable to bacteries. This is not a bad thing: we still improved life expectancy a lot with hygiene and antibiotics. But we got weaker immune systems and allergies.

Re: Revenge of the Types

#130

Post by sitkack » Tue, Aug 26, 2014, 1:44 PM UTC

Demiurge wrote: post #69

sitkack wrote: post #63

Earlier quoted context omitted.

Python 3 should have been a from the ground rewrite of a new core runtime written to a language specification. Maybe we can get that in Python 4.

Who's going to work on that, and most importantly bless it as official and unite people? I haven't seen anything from Guido on the criticisms of Python 3 and CPython, like this post and other unicode complexity complaints in Python 3. It seems that a lot of people who like Python because it lets them move fast hit a wall when they encounter main Python developers as moving so slow as to consider it okey to have two m…

There should be a spec and M versions of the runtime. The batteries should be portable between those versions. I used to split by time evenly between Jython, CPython and PyPy. Now I use PyPy about 80% of the time. But having the spec defined as how CPython and the included libraries operate is detrimental to the language. Python3 could have been a chance to clean up the syntax, define and excellent FFI protocol and split the standard library. Python3 could have been a reference implementation that spread Python to all corners of computation.