6 ms·

I remember this being posted in 1998, as people were debating the surge of Java relative to C++ or Smalltalk. These were the twilight days where C and assembly

I remember this being posted in 1998, as people were debating the surge of Java relative to C++ or Smalltalk. These were the twilight days where C and assembly were the only language Real Programmers used, Perl and Tcl or any scripting/interpreted language were considered toys for sysops and never meant for production, OO was treated with deep suspicion, and functional languages were considered crazy talk. I remember people in my company saying a particular C++ replacement program my colleague wrote was "too OO" and would execute 10x slower than required (when it was 2x faster than the legacy). Point is, a lot of what Kay says is obvious now, but it wasn't in the 90s, and it REALLY wasn't in the 70s. One sees new things every time one reads this. For example, Kay comes out as a supporter (of sorts) to functional programming principles by calling assignments (mutable state) a metalevel change.

mikro2nd 12y ago
1998?... More like the twilight days when Cobol still ruled the land and we thought (feared) that it would never die. Fortunes were being made consulting on the Y2K bug and patching the dodgy Cobol systems responsible. I do agree, though that OO was treated with suspicion and hostility. Only a tiny number of (us) mavericks were brave enough (or foolish enough) to propose using what our management saw as a "newfangled and risky" proposition. Let's not even mention mucking about with Extreme Programming. ;)
- parasubvert 12y ago
  Oh yes, COBOL was C's evil twin in that regard. It depended what circles you travelled in - engineering depts or IT depts. I remember posting the c2 wiki pages for XP on my cube wall when XP first came out, and had a Gantt-chart oriented systems engineer tear them down as dangerous nonsense.
zak_mc_kracken 12y ago
> Point is, a lot of what Kay says is obvious now It's obvious because he's not saying much, besides trying to redefine "function call" with "message passing" so that it makes Smalltalk look better.
- mpweiher 12y ago
  So if "function call" and "message passing" are the same thing, why does Erlang support both?
  - contingencies 12y ago
    Guesstimate: Message passing implies a fully self-encompassed message carrying enough meaning for potential distribution between systems? [Substitute: Erlang VMs, physical machines, or whatever] Function call typically means within the same interpreter instance / language virtual machine / operating system native process. (ie. in cases where parallelism exists or is warranted, a message passing model enables it. In cases where it does not, they are essentially the same, possibly message passing being slightly slower due to marshalling/encode/decode overheads. These days that overhead is usually irrelevant and thus message-orientation is a plus, as it encourages smaller components and thereby helps to bring clearer architectural paradigms to complex systems)
  - vlastachu 12y ago
    tell me about message passing without concurrency. is it message passing in ruby? and why.
    - mpweiher 12y ago
      Message passing in KO (Kay Objects) is always inherently concurrent. After all the object abstraction is "individual computers all the way down"[1], and with separate computers, I hope we agree to call the message asynchronous. Anyway, mapping the passing of messages to synchronous lookup of a method in Smalltalk was always an optimization purely out of expediency. Highly important at the time so they could get real systems running on their "Interim Dynabooks" (aka Altos, 128K DRAM, 5.8 MHz[2]), and try them out. However, the ability to do a full message-send was always retained in systems like Smalltalk and descendants such as Objective-C and Ruby, with the DNU hook turning the message that only exists in pieces on the call stack into a bona-fide object (Message in Smalltalk, NSInvocation in Objective-C). And lo and behold, these hooks were and are used to implement asynchronous, remote and other forms of messaging. So to answer your question: yes, what Ruby, Smalltalk and Objective-C do is message passing. It is probably on the extreme end of what can still be considered KO-style message passing, which to me means it is late-bound and an object representing the message for further processing can be recovered easily. [1] http://worrydream.com/EarlyHistoryOfSmalltalk/ http://worrydream.com/EarlyHistoryOfSmalltalk/ [2] http://www.cpushack.com/2010/10/18/before-the-pc-before-apple-was-the-xerox-alto/ http://www.cpushack.com/2010/10/18/before-the-pc-before-appl...
ryuzakieru 12y ago
FORTRAN was my language of choice back then. Oh the memories. I'd still be using it if I stayed in the infrastructure industry.

mikro2nd 12y ago

1998?... More like the twilight days when Cobol still ruled the land and we thought (feared) that it would never die. Fortunes were being made consulting on the Y2K bug and patching the dodgy Cobol systems responsible. I do agree, though that OO was treated with suspicion and hostility. Only a tiny number of (us) mavericks were brave enough (or foolish enough) to propose using what our management saw as a "newfangled and risky" proposition. Let's not even mention mucking about with Extreme Programming. ;)

parasubvert 12y ago
Oh yes, COBOL was C's evil twin in that regard. It depended what circles you travelled in - engineering depts or IT depts. I remember posting the c2 wiki pages for XP on my cube wall when XP first came out, and had a Gantt-chart oriented systems engineer tear them down as dangerous nonsense.

zak_mc_kracken 12y ago

> Point is, a lot of what Kay says is obvious now It's obvious because he's not saying much, besides trying to redefine "function call" with "message passing" so that it makes Smalltalk look better.

mpweiher 12y ago
So if "function call" and "message passing" are the same thing, why does Erlang support both?
- contingencies 12y ago
  Guesstimate: Message passing implies a fully self-encompassed message carrying enough meaning for potential distribution between systems? [Substitute: Erlang VMs, physical machines, or whatever] Function call typically means within the same interpreter instance / language virtual machine / operating system native process. (ie. in cases where parallelism exists or is warranted, a message passing model enables it. In cases where it does not, they are essentially the same, possibly message passing being slightly slower due to marshalling/encode/decode overheads. These days that overhead is usually irrelevant and thus message-orientation is a plus, as it encourages smaller components and thereby helps to bring clearer architectural paradigms to complex systems)
- vlastachu 12y ago
  tell me about message passing without concurrency. is it message passing in ruby? and why.
  - mpweiher 12y ago
    Message passing in KO (Kay Objects) is always inherently concurrent. After all the object abstraction is "individual computers all the way down"[1], and with separate computers, I hope we agree to call the message asynchronous. Anyway, mapping the passing of messages to synchronous lookup of a method in Smalltalk was always an optimization purely out of expediency. Highly important at the time so they could get real systems running on their "Interim Dynabooks" (aka Altos, 128K DRAM, 5.8 MHz[2]), and try them out. However, the ability to do a full message-send was always retained in systems like Smalltalk and descendants such as Objective-C and Ruby, with the DNU hook turning the message that only exists in pieces on the call stack into a bona-fide object (Message in Smalltalk, NSInvocation in Objective-C). And lo and behold, these hooks were and are used to implement asynchronous, remote and other forms of messaging. So to answer your question: yes, what Ruby, Smalltalk and Objective-C do is message passing. It is probably on the extreme end of what can still be considered KO-style message passing, which to me means it is late-bound and an object representing the message for further processing can be recovered easily. [1] http://worrydream.com/EarlyHistoryOfSmalltalk/ http://worrydream.com/EarlyHistoryOfSmalltalk/ [2] http://www.cpushack.com/2010/10/18/before-the-pc-before-apple-was-the-xerox-alto/ http://www.cpushack.com/2010/10/18/before-the-pc-before-appl...

ryuzakieru 12y ago

FORTRAN was my language of choice back then. Oh the memories. I'd still be using it if I stayed in the infrastructure industry.