jscheme-user

[Jscheme-user] Re: Introduction

[Ken A. <kan...@bb...>]

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):
>
>  - Basic, Pascal, Logo, AppleScript, HyperTalk, REXX, Prolog, FORTRAN, C, PostScript, C++, NewtonScript, Awk, Perl, Tcl, Java, S, MetaPost, Python, JavaScript, PHP.
>
>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 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,
>
>--David

[Jscheme-user] Re: Introduction

[David A. <Da...@Ac...>]

Ken Anderson wrote:

> Welcome!  One of the most important things that LL has done was bring academic and business software developers together!

Thanks, and agreed.  (I'm following Ken's lead and including the two 
lists -- I'll elide them if so prompted).

> 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.

Didn't know much about JScheme until now.  I'm glad I know more now.

> 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.

Yes.  I tried to be careful in not using phrases like 'weakly typed' or 
'typeless', which, I agree, aren't especially useful features.

> 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. 

Believable.  I'd love a reference...

> 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).

I don't think there's a good generalization to be made there (and 
unfortunately a main requirement of the paper is to be able to 
generalize across languages).  Each language community I've studied has 
reacted differently to the pressures put upon it, with very differing 
results.

> 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.

Lua aside, I agree in theory, not in practice yet af far as I know.  I 
know very little about implementation techniques, but the market says 
that with some exceptions (Lua, Tcl), dynamic language implementations 
are "big" -- that is, bigger than hand-crafted low-level code.  I would 
be thrilled to be proven wrong by some really bright implementor who 
"solves" problems like JITting of messy languages like Python which have 
eluded real-world, practical type inferencing mechanisms (StarKiller, as 
far as I know, is still very far from being applicable in the real world).

> 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.

Mostly agreed.  Most type errors are found in the compile time of a 
statically typed language because statically typed languages force you 
to think about type almost above all else.  I get the feeling that 
"people" will blame things like runtime errors in programs written in 
dynamic languages on the language, but runtime errors in programs 
written in static languages are blamed on bad programming.  Seems 
unfair, no? ;-)

Your points about refactoring are interesting in that they're a real 
challenge for me.  People have built remarkable refactoring tools in 
some languages (Smalltalk, Java come to mind), but almost nothing really 
useful in open source languages.  Part of me thinks that it's because 
the open source programming language community in general doesn't buy 
into "big idea" approaches to software engineering, and refactoring 
tools are definitely a big idea (i.e. big rewards from big investment). 
  So the languages naturally evolve to deal with micro problems, with 
little attention to how language changes could make higher level tools 
more doable (e.g., type annotations, various pragma constructs, etc).

> 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?

I haven't seen that in practice, but that may be a peculiarity of the 
languages I deal with -- the licenses are relatively clearly 
unencumbered from distribution hassles, and one of ActiveState's 
value-add bits is to simplify the packaging/distribution problem.  Is 
that a problem you get a lot w/ JScheme?

> Lack of startigic vision:
> Besides SOAP and REST ERLANG has an intersting compact alternative.

I definitely need to learn more about erlang.  Thanks for the pointer. 
Do you have a specific reference for web services & ERLANG?

--david

[Jscheme-user] Re: Introduction

[Ken A. <kan...@bb...>]

At 09:44 AM 8/19/2004 -0700, David Ascher wrote:
>Ken Anderson wrote:
>
>>Welcome!  One of the most important things that LL has done was bring academic and business software developers together!
>
>Thanks, and agreed.  (I'm following Ken's lead and including the two lists -- I'll elide them if so prompted).
>
>>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.
>
>Didn't know much about JScheme until now.  I'm glad I know more now.
>
>>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.
>
>Yes.  I tried to be careful in not using phrases like 'weakly typed' or 'typeless', which, I agree, aren't especially useful features.
>
>>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. 
>
>Believable.  I'd love a reference...

I don't think this is where i saw it, but its close
http://www.stsc.hill.af.mil/crosstalk/1995/10/Survey.asp
http://www.stsc.hill.af.mil/crosstalk/1997/12/languages.asp

>>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).
>
>I don't think there's a good generalization to be made there (and unfortunately a main requirement of the paper is to be able to generalize across languages).  Each language community I've studied has reacted differently to the pressures put upon it, with very differing results.
>
>>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.
>
>Lua aside, I agree in theory, not in practice yet af far as I know.  I know very little about implementation techniques, but the market says that with some exceptions (Lua, Tcl), dynamic language implementations are "big" -- that is, bigger than hand-crafted low-level code.  I would be thrilled to be proven wrong by some really bright implementor who "solves" problems like JITting of messy languages like Python which have eluded real-world, practical type inferencing mechanisms (StarKiller, as far as I know, is still very far from being applicable in the real world).

I think the Northeastern PLT-Scheme guys have done the best attempt.
http://plt-spy.sourceforge.net/papers/scheme-workshop-2003-web/scheme-workshop-2003.html
unfortunately, a few python classes do sneaky things at the meta level that causes the inference to fail.  If those classes were altered we might have something.

>>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.
>
>Mostly agreed.  Most type errors are found in the compile time of a statically typed language because statically typed languages force you to think about type almost above all else.  I get the feeling that "people" will blame things like runtime errors in programs written in dynamic languages on the language, but runtime errors in programs written in static languages are blamed on bad programming.  Seems unfair, no? ;-)

It sure does.

>Your points about refactoring are interesting in that they're a real challenge for me.  People have built remarkable refactoring tools in some languages (Smalltalk, Java come to mind), but almost nothing really useful in open source languages.  Part of me thinks that it's because the open source programming language community in general doesn't buy into "big idea" approaches to software engineering, and refactoring tools are definitely a big idea (i.e. big rewards from big investment).  So the languages naturally evolve to deal with micro problems, with little attention to how language changes could make higher level tools more doable (e.g., type annotations, various pragma constructs, etc).

Maybe the focus tends to be about the language rather than about programming.  For JScheme we wanted a small simple interactive language on top of Java.
Maybe Eclipse could be a basis for such tools for dynamic languages.
Squeak is probably a "big idea" language but its user interface is completely foreign to modern users.

>>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?
>
>I haven't seen that in practice, but that may be a peculiarity of the languages I deal with -- the licenses are relatively clearly unencumbered from distribution hassles, and one of ActiveState's value-add bits is to simplify the packaging/distribution problem.  Is that a problem you get a lot w/ JScheme?

No, JScheme has a liberal license, but we are now also providing third party jars with different licences.

>>Lack of startigic vision:
>>Besides SOAP and REST ERLANG has an intersting compact alternative.
>
>I definitely need to learn more about erlang.  Thanks for the pointer. Do you have a specific reference for web services & ERLANG?

http://www.sics.se/~joe/ubf/site/home.html Universal Binary Format
they also have xml webservices but its UBF that i find intersting.