Types for an Untyped World: Bracha vs. Felleisen [video]

https://www.youtube.com/watch?v=JBmIQIZPaHY

by namarkiv • 11 years ago

57 9 11 years ago

toolslive• 11 years ago

Feels like a "Live at the Apollo for Computer Scientists"

stcredzero• 11 years ago

Off the cuff comment, just before I go to watch the video: Here's something that Smalltalkers didn't like to talk about during the height of the Java vs. Smalltalk flamewars of the late 90's/early 2000's -- To be a good production Smalltalk programmer, you had to be very mindful of "types." (Reason for quotes!)

Exactly what do I mean by this? The good Smalltalkers would code in a such a way, that people could rapidly and completely figure out what "type" was in every variable, and reliably keep track of all implicit "Interfaces."

So of what value was Smalltalk, if you had to do all that manual work? The fact that what would be "types" in other languages were handled as conventions. This made exploratory coding very rapid.

This is also why I appreciate Go's pragmatic language design around this issue: The compiler keeps track of these things for you, but doesn't require nearly as much bookkeeping from the programmer to have that happen.

Now to see what Mr. Bracha has to say.

(Note: Conventional Smalltalk is actually strongly typed. It's just that everything is typed "Object" and exceptions are more or less just normal program execution with one VM built-in to get it started. This is why what other languages would consider "types" are really just conventions.)

octaveguin• 11 years ago

This is a boring, uninteresting debate on an interesting topic.

I'm sure HN has much more to say in much less time about it.

Types help document code such that I'd prefer an optional typed languages wherein libraries and large code bases are expected to be typed but the glue on top doesn't need to be.

Javascript in particular is not very self documenting but I find typescript much easier to read. It's a real shame it's not often adopted if only to provide IDE hints.

moonchrome2• 11 years ago

Currently looking in to groovy for android dev precisely based on this observation - it has optional static typing (and it gets compiled to equivalent Java bytecode if you provide it not striped out like Dart) but it's dynamically typed and seems to be expressive enough to make the glue code succint. I figured since we need to learn it for the build system why not see if we can reuse it - looks promising so far.

I feel like whenever you have complex data hierarchies static typing just makes the whole thing manageable (recently wrote 2k loc python exporter for blender and prototype to consume it in C# - the C# is much more managable for this kind of thing, c++ is still kind of tedious because of shitty tools, build/module system and it's fairly verbose due to low level nature)

incepted2• 11 years ago

Currently looking in to groovy for android dev precisely based on this observation

You should look at Kotlin, I can't imagine any good reason to use Groovy on Android with Kotlin around.

vorg2• 11 years ago

I figured since we need to learn it for the build system

Most gradle build scripts are fairly short (e.g. 30 lines) and only use a minute subset of the Groovy grammar, so you don't really need to learn it. Any problems with the build script are far likely to be with the Gradle vocab than the Groovy grammar, e.g. the names of variables you're assigning to, or whether you've included them all.

Types for an Untyped World: Bracha vs. Felleisen [video]

Related Stories