

Types for an Untyped World: Bracha vs. Felleisen [video] - namarkiv
https://www.youtube.com/watch?v=JBmIQIZPaHY

======
stcredzero
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.)

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

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

~~~
moonchrome
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)

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

~~~
moonchrome
I've seen Kotlin - few issues :

* it isn't 1.0 yet (guaranteed to have breaking changes)

* I don't see it as a dynamic/prototyping language - I see it more as a C# than as Python, frankly for the front end code that I want to write the python style of development is much faster and Groovy seems to have an answer if the performance of dynamic typing ends up being an issue. Most of the complex datastractures are in C++ anyway and will have a simple/clean interface to the front end

* it's an extra language to learn - not only me but by my coworkers as well. We already took on Groovy with Grails and we have a decent amount of build automation in it (and will have more)

I've learned a lot of languages so far (C++, Python, C#, Java, Clojure,
JavaScript and I've played with Rust, F#, TypeScript, Objective C) - frankly
the value of having as few languages as possible to share the actual
code/tools/knowledge between different areas is huge and in order to introduce
a new language to the mix it better have a significant benefit over the ones
already used.

~~~
incepted
That's fair.

There are a few pros, though, one of which being that JetBrains is fully
behind Android, and as a consequence, the Kotlin runtime is very small. Do you
know how many methods Groovy's is?

I think you will also find out that Groovy's performance is going to be a
problem on Android, but maybe it will be fast enough for you.

