On Fri, 9 Jul 2004 17:16:08 +0900, Sean O'Dell <sean / celsoft.com> wrote: > On Friday 09 July 2004 00:17, zuzu wrote: > > > > not for me. corba, and to a much lesser extent xml-rpc, seem complex > > for complexity sake, to satisfy "enterprise level job security" or > > something. find me a person who can implement corba themselves and > > i'll concede this argument. even gnome only implements a subset of > > corba for their orbs. > > For developers using CORBA or XML-RPC, it's pretty simple. You have to use > good libraries of course, not implement client/server code from scratch. ok, but could you easily figure out or write those libraries yourself if you had to? i feel the better method can expose all "black magic" programming to the light of day so that a programmer wouldn't need to be an expert in that to easily grok how it works and why. (ruby's marshalling, for example, seems much more friendly and elegant.) > > > I think the freedom isn't the only culprit; it's the sheer length of time > > > C++ has been around, and how many programmers it attracted early on when > > > programming itself as a discipline was still a very mystic activity. > > > Nowadays, there are loads of design patterns to use as examples, so when > > > a bunch of new programmers jumps on a new language, like Ruby, it's a lot > > > easier to get them all cohesively communicating and using "approved" > > > design patterns. > > > > if you concede "approved design patterns", then i'm not sure why we're > > arguing. i happen to feel that actor / flow-based style would be a positive > > evolution in the "approved design patterns" of ruby. > > I don't think we're arguing, just exchanging ideas. Just because this is the > Ruby ML doesn't mean every contentious exchange has to be an "argument." =) hehe, "this isn't an argument, it's just contradiction!" of course, i didn't mean argument in the negative sense... "discussion" or what have you. :D > I haven't found much to read on Actor/Flow-Based programming. I only saw one > brief page on it, but I couldn't figure out how it was different from > event-based client/server programming, which is, to say the least, some of > trickiest programming around. well, i do not think the model need be "client/server", though from looking over some initial reading of "event-driven programming" as said before, it appears to be an earlier version in the evolution of an idea. i think that once some design patterns are flushed out, asynchronous messaging will be found much less tricky than synchronous messaging. perhaps corba is an example of this. it also scales much more freely across multiple processors both local (per my dual-G4 example) and across networks (collaborative software, distributed computing, etc.) if programmers can learn to program in this style well and can apply it in all of these situations, that seems a more efficient use of creative resources -- more time manipulating data and less time massaging the environment to be able to manipulate data. http://www.jpaulmorrison.com/fbp/index.shtml http://www.jpaulmorrison.com/cgi-bin/wiki.pl?FlowBasedProgramming http://c2.com/cgi/wiki?ActorsAndFlowBasedProgrammingDiscussion http://c2.com/cgi/wiki?ActorsModel http://cliki.tunes.org/Actor http://www.jpaulmorrison.com/fbp/cognates.htm > > > I actually think Ruby gives you the ability to use MORE paradigms than > > > C++ can, at least effectively. I felt far more boxed in with C++ than > > > with Ruby. > > > > which then essentially is my argument. by moving forward with "one > > pretty good way", more people will be able to achive more real > > productivity with less work. aka "less is more". > > I disagree; more is more. It's good to cut away the really useless stuff that > causes more problems than it solves, like multiple inheritance, but there are > a heck of a lot of patterns that work, and I don't want to program in a > language that forces me towards one pattern. not one pattern, but certainly a pattern language. although i'm an advocate of multi-lingualism, when you need to exchange ideas as we are doing here, it helps that we've all agreed to do so in english. better still would be to apply weakly true sapir-whorf hypothesis to articulate in a language that optimizes our communication of ideas with a minimum of time/reading. think of 'babel-17' (by samuel r. delany) and its influence on matz in creating ruby. http://en.wikipedia.org/wiki/Sapir-Whorf_Hypothesis "more is more" becomes "How Much Land Does a Man Really Need?" by Leo Tolstoy or, here's another way to look at why less is more. the fewer possessions you own, the less you have to worry about keeping them safe, maintaining them (even dusting), paying for the storage space, mental cost of locating them, and so on. but there is a balance, there will be tools you use quite often where their usefulness outweighs their ownership cost over time. but many people acquire a tool because they use it once, and after that it becomes a burden. and if you re-use a tool in a slightly different way rather than acquire a new tool for that unique task, you've learned to use that original tool better. in some ways this is what's nice about "everything is a function" with functional programming. mucking things up with "operators" can be more confusing than useful. > Sean O'Dell > > -z