Message 2 [Fwd: Re: About Park - points to consider when designing a new programming language]

-------- Forwarded Message --------
From: Shlomi Fish <shlomif-ik1l9ssToec+JF/[email protected]>
To: Omer Zak <[email protected]>
Cc: ******@******
Subject: Re: About Park - points to consider when designing a new
programming language
Date: Fri, 23 Jun 2006 21:06:47 +0300
Hi Omer!

I hope you don't mind me CCing this message to ******@******. They 
may be interested in it. I don't see anything particularly personal in it.

On Friday 23 June 2006 18:32, Omer Zak wrote:
> Hello Shlomi,
>
> 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.

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.

But back to what you are saying:

>
> So, I suggest that the following points be addressed in the specs of the
> new language (rather than minutieae about expressing stuff which is
> expressed in O(1) lines of source code):
> - Modularization (you did mention namespaces; is it possible to declare
> a namespace within another namespace like in Perl AA::BB::CC?)

Of course it would be possible. It's also possible in Python, BTW. (albeit in 
Python I believe that namespaces are done somewhat differently to Perl 5).

> - Support for expressing things in terms of design patterns.

Well, Paul Graham points in:

http://www.paulgraham.com/icad.html

That "Peter Norvig found that 16 of the 23 patterns in "Design Patterns" (the 
book) were "invisible or simpler" in Lisp." pointing to 
http://www.norvig.com/design-patterns/ . Hopefully this will be the case for 
Park as well.

There are plenty of patterns and anti-patterns out there - many of them 
concern software management. Many of them are constantly found. 

> - Aspect orientation.

Aspects are implementable in Common Lisp with very little effort (I recall 
reading a quote about it). They are also implementable in Perl 5, at least to 
some extent:

http://search.cpan.org/dist/Aspect/

Only in Java did they require someone to start a startup to add support for it 
to the JVM, etc.

> - Laws of the thumb, like Demeter's Law.

[Looking up Demeter's Law - http://en.wikipedia.org/wiki/Law_of_Demeter]

Reading about it a bit, it seems that there should be no problem using it in 
the OOP system I proposed. (or in Perl 5 or in CLOS). 

> - Support for mixed-language software development.

Do you mean mixed-programming language or mixed human-language (I.e: Unicode, 
etc.)

> - Seamless integration of database access, with all the power of SQL.
> Also include declaration of constraints for integrity validation of data
> being stored in the database.

Yes, I intended to mention APIs like those for SQL databases, non-SQL 
relational databases, Berkeley DB etc., XML, WWW Automation (libwww-perl, 
curl, etc.), web server programming, etc. etc.

At the moment, I'm not thoroughly or conclusively defining any specs for them.

A different issue from a unified SQL access (like Perl's DBI) is 
Object-Relational-Mapping (ORM). There are several approaches for doing this 
in Perl. One of the most interesting is Tangram which allows converting 
something like:

<<<
sum(map { $_->age() } grep { $_->name() eq "Omer" } @$persons);
>>>

Into the following SQL Query:

<<<
SELECT sum(age)
FROM persons
WHERE name = "Omer"
>>>

Or at least should in theory.

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

> - Testability (probably supported by aspect orientation).

What do you mean by "Testability"? I'm waiting for an answer.

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

> - Seamless multithreading.

That is a good idea. Of course, multi-threading is a can of worms, and causes 
a lot of problems. It is sometimes needed or helpful, but still is.

Recently I discovered that my FCFS RWLock:

http://www.shlomifish.org/Vipe/rwlock/

has become broken in modern Linuxes and other modern systems. While it is 
conceivable that I'm doing something wrong, I also suspect a kernel or libc 
(or gcc?) bug. And an FCFS RWLock is a pretty simple-to-get-right thing.

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

If you want something like Eclipse for Java Development (which I heard a lot 
of raves about, and seems to work nicely from what I tried, if a bit slowly), 
then I guess Park is not for you. Idle for Python also seems very nice from 
some demos I saw. However, with Perl 5 and Perl 6 and Lisp (of all variants) 
it would be almost impossible to get right.

> I am not saying that the language design needs to provide for all of the
> above.  But I claim that when a new language is designed, the above
> points should be addressed.

That's right.

I believe Hackers-IL will also be interested in this conversation. If you wish 
you can CC the reply there.

Regards,

	Shlomi Fish

---------------------------------------------------------------------
Shlomi Fish      shlomif-ik1l9ssToec+JF/[email protected]
Homepage:        http://www.shlomifish.org/

95% of the programmers consider 95% of the code they did not write, in the
bottom 5%.



------------------------ Yahoo! Groups Sponsor --------------------~--> 
Something is new at Yahoo! Groups.  Check out the enhanced email design.
http://us.click.yahoo.com/SISQkA/gOaOAA/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/