
Objects All the Way Down - wirrbel
http://www.holger-peters.de/objects-all-the-way-down.html
======
pavlov
Smalltalk is the future the GUI promised us. But something went wrong in the
'80s and we got stuck with file systems, terminal emulators and command line
arguments.

Isn't it absolutely crazy that we have laptops with 6-megapixel screens, and
we use those capabilities to simulate a 40-year old video terminal that in
turn simulates the behavior of an even older line-based Teletype machine? [1]

Programming today is fundamentally the same it was on a PDP-10 many decades
ago, except that the unintuitive CLI interfaces have been propped up by fast
web search: "Just google it, no big deal."

[1]
[http://www.linusakesson.net/programming/tty/](http://www.linusakesson.net/programming/tty/)

~~~
wtbob
I'm sympathetic to the GUI dream, but do note that language is far richer than
pictures: we graduate from picture-books to literature, and from pointing and
grunting to speaking.

I do think that a Smalltalk future might have actually managed to be the best
of both worlds, combining images and text into one coherent whole. But it
never really came to fruition.

As things are, since I may not have both, I'll choose the power of text over
the ease of pictures.

~~~
pavlov
To me, the GUI dream isn't really about pictures -- it's about structure.
Humans are much better at understanding visual and symbolic representations of
structure than prose. Purely textual interfaces don't take advantage of that.

The structure that we currently have is file hierarchies and URLs (just
another form of Unix-style path strings), and files containing sequences of
text with no more structure than line breaks and indentations -- and after 40
years, we haven't even agreed on how to represent those in ASCII. The whole
thing is barely removed from sectors on disk.

Smalltalk's class browser let you drill into a live hierarchy of objects and
edit them in place. That's already much more advanced than our static blobs of
text in a lifeless path hierarchy. And that was in 1975.

~~~
woah
I've got to disagree, because representing everything as an object involves a
serious amount of cognitive overhead. You're limiting yourself to things that
can be represented as objects and still make sense, plus you've got to write
the code to make your ideas fit into the object box (methods, interfaces,
this, public private etc).

I've been working on some networking protocols, and I started by modeling each
node as an object. Seemed to make sense. But there's a lot of overhead. Send,
receive methods etc etc, and then you've got to instantiate them and then
collect the data from the objects afterwards to see how the network did. I
switched my code over to being a bunch of stateless functions that operate on
a network graph and stuff got a lot less verbose.

This is not necessarily always the case, but I would hate working in an
environment where I was forced to always use a very specific metaphor for my
work.

------
agentultra
Well there are version control tools in Smalltalk land. The primary one that
ships with Pharo is called, Monticello [0].

Images are also a huge advantage which the author has obviously not had time
to exploit.

Knowing next to nothing about Smalltalk before the summer I checked out Pharo
and wrote a small application to scrape the HN front page and display the
links in a Painter window. I watched a few videos, read some tutorials, and
eventually had a working Smalltalk program in a couple of days. It was
actually a pleasant experience.

A typical workflow starts by writing a snippet of code in the playground that
instantiates the program you want to run. You execute it and get dropped in
the debugger. You slowly add the missing methods and tests, stepping through
the debugger as you go, and eventually your program runs. If you ever need to
take a break you can save your image -- debugging session and all -- and pick
it up later. There's no need to load up your source code and try to rebuild
your application state to get to the point you were at when you last left your
work.

That's really powerful for interesting systems like the Moose platform [1].

Overall I think the author is too biased to his existing tools to appreciate
what Smalltalk is really about.

[0]
[http://pharo.gemtalksystems.com/book/PharoTools/Monticello/](http://pharo.gemtalksystems.com/book/PharoTools/Monticello/)
[1] [http://moosetechnology.org/](http://moosetechnology.org/)

~~~
data_hope
Original author of the blog post here. I find it interesting that your
takeaway from my blog post is that I am writing unfavorable over smalltalk. I
quite liked it. I think I mentioned that I was checking out Smalltalk, didn't
claim to summarize longer experience with it.

Moose looks interesting indeed.

~~~
agentultra
It did come off that way. If you are interested you should definitely keep
exploring. It's an interesting system.

------
cousin_it
Little known fact: you can't have objects all the way down. At some level you
need to add machine integers together. For that you need the internal
representations of two different objects at once, not just their responses to
a bunch of methods. If your language is objects all the way down, that's
fundamentally impossible.

In fact, Smalltalk's VM has special code that detects when you try to add two
small integers. That's similar to "abstract data types" in ML or "class-based
encapsulation" in Java, as opposed to "object-based encapsulation" which is
the cornerstone of Smalltalk.

~~~
mahmud
> At some level you need to add actual integers together. For that you need to
> access the internal representation of both integers at once

Not necessarily.

[https://en.wikipedia.org/wiki/Church_encoding](https://en.wikipedia.org/wiki/Church_encoding)

~~~
cousin_it
Yeah, fair enough. Updated my comment to say "machine integers" :-)

~~~
kazinator
In a language without machine integers exposed to the programmer, there may be
no way within that language to see any machine integers. There is a further
"way down", but not from within the language.

A proposition about an implementation aspect of the language you're working in
is testable in that language if a program in that language can produce output
which is different based on whether or not that proposition is true. If the
proposition isn't testable in that language, then it doesn't lie on the "all
the way down" path which begins inside the language.

------
jkot
What if my name is "anonymous user"?

Anyway, primitive types in java is one of the reasons, why java has success.
Try to do image processing or fast networking, while each byte is represented
as an object.

~~~
masklinn
An object is an interface, nothing precludes optimising representations either
specifically (tagged pointers, unboxed values) or generally (collection
strategies and JIT unboxing). The former being what C# does, its primitive
types can still be interacted with as objects, you can even add new methods on
`int`.

~~~
david-given
I have an experimental and somewhat half-baked programming language where all
types are anonymous; type names always refer to interfaces. It then does
global type inference to decide whether the thing you're referring to is a
primitive type or an object for the actual implementation.

What this means is that at the semantic level, the language doesn't
distinguish between objects and scalars, so avoiding the horrible
schizophrenia that languages like C++ and Java do --- you can subclass an
integer just as easily as you can anything else. Performance is really good,
too, mostly.

The downside is somewhat unpredictable behaviour due to invisible boxing and
unboxing. e.g.:

    
    
        function complexExpression(x: int) {
          // do something expensive with x
        }
    
        complexExpression(4);
        complexExpression(numberlikeObject);
    

The type inference will see that complexExpression() is being called by both a
scalar and an object, which means that x needs to be implemented as an object
pointer, and the literal 4 needs to be boxed. This means the calculations
inside complexExpression() will end up being a lot more expensive due to
boxing and unboxing overhead.

I should readdress this at some point; it was a really nice thing to write
code for.

[http://cowlark.com/cowbel/example.html](http://cowlark.com/cowbel/example.html)

~~~
wtetzner
You could specialize for primitives, e.g. under the hood generate
complexExpression_int() and complexExpression_ref(). It wouldn't be too bad in
terms of code size, because you only have to specialize primitives, and all
reference types can share the same implementation.

~~~
david-given
Yes, that'd be the obvious thing to do, but I think right now it doesn't (I
could be wrong; I haven't looked at the code for ages).

I did at one point try to specialise everything. The results were hilarious...

    
    
        var a = cons(cons(cons(cons(empty, 1), 2), 3), 4);
    

As the left-hand-side of each cons was a slightly different type, it ended up
generating four different versions of the cons function!

------
frankiechh
"Overall I think the author is too biased to his existing tools to appreciate
what Smalltalk is really about."

Agreed. The author is clueless.

~~~
dang
(We detached this comment from
[https://news.ycombinator.com/item?id=10637544](https://news.ycombinator.com/item?id=10637544)
and marked it off-topic.)

> _The author is clueless_

Maybe so, but since your comment is only name-calling [1], you shouldn't have
posted it here.

Since you know enough about this fascinating topic to identify cluelessness,
it would be much better to post a comment with real information that could
teach readers something about it. If you don't have time to do that, posting
nothing is always an option.

1\.
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

