6 ms·

Objects All the Way Down

43 points by wirrbel 11y ago

jkot 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        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!
- iopq 11y ago
  Try to do anything where each struct is represented as an Object... oh wait, in Java, it is!
- deleted 11y ago
  [deleted]
cousin_it 11y ago
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.
- abecedarius 11y ago
  See "Rights Amplification" at http://erights.org/elib/capability/ode/ode-capabilities.html http://erights.org/elib/capability/ode/ode-capabilities.html -- the general term for how things like binary operations can fit with an objects-all-the-way-down model. It's true that it means an extension to the model, but it's not really about machine words vs. objects.
- nabla9 11y ago
  This is not necessarily true. There has been several Lisp dialects (3-Lisp and T project) based on infinite tower of interpreters. You can build a language where the point where the rubber of abstraction hits the road of reality is nowhere to be found.
  - cousin_it 11y ago
    Very interesting! I've started reading the 3-Lisp paper [1] and it's a lot of fun. I'm not sure if it's really a counterexample, though. Does 3-Lisp claim that you can only interact with values by calling their methods, or something like that? For example, can you impersonate a cons cell? [1] http://cs.au.dk/~hosc/local/LaSC-1-1-pp11-37.pdf http://cs.au.dk/~hosc/local/LaSC-1-1-pp11-37.pdf
- mahmud 11y ago
  > 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
agentultra 11y ago
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 11y ago
  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 11y ago
    It did come off that way. If you are interested you should definitely keep exploring. It's an interesting system.
pavlov 11y ago
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/
- masklinn 11y ago
  Lisp Machines possibly even more so, these were entire systems built in lisp from the ground up, extensively documented, introspectable and editable.
- wtbob 11y ago
  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 11y ago
    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.
frankiechh 11y ago
"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 11y ago
  (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
- deleted 11y ago
  [deleted]

43 points by wirrbel 11y ago

jkot 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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!
iopq 11y ago
Try to do anything where each struct is represented as an Object... oh wait, in Java, it is!
deleted 11y ago
[deleted]

cousin_it 11y ago

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.

abecedarius 11y ago
See "Rights Amplification" at http://erights.org/elib/capability/ode/ode-capabilities.html http://erights.org/elib/capability/ode/ode-capabilities.html -- the general term for how things like binary operations can fit with an objects-all-the-way-down model. It's true that it means an extension to the model, but it's not really about machine words vs. objects.
nabla9 11y ago
This is not necessarily true. There has been several Lisp dialects (3-Lisp and T project) based on infinite tower of interpreters. You can build a language where the point where the rubber of abstraction hits the road of reality is nowhere to be found.
- cousin_it 11y ago
  Very interesting! I've started reading the 3-Lisp paper [1] and it's a lot of fun. I'm not sure if it's really a counterexample, though. Does 3-Lisp claim that you can only interact with values by calling their methods, or something like that? For example, can you impersonate a cons cell? [1] http://cs.au.dk/~hosc/local/LaSC-1-1-pp11-37.pdf http://cs.au.dk/~hosc/local/LaSC-1-1-pp11-37.pdf
mahmud 11y ago
> 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

agentultra 11y ago

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 11y ago
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 11y ago
  It did come off that way. If you are interested you should definitely keep exploring. It's an interesting system.

pavlov 11y ago

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/

masklinn 11y ago
Lisp Machines possibly even more so, these were entire systems built in lisp from the ground up, extensively documented, introspectable and editable.
wtbob 11y ago
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 11y ago
  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.

frankiechh 11y ago

"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 11y ago
(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
deleted 11y ago
[deleted]