Re: [shlomif-beta-reviewers] Re: Message 3 (Re: About Park - points to consider when designing a new programming language)

On Sat, 2006-06-24 at 01:01 +0300, Shlomi Fish wrote:
> On Friday 23 June 2006 23:08, Omer Zak wrote:
> > On Fri, 2006-06-23 at 21:06 +0300, Shlomi Fish wrote:
> > > (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.

[... discussion how Shlomif works on his code was snipped ...]
The issue is that each one has his own style of working.  The optimal
environment for shlomif is not optimal for me and vice versa.

> I believe most one liners assume the programmer has a ready, instant, 
> knowledge of most of the core functions and concepts he needs to write stuff.

A properly-designed IDE with a properly-designed search engine and
properly-catalogued Internet-based database of documentation and code
examples - would extend the effective "ready, instant knowledge" used by
the programmer.

> My intention in Park is to have an actually useful Lisp dialect that people 
> could use in place of Perl, Python, etc.

Again, I believe more in designing the whole environment rather than in
polishing a single component (the programming language).  The Smalltalk
developers did develop a whole environment.  The FORTH inventor (Chuck
Moore) developed a whole environment together with FORTH (alebit very
unconventional one, as he has very unconventional mind).

> I believe PHP would be suitable for writing > n*10M LOCs codebases. But you'll 
> probably need to have very good and discplined programmers for achieving 
> this. (But this goes without saying for any other language you'd like to 
> maintain such codebases in).

For a O(10^7) software development project, you need disciplined
programmers anyway.

I am now thinking that I have been barking on the wrong tree.

If we want to improve the productivity of software developers, then
investment of neuron firings will be more profitable, if it is made at
design and development of a multilingual environment (which I refer to
as IDE elsewhere), rather than at design of a single new language.

However this is a different problem, which is probably of no interest to
people, who make an hobby of designing new programming languages.

> > > 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.
> >
> 
> Do you include static run-time checking there? (Like the Stanford checker, 
> etc.)
> 
> I'd rather not go too much into the direction of a language in which bugs can 
> be proven not to exist for fear of the following quote:
> 
> <<<
> "UNIX was not designed to stop its users from doing stupid things, as that 
> would also stop them from doing clever things." – Doug Gwyn
> >>>
> 
> So I'm not sure whether such a feature would prevent doing smart things like 
> doing self-writing code, or even generating functions on the fly, or 
> dynamically changing the class inheritance graph.

It is possible to combine both concerns, by language design which
enforces type checking (including legality of unlocked accesses) by
default, but allows the software developer to explicitly override it.

An example:  the coercion operator in C/C++.  It allows you to shoot an
atom bomb at your foot, but you have to explicitly declare that this is
what you are doing.

> > 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.
> >
> 
> I also think Alan Turing has something to say about it too:
> 
> http://en.wikipedia.org/wiki/Halting_problem
> 
> If we generalise the Halting problem than we can say a program to conclusively 
> analyse a different computer program would be impossible to write. I don't 
> see how I can get an IDE to analyse a macro and determine how it does what 
> it's supposed to do. The best way would probably be to document the behaviour 
> of the macros in the program a la doxygen or javadoc. But this will require 
> an extra work from the programmer.

One possible (and relatively simple) way to implement it:
You set the IDE to execute a macro, with arguments which you supply,
each time you modify its definition.  Then display the resulting code in
a separate window pane.  Then you can see immediately the effects of
changes in the macro definition.
                                           --- 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 --------------------~--> 
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/