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
  • 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 1 of 6 , Jun 25, 2006
      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.


      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.