Welcome! One of the most important things that LL has done was bring academic and business software developers together!
Here are some comments about your paper. I liked it, and i hadn't thought about the connection with open source much before. I may use JScheme examples, but i've been reading a Jython book.
Criterion 3: Dynamically types:
"thus being dynamcally types makes sense if the nature of objects being manipulated is either unknown or unpredicatable"
This i certainly true for procedures like (read) which can return anything.
However many dynamic procedures are "typable", such as (map car xs) says that xs has type "list of lists". The important thing is you don't need the full ceremony of, say Java, to get the types right.
This is why you write a one line shell script to copy files from one place to another, than write a C program.
Open source, deeply:
I once read something about military software. The crisis was that their code was implemented in 400+ languages. These were actually OS x Language rather than real language differences, but because there were 400 implementations, all different in some way, that was the maintenance issue.
Evolution by meritocracy and natural selection
"set of individuals" is often of size 1 initially for Perl, Python, and TCL. How does this core grow over time? JScheme has 3 main developers but about a dozen who've contributed, sometimes significantly (changing the implementation enough i don't recognize it).
Small memory systems
Python might be too big, but LUA seems to fit on gaming systems, and there have been tiny lisp/schemes on small hardware. One might argue that a dynamic language could make better use of available memory. For example newton script saves memory by being prototype based rather than class based and thus save space. There are also efficient code representations that could be a win here.
Myth: "Dynamic languages are more brittle"
I think the issue here is that while static type checking finds errors at compile time, and dynamic type checking finds errors at runtime, most type errors are found the first time the dynamic code is run.
Here's a lazy refactoring method i've used for the Java part of JScheme:Change the thing you want to change and let the compiler tell you what else you need to change. You could argue this is a benifit of Java, but the only advantage is that you get all the static errors at once, while in a dynamic language you would get them only one at a time. If i get a pile of compiler errors i only change one or two before recompiling so the "advantage" isn't very important.
In the 2 refactorings i've done recently, there was one bug that the compiler did not catch. However, the orignal version of JScheme i got from Peter Norvig was 2500 lines of perfectly compilable Java code, but it took me 60 tests before i had a running JScheme application. So you should expect a but every 41 lines of code with strong typing. So static and dynamic typing come out pretty even.
Myth: "dynamic langues don't have good tools"
What about licensing issues? Can i distribute my software to my customers?
Do i have to donwload every piece of sotware separately?
Lack of startigic vision:
Besides SOAP and REST ERLANG has an intersting compact alternative.
At 03:06 PM 8/13/2004 -0700, you wrote:
>It occurred to me that all of you might already know each other quite well, but that only Jeremy knows me. I figured I'd give a little intro to my background and perspectives on the domain of programming languages.
>I've been programming since 1981 or so, and have gone through a fairly typical sequence of programing languages for someone of my generation. In rough order (and forgetting some I'm sure):
>Notably absent from the list is any significant experience with functional languages. What I think of as a gap in my education may be a 'feature' when it comes to the composition of this PC ;-).
>I dabble in languages as an intellectual pastime, getting more satisfaction from breadth of experience than depth. I don't consider myself an expert in any of the above languages, having met experts in many of them.
>I'm an academic by training (degrees in Physics and Cognitive Science from Brown, with a strong CS component to both), have experience doing non-CS research (computational modeling of and psychophysical experiments in human vision), and have worked in various software firms on various domains such as graphics, UI, neural networks, mobile apps. I've spent the last 4+ years at ActiveState (now a part of Sophos) focusing on building tools for users of languages like Python, Perl, Tcl, PHP and XSLT. I was the tech lead for Komodo (one of ActiveState's IDEs for same languages), and currently run the Tools & Languages division of Sophos, aka ActiveState. In other words, while I have a technical and academic background, I do have to keep an eye on a balance sheet. Life is strange.
>I have a public preference for languages like Python over many others, having co-written two books on the topic and serving on the Python Software Foundation board since its inception. I am professionally bound to respect differences of opinion on such preferences, obviously.
>I've been responsible for systems large enough to know that I don't ever want to be responsible for _truly_ large systems.
>My interest in the LL workshop is a combination of intellectual curiosity and a belief that supporting the growth, adoption of, and interest of not-so-mainstream languages is important for a wide range of goals, including the selfish (ensuring ActiveState's future success) and the more altruistic (making the world a more fun place to program in, and a more fun place to use software).
>I've been involved in the planning of enough conferences that I know not to commit to too much -- the fact is that my job will take precedence over any conference duties, and surges in workload are predictably unpredictable. I am happy to assist in reading and discussing papers and the like, but will stay out of logistical discussions, especially since I don't know the expectations of the LL crowd.
>I will also consider getting ActiveState to help fund the conference, but such decisions are (deliberately) left to my marketing team, who have to judge where we spend the few dollars we can allocate to conferences.
>Finally -- I've recently published a whitepaper on a related topic, (see http://www.ActiveState.com/Dynamic), and I want to emphasize at the outset that I did not intend to step on any toes in the definitions used in that paper esp. w.r.t. the usage of the term "Dynamic Languages" (which in the context of the paper assumes an open source component which many dynamic languages don't have). That paper tries hard to make a "business" case in the context of market dynamics, and unfortunately many simplifications had to be made (e.g. regarding the taxonomies of programming languages and the relative importance of various languages) to make the paper (hopefully) convincing. My default expectation is that we are all aligned in an effort to correct the simplistic market presentations on programming languages. Feel free to send me comments on the paper (off list!) if you want.
>With apologies for the long intro, I look forward to working with all of you,