Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
Hi, Here's a new language that may be of interest: a dynamically-typed rewriting language, sort of a cross between Smalltalk and Haskell. http://code.google.com/p/pure-lang/ Note the native-code LLVM backend. Marcus FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
[FRIAM] Stevey's Blog Rants: Rhino on Rails
Thanks to Owen for introducing those of us who were unfamiliar with Steve Yegge to his blog (http://steve-yegge.blogspot.com). I found the guy sufficiently entertaining (as well as insightful) to follow the link from the blog to Stevey's Drunken Blog Rants (what a great name!). In one of his posts (http://steve.yegge.googlepages.com/tour-de-babel ), Steve Y writes quite an interesting, and of course, highly opinionated, discussion of programming languages (including the ever popular C++ bashing that some of us have indulged in here). His high opinion of the use of Lisp (and C) in the early days of amazon.com, and his equally low opinion of the use of C++ later on in the company, are particularly entertaining. More fuel for the fire :-) ;; Gary FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
On Sun, 15 Feb 2009 20:58:43 -0700, Owen Densmore o...@backspaces.net said: I'm with Nick. Why? We have to separate understanding *architecture* from implementation. Architectural studies look at the system from a 50,000 foot view, so that the student can understand how the whole system works. Implementation studies look at how a practitioner would, on the job, build part of a system. Very different issues. I would love to argue this with you as I am in almost complete disagreement. How would you regard the Agile belief in emergent architecture? The 'breadth first' idea has little to nothing to do with architecture in my opinion. So I'd not mind taking a class that assumed the implementation used within the class was not mainstream. That it left the student with very broad understanding of how computing works. Sure it'd be great to teach where you got both: understanding and practical skills. I'm not sure its possible. I sure hope it is - otherwise I have been fooling myself for a long time. Re: Ruby -- It really does not cut it. I probably agree - but can 100,000 avid users be wrong? I included it in my list only on the basis of popularity for Web-only development. So GLASS it is for now, right? I think I'd prefer Javascript, but at least I understand the struggle. You will get Javascript - I promise - as we integrate the Lively Kernel into Squeak. davew FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
Owen wrote: Architectural studies look at the system from a 50,000 foot view, so that the student can understand how the whole system works. Implementation studies look at how a practitioner would, on the job, build part of a system. If in fact it is possible for a student to understand how a system works in complete ignorance of the semantics of its subsystems, then there's no real distinction I can see between understanding a part of a system or understanding the architecture of the whole thing. It is scale free. Only if the interfaces and interactions between parts are more complex or require special expertise domain knowledge do I start to find this distinction plausible. FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
I finally got around to looking up the Lively Kernel: http://research.sun.com/projects/lively/ I'm impressed! Entirely written in Javascript. No downloads required (apparently like GoogleMaps, you use the Javascript library remotely, at http://www.experimentalstuff.com) This is fascinating, especially considering our recent conversations about both Javascript and SVG recently on the WedTech list and the quantum classical clock. So Javascript rulz? -- Owen FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
On Mon, Feb 16, 2009 at 7:28 AM, Prof David West profw...@fastmail.fmwrote: On Sun, 15 Feb 2009 20:58:43 -0700, Owen Densmore o...@backspaces.net said: Re: Ruby -- It really does not cut it. I probably agree - but can 100,000 avid users be wrong? I included it in my list only on the basis of popularity for Web-only development. I did mention out of date? Ignorant, misinformed, and out of date -- that's me. And they might all be wrong, in some objective sense, but who could review all the possible ways to build web sites? There are so many truly miserable ways to build web sites, seriously suboptimal could be an enormous improvement for many. So GLASS it is for now, right? I think I'd prefer Javascript, but at least I understand the struggle. You will get Javascript - I promise - as we integrate the Lively Kernel into Squeak. And we'll get the Hollywood production model, too, for free with Disney's smalltalk? -- rec -- FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
On Sat, Feb 14, 2009 at 2:24 PM, Prof David West profw...@fastmail.fmwrote: 2. Except for a really dumb decision on the part of ParcPlace, Java would never have come into existence. Sun wanted Smalltalk, and only when rebuffed, decided to morph Oak to Java. (An earlier, equally stupid, decision forced Apple to do Object Pascal when they wanted Smalltalk.) The initial design criteria for Java was to be as Smalltalk-like as possible while still preserving the small-footprint/embeddable goals of Oak. I don't understand this. Sun owned David Ungbar's Self group from 1990. If Gosling wanted a Smalltalk in 1991, they already had one. -- rec -- FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
Thus spake Prof David West circa 14/02/09 01:24 PM: Language selection reasons like, it is too hard to learn, memory leaks, it runs faster, Java developers are cheaper because there are more of them, etc., are really dumb reasons for choosing a language. Instead you should focus on your application domain, your reason for creating the software in the first place, your working style, and how well you truly understand the problem, and any potential solution to that problem, you are trying to address. This paragraph seems a little self-contradictory. When I write a program for a client and that client's requirements include taking over and developing the code themselves, then choosing Java because Java developers are cheaper because there are more of them is not only NOT dumb, it reflects a focus on your application domain, your reason for creating the software in the first place, The same goes with the it is too hard to learn justification. Often, the system requirements flow down to those justifications. And they're not dumb if they follow directly from the requirements. Likewise, if I write a program that is intended to run on a microprocessor and will hook up to devices that require high I/O rates, then it runs faster is an excellent reason for choosing a particular language. Of course it runs faster is an oversimplification of the full complexity of the build process; but it's not dumb if it flows directly from the requirements. The requirements are the cause and the characteristics of the solution are the effect. So what I hear you saying is choosing a language because of its _effect_ is dumb, instead you should choose a language because of the _cause_ of that effect. In reality, of course, systems engineering is not linear or acyclic. So, choosing a language based on its effect in a certain context versus choosing a language based on the requirements for the solution are _both_ perfectly reasonable and are arguably the same thing. Any attempt to linearize or factor systems engineering into disjoint justifications (like what a language was originally intended for or the desire to get children to learn it) will fail because there are always multiple, inextricably intertwined requirements for any solution. There are always multiple objectives, usually where many conflict. Of course, that's subject to the 80/20 rule. A linearized engineering process is usually be good enough, at least within the domains of engineered devices like bridges or computers. But we've seen that natural systems don't succumb as easily to solutions built with linearized methods, which is why agile methods are so popular these days. -- glen e. p. ropella, 971-222-9095, http://agent-based-modeling.com FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
Parks, Raymond wrote: Owen Densmore wrote: ... Really hip programming teams will define a subset of all these systems that are platform independent -- i.e. work on all systems. They will stick to these subsets, understanding that sometimes constraints really are freedoms. I have a colleague who insists that the only such subset is C, straight up, no ++, no #, no Objective, no C-like scripting language. She insists that if you stick with ANSI C (C89) you will have code that is highly portable - as long as you stay out of the hardware. She considers C90 is just as portable, but is suspicious of C99 as it is still catching on in some places. Perhaps it is worth at least entertaining the idea that some platforms are _better_ than others? For example, the compilers that implement at least 10 year old standards instead of 20? No, it's not freedom to be constrained to 20 year old programming language standards. FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
Marcus G. Daniels wrote: Parks, Raymond wrote: Owen Densmore wrote: ... Really hip programming teams will define a subset of all these systems that are platform independent -- i.e. work on all systems. They will stick to these subsets, understanding that sometimes constraints really are freedoms. I have a colleague who insists that the only such subset is C, straight up, no ++, no #, no Objective, no C-like scripting language. She insists that if you stick with ANSI C (C89) you will have code that is highly portable - as long as you stay out of the hardware. She considers C90 is just as portable, but is suspicious of C99 as it is still catching on in some places. Perhaps it is worth at least entertaining the idea that some platforms are _better_ than others? For example, the compilers that implement at least 10 year old standards instead of 20? No, it's not freedom to be constrained to 20 year old programming language standards. Hey, like I said, it's not my idea but a colleague's. I ran up against it when I suggested writing something in C++ rather than ANSI C. However, constraints sometimes free one by eliminating the difficulty of choice. One can move on without worry that the choice is wrong. -- Ray Parks rcpa...@sandia.gov Consilient Heuristician Voice:505-844-4024 ATA Department Mobile:505-238-9359 http://www.sandia.gov/scada Fax:505-844-9641 http://www.sandia.gov/idart Pager:800-690-5288 FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
Given that a Steve Yegge blog post started this discussion, you might be interested in another (earlier) post of his http://steve-yegge.blogspot.com/2007/02/next-big-language.html and something more for the Javascript fan-boys: http://javascript.crockford.com/javascript.html BTW having worked with a number of mainstream languages - FORTRAN, C, C++, Java, Javascript, XML, XSLT and lately RubyI'd have to say I'm having a lot of fun working with Ruby right now. However, I'm not building web sites and I haven't used Python (shame), so I'm missing the point on where Ruby fails. Perhaps also I've been doing too much BPEL lately and every language looks good from there. One annoying thing I'm finding with loosely typed Ruby is that the compile/debug/compile cycle has been replaced by unit-test/debug/unit-test. The thing that saves me though is that Runit and Rake make unit testing very easy. This really irritated me with Javascript when I was using it heavily a few years ago because it lacked a good test environment. Perhaps that has changed. (and yes I mention XML and XSLT as programming languages because that is the way that so many enterprise systems treat them - look at BPEL for examplebut then maybe you shouldn't). Regards, Saul FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
On Feb 16, 2009, at 12:12 PM, glen e. p. ropella wrote: Thus spake Prof David West circa 14/02/09 01:24 PM: Language selection reasons like, it is too hard to learn, memory leaks, it runs faster, Java developers are cheaper because there are more of them, etc., are really dumb reasons for choosing a language. Instead you should focus on your application domain, your reason for creating the software in the first place, your working style, and how well you truly understand the problem, and any potential solution to that problem, you are trying to address. This paragraph seems a little self-contradictory. When I write a program for a client and that client's requirements include taking over and developing the code themselves, then choosing Java because Java developers are cheaper because there are more of them is not only NOT dumb, it reflects a focus on your application domain, your reason for creating the software in the first place, The same goes with the it is too hard to learn justification. Often, the system requirements flow down to those justifications. And they're not dumb if they follow directly from the requirements. At my previous job at a non-profit I could have written some systems administration scripts/programs in Ruby or Python. I chose to write everything in BASH (except one or two things I had to do in PERL) because I felt it would be irresponsible of me to leave the job to a recent college graduate (as occurred) who might not have had any experience with Ruby (for example). I guess my point here is that, if I understand what he is saying, I agree with Owen about problem of the silo of IT vs. what I consider real programmers to be doing. IMHO, the needs, considerations, and motivations of a sysadmin writing maintenance/monitoring/reporting scripts vs. someone hired to write a custom webapp for an organization are quite different. I said I'd never dare call myself a programmer because of my skill level, and because I don't get paid to write software. I do mostly systems administration, in the context of which I write programs as a consequence thereof. While it could be argued that sysadmins get paid to write software too, I think many of of are in a different league that is many echelons below the skill/experience level of those of you who write functional applications of more complexity, features, and containing more lines of code in a variety of languages. Also I consider the maintenance software as more OS level work and webapps or desktop applications more application-layer programming. Returning to Owen's point, I wish to educate myself away from the silo mentality and approach as I hope doing so will improve my skills and work and potentially open the door to more versatility for myself and the people I'm serving in doing my job (supporting bioinformatics research). To address the same point obliquely from another angle, my decisions on script language are as much based on organizational and personnel needs and sticking to longstanding and well-understood standards as anything else; with particular emphasis on who would inherit the maintenance of the software, however simple that software may be (RAID hardware monitoring and reporting scripts). The last script I wrote in PERL ran 2x faster when re-written in Python, but at 500ms execution time vs. 1 second who cares other than me and does it even matter? At my first real Unix job 13 years ago I was promised training I never received and am grateful that the mission critical systems I was examining in my learning process were running standard software and relatively uniform shell scripts. I'm not sure how well I'd do if I inherited the same situation today and %20 of the administration software was written each in a different language (C, BASH, PERL, and Ruby.however similar they might be in some respects). But, from a learning standpoint, both I and my successor's probably would have learned more if I'd left the same script behind in two to three languages (BASH, PERL, and Python) though in reality since time is my most precious commodity and at a premium, it's unlikely I would have been able to do that. As skill increases, however, this becomes possible and is an idea that intrigues me. When I was young and naive I complained about the way my predecessors did things when I inherited scripts, Unix systems and the like. Today my attitude is more that if I don't like it, I should change it, and if I lack the skill to do so I have no right to complain. From another point of view maybe in my field the language of maintenance scripts is irrelevant and it's the job of whoever inherits the job to deal with what they find, or learn, or find another vocation. I don't have a hard and fast answer to this question of what's appropriate to leave behind? but I know I have tried to stick to
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
Thus spake glen e. p. ropella circa 16/02/09 16:02 PM The next trick is to transition ... to more formal, repeatable, and communicable processes. There are no such things. Formal only applies in the small number of cases where the domain you are trying to understand and in which your software is to be deployed is itself a formal system; e.g. compilers, OS kernels and most utilities, and the kind of programming done by systems programmers focused on the machine itself. Repeatable is a myth, a religion actually, pushed by Carnegie-Mellon Software Engineering Institute with their Capability Maturity Model and their fellow travelers. Repeatable applies only to production processes and software development is not a production process. (It involves, in a fairly trivial way, a production process.) Communicable is a totally local phenomenon - that is to say that a team of people working on a project can establish communication among themselves and can establish a group consensus of what it all means but that knowledge is NOT transmittable to others not a part of the group. In fact, if the group holding the knowledge disbands and reconvenes after some period of time (as short as six months) it is not communicable to themselves. Forty years of empirical evidence to the contrary - the software development field still insists that engineering is a good metaphor for what most software developers do. It is a terrible metaphor. Just remember to be skeptical Absolutely! dave west FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
Thus spake glen e. p. ropella circa 16/02/09 11:12 AM When I write a program for a client and that client's requirements include taking over and developing the code themselves, then choosing Java because Java developers are cheaper because there are more of them is not only NOT dumb, it reflects a focus on your application domain, your reason for creating the software in the first place, It IS dumb. Not for you as the developer, but on the part of the client for making it a requirement. All the different ways it is dumb are too numerous to go into here - but many of them derive from the fallacy that developers are a commodity. Likewise, if I write a program that is intended to run on a microprocessor and will hook up to devices that require high I/O rates, then it runs faster is an excellent reason for choosing a particular language. Smalltalk is too big and too slow to use for telephone switching systems with millisecond time budgets. C runs faster than anything except assembler. We are developing an embedded telephony switch therefore we absolutely positively have to use C. Dumb!! I have seen Smalltalk applications for telephone switches that outperformed C code doing the same job with the added advantage that they took 6 months to develop in Smalltalk and 18 months using C. Moreover, the C team were all senior programmers with lots of experience writing C and the Smalltalk team had less than two years experience with that language. The dumbness arises from a failure to take into account all the factors - most notably design - that could address and resolve the performance requirements. Years ago, companies were demanding that all of their applications be written in C++, because of speed and because of features like multiple inheritance and friend declarations that improved the efficiency of your code. In the process they incurred millions of dollars of technical debt for no real reason. Stroustroup himself admitted in a keynote speech that in his career he had encountered exactly one instance where he positively absolutely could not have satisfied performance requirements without using multiple inheritance (and another for a friend declaration) which means that 99.9% of the software written in companies that mandated C++ could have been written in other languages at less cost. That is absurd waste. So what I hear you saying is choosing a language because of its _effect_ is dumb, instead you should choose a language because of the _cause_ of that effect. No, I am saying that you should seek an isomorphism between the language you choose and what it is that you want to express. All programming languages were created with a purpose, based on a philosophy and a set of values. This is very evident when you read the ACM history of programming languages books. If the intrinsic 'philosophy' of a language is at odds with what you want to say you will be forced to use convoluted and complex expressions to say what you want, while in another language your expressions would be elegantly simple. I am not talking about grammar here, but design. The increasing interest in domain specific languages is based, in part, on this idea. But we've seen that natural systems don't succumb as easily to solutions built with linearized methods, which is why agile methods are so popular these days. So if you want to find elegant solutions for problems arising in natural systems you should choose a language that was explicitly designed to support exploratory, iterative, incremental, adaptive, and evolutionary development; that is not strongly typed (because the real world is not); that hides implementation details (like memory management); and, supports the use of domain vernacular in its grammar, etc. etc. Sounds like Smalltalk. [grin] davew FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
They had the seed of one. Self did not have the class library and range of functionality of Smalltalk and, more importantly for Sun, it had no user base; at the time that Smalltalk was being touted as the next COBOL because of the extent to which is was being used in industry. There was, from what I have been told, an internal discussion about using Self as the foundation for Java instead of Oak - but the Web, which at the time required apps with very small footprints, became the dominant decision factor. The embedded, portable, VM, characteristics of Oak won out. My memory may wrong here, but I don't think Self had a VM while Smalltalk did. In fact, the Smalltalk VM could read Java bytecode, allowing you to create hybrid apps that intermixed both languages. davew FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
Thus spake Prof David West circa 16/02/09 05:51 PM: It IS dumb. Not for you as the developer, but on the part of the client for making it a requirement. The client doesn't _make_ it a requirement, as if requirements are created willy-nilly by some air-headed marketing type (no offense intended). The client is living within a context full of constraints, some of which disallow the open-ended search for a more optimal solution. The requirements come from the objectives of the project and the constraints that obtain in the environment. It is definitely not dumb. It's reality. It's not dumb to derive requirements from the set of extant resources and constraints. And sometimes the derived requirements point explicitly to a particular language. Smalltalk is too big and too slow to use for telephone switching systems with millisecond time budgets. C runs faster than anything except assembler. We are developing an embedded telephony switch therefore we absolutely positively have to use C. Dumb!! I have seen Smalltalk applications for telephone switches that outperformed C code doing the same job with the added advantage that they took 6 months to develop in Smalltalk and 18 months using C. Moreover, the C team were all senior programmers with lots of experience writing C and the Smalltalk team had less than two years experience with that language. Heh, all I can say is so what? Are you simply telling me anecdotes about how people have made premature and unjustifiable claims in the past? Well, ... duh! Obviously people make premature and unjustifiable claims all the time. But that doesn't mean that _every_ time someone chooses C++ over Smalltalk because of execution time, it automatically means they made a dumb decision or that their justification is dumb. Yes, if they jump to premature and unjustified conclusions, then it's ... well, premature and unjustified. But it may not be dumb! Perhaps that's the only justification they could come up with and if they spent the next 50 years trying to find a good one, they'd be laid off and another yahoo willing to shoot from the hip would have taken her place and made millions of dollars on an IPO? [grin] (with which she can then spend the next 50 years figuring out and yapping about what the _best_ language would have been) This goes back to my original point: requirements are often _complex_ and cannot be linearized or deconvolved without doing severe damage to the understanding of the problem or the solution. The dumbness arises from a failure to take into account all the factors - most notably design - that could address and resolve the performance requirements. But if, say, C++ is explicitly _derived_ from the requirements, then it is a smart choice. Likewise, if Smalltalk is derived from the requirements, then it is a smart choice, regardless of any linearized conception you or any other outsider may have of the problem and solution under consideration. Years ago, companies were demanding that all of their applications be written in C++, because of speed and because of features like multiple inheritance and friend declarations that improved the efficiency of your code. In the process they incurred millions of dollars of technical debt for no real reason. Stroustroup himself admitted in a keynote speech that in his career he had encountered exactly one instance where he positively absolutely could not have satisfied performance requirements without using multiple inheritance (and another for a friend declaration) which means that 99.9% of the software written in companies that mandated C++ could have been written in other languages at less cost. That is absurd waste. [grin] You act as if you _know_ all the facts and circumstances. That's nice that you're so convinced. I remain skeptical of _both_ corporate policies mandating languages _and_ your accusation that these particular ones were an absurd waste. It reminds me of many of the business process reengineering people I've met. They often have _no_ idea of how efficient their current business processes are. They just know that they're getting pressure from their stock holders, board, and management to change _something_ ... _anything_ ... because the performance of the company (as measured through some myopic lens) isn't satisfactory. You think such a corporate mandate is a waste. But do you really _know_ that? Can you _demonstrate_ it? (or at least provide some experimental data to show that it was a waste ... experimental in the same sense as scientific data, by the way ... not some long-winded prophet who writes books for a living) No, I am saying that you should seek an isomorphism between the language you choose and what it is that you want to express. Again, you're linearizing the requirements process. Language choice is a result of all the _many_ and intertwined requirements for any given project, including the time you have, the money
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
On Sat, Feb 14, 2009 at 2:24 PM, Prof David West profw...@fastmail.fmwrote: Re: programming languages - antipathy to C++ Few questions seem to drive passions more than language choice - The reason for this is that people who program are woefully ignorant or misinformed about the majority of programming languages, so they pick the ones they know and like, defend them, promote them, and attack everything else. We shall always be woefully ignorant and misinformed about the majority of programming languages, and opinions rooted in ignorance and misinformation are never a great basis for dialogue. They are, however, a good basis for religious disagreements If you want to build Web apps: Ruby and Rails. The first time I installed Ruby, it installed a windows registry that disabled my previous installation of Tcl/Tk, because Ruby wanted to use the version of Tk that it had hijacked as its user interface library. I sent Matz a nastygram and deleted the installation. The second time, with Rails, it was so slow that I couldn't believe anyone could use it. Googling the problem revealed that the whole world agreed, and none of the proposed solutions were worth anything. That's my 6 hours spent reviewing Ruby and Rails in a nutshell. How ignorant and misinformed is that? If you want to build desktop applications that are delivered via the Web or a Cloud - you really need to evaluate GLASS at the Complex workshop next month. That's a hard google: GLASS = Gemstone Linux Apache Seaside Smalltalk = http://seaside.gemstone.com which didn't appear on the first page of any search until I knew to include gemstone in the search terms. Why for desktop applications? It's presenting itself as a refactored LAMP (Linux Apache Mysql Php) stack? If you want infidel participation in a 4-1/2 day workshop you really need to make more of a case. -- rec -- FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
And I, too, would pay to attend such a workshop. -tj On Sun, Feb 15, 2009 at 5:48 PM, Nick Frost ni...@nickorama.com wrote: On Feb 15, 2009, at 4:52 PM, Roger Critchlow wrote: That's a hard google: GLASS = Gemstone Linux Apache Seaside Smalltalk = http://seaside.gemstone.com which didn't appear on the first page of any search until I knew to include gemstone in the search terms. Why for desktop applications? It's presenting itself as a refactored LAMP (Linux Apache Mysql Php) stack? If you want infidel participation in a 4-1/2 day workshop you really need to make more of a case. I'm thankful to Roger for helping me strike yet one more book off my wish list (Ruby Programming) as that will save a few pennies. Speaking from the neophyte point-of-view of someone who wouldn't dare call himself a programmer but as one who writes simple programs (mostly in BASH, PERL, and Python) I'm interested in the GLASS workshop merely for what more I might learn about programming in general. Most of what I've written over the years is for systems administration (mostly in BASH) and I doubt I've written anything in my career or amateur experimentation over 500 lines. I don't know if there's a workshop series planned, but think it's safe to say I know more than one person who would be willing to pay for a 1-4 day computer programming workshop that covered coding topics (GLASS, Python, C, PERL, etc.). I'd like to learn more about Python programming. I don't know if there are enough like-minded people to make running such a workshop or series at the sfComplex worthwhile? For me my interest is as much in learning about the process and fundamentals than the language.I just wonder how many people there are who, instead of plugging along blindly with O'Reilly books and writing small programs for specific projects, might like to take a class for a few days to learn from an expert or two. I'm willing to wager that a few people on the NMLUG and/or NMGLUG lists might be interested as well. Maybe the constituency is already being served by the CSF curriculum, but I think there might be working people who haven't time for a class but who would have time for a programming workshop. -Nick Nicholas S. Frost 7 Avenida Vista Grande #325 Santa Fe, NM 87508 ni...@nickorama.com FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org -- == J. T. Johnson Institute for Analytic Journalism -- Santa Fe, NM USA www.analyticjournalism.com 505.577.6482(c)505.473.9646(h) http://www.jtjohnson.com t...@jtjohnson.com You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete. -- Buckminster Fuller == FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
Tom and Nick, The GLASS workshop is the first of many - some will be shorter in duration, but all will be workshops where you have the opportunity to learn and immediately apply your knowledge to real software, not canned examples that some instructor wrote. Future offerings are dependent, to a degree, on proving that people will in fact sign-up and pay for the workshops. The GLASS week will be test. Re: why desktop -- Web delivered software has generally lacked the sophistication, functionality, efficiency. and bling of desktop apps. To the extent that Web-services and Cloud computing really are the future, we need to be able to close the perceived gap with desktop apps. I think that GLASS has promise, but I could be wrong. I am really curious to see what the limitations might be when people at the Complex try to do what they do in their day jobs, with GLASS. davew On Sun, 15 Feb 2009 17:56:43 -0700, Tom Johnson t...@jtjohnson.com said: And I, too, would pay to attend such a workshop. -tj On Sun, Feb 15, 2009 at 5:48 PM, Nick Frost ni...@nickorama.com wrote: On Feb 15, 2009, at 4:52 PM, Roger Critchlow wrote: That's a hard google: GLASS = Gemstone Linux Apache Seaside Smalltalk = http://seaside.gemstone.com which didn't appear on the first page of any search until I knew to include gemstone in the search terms. Why for desktop applications? It's presenting itself as a refactored LAMP (Linux Apache Mysql Php) stack? If you want infidel participation in a 4-1/2 day workshop you really need to make more of a case. I'm thankful to Roger for helping me strike yet one more book off my wish list (Ruby Programming) as that will save a few pennies. Speaking from the neophyte point-of-view of someone who wouldn't dare call himself a programmer but as one who writes simple programs (mostly in BASH, PERL, and Python) I'm interested in the GLASS workshop merely for what more I might learn about programming in general. Most of what I've written over the years is for systems administration (mostly in BASH) and I doubt I've written anything in my career or amateur experimentation over 500 lines. I don't know if there's a workshop series planned, but think it's safe to say I know more than one person who would be willing to pay for a 1-4 day computer programming workshop that covered coding topics (GLASS, Python, C, PERL, etc.). I'd like to learn more about Python programming. I don't know if there are enough like-minded people to make running such a workshop or series at the sfComplex worthwhile? For me my interest is as much in learning about the process and fundamentals than the language.I just wonder how many people there are who, instead of plugging along blindly with O'Reilly books and writing small programs for specific projects, might like to take a class for a few days to learn from an expert or two. I'm willing to wager that a few people on the NMLUG and/or NMGLUG lists might be interested as well. Maybe the constituency is already being served by the CSF curriculum, but I think there might be working people who haven't time for a class but who would have time for a programming workshop. -Nick Nicholas S. Frost 7 Avenida Vista Grande #325 Santa Fe, NM 87508 ni...@nickorama.com FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org -- == J. T. Johnson Institute for Analytic Journalism -- Santa Fe, NM USA www.analyticjournalism.com 505.577.6482(c)505.473.9646(h) http://www.jtjohnson.com t...@jtjohnson.com You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete. -- Buckminster Fuller == FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
Looking forward to it. Do you have a schedule yet? -tj On Sun, Feb 15, 2009 at 8:57 PM, Prof David West profw...@fastmail.fmwrote: Tom and Nick, The GLASS workshop is the first of many - some will be shorter in duration, but all will be workshops where you have the opportunity to learn and immediately apply your knowledge to real software, not canned examples that some instructor wrote. Future offerings are dependent, to a degree, on proving that people will in fact sign-up and pay for the workshops. The GLASS week will be test. Re: why desktop -- Web delivered software has generally lacked the sophistication, functionality, efficiency. and bling of desktop apps. To the extent that Web-services and Cloud computing really are the future, we need to be able to close the perceived gap with desktop apps. I think that GLASS has promise, but I could be wrong. I am really curious to see what the limitations might be when people at the Complex try to do what they do in their day jobs, with GLASS. davew On Sun, 15 Feb 2009 17:56:43 -0700, Tom Johnson t...@jtjohnson.com said: And I, too, would pay to attend such a workshop. -tj On Sun, Feb 15, 2009 at 5:48 PM, Nick Frost ni...@nickorama.com wrote: On Feb 15, 2009, at 4:52 PM, Roger Critchlow wrote: That's a hard google: GLASS = Gemstone Linux Apache Seaside Smalltalk = http://seaside.gemstone.com which didn't appear on the first page of any search until I knew to include gemstone in the search terms. Why for desktop applications? It's presenting itself as a refactored LAMP (Linux Apache Mysql Php) stack? If you want infidel participation in a 4-1/2 day workshop you really need to make more of a case. I'm thankful to Roger for helping me strike yet one more book off my wish list (Ruby Programming) as that will save a few pennies. Speaking from the neophyte point-of-view of someone who wouldn't dare call himself a programmer but as one who writes simple programs (mostly in BASH, PERL, and Python) I'm interested in the GLASS workshop merely for what more I might learn about programming in general. Most of what I've written over the years is for systems administration (mostly in BASH) and I doubt I've written anything in my career or amateur experimentation over 500 lines. I don't know if there's a workshop series planned, but think it's safe to say I know more than one person who would be willing to pay for a 1-4 day computer programming workshop that covered coding topics (GLASS, Python, C, PERL, etc.). I'd like to learn more about Python programming. I don't know if there are enough like-minded people to make running such a workshop or series at the sfComplex worthwhile? For me my interest is as much in learning about the process and fundamentals than the language.I just wonder how many people there are who, instead of plugging along blindly with O'Reilly books and writing small programs for specific projects, might like to take a class for a few days to learn from an expert or two. I'm willing to wager that a few people on the NMLUG and/or NMGLUG lists might be interested as well. Maybe the constituency is already being served by the CSF curriculum, but I think there might be working people who haven't time for a class but who would have time for a programming workshop. -Nick Nicholas S. Frost 7 Avenida Vista Grande #325 Santa Fe, NM 87508 ni...@nickorama.com FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org -- == J. T. Johnson Institute for Analytic Journalism -- Santa Fe, NM USA www.analyticjournalism.com 505.577.6482(c)505.473.9646(h) http://www.jtjohnson.com t...@jtjohnson.com You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete. -- Buckminster Fuller == FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org -- == J. T. Johnson Institute for Analytic Journalism -- Santa Fe, NM USA www.analyticjournalism.com 505.577.6482(c)505.473.9646(h) http://www.jtjohnson.com t...@jtjohnson.com You never change things by fighting the existing reality. To change something, build a new model that makes the
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
Re: programming languages - antipathy to C++ Few questions seem to drive passions more than language choice - In the good old days the Smalltalk vs. C++ conflicts actually became physical and the very real emotional rage that some people exhibited when their language was dis'ed was truly amazing. And the various arguments for/against a specific language were almost always based on totally specious reasoning. Caveat: all programming languages are Turing machines so are ultimately equivalent. Historical Notes (included only because some earlier posts intimated that C++ and Java were OO): 1- C++ is not, never was, and was never intended to be an object oriented language. You can do objects in C++ (and in Assembler, for that matter) but only at the cost of subverting Stroustroup's stated intent for the language. 2. Except for a really dumb decision on the part of ParcPlace, Java would never have come into existence. Sun wanted Smalltalk, and only when rebuffed, decided to morph Oak to Java. (An earlier, equally stupid, decision forced Apple to do Object Pascal when they wanted Smalltalk.) The initial design criteria for Java was to be as Smalltalk-like as possible while still preserving the small-footprint/embeddable goals of Oak. Java is OO to the extent it emulated Smalltalk and not OO to the extent that it emulated C; and Objective-C is a far, far, better realization of the original design goals for Java than Java. Language selection reasons like, it is too hard to learn, memory leaks, it runs faster, Java developers are cheaper because there are more of them, etc., are really dumb reasons for choosing a language. Instead you should focus on your application domain, your reason for creating the software in the first place, your working style, and how well you truly understand the problem, and any potential solution to that problem, you are trying to address. If you are trying to emulate a machine - i.e. solve a problem with a known, formal, solution - use C or C++. That is what the language was created to do, and nothing will be as 'machinelike' as a well-crafted C++ program. If you want to enable non-programmers, especially children, to develop applications while teaching them good design and programming skills - use Smalltalk (Logo, NetLogo, and even Erlang are also useful). If your working style is any combination of exploratory, iterative, and incremental; or if you are consciously trying to simulate some part of the real world - use Smalltalk with an object database for persistence. If you want to build Web apps: Ruby and Rails. If you want to build desktop applications that are delivered via the Web or a Cloud - you really need to evaluate GLASS at the Complex workshop next month. (Same thing is true if you want to deliver Flash-like iPhone apps. The iPhone does not do Flash, but Smalltalk's Morphic via the Lively Kernel and Javascript can do the same job.) davew On Thu, 12 Feb 2009 17:33:31 -0700, Owen Densmore o...@backspaces.net said: The other day, I mentioned reading that Google had settled on 4 languages for work inside the company. It occurred to me to look up the article. Here it is: http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html They use C++, Java, Python, and JavaScript. Here's the quote: One of the (hundreds of) cool things about working for Google is that they let teams experiment, as long as it's done within certain broad and well-defined boundaries. One of the fences in this big playground is your choice of programming language. You have to play inside the fence defined by C++, Java, Python, and JavaScript. It's sorta an interesting article. It's about how one sophisticated engineer worked within these constraints to build a ruby on rails environment using rhino, the java based javascript implementation. One reason we care about this is that the Google Ecology is becoming a pretty interesting one for us (redfish and the complex). -- Owen FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
Prof David West wrote: If you are trying to emulate a machine - i.e. solve a problem with a known, formal, solution - use C or C++. That is what the language was created to do, and nothing will be as 'machinelike' as a well-crafted C++ program. It's limiting that C is the primary language for high performance computing, because of its literal nature. For example, with C, even just mapping matrix manipulation to vector hardware is often impossible for compilers to do. Without careful qualification, pointers make it difficult to deduce that a memory location is used in only one way. And data alignment and relative structure ordering is implied and not open for reinterpretation (to better map to execution units). The result is we now have decades of code written for inherently scalar, serial hardware architectures. And, unfortunately, performance can only now come from using parallel, vectorized hardware. Efforts to improve the situation have been made over the years (the POOMA C++ library comes to mind), but it seems to me the problem is in large part a social one: If a problem is hard to solve with current technology its easier to hire someone else to futz with it (e.g. one of a billion `Java programmers') than it is to change the technology or the techniques. The incompetence is self-reinforcing. Much easier to feel good about the lines of code that are written, than the lines of code spent. Marcus FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
[FRIAM] Stevey's Blog Rants: Rhino on Rails
The other day, I mentioned reading that Google had settled on 4 languages for work inside the company. It occurred to me to look up the article. Here it is: http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html They use C++, Java, Python, and JavaScript. Here's the quote: One of the (hundreds of) cool things about working for Google is that they let teams experiment, as long as it's done within certain broad and well-defined boundaries. One of the fences in this big playground is your choice of programming language. You have to play inside the fence defined by C++, Java, Python, and JavaScript. It's sorta an interesting article. It's about how one sophisticated engineer worked within these constraints to build a ruby on rails environment using rhino, the java based javascript implementation. One reason we care about this is that the Google Ecology is becoming a pretty interesting one for us (redfish and the complex). -- Owen FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
Owen, John Cage the great 20th century composer used exactly this methodology in creating his chance music and in collaboration with others. Also, isn't following the protocols the way most scientific experiments are done? O Owen Densmore wrote: The other day, I mentioned reading that Google had settled on 4 languages for work inside the company. It occurred to me to look up the article. Here it is: http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html They use C++, Java, Python, and JavaScript. Here's the quote: One of the (hundreds of) cool things about working for Google is that they let teams experiment, as long as it's done within certain broad and well-defined boundaries. One of the fences in this big playground is your choice of programming language. You have to play inside the fence defined by C++, Java, Python, and JavaScript. It's sorta an interesting article. It's about how one sophisticated engineer worked within these constraints to build a ruby on rails environment using rhino, the java based javascript implementation. One reason we care about this is that the Google Ecology is becoming a pretty interesting one for us (redfish and the complex). -- Owen FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org -- Orlando Leibovitz orla...@orlandoleibovitz.com www.orlandoleibovitz.com Studio Telephone: 505-820-6183 FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
For some while I've been kind of surprised, in a detached sort of way, at the general disregard that the FRIAMers I talk with hold for C++. One explanation that has been given me was Well, C++ is prone to horrible memory management errors. To which I respond: not if you code properly. And when you do make (the inetivable) memory allocation/deallocation/reference error, there are tools that will help you track the problem down posthaste. Valgrind, for example. Purify, for another. Another reason that has been repeatedly given for C++'s disfavor is, It takes too long to develop C++ expertise. I guess I don't buy that either. I don't really think the level of expertise necessary to gain proficiency in C++ is all that much different that FORTRAN, Java, Pascal, LISP, or any other major language. I suppose I understand the FRIAM community's interest in Netlogo, but it still seems to me to be a toy language, in which you can develop small prototypes, but you can't scale a Netlogo application beyond serial computing environments. Translated: you can't develop interesting real world problem solutions in Netlogo. So, I guess it really doesn't surprise me much that Google picked the language set that they did, given the company's technology focus, and the collective power provided by that selection of languages. --Doug -- Doug Roberts, RTI International drobe...@rti.org d...@parrot-farm.net 505-455-7333 - Office 505-670-8195 - Cell On Thu, Feb 12, 2009 at 5:33 PM, Owen Densmore o...@backspaces.net wrote: The other day, I mentioned reading that Google had settled on 4 languages for work inside the company. It occurred to me to look up the article. Here it is: http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html They use C++, Java, Python, and JavaScript. Here's the quote: One of the (hundreds of) cool things about working for Google is that they let teams experiment, as long as it's done within certain broad and well-defined boundaries. One of the fences in this big playground is your choice of programming language. You have to play inside the fence defined by C++, Java, Python, and JavaScript. It's sorta an interesting article. It's about how one sophisticated engineer worked within these constraints to build a ruby on rails environment using rhino, the java based javascript implementation. One reason we care about this is that the Google Ecology is becoming a pretty interesting one for us (redfish and the complex). -- Owen FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
On Feb 12, 2009, at 8:07 PM, Douglas Roberts wrote: For some while I've been kind of surprised, in a detached sort of way, at the general disregard that the FRIAMers I talk with hold for C++. [...] Hi Doug, Interesting topic! I don't know if I'm a typical FRIAMer (there is probably no such thing), but I am a long time geek with 25 years in the software industry (semi-retired/self-employed as of last summer). I started out programming in Lisp in the mid-1980s, just before AI Winter (http://en.wikipedia.org/wiki/AI_Winter) set in. In my opinion, it was a knee-jerk reaction to abandon Lisp because of its association with AI, and always felt that the software industry took an incredibly wrong turn when it moved to languages and environments that puts more burden on the programmer, i.e. C/C++ (again, my opinion). Lisp seems to have been making somewhat of a comeback lately, but time will tell. I think a lot of some FRIAMers' reactions (mine included) to C++ has to do with valuing programmer time and energy over that of the hardware. The need to quickly build prototypes with limited programmer time favors higher level languages like Python. Of course, I've heard similar reactions to Java, which I haven't found that bad (I've been programming in Java since 1997). A good IDE, e.g. Eclipse, helps a lot. [...] One explanation that has been given me was Well, C++ is prone to horrible memory management errors. To which I respond: not if you code properly. And when you do make (the inetivable) memory allocation/deallocation/reference error, there are tools that will help you track the problem down posthaste. Valgrind, for example. Purify, for another. Well, you could say the same thing about any software tool - if you use it correctly, it is fine (a VERY BIG if), and there are tools to help you cope with the inevitable mistakes. I coded C++ for several years in its early days (late 80s, early 90s), and didn't care much for it. Chasing down memory leaks were bad enough, but holding onto freed memory was even worse, and nearly impossible (in those days) to find, since it usually resulted in core dumps long after the original error had occurred. No doubt the tools have improved, but is that how I really want to spend my time? I'd much rather concentrate on the problem, not arcane details like manual memory management. I like to think that my mental CPU cycles are worthy of something more interesting like the problem I'm trying to solve. Another reason that has been repeatedly given for C++'s disfavor is, It takes too long to develop C++ expertise. I guess I don't buy that either. I don't really think the level of expertise necessary to gain proficiency in C++ is all that much different that FORTRAN, Java, Pascal, LISP, or any other major language. I haven't actually heard anyone say that it takes too long to learn, but I can believe it. C++ has always seemed to be an overly complex language, what with multiple ways of passing and dereferencing pointers, passing complex structures by value with bitwise copy, multiple inheritance, templates... I suppose I understand the FRIAM community's interest in Netlogo, but it still seems to me to be a toy language, in which you can develop small prototypes, but you can't scale a Netlogo application beyond serial computing environments. Translated: you can't develop interesting real world problem solutions in Netlogo. I haven't used NetLogo personally, so someone else can comment on whether or not it would be practical to do real world systems with it, but as I understand it, NetLogo makes it easier to build agent based models. But again, the main point for a small group is that getting proof of concept solutions up and running quickly is very important, and with limited staff, it makes no sense to waste valuable programming time on something like memory management, which a garbage collector is perfectly capable of doing very well. And when your bread and butter (ideally) is complex systems, why not at least start with a tool that closely matches one of its problem domains, i.e. agent based modeling? So, I guess it really doesn't surprise me much that Google picked the language set that they did, given the company's technology focus, and the collective power provided by that selection of languages. What they picked probably makes sense. Java is industrial strength enough to do the server side of a lot of application software; Javascript capable and enabled browsers are safe to take for granted for the client side; C++ provides low level access to hardware. Python seems to be at least holding its own for a general purpose language and as a scripting language in competition with Perl and Ruby, and in a lot of cases can supplant Java for the server side application software. See for example reddit.com, which started out written
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
On Thu, Feb 12, 2009 at 06:07:31PM -0700, Douglas Roberts wrote: For some while I've been kind of surprised, in a detached sort of way, at the general disregard that the FRIAMers I talk with hold for C++. One explanation that has been given me was Well, C++ is prone to horrible memory management errors. To which I respond: not if you code properly. And when you do make (the inetivable) memory allocation/deallocation/reference error, there are tools that will help you track the problem down posthaste. Valgrind, for example. Purify, for another. +1. And one almost never makes these types of errors if you use RAII properly. The only time I make such errors is when I'm being forced into a non-RAII framework by some API, and the errors are typically confined to the RAII layer I erect around that API as a matter of course. Another reason that has been repeatedly given for C++'s disfavor is, It takes too long to develop C++ expertise. I guess I don't buy that either. I don't really think the level of expertise necessary to gain proficiency in C++ is all that much different that FORTRAN, Java, Pascal, LISP, or any other major language. It is when it comes to object oriented techniques. C++ is a much richer language than say Java, so it does require more learning to use it effectively. But once learnt, there is no difference in productivity, and there is a greater range techniques to express algorithms, giving greater control to the programmer for efficiency and the like. I do use both, but much prefer the expressive power of C++. Cheers -- Prof Russell Standish Phone 0425 253119 (mobile) Mathematics UNSW SYDNEY 2052 hpco...@hpcoders.com.au Australiahttp://www.hpcoders.com.au FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Stevey's Blog Rants: Rhino on Rails
On Feb 12, 2009, at 5:47 PM, Orlando Leibovitz wrote: Owen, John Cage the great 20th century composer used exactly this methodology in creating his chance music and in collaboration with others. Also, isn't following the protocols the way most scientific experiments are done? Well, of late, there has been an absolute frenzy of agile languages which tend to be loose to the point of chaotic. And believe it or not, many languages do not have a standard syntax .. there are slight variations across systems: microsoft's Java will have additions that, if you use them, weld you to Windows. Hopefully this is dying out as industry finds out the horrific costs of not being standard, but so far Greed Anger and Delusion is winning. Really hip programming teams will define a subset of all these systems that are platform independent -- i.e. work on all systems. They will stick to these subsets, understanding that sometimes constraints really are freedoms. Unfortunately, most folks don't get it and like trout to a fly, use the nice shiny features that hook them to a single system. -- Owen FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
