Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • Omer Zak
    ... From: Shlomi Fish To: Omer Zak Cc: ******@****** Subject: Re: About Park - points to consider when designing a
    Message 1 of 1 , Jun 23, 2006
      -------- Forwarded Message --------
      From: Shlomi Fish <shlomif@...>
      To: Omer Zak <omerz@...>
      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):


      (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:


      (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

      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:


      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:


      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%5d

      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,

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


      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:


      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.


      Shlomi Fish

      Shlomi Fish shlomif@...
      Homepage: http://www.shlomifish.org/

      95% of the programmers consider 95% of the code they did not write, in the
      bottom 5%.
    Your message has been successfully submitted and would be delivered to recipients shortly.