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

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

Expand Messages
  • Omer Zak
    ... [... 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
    Message 1 of 6 , Jun 23, 2006
    • 0 Attachment
      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
    • Shlomi Fish
      Hi Omer! ... Right. Someone mentioned here that he was using vim for editing Java code after he found that Eclipse was not his cup of tea. I used gvim to edit
      Message 2 of 6 , Jun 24, 2006
      • 0 Attachment
        Hi Omer!

        On Saturday 24 June 2006 02:10, Omer Zak wrote:
        > 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.

        Right. Someone mentioned here that he was using vim for editing Java code
        after he found that Eclipse was not his cup of tea. I used gvim to edit
        Scheme code for my SICP exercises and other Scheme experimentation.

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

        Possibly. However, many (most ?) programs will just fire-up vim, joe, edit.exe
        or their different idea of a lightweight and convenient command line editor
        to write the script (or edit it directly in the shell prompt), if a one-liner
        is all they want to write.

        Only when editing, longer and usually large-scale program does an IDE
        justifies itself.

        When I said "ready, instant knowledge" I meant knowledge that you do not have
        to lookup. For example, when programming Perl, I already know the syntax for
        regular expressions, most of the useful functions out of perlfunc, the
        operators that I need, etc. Some people know it for Python or Ruby or PHP or
        a different language. Part of the reason I'm still using Perl for my scripts
        is that looking everything up for a different language would be more time
        consuming, so even if the resultant script would be shorter, it would take me
        longer to write.

        >
        > > 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've recently started learning Smalltalk. I first tried Squeak Smalltalk which
        is a Smalltalk environment written in C. (by the original Smalltalk
        designers) It looks very nice and all, but its conventions are unconventional
        and therefore annoying. I did not like its own internal editor (or could get
        the hang of it), and tried to find a way to write code in gvim. The people at
        #squeak even told me there was no way to write everything using plaintext.
        (No to mention the code exported by Squeak to a Unix system was \r instead of
        \n terminated.)

        Meanwhile, I'm using GNU Smalltalk instead which allows me to edit everything
        as text and uses the native filesystem. Obviously Squeak is probably an
        extreme case of making an environment. Other environments like Eclipse or
        Emacs do play nicely with the other kids on the block.

        Guy once posted a message about enhancing the "Unix IDE":

        http://groups.yahoo.com/group/hackers-il/message/3681

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

        Right.

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

        I see. Well the best type system I saw was in Haskell and O'Caml which are
        truly strongly typed (but see [1]), but also functional. It is possible a
        similar type system exists in such languages as Module 3 and Ada 95, but I
        don't know them yet.

        Only problem is that such a type system does not correspond very well with the
        spirit of Lisp until now, nor with my plans for Park. I personally find such
        types too limiting to think of in day-to-day-programming. Plus, while they
        may help write more bug-free code, they are not a necessity for large scale
        projects. (See my quote about doing smart things and stupid things in the
        previous message).

        Python has a type system but it is still dynamically typed where each
        container can contain hetrogeneous values. Perl 6 aims to also have a
        stricter type system than Perl 5, but from what I understood you can do
        Haskell-like type signatures like $foo is a hash whose keys are string and
        his values are hash refs whose "a" element is a string, and "omer" element is
        a float. But I may have mis-concepted the Perl 6 specs.

        I don't see such type systems belonging in Park. Park would have an object
        system with a nice Object hierarchy (based on that of another language, but
        possibly somewhat different.) and everything would be an object there. Now,
        containers will generally manage references to the base class (in a similar
        way to Smalltalk or Java) as values. Since Park would be a symbolic language,
        then like Perl 5, you won't need any casting to call a method of any of the
        derived classes the object belongs to.

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

        Hmmm... wouldn't it still require some work from the programmer? Can you point
        to an implementation of this for a different Lisp dialect?

        Regards,

        Shlomi Fish

        [1] - http://perl.plover.com/yak/12views/samples/notes.html - search
        for "Strongly Typed".

        --

        ---------------------------------------------------------------------
        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%.
      • Omer Zak
        ... The search engine can be available in a separate window, say inside a Web browser. It would be open all the time. ... Limiting the tools used to write
        Message 3 of 6 , Jun 24, 2006
        • 0 Attachment
          On Sat, 2006-06-24 at 11:27 +0300, Shlomi Fish wrote:

          > > > 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.
          >
          > Possibly. However, many (most ?) programs will just fire-up vim, joe, edit.exe
          > or their different idea of a lightweight and convenient command line editor
          > to write the script (or edit it directly in the shell prompt), if a one-liner
          > is all they want to write.

          The search engine can be available in a separate window, say inside a
          Web browser. It would be open all the time.

          > When I said "ready, instant knowledge" I meant knowledge that you do not have
          > to lookup. For example, when programming Perl, I already know the syntax for
          > regular expressions, most of the useful functions out of perlfunc, the
          > operators that I need, etc. Some people know it for Python or Ruby or PHP or
          > a different language. Part of the reason I'm still using Perl for my scripts
          > is that looking everything up for a different language would be more time
          > consuming, so even if the resultant script would be shorter, it would take me
          > longer to write.

          Limiting the tools used to write one-liners limits the power of one's
          one-liners. My suggestion is about expanding the scope of tools
          immediately available for this. Especially, example code fragments will
          be very useful for writing one-liners in a language which is not being
          frequently used. And this is very good when a different than usual
          language needs to be used due to better match of its paradigms and the
          problem in hand.

          > Guy once posted a message about enhancing the "Unix IDE":
          >
          > http://groups.yahoo.com/group/hackers-il/message/3681

          The task of looking for references and examples is just one of the tasks
          which Guy's approach would optimize. I claim that optimizing this task
          has huge payoff.

          > > 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.
          >
          > Hmmm... wouldn't it still require some work from the programmer? Can you point
          > to an implementation of this for a different Lisp dialect?

          I never saw such an implementation.

          The programmer has to tell the IDE that he wants to have the macro
          automatically invoked with certain arguments each time it is modified;
          and to have the resulting code automatically displayed in a pane.

          Then it will work somewhat like Watch windows in a debugger IDE (the
          windows which display variable or register values, which change each
          time you step through an instruction in a debugger).

          --- 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
        • Shlomi Fish
          ... I see. Well, as far as Konsole+bash+vim (or different implementations of any of them) is concerned, I could use Firefox or Konqueror (or possibly Opera,
          Message 4 of 6 , Jun 25, 2006
          • 0 Attachment
            On Sunday 25 June 2006 00:51, Omer Zak wrote:
            > On Sat, 2006-06-24 at 11:27 +0300, Shlomi Fish wrote:
            > > > > 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.
            > >
            > > Possibly. However, many (most ?) programs will just fire-up vim, joe,
            > > edit.exe or their different idea of a lightweight and convenient command
            > > line editor to write the script (or edit it directly in the shell
            > > prompt), if a one-liner is all they want to write.
            >
            > The search engine can be available in a separate window, say inside a
            > Web browser. It would be open all the time.
            >

            I see. Well, as far as Konsole+bash+vim (or different implementations of any
            of them) is concerned, I could use Firefox or Konqueror (or possibly Opera,
            which I try not to use too much because of its licence) very effectively. If
            Park's online documentation and community will be good enough, which is a
            goal I hope to achieve (and mention in the informal spec), then people can
            use such a browser with some customisations.

            BTW, is anyone aware of anything like "perldoc -f $SOMEFUNC" for Perl
            (e.g: "perldoc -f length" or "perldoc -f open") for different P-languages.
            What I mean is a way to access documentation to individual functions, which
            is very convenient. For perl I'd also like to have something
            like "perldoc --var '$@'" for built-in variables, but this is not applicable
            for Python for instance.

            > > When I said "ready, instant knowledge" I meant knowledge that you do not
            > > have to lookup. For example, when programming Perl, I already know the
            > > syntax for regular expressions, most of the useful functions out of
            > > perlfunc, the operators that I need, etc. Some people know it for Python
            > > or Ruby or PHP or a different language. Part of the reason I'm still
            > > using Perl for my scripts is that looking everything up for a different
            > > language would be more time consuming, so even if the resultant script
            > > would be shorter, it would take me longer to write.
            >
            > Limiting the tools used to write one-liners limits the power of one's
            > one-liners.

            I don't see how. One-liners are things you write using an existing language.
            They are not impossible to do (e.g: the halting problem), probably polynomial
            complexity, within the how-to-do-something knowledge of the programmer, and
            don't require any extraenous knowledge. Obviously, if a programmer only knows
            C (without regexps, etc.) and tries to write a one-liner in it, it'll take
            him quite a while to write. Most Perl one-liners will also probably take a
            while to write with Visual Basic Classic.

            I wouldn't write the same one-liner now that I wrote when I started using
            UNIX, but that's because I'm not as clueless today as I used to be.
            Nevertheless, my one-liners back then were ok for what I needed to do.

            BTW, I (electronically) know someone who writes his one-liners in Haskell.
            However, after I analysed one of his programs (which took me quite a while) I
            found out i had an O(N^2) complexity instead of the optimal O(N). A different
            program I wrote in Haskell, using recursion and matching rules, was in fact
            O(N). He said his program worked for him, etc.

            > My suggestion is about expanding the scope of tools
            > immediately available for this. Especially, example code fragments will
            > be very useful for writing one-liners in a language which is not being
            > frequently used.

            That's right. But I hope Park will be frequently used.

            > And this is very good when a different than usual
            > language needs to be used due to better match of its paradigms and the
            > problem in hand.

            Hmmm... yes.

            >
            > > Guy once posted a message about enhancing the "Unix IDE":
            > >
            > > http://groups.yahoo.com/group/hackers-il/message/3681
            >
            > The task of looking for references and examples is just one of the tasks
            > which Guy's approach would optimize. I claim that optimizing this task
            > has huge payoff.

            Right. I see your point.

            >
            > > > 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.
            > >
            > > Hmmm... wouldn't it still require some work from the programmer? Can you
            > > point to an implementation of this for a different Lisp dialect?
            >
            > I never saw such an implementation.
            >

            OK, this is not very comforting.

            > The programmer has to tell the IDE that he wants to have the macro
            > automatically invoked with certain arguments each time it is modified;
            > and to have the resulting code automatically displayed in a pane.
            >
            > Then it will work somewhat like Watch windows in a debugger IDE (the
            > windows which display variable or register values, which change each
            > time you step through an instruction in a debugger).

            I see. Well, this may require some extra work on part of the programmer. And
            most programmers are lazy (and impatient and hubrisful), and wouldn't want to
            do that. It's like most code out there doesn't have doxygen documentation, or
            much less written using literate programming tools.

            Regards,

            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.