201–210 of 212 posts
Earlier quoted context omitted.
HTTP(S) is the opposite of RPC (meaning: message-based). Both SOAP and XML-RPC tried to remedy that.
How exactly it is opposite?
http://stackoverflow.com/questions/9062475/what-is-the-diffe...
Replace SOAP with HTTP, since SOAP is just an ill-advised, unnecessary, redundant obfuscation layer on top of HTTP, and so contrast still applies.
I don't really understand this obsession with messages. We're moving away from it. This is not how we program in the 21st century. The last popular language that supported this paradigm (Objective C) is being replaced and will probably be all but gone in just a few years as Swift (not message based) takes it place. Besides, this idea of message passing is really not that useful for modern programming anyway but a lot…
Earlier quoted context omitted.
Message passing implies one way broadcast. Think GOTO. HTTP is a request / reply protocol, i.e. a function call. Map / Reduce is an implementation device for SQL-like collection-based processing, modern Map / Reduce systems [Google's Flume / Dataflow] offer directly the collection API, using Map / Reduce as an implementation detail. FRP is a device for adding a collection API on top of streams of events. Collection A…
> Message passing implies one way broadcast. Can you explain that since its contrary to my experience. PDO and normal Objective-C methods had a return and are not one way.
A. One way communication, aka events, goto. Very useful as an implementation concept, but generally a poor idea for structuring applications, as it makes local reasoning about code harder than necessary.
B. Polymorphism, aka closures. This is a very useful device for modularizing code, albeit, in practice, vastly overused. It also happens to trivially fall out from the concept of "first class function". To have first class functions, we need to be able to create them at any point in the program, thus we need some form of variable capture to allow value capture, which was named "closure", in the example below "function g closes over variable x". Furthermore, we need to be able to return the function value we just created and invoke it later, in the example below the invocation of q(4) actually invokes the closure of g over 3. Once we have first class functions, we can add any number of concrete syntactic sugar constructs [classes, vtables, etc, etc, etc].
def f(x) = {
def g(y) = {
x + y
}
g
}
val q = f(3)
q(4)
Earlier quoted context omitted.
Seriously? Have you watched any of the demos Alan references? They were doing things with computers in the 1960s/70s that still haven't reached mainstream use as yet. Computers as used today are still absolutely dumb machines that are little more than super-fast calculators, and in most cases increases the mental burden of their users instead of reducing/augmenting them. Nicholas Negroponte had a great quote in '94 t…
Do you have links to any of those demos?
I have to admit I never really got further than the first 5-10 minutes or so. My first computer experiences are from the late 80s (and indeed didn't have a mouse) but this demo is so old, I kept having to mentally translate for myself which bits might have been new or ground breaking, and which just plain archaic. I keep meaning to watch it in full some day, but the first bit that I saw, I keep feeling I'm missing something important. People are lyrical about this demo (hence the name!), but I don't quite feel it or something. Then again, while I appreciate the great work of engineering that went into it, I'm not really one to sit down and watch a documentary about the moon landing program either.
Maybe somebody here knows a good link or article about The Mother of All Demos that explains which things I should be in awe about and why they were so novel then?
Part of it kind of looks like a simple database table system, which reminds me of a stupid story from my childhood. When I was young (~1990 I guess), I was playing with the MSX BASIC on a friend's computer whose family had a farm. They wondered if I could write anything to keep track of their cows or something--sure thing! (though I really preferred to write graphics code, later joined the demoscene, way more fun). Now I had no idea about business or their requirements (let alone requirements engineering), so I just wrote some whatever that let them enter data, but in the back of my mind I wondered how this was going to be useful for anything. Neither did I know (yet) how to actually save the data so it'd be available after reboot, which was probably a big reason for my doubts. And they were still impressed (that it could repeat names of many cows, I guess). I never finished it (nor any idea of what "finished" would mean).
I find it interesting that everyone gets so up-beat about the ideology or philosophical debate about objects sending each object messages, hell even not relying to a message one object send you until a later date. Without even thinking about concurrency, state, and hell even the basics such as cyclic loops within a event based system! Though I keep hearing from Alan and other prominent language designers that we stil…
Earlier quoted context omitted.
"For what its worth I consider object's simply as a basic level category of procedures and data tied to a namespace.“ I mean you're just using different words to talk about the same thing. In your terminology inheritance is just extending a namespace and overloading names. How does that discredit or put into question the "mental model of command and control, or structured design concepts" If anything I feel the failu…
> If anything I feel the failure of OO languages What failure exactly? OOP has flaws but it has certainly proven to be extremely versatile and adaptable over these past decades since even today, it's still the dominant paradigm to solve modern problems in computing.
Earlier quoted context omitted.
Can you summarize what those things might be? (That haven't reached mainstream use)
Here are 2 that he often brings up: Ivan Sutherland's Sketchpad demo - Object oriented graphics using a constraint based system ( https://www.youtube.com/watch?v=6orsmFndx_o ) Douglas Englebart's demo - too many innovations to list, but includes real time collaboration (he demoed in a convention center while the system ran 30 miles away in his lab, connected by a leased line operating at 1200 baud!). People think he…
I don't really understand this obsession with messages. We're moving away from it. This is not how we program in the 21st century. The last popular language that supported this paradigm (Objective C) is being replaced and will probably be all but gone in just a few years as Swift (not message based) takes it place. Besides, this idea of message passing is really not that useful for modern programming anyway but a lot…
Earlier quoted context omitted.
> Technically that's what classes gives you, not objects. But agreed on the sentiment. No, that's what objects give you. Classes are merely one means of creating objects (others exist), but the benefits come from the objects, not their means of construction.
My point is that you can have an OOP language / system that consists entirely of singletons. The ability to create multiple object instances from a template is classes or prototypes or whatever other mechanism. It's not something strictly necessary to OOP.
Isn't a lack of direct hardware/ISA support for message passing becoming apparent in today's world of multicore architectures? The Disruptor library used by HFT shops and much of Erlang seem to suggest a need for this.