Message 3 (Re: About Park - points to consider when designing a new programming language)

On Fri, 2006-06-23 at 21:06 +0300, Shlomi Fish wrote:
> Hi Omer!
> 
> I hope you don't mind me CCing this message to shlomif-beta-reviewers. They 
> may be interested in it. I don't see anything particularly personal in it.

Actually, Hackers-IL is a more suitable mailing list for this
discussion.  It is really about how a programming language could support
programming in the large.

> > ref: http://www.shlomifish.org/park-lisp-fooware/
> >
> > I believe that a new non-DSL can justify its existence only if it
> > addresses the problems of developing a giant application (O(10^7 lines
> > of source code)).  I raised the subject in Hackers-IL few years ago.
> 
> Yes, I know. Well, most codebases never reach this kind of volume. I know that 
> Amazon.com has a ~100 Million codebase (which is constantly evolving):
> 
> http://xrl.us/nowb
> 
> (and a lot of it is in Perl and in other high-level, succint languages)
> 
> But this is relatively rare. As MJD points out here:
> 
> http://perl.plover.com/yak/12views/samples/notes.html
> 
> (Search for "LISP") he writes about a dozen one-liners a day. So one thing I'd 
> like to make Park suitable for is writing short scripts and programs.

To do quick one-liners, I think that a properly designed IDE would be
better than a new language.  I have in mind an IDE which integrates with
a powerful search engine:
You type in concepts as keywords.
The search engine searches through library documentation and cookbooks.
You get, as results, links to relevant libraries (from all programming
languages) and relevant coding cookbook entries.

> My expectation from languages is that unless it's a truly estoric language 
> (like Intercal) it can scale well. Hell, even PHP which has some serious 
> maintainability problems (at least IMO) can scale well to large or very large 
> codebases.

A language needs to be both scalable and maintainable.  If PHP has
serious maintainability problems, then it is not suitable as main
language for O(10^7) projects.

> > - Support for mixed-language software development.
> 
> Do you mean mixed-programming language or mixed human-language (I.e: Unicode, 
> etc.)

I mean mixed-programming languages, as in Inline::Guile, which mixes
Scheme into Perl (when it works).

> > - Multi-versioning of support code (it would be cool to be able to link
> > one part of a giant application with version 1.5 of a library, and
> > another part of the same application with version 1.6.3 of the same
> > library).
> 
> That's interesting. I don't think Perl supports it, but Python might if I 
> understood its module system correctly. Of course, we also have to take into 
> consideration a Perl "Safe;" like protected environment module which is often 
> used for IRC eval bots, embedded Perl etc..
> 
> The Pythoneers tried implementing something like that in Python, but they kept 
> discovering security problems, and ended up abandoning by concluding it was a 
> difficult problem.
> 
> One possible solution would be to set a different root namespace or do a 
> namespace assignment. If each namespace (and sub-namespace) is a first-order 
> object (which was what I planned for Rindolf) then we can mix and match them.

This is more of distribution (in the sense of Gentoo, Ubuntu or
Mandrake) issue.  Different programs can link to different libraries,
and be glued together using a script file to form a single gigantic
application.

For example, consider what is needed to be able to keep both versions
1.4 and 1.9 of automake in a Debian system.

> > - Testability (probably supported by aspect orientation).
> 
> What do you mean by "Testability"? I'm waiting for an answer.

Let's keep it open-ended question here.  Additional brains are invited
to discuss implications of testability upon language and IDE design.

An hypothetical language, which does not allow you to run separately a
module from a big application, with reasonable amount of scaffolding -
does not support testability.

> > - Debugability (a language which can help detect heisenbugs can be a
> > winner).
> 
> Funny that you mention it. I recently encountered a heisenbug in "perl -d" and 
> one in the entire debugger interface. Now the default perl debugger is very 
> hairy and error-prone, and I could only reproduce this heisenbug 
> occasionally, and not too many others could reproduce it.
> 
> One suggestion for handling heisenbugs that has been raised is a reversible 
> debugger. See for example:
> 
> http://use.perl.org/article.pl?sid=06/06/22/1210201
> 
> Do you have any other suggestions?

Not really.  But can try to use theory (http://lambda-the-ultimate.org/)
to specify a language, in which it is possible to prove that certain
types of heisenbugs cannot occur.  For example, require explicit
declaration of variables, which are shared among threads, so that the
compiler (or interpreter) can check, at compile time, that accesses to
those variables are properly locked.

> > - Several views of the source code (LabVIEW is suited to certain
> > personality types, among whom I am not).  Syntax coloring.  Finding all
> > references to a concept [variable, procedure, object] without being
> > confused by having its name reused elsewhere; or having several names
> > aliased to it.
> >
> 
> That's pretty much impossible to do all the time in Lisp (if I understand you 
> correctly). While someone can implement a syntax coloring editor which will 
> work if your code does not use macros or fancy stuff like that too much. 

Can you design Park to support this, even when macros are used?
It may be a good idea to design an IDE, which would allow a developer to
have a view of code, which could be generated by a LISP macro, as the
macro is being developed.

I think that it is more of IDE issue than language issue, however.

                                          --- Omer

-- 
You haven't made an impact on the world before you caused a Debian
release to be named after Snufkin.
My own blog is at http://tddpirate.livejournal.com/

My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which
I may be affiliated in any way.
WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html



------------------------ Yahoo! Groups Sponsor --------------------~--> 
See what's inside the new Yahoo! Groups email.
http://us.click.yahoo.com/2pRQfA/bOaOAA/yQLSAA/saFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/hackers-il/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/