[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