Administrator
|
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 |
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: ============================================================ 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 |
In reply to this post by Owen Densmore
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 [hidden email] [hidden email] 505-455-7333 - Office 505-670-8195 - Cell On Thu, Feb 12, 2009 at 5:33 PM, Owen Densmore <[hidden email]> 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: ============================================================ 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 |
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 in Lisp and was later migrated to Python (much to the consternation of a lot of the Lisp community). By the way, Peter Norvig (http://www.norvig.com) is director of Research at Google, and he has a really nice page on Lisp and Python (http://www.norvig.com/python-lisp.html ). I noticed that in the blog entry referenced, the blogger stated that "productive work" at Google had to be done in the four languages. I suspect that the same constraints don't carry over into Google Research, but couldn't say for sure. > --Doug > -- > Doug Roberts, RTI International > [hidden email] > [hidden email] > 505-455-7333 - Office > 505-670-8195 - Cell ;; My .02 ;; 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 |
In reply to this post by Douglas Roberts-2
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 [hidden email] Australia http://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 |
Administrator
|
In reply to this post by Orlando Leibovitz
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 |
In reply to this post by Owen Densmore
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" <[hidden email]> 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 |
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 |
In reply to this post by Prof David West
On Sat, Feb 14, 2009 at 2:24 PM, Prof David West <[hidden email]> wrote:
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
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 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 |
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 [hidden email] ---------------------------------------- ============================================================ 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 |
And I, too, would pay to attend such a workshop.
-tj On Sun, Feb 15, 2009 at 5:48 PM, Nick Frost <[hidden email]> wrote: On Feb 15, 2009, at 4:52 PM, Roger Critchlow wrote: -- ========================================== 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 [hidden email] "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 |
In reply to this post by Owen Densmore
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" <[hidden email]> said: > And I, too, would pay to attend such a workshop. > > -tj > > On Sun, Feb 15, 2009 at 5:48 PM, Nick Frost <[hidden email]> 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 > > [hidden email] > > ---------------------------------------- > > > > > > ============================================================ > > 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 [hidden email] > > "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 |
Administrator
|
In reply to this post by Nick Frost
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 find the architectural, breadth-first approach important for students today because today's computing ecology has created silos: IT vs CompSci vs Software Engineering vs Math vs ... I find billions of computer folks who understand only 5% of computing, but well. I tend toward understanding 50% well enough to be able to work out the other 50%. 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. Re: Ruby -- It really does not cut it. Great for Rails, but you have to be a web-only programmer. I think Python still wins the agile war. My experience with Django on Google App Engine convinced me that its good enough for web work. Oddly enough, if I were trying to put together an architectural class, I just might choose Javascript! Why? Well, it really is an agile language. And it comes with a window system: the browser. Consider this: almost all modern languages do *not* come with windowing and graphics (Java is an exception). And javascript is now making both browser and server systems that are quite impressive. So from the architectural standpoint, you get a sophisticated system that can be run locally as a shell (Rhino), as a web/client system (DOM + Browser), as a server (jaxer/Aptana), and as a general purpose scripting language (used as Flash's ActionScript, for example). It even ships with Java nowadays, and may become the scripting language of choice for Java! .. what irony! Teaching computing is tough. It faces a near-chaotic ecology. It faces absurd bias. It faces an environment where very few practitioners understand the overall computing milieu. So GLASS it is for now, right? I think I'd prefer Javascript, but at least I understand the struggle. -- Owen On Feb 15, 2009, at 5:48 PM, Nick Frost 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 ============================================================ 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 |
In reply to this post by Prof David West
Looking forward to it. Do you have a schedule yet?
-tj On Sun, Feb 15, 2009 at 8:57 PM, Prof David West <[hidden email]> wrote:
-- ========================================== 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 [hidden email] "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 |
In reply to this post by Roger Critchlow-2
On Sun, 15 Feb 2009 20:58:43 -0700, "Owen Densmore"
<[hidden email]> 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 |
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 |
Administrator
|
In reply to this post by Prof David West
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 |
In reply to this post by Prof David West
On Mon, Feb 16, 2009 at 7:28 AM, Prof David West <[hidden email]> wrote:
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 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 |
In reply to this post by Prof David West
On Sat, Feb 14, 2009 at 2:24 PM, Prof David West <[hidden email]> wrote:
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 |
In reply to this post by Prof David West
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 |
Free forum by Nabble | Edit this page |