It sounds like a joke but it's not (unfortunately). The Java platform
will soon embrace a new programming language known as �Groovy�[1]. It is
designed to be more �agile� like Python or Perl.
According to a member of this JSR[2], Java as same flaws:
"The Java programming language is, simply put, a convenient
abstraction for the real language of the Java platform: byte
code. As a user-friendly abstraction for byte code the Java
programming language is powerful, but it's not omnipotent. There
are circumstances in which a different language, an agile
programming language, is more expressive and productive."
This comes like a public confession about dynamic languages. But
unfortunately, they still try to put Lisp features (like closure and
support for lists) without changing any of Java poor syntax, as a
result, it's just pathetic[2].
You should read the Weblog of Richard Monson-Haefel[3] for all
details.
Have a nice day.
[1] http://groovy.codehaus.org/
[2] http://www.jcp.org/en/jsr/detail?id=241
[3] http://weblogs.java.net/pub/wlg/1125
--
Frederic Brunel
On Wed, 17 Mar 2004 10:13:25 +0100, Frederic Brunel
<···············@in-fusio.com> wrote:
Sounds to me like Jython fit's the bill.
Who needs groovey?
>
> It sounds like a joke but it's not (unfortunately). The Java platform
> will soon embrace a new programming language known as �Groovy�[1]. It is
> designed to be more �agile� like Python or Perl.
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
John Thingstad wrote:
> On Wed, 17 Mar 2004 10:13:25 +0100, Frederic Brunel
> <···············@in-fusio.com> wrote:
>
> Sounds to me like Jython fit's the bill.
> Who needs groovey?
Not Invented Here:
"So why Groovy? Why not Jython or JRuby? Why not one of the dozens of
other programming languages that are designed to run on the Java Virtual
Machine? It's my opinion, and I believe the opinion of those who support
this JSR, that Groovy is the best choice because it was built from the
ground up for the Java Platform and uses syntax that is familiar to Java
developers, while leveraging some of best features that Python, Ruby and
Smalltalk have to offer. Jython and JRuby are excellent examples of how
existing languages can be ported to the Java platform, but they are,
after all, ports. They use syntax that is not designed with Java
developers in mind and they are founded on a completely different set of
code libraries. Groovy is designed for Java developers and its
foundation is the standard APIs of the Java Platform."
-- http://weblogs.java.net/pub/wlg/1125
>
>>
>> It sounds like a joke but it's not (unfortunately). The Java platform
>> will soon embrace a new programming language known as �Groovy�[1]. It is
>> designed to be more �agile� like Python or Perl.
>>
>
>
>
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Frederic Brunel wrote:
> It sounds like a joke but it's not (unfortunately). The Java platform
> will soon embrace a new programming language known as �Groovy�[1]. It is
> designed to be more �agile� like Python or Perl.
>
> According to a member of this JSR[2], Java as same flaws:
>
> "The Java programming language is, simply put, a convenient
> abstraction for the real language of the Java platform: byte
> code. As a user-friendly abstraction for byte code the Java
> programming language is powerful, but it's not omnipotent. There
> are circumstances in which a different language, an agile
> programming language, is more expressive and productive."
>
> This comes like a public confession about dynamic languages. But
> unfortunately, they still try to put Lisp features (like closure and
> support for lists) without changing any of Java poor syntax, as a
> result, it's just pathetic[2].
From what I have read, Bigloo (scheme implementation) also supports JVM
compilation (haven't tried it though).
See http://www-sop.inria.fr/mimosa/fp/Bigloo/ for more details.
Best regards,
Tomek Lipski
Tomek Lipski wrote:
> From what I have read, Bigloo (scheme implementation) also supports JVM
> compilation (haven't tried it though).
> See http://www-sop.inria.fr/mimosa/fp/Bigloo/ for more details.
Bigloo is interesting because it has multiple back ends, including C and
Java bytecode.
There are a number of other good Scheme implementations which target the
JVM:
SISC: http://sisc.sourceforge.net/ - very standards compliant, good
performance, excellent Java integration via multimethods
GNU Kawa: http://www.gnu.org/software/kawa/ - compiles to Java bytecode
JScheme: http://jscheme.sourceforge.net/ - Java integration via "Javadot"
notation, authors include Peter Norvig
The nice thing about using Java as a host platform is that you get access to
a large set of libraries, and can easily integrate with systems that many
companies already have - e.g. deploy an application as a .JAR or .WAR file
that slots right into an existing Java application server.
But, apparently s-exps aren't "Groovy".
Anton
Frederic Brunel wrote:
> It sounds like a joke but it's not (unfortunately). The Java platform
> will soon embrace a new programming language known as �Groovy�[1]. It is
> designed to be more �agile� like Python or Perl.
I was also surprised when I first read this. However, note that this is
"only" a JSR. This doesn't mean that it will get accepted. (Sun has
opened the standardization process to a degree that anyone can submit a
JSR, AFAIK.)
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Pascal Costanza <········@web.de> writes:
> I was also surprised when I first read this. However, note that this
> is "only" a JSR. This doesn't mean that it will get accepted. (Sun has
> opened the standardization process to a degree that anyone can submit
> a JSR, AFAIK.)
Yes, you're right but what I'm pointing out is that they're again
trying to make a new language instead of looking around. And again,
we'll get the same thing based on the same mistakes.
--
Frederic Brunel
From: André Thieme
Subject: Re: The Groovy Programming Language
Date:
Message-ID: <c3amu7$b0u$1@ulric.tng.de>
Frederic Brunel wrote:
> Pascal Costanza <········@web.de> writes:
>
>
>>I was also surprised when I first read this. However, note that this
>>is "only" a JSR. This doesn't mean that it will get accepted. (Sun has
>>opened the standardization process to a degree that anyone can submit
>>a JSR, AFAIK.)
>
>
> Yes, you're right but what I'm pointing out is that they're again
> trying to make a new language instead of looking around. And again,
> we'll get the same thing based on the same mistakes.
Do you have some concrete "mistakes" in mind?
Andr� Thieme <······································@justmail.de> writes:
> Do you have some concrete "mistakes" in mind?
Infix notation?
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
> (dwim x)
NIL
Andr� Thieme <······································@justmail.de> writes:
>> Yes, you're right but what I'm pointing out is that they're again
>> trying to make a new language instead of looking around. And again,
>> we'll get the same thing based on the same mistakes.
>
> Do you have some concrete "mistakes" in mind?
Designing another new language trying to mimic Lisp. Everything
indicates that developers need more flexibility in
programming. They don't see it (or they don't want to), but they
want Lisp. They try to do Lisp without using it's syntax but it's
one of the reason why it works so well.
--
Frederic Brunel
Andr� Thieme wrote:
>> Yes, you're right but what I'm pointing out is that they're again
>> trying to make a new language instead of looking around. And again,
>> we'll get the same thing based on the same mistakes.
>
> Do you have some concrete "mistakes" in mind?
With regard to Java's mistakes, there is a classic rant by Jamie
Zawinski at http://www.jwz.org/doc/java.html
One could argue that at least some of those mistakes were corrected by
Sun afterwards. However, the really important point is this: If Java
were a "real" language, programmers could have fixed them by themselves.
With regard to typical mistakes made when designing new languages: It
doesn't seem to be fashionable (!) to learn from mistakes made in other
languages. Instead, language designers just overrate themselves and
think they can do better than others without actually being able to
measure what "better" means.
A typical mistake made in many scripting languages is that their
designers believe that things should be much simpler than in those
"complicated" and "big" "academic" languages. However by the time, their
languages become more complicated to use because the models we are
trying to build _with_ our languages are in fact complex, and we need to
find complicated workarounds for the oversimplifications made at the
start. The same goes for new versions of such languages because they
need to be backward compatible to a certain extent.
The only way out, as far as I can see, is to have a "programmable"
programming language in which you can change the language itself to
better suit the needs of some concrete problem at hand. Lisp is
certainly not the only language here, but IMHO the most flexible I have
seen so far in that regard.
Note that the "programmability" aspect of Lisp is not some warm and
fuzzy feeling that our community has, but is an objectively stateable
aspect of the essential ingredients of Lisp. So it's a completely
rational choice to go for Lisp. This level of rationalizability strongly
differs from the relatively vague "this syntax is easier to understand
than that syntax". Not that I think the latter consideration is
unimportant, but it boils down to setting the right priorities.
For more information, see http://www.paulgraham.com/rootsoflisp.html
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
From: Joe Marshall
Subject: Re: The Groovy Programming Language
Date:
Message-ID: <wu5ffl08.fsf@comcast.net>
Pascal Costanza <········@web.de> writes:
> With regard to typical mistakes made when designing new languages: It
> doesn't seem to be fashionable (!) to learn from mistakes made in
> other languages. Instead, language designers just overrate themselves
> and think they can do better than others without actually being able
> to measure what "better" means.
As everyone does, I started thinking about language design way back
around 1985. I thought I'd do it differently by actually looking at
prior attempts and comparing them to each other (and it seems that
most designers don't even do *this* much!). I figured that a simple,
powerful core language that minimizes impediments to adding extensions
would be ideal. It would have to be a programmable programming language.
Given these constraints, I kept coming up with Lisp.
--
~jrm
Frederic Brunel <···············@in-fusio.com> writes:
> Pascal Costanza <········@web.de> writes:
>
> > I was also surprised when I first read this. However, note that this
> > is "only" a JSR. This doesn't mean that it will get accepted. (Sun has
> > opened the standardization process to a degree that anyone can submit
> > a JSR, AFAIK.)
>
> Yes, you're right but what I'm pointing out is that they're again
> trying to make a new language instead of looking around. And again,
> we'll get the same thing based on the same mistakes.
This is interesting. A programming 'language' these days seems to be
much more about community and inertia than any particular quality of
the language itself. The phenomenon manifests itself in that bad
languages with a community will get redesigned over and over, instead
of its followers abandoning it for a better language.
Watch the (second!) complete redesign of Perl. You can hear Perl
afficionados explain "yes, I know, {OO, the GC, <whatever>} isn't that
great in the current version of perl, but just wait for Perl 6!". On
comp.lang.c++.moderated I have read several discussions of language
improvements concerning garbage collection and language support for
lambda programming (unnamed functions). Etc.
In all, it seems that someone wanting to take over the world with a
new programming language should focus on creating a community, and a
user base. The language itself can always be improved later. If this
observation is correct, then Paul graham is starting at the completely
wrong end with his Arc, actually focusing on creating a good language.
Bj�rn
·······@nada.kth.se (Bj�rn Lindberg) writes:
> In all, it seems that someone wanting to take over the world with a
> new programming language should focus on creating a community, and a
> user base. The language itself can always be improved later.
So, you're saying, "Worse is better"? ;-)
--
I'm awfully glad I'm a Beta, because I don't work so hard.
·······@nada.kth.se (Bj�rn Lindberg) writes:
> This is interesting. A programming 'language' these days seems to be
> much more about community and inertia than any particular quality of
> the language itself.
Also, people often like to jump into something fresh to get there
ahead of the others who will surely follow. The only progress being
made involves young people getting the chance to have a "founding
influence," and possibly getting to write the first book on the
subject.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
Bj?rn Lindberg <·······@nada.kth.se> wrote:
> Watch the (second!) complete redesign of Perl. You can hear Perl
> afficionados explain "yes, I know, {OO, the GC, <whatever>} isn't that
> great in the current version of perl, but just wait for Perl 6!". On
> comp.lang.c++.moderated I have read several discussions of language
> improvements concerning garbage collection and language support for
> lambda programming (unnamed functions). Etc.
I can't take Perl 6 seriously.
It has an infix operator spelled >>=><<, and another spelled =:= .
I am not making this up.
>><<, >>, and << are three different spellings for MAPCAR depending on
whether the operation you're MAPCARing is infix, postfix, or prefix.
Since => is an infix CONS (it constructs Pair objects), >>=><< is
MAPCAR #'CONS.
=:= is ... wait for it ... EQ.
Again, I am not making this up:
http://www.perl.com/pub/a/2004/03/18/synopsis3.html
Perl 4 looked like C crossed with Unix shellscript.
Perl 6 looks like Perl crossed with Kvikkalkul.
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
From: Joe Marshall
Subject: Re: The Groovy Programming Language
Date:
Message-ID: <k71ffd58.fsf@comcast.net>
"Karl A. Krueger" <········@example.edu> writes:
> I can't take Perl 6 seriously.
To quote the web page,
``Several operators have been given new names to increase clarity
and better Huffman-code the language.''
And we all know how important it is to Huffman code computer languages.
``For example, | becomes either +| or ~| or ?|, depending on whether
the operands are to be treated as numbers, strings, or Boolean
values. Left shift << becomes +< , and correspondingly with right
shift. Unary ~ becomes either +^ or ~^ or ?^, since a bitwise NOT is
like an exclusive-or against solid ones. Note that ?^ is
functionally identical to !. ?| differs from || in that ?| always
returns a standard Boolean value (either 1 or 0), whereas || returns
the actual value of the first of its arguments that is true.''
Perspicuous, eh?
My big fear was that with redesign they might just fix enough of the
language to make it difficult to ridicule, but it seems my fears were
unfounded.
--
~jrm
Joe Marshall <·············@comcast.net> writes:
> "Karl A. Krueger" <········@example.edu> writes:
>
>> I can't take Perl 6 seriously.
>
> To quote the web page,
> ``Several operators have been given new names to increase clarity
> and better Huffman-code the language.''
>
> And we all know how important it is to Huffman code computer languages.
>
> ``For example, | becomes either +| or ~| or ?|, depending on whether
> the operands are to be treated as numbers, strings, or Boolean
> values. Left shift << becomes +< , and correspondingly with right
> shift. Unary ~ becomes either +^ or ~^ or ?^, since a bitwise NOT is
> like an exclusive-or against solid ones. Note that ?^ is
> functionally identical to !. ?| differs from || in that ?| always
> returns a standard Boolean value (either 1 or 0), whereas || returns
> the actual value of the first of its arguments that is true.''
>
> Perspicuous, eh?
>
> My big fear was that with redesign they might just fix enough of the
> language to make it difficult to ridicule, but it seems my fears were
> unfounded.
Well this could kill perl6, 5.X will be around for years though and they
might be forced to reopen active development on it by the community.
marc
Joe Marshall <·············@comcast.net> wrote:
> "Karl A. Krueger" <········@example.edu> writes:
>> I can't take Perl 6 seriously.
>
> To quote the web page,
> ``Several operators have been given new names to increase clarity
> and better Huffman-code the language.''
>
> And we all know how important it is to Huffman code computer languages.
Heh. I think that was a throw-in.
> ``For example, | becomes either +| or ~| or ?|, depending on whether
> the operands are to be treated as numbers, strings, or Boolean
> values. Left shift << becomes +< , and correspondingly with right
> shift. Unary ~ becomes either +^ or ~^ or ?^, since a bitwise NOT is
> like an exclusive-or against solid ones. Note that ?^ is
> functionally identical to !. ?| differs from || in that ?| always
> returns a standard Boolean value (either 1 or 0), whereas || returns
> the actual value of the first of its arguments that is true.''
>
> Perspicuous, eh?
The thing is, Perl folks appear to be stuck with their decision to
locate types in "context" rather than on variables (where static-typists
put them) or values (where dynamic-typists put them). This means that
if you want to have four operators that are kind of like "binary or"
but treat their inputs as different types, you can't call them all "|".
Perl "context" is a bit of a fuzzy idea to begin with. It's as if
someone who'd never heard of type inferencing tried to invent it, while
retaining the Tcl-ish idea that string "42" and integer 42 should be the
same value.
Put another way, it's the opposite of multiple method dispatch -- it's
multiple argument dispatch! Instead of the method being selected
according to the types of its arguments, the meaning of an argument is
selected according to the types expected by functions. Functions have
all the power, values have none. That's what "functional programming"
means, right? :)
> My big fear was that with redesign they might just fix enough of the
> language to make it difficult to ridicule, but it seems my fears were
> unfounded.
Perl's going to continue losing low-end Web-coder types to PHP and
higher-end rapid-development types to Python for some time to come. On
the other hand, anyone who remembers APL may well flock to Perl 6. Did
you notice that you can enter that << operator as the Unicode character
for a European left double-angle-quote? Perl 6 is the first language I
know of since APL to encourage a non-ASCII character set for code. :)
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
<SNIPPO />
> In all, it seems that someone wanting to take over the world with a
> new programming language should focus on creating a community, and a
> user base.
Funny you would mention it -- this is exactly what sun
has done with Java. The hype the company started as
early as 1994 would have made George Lucas proud.
> The language itself can always be improved later. If this
> observation is correct, then Paul graham is starting at the completely
> wrong end with his Arc, actually focusing on creating a good language.
Languages that don't suck will be rejected by
the market. Perhaps Sun screwed up Java deliberately?
>
>
> Bj�rn
Pascal Costanza wrote:
> Frederic Brunel wrote:
>
>> It sounds like a joke but it's not (unfortunately). The Java platform
>> will soon embrace a new programming language known as �Groovy�[1]. It is
>> designed to be more �agile� like Python or Perl.
>
> I was also surprised when I first read this. However, note that this is
> "only" a JSR. This doesn't mean that it will get accepted. (Sun has
> opened the standardization process to a degree that anyone can submit a
> JSR, AFAIK.)
Now, I am even more surprised. They have accepted it. Even Sun voted
"yes". Wow.
Perhaps someone should submit a Common Lisp JSR. ;)
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Pascal Costanza wrote:
>
> Pascal Costanza wrote:
>
>> Frederic Brunel wrote:
>>
>>> It sounds like a joke but it's not (unfortunately). The Java platform
>>> will soon embrace a new programming language known as �Groovy�[1]. It is
>>> designed to be more �agile� like Python or Perl.
>>
>>
>> I was also surprised when I first read this. However, note that this
>> is "only" a JSR. This doesn't mean that it will get accepted. (Sun has
>> opened the standardization process to a degree that anyone can submit
>> a JSR, AFAIK.)
>
>
> Now, I am even more surprised. They have accepted it.
Game over.
> Even Sun voted
> "yes". Wow.
"Static typing? Never mind!" -- Gilda Radner
>
> Perhaps someone should submit a Common Lisp JSR. ;)
:) Good idea. But just make it macros. That'll nail their coffin nicely.
The bad news is that if Peter does not hurry up with his book it will be
a book on...Java! Doh!
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
>> Perhaps someone should submit a Common Lisp JSR. ;)
>
> :) Good idea. But just make it macros. That'll nail their coffin nicely.
Hmm, perhaps we shouldn't joke too much about these things. See
http://wiki.codehaus.org/groovy/ExtensibleLanguageConstructs
Pascal
--
ECOOP 2004 Workshops - Oslo, Norway
*1st European Lisp and Scheme Workshop, June 13*
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
*2nd Post-Java Workshop, June 14*
http://prog.vub.ac.be/~wdmeuter/PostJava04/
Pascal Costanza wrote:
> Kenny Tilton wrote:
>
>>> Perhaps someone should submit a Common Lisp JSR. ;)
>>
>>
>> :) Good idea. But just make it macros. That'll nail their coffin nicely.
>
>
> Hmm, perhaps we shouldn't joke too much about these things. See
> http://wiki.codehaus.org/groovy/ExtensibleLanguageConstructs
Indeed:
"Folks who like languages like Lisp, Self and Smalltalk often talk about
how cool it is to grow the language with new constructs. Well we don't
support powerful macros yet but ....<snip lame alternative>"
Damn. Lisp is no longer the crazy aunt in the attic, she is now out in
the front parlor where her admirers come to pay respect and learn.
"Several people are working on Scheme-style macro systems for Java; the
furthest-advanced is probably JSE (http://jse.sourceforge.net/). This
would be a tremendous addition to Groovy..."
Unthinkable. "tremendous addition"=>"done deal". As language wars go,
this feels like the break-up of the Soviet Union. And...
Doh! Steele knew what he was doing all along!! Game over.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Never herd lisp refered to quite that way before!
rlol
On Wed, 31 Mar 2004 16:28:35 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
> Damn. Lisp is no longer the crazy aunt in the attic, she is now out in
> the front parlor where her admirers come to pay respect and learn.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
John Thingstad wrote:
> Never herd lisp refered to quite that way before!
> rlol
Gotta give credit where it's due: " The debt is like a crazy aunt we
keep down in the basement." -- H. Ross Perot
I moved the old girl up to the attic where it's not so damp. :)
kt
>
> On Wed, 31 Mar 2004 16:28:35 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>
>> Damn. Lisp is no longer the crazy aunt in the attic, she is now out in
>> the front parlor where her admirers come to pay respect and learn.
>
>
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Frederic Brunel wrote:
> It sounds like a joke but it's not (unfortunately). The Java platform
> will soon embrace a new programming language known as �Groovy�[1]. It is
> designed to be more �agile� like Python or Perl.
Ah, fascinating. Thx for the links. The wheels are really coming off the
static model.
>
> According to a member of this JSR[2], Java as same flaws:
>
> "The Java programming language is, simply put, a convenient
> abstraction for the real language of the Java platform: byte
> code. As a user-friendly abstraction for byte code the Java
> programming language is powerful, but it's not omnipotent. There
> are circumstances in which a different language, an agile
> programming language, is more expressive and productive."
>
> This comes like a public confession about dynamic languages. But
> unfortunately, they still try to put Lisp features (like closure and
> support for lists) without changing any of Java poor syntax, as a
> result, it's just pathetic[2].
One of your links mentions that the similar syntax empowers the
refactoring tools. A response lower down was that you know you have been
doing Java too long when you start designing the language around
refactoring tools. :)
I wouldn't be discouraged. The plan is working. Python and Ruby have
infected the Body Static. They cannot give a nod to Lisp because it
would be just too damn embarrassing.
Now if only Lisp had a GUI!
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Now if only Lisp had a GUI!
If someone could just get around to designing one...
Also standard threading and networking APIs.
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
> (dwim x)
NIL
From: André Thieme
Subject: Re: The Groovy Programming Language
Date:
Message-ID: <c3an0f$b0u$2@ulric.tng.de>
Kenny Tilton wrote:
> Now if only Lisp had a GUI!
A GUI alone is not enough. It should be fast and easy to use and support
all "modern stuff" one expects to be in a GUI.
From: ··········@YahooGroups.Com
Subject: Re: The Groovy Programming Language
Date:
Message-ID: <REM-2004mar17-001@Yahoo.Com>
> Kenny Tilton wrote:
> > Now if only Lisp had a GUI!
> A GUI alone is not enough. It should be fast and easy to use and
> support all "modern stuff" one expects to be in a GUI.
I propose that we list what a modern GUI is expected to do.
Here are some specific things I've found that I liked and wish were
always available:
- Alto/Dorado/Macintosh: GUI file manager: Icons on "desktop" and in
folders, which can be dragged around to move or copy, and can be
clicked to get information or to start running program or to examine
document via whatever editor is linked to it.
- HyperCard/VisualBasic: Drag-and-drop editor for designing dialogs
(windows with controls, used as control panels for application
programs), both the physical/visual layout of various controls and the
scripts/software associated with each control, in the style of
SmallTalk/OO message passing or event handling.
- Info(my1975)/EmacsInfoMode(RMS)/HyperCard/WWW: Links from one
info-frame to another to support browsing information nets just by
clicking on links which appear on-screen as hot text.
- Emacs/MacintoshAllegroCommonLISP/VisualC++/VisualBasic: Smart editors
for specific file formats such as source-code in specific programming
languages. Live interaction between source-edit window and run-program
window, both ability to click on source expression and have it passed
to run window for immediate execution, and ability of running program
to perform automated edit of text in other window.
That's all I can think of at the moment. Others here, please suggest
other very different features of a GUI that you've come to value and
always want.
One thing I've never seen but would like is data pipelining, like the
Unix pipe between processes except it'd be done by drawing a line
between output and input ports of icons of processes rather than
writing | syntax between text descriptions of processes.
Also it'd be nice if the Macintosh idea of having a program associated
with a document, which can in some cases be a scripting language
associated with a script, could be extended to mulitple levels. So for
example, for the programming system Common LISP, we could have a script
which is an application program, but then we could have a document that
is to be used as input for that program, so double-clicking on the
document would start CL then load the application script then start
running that application with the document as standard input. Or
shift-clicking on both the script and the document (to select them both
simultaneously) then double-clicking would do the same thing except you
wouldn't have to link the document to the script ahead of time. Or you
could double-click on the application, which would ask for first input
file and let you specify it merely by clicking on the document's icon,
then ask for second input file and likewise you specify it by clicking
on that document's icon. Or you could build a process by clicking on
the script, which would show you that it needs two input files, and
show a process window into which you drag the icons of those two files.
Then when the process is done, the output file is in the process
window, and you drag and optionally rename it to whereever you want it
to end up before you close the process window.
<··········@YahooGroups.Com> wrote:
+---------------
| One thing I've never seen but would like is data pipelining, like the
| Unix pipe between processes except it'd be done by drawing a line
| between output and input ports of icons of processes rather than
| writing | syntax between text descriptions of processes.
+---------------
Google for "ProGraph", a language which did exactly that, with relational
databases as well as low-level constructs. Hmmm... In fact, you might find
<URL:http://www.informatik.uni-kiel.de/inf/Kluge/calendar/program.html#7>
and/or <URL:http://www.tidbits.com/tb-issues/TidBITS-312.html#lnk7> to be
interesting.
Actually, there's been *lot* of work in the area of "visual" programming
languages. <URL:http://www-2.cs.cmu.edu/~wjh/papers/bakeoff.html> has a
lot of nice cute pictures of various languages (circa 1994).
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
··········@YahooGroups.Com wrote:
>>Kenny Tilton wrote:
>>
>>>Now if only Lisp had a GUI!
>>
>>A GUI alone is not enough. It should be fast and easy to use and
>>support all "modern stuff" one expects to be in a GUI.
>
>
> I propose that we list what a modern GUI is expected to do.
> Here are some specific things I've found that I liked and wish were
> always available:
> - Alto/Dorado/Macintosh: GUI file manager: Icons on "desktop" and in
> folders, which can be dragged around to move or copy, and can be
> clicked to get information or to start running program or to examine
> document via whatever editor is linked to it.
Hmmm... Yes, the file manager provides a graphical user interface to the
file system, using some GUI framework such as Allegro Common Graphics
and Lispworks CAPI. I am thinking about the framework, not specific
applications thereof. So in the above I see one item for my do-list,
viz., drag-and-drop.
I think you are talking about the Lisp OS project we should be getting
on with it as soon as we have standardized on Cello.
> - HyperCard/VisualBasic: Drag-and-drop editor for designing dialogs
God, no, we have enough carpal tunnel as it is. What works better are
text files in which one codes up smart containers that automatically
arrange things, allowing overrides any time you need them.
Cello has stacks, rows, and grids, with left, right, top, bottom, or
center alignment and parameters for spacing and outset (a margin around
the contained children. That's what I use 90% of the time. Standard
stuff any GUI offers. The other 10% is where things get dynamic and
should react to the semantics of what is going on. With Cello that is as
easy as the stacks/rows stuff.
> (windows with controls, used as control panels for application
> programs), both the physical/visual layout of various controls and the
> scripts/software associated with each control, in the style of
> SmallTalk/OO message passing or event handling.
Ya lost me.
> - Info(my1975)/EmacsInfoMode(RMS)/HyperCard/WWW: Links from one
> info-frame to another to support browsing information nets just by
> clicking on links which appear on-screen as hot text.
check.
> - Emacs/MacintoshAllegroCommonLISP/VisualC++/VisualBasic: Smart editors
> for specific file formats such as source-code in specific programming
> languages. Live interaction between source-edit window and run-program
> window, both ability to click on source expression and have it passed
> to run window for immediate execution, and ability of running program
> to perform automated edit of text in other window.
Inter-widget communication? Cells are all over that.
>
> That's all I can think of at the moment. Others here, please suggest
> other very different features of a GUI that you've come to value and
> always want.
>
> One thing I've never seen but would like is data pipelining, like the
> Unix pipe between processes except it'd be done by drawing a line
> between output and input ports of icons of processes rather than
> writing | syntax between text descriptions of processes.
A consensus is growing amongst the algorithmic music crowd I run with
now as part of the Lisp-NYC music SIG: graphical programming sucks. It's
cute as the dickens when you draw one line. Do some real programming and
by the time your wrists lock up the screen gives new meaning to
spaghetti code.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> A consensus is growing amongst the algorithmic music crowd I run with
> now as part of the Lisp-NYC music SIG: graphical programming
> sucks. It's cute as the dickens when you draw one line. Do some real
> programming and by the time your wrists lock up the screen gives new
> meaning to spaghetti code.
I discovered how much this sucks about 13 years ago. It wasn't exactly
_programming_, but the principle is the same:
My wife was doing some statistical work for her master thesis in
sociology. She tried to use an apparently cute tool for the mac that
took GUI to the extreme. E.g. you would create cross-tabulations with
chi-quadrat tests by dropping icons representing your data on each
other (or something like that, my memory is a bit vague).
Since she had collected a whole lot of data, we discovered that this
would probably keep her dragging and dropping things on our Mac SE for
an indefinite time, so I quickly solved the problem by writing a cute
little extension of MCLs FRED that helped her enter her data in a safe
and easy way, and then I added a little code to produce the tables in
good-looking rtf-format. Her interface to the whole thing then was the
MCL lisp-listener and FRED windows, and a few hours of fun lisp
hacking for me saved her _weeks_ of work :-)
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Since she had collected a whole lot of data, we discovered that this
> would probably keep her dragging and dropping things on our Mac SE for
> an indefinite time, so I quickly solved the problem by writing a cute
> little extension of MCLs FRED that helped her enter her data in a safe
> and easy way, and then I added a little code to produce the tables in
> good-looking rtf-format. Her interface to the whole thing then was the
> MCL lisp-listener and FRED windows, and a few hours of fun lisp
> hacking for me saved her _weeks_ of work :-)
Yes, that's about the ratio. Some work done in a GUI word processor
for three hours by a clueless user took me 5 minutes of shell
scripting...
The GUI is a scheme to keep unemployment numbers low.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> The GUI is a scheme to keep unemployment numbers low.
I thought it was a conspiracy on the part of physical therapists
everywhere. If your theory is right: my god, all that RSI, and it
doesn't even work!
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: ··········@YahooGroups.Com
Subject: Re: The Groovy Programming Language
Date:
Message-ID: <REM-2004mar31-003@Yahoo.Com>
> From: Kenny Tilton <·······@nyc.rr.com>
> Yes, the file manager provides a graphical user interface to the file
> system, using some GUI framework such as Allegro Common Graphics and
> Lispworks CAPI. I am thinking about the framework, not specific
> applications thereof. So in the above I see one item for my do-list,
> viz., drag-and-drop.
Yes, "Finder" (the GUI file manager on Macintosh), and the equivalent
on MS-Windows-recent (but not the very old version I tried several
years ago), does have drag-and-drop to move or copy a file or folder
from one folder or device to another. And it has shift-click or
drag-around-group to select more than one item for drag-and-drop next.
But sometimes it's more convenient to select one or more items then
issue a menu or keyboard command instead of drag-and-drop, so that
variant should be on your list too. (For example clover-I = Get Info on
Macintosh.) Also, not implemented there, but which would be useful,
would be to more-permanently select an icon (of a file or folder) so
that you can then browse several different folders and more-permanently
select more icons there too, and finally drag or command the whole
batch at one time. In lieu of that, I often have to drag several items
from different places into a "staging area", a temporary folder, and
then when I've assembled them all there, finally drag-around-group (or
clover-A to select all) and do the operation I wanted.
> > - HyperCard/VisualBasic: Drag-and-drop editor for designing dialogs
> ... no, we have enough carpal tunnel as it is. What works better are
> text files in which one codes up smart containers that automatically
> arrange things, allowing overrides any time you need them.
That's basically the way I set up dialogs in Macintosh Allegro
CommonLISP before my Mac Plus died. If I wanted to override anything, I
needed to explicitly add code to move the last (mis)-placed item to
where I really want it before letting it proceed to default-place the
next item. It took several minutes to do the whole process of
(dialog-item-position <ditem>) -> h,v
then copy&paste the result into
(set-dialog-item-position <ditem> h v)
and keep fudging the x and y values until I liked the position. It
would be nicer to be able to drag the dialog item directly to near the
desired position, then use arrow keys to nudge it one pixel at a time
until I had it exactly right. I think best-of-both-worlds, i.e. default
but a way to directly drag and nudge the object, and the dialog-create
code gets automatically modified to have the correct call to
set-dialog-item-position from where I left it by nudging. Or maybe the
process of creating each dialog item and assigning a corresponding
temporary/local label, and deciding where to position it within the
dialog, should be split into two sections, so that the overriding
defaults of postion is pure data that is easier to automatically
update.
> > (windows with controls, used as control panels for application
> > programs), both the physical/visual layout of various controls and the
> > scripts/software associated with each control, in the style of
> > SmallTalk/OO message passing or event handling.
> Ya lost me.
First of all, when I originally conceived the idea of software control
panels, as a variation on what I saw on StarTrek in 1966..., the idea
was a touch-screen (because I'd never heard of a mouse on a computer at
that time), but later when I saw the computers at Xerox-PARC, of course
the idea transformed. In either case, the idea is that you control a
device or program by a software-emulated control panel rather than a
physical control panel, so that it's easy to reconfigure the control
panel either to make upgrades or in the process of normal operation in
different modes. Nowadays these are called "dialogs" for this reason:
Unfortunately Apple Computer Inc. usurped the term "control panel" to
mean strictly the dialogs which control the system software itself, not
J. Random application program. The control panels, per Macintosh
jargon, are only those accessible from the Control Panel entree in the
Apple menu, not the very similar dialogs put up by ordinary programs.
We seem to be stuck with System control panels being the only ones we
can call "Control Panels", while all application-program control panels
must be called "Dialogs" instead.
Anyway, the way these "dialogs" are set up in HyperCard (where they are
called "cards" or "backgrounds" instead) and MACL and VB, there's a
visual representation of the dialog-item (called a "control" in VB),
complete with all the parameters of that visual representation
(position, type, mode, color, font, name, etc.), and separate from that
there's a script telling how that dialog item (control) handles various
events. (In HyperCard these event-handling script are attached to the
dialog-item. In VB there's one master script for the entire dialog
which lists all the event handlers for all the controls in the dialog.
MACL has a rather limited view of all this, namely an object function
called dialog-item-action which is invoked when the dialog-item is
clicked. But the basic idea of dialog items handling events is the same
in all three programming environments. SmallTalk seems to be the
original programming system that had event handlers associated with
software objects. So does what I wrote make sense now?
> Inter-widget communication? Cells are all over that.
Where might I find a plain-text Web-accessible introduction to that?
(Unfortunatley "cells" is a common word in microbiology, and cellular
automata theory, and cellphone jargon, and penal (jail/prison) jargon,
etc., so a Google/Yahoo search is likely to be frustrating.)
> graphical programming sucks. It's cute as the dickens when you draw
> one line. Do some real programming and by the time your wrists lock
> up the screen gives new meaning to spaghetti code.
I'd like to try various graphical programming systems and see how I
feel about them. Maybe there's some obvious flaw in their designs.
Or maybe the whole idea sucks as you say. I want to decide for myself.
··········@YahooGroups.Com wrote:
>>Inter-widget communication? Cells are all over that.
>
>
> Where might I find a plain-text Web-accessible introduction to that?
the tilton-technology link in my sig, or:
http://home.comcast.net/~bc19191/2003_09_07_bill-clementson_archive.html
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Erik Winkels
Subject: Re: The Groovy Programming Language
Date:
Message-ID: <87znae8pcu.fsf@xs4all.nl>
··········@YahooGroups.Com wrote on Wed, 17 Mar 2004 23:01:52 -0800:
>
> One thing I've never seen but would like is data pipelining, like
> the Unix pipe between processes except it'd be done by drawing a
> line between output and input ports of icons of processes rather
> than writing | syntax between text descriptions of processes.
Something like this?:
http://bioinformatics.org/piper/screenshots/index.html/
(now a defunct project)
Erik
Andr� Thieme wrote:
> Kenny Tilton wrote:
>
>> Now if only Lisp had a GUI!
>
>
> A GUI alone is not enough. It should be fast and easy to use and support
> all "modern stuff" one expects to be in a GUI.
This is Lisp. It should be faster, easier to use, and more powerful than
any GUI available for any other language. The way CLOS simply crushes
the competition.
kenneth
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> I wouldn't be discouraged. The plan is working. Python and Ruby have
> infected the Body Static. They cannot give a nod to Lisp because it
> would be just too damn embarrassing.
That's the positive thing about all that... Static-turned mind
starts to change (Bruce Eckel for example)... Actually, one of the
great thing about Java is that it made the garbage collection
accepted in the industry as well as the fact that raw performances
are not so important (well, you know what I mean! :)).
--
Frederic Brunel
Frederic Brunel <···············@in-fusio.com> writes:
> It sounds like a joke but it's not (unfortunately). The Java
> platform will soon embrace a new programming language known as
> �Groovy�[1]. It is designed to be more �agile� like Python or Perl.
[...]
I read recently (don't have an URI) that Groovy was 'inspired' by
Dylan (the language). Dylan was created at Apple and was in turn
inspired by Lisp.
Is this how the family tree goes?
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
David Magda wrote:
> Frederic Brunel <···············@in-fusio.com> writes:
>
>
>>It sounds like a joke but it's not (unfortunately). The Java
>>platform will soon embrace a new programming language known as
>>�Groovy�[1]. It is designed to be more �agile� like Python or Perl.
>
> [...]
>
> I read recently (don't have an URI) that Groovy was 'inspired' by
> Dylan (the language). Dylan was created at Apple and was in turn
> inspired by Lisp.
>
> Is this how the family tree goes?
Interesting, thx:
http://lists.codehaus.org/pipermail/groovy-dev/2003q4/000307.html
Game over.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
More from:
http://lists.codehaus.org/pipermail/groovy-dev/2004q1/000723.html
>> done. But most important, static types are useful for an IDE to
>> provide context-based code completion and automatic refactorings.
>
> Agreed.
So they are working an order of magnitude slower so they do not have to
know the fields of data structures they are using and so they can...
work (refactor) faster? Please check your arithmetic. I guess the other
thing is that this is the problem with winning thru billyuns and
billyuns of libraries -- no one knows the tools they are using.
Groovy so far very much has the feel of Ruby with optional
> static typing & type-based method overloading. It actually turns out
> Groovy is more like Dylan conceptually with a Java-Ruby blended syntax
> which still looks surprisingly like normal Java IMHO
>
>
>> For me, Dylan means generic functions with multi methods. This is a
>> nice and powerful concept ...
there is hope!
but it might be a challenge to find a good
>> way to interface with "legancy code", that is the Java class library.
>> And I wouldn't want to write show(frame) instead of frame.show().
what is the the thing.method() syntax for multimethods? maybe:
(thing, otherThing).show
>
> Agreed. Whilst multi-methods are academically cool; I'm not yet
> convinced we should go there for Groovy.
"academically cool"? as opposed to..."what I already know" cool?
>
>
>> If anybody happens to know Cecil (one of my favorite language although
>> I never wrote a single line in that language), it also features
>> generic methods with multi methods. They define that a.b is actually
>> just syntactic sugar for b(a) and a.b = c for b-setter(a, c).
>>
>> The (as I'd call it) original Dylan with the Lisp-like syntax was IMHO
>> esthetically pleasing,
we have just been picked up on radar!!
but the current Dylan with Pascal-like has too
>> much syntax for my taste. I prefer languages with less syntax. Ruby
>> seems to be a good compromise. Smalltalk or Lisp might have be a
>> little bit over the line and start to sacrify readablity for purity.
>
> Agreed
>
> James
oh, well, it was fun while it lasted. i better get back to this Cello
code. just wish I could read the over-the-line purely crap.
kenneth
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> More from:
>
> http://lists.codehaus.org/pipermail/groovy-dev/2004q1/000723.html
<snip>
> > Agreed. Whilst multi-methods are academically cool; I'm not yet
> > convinced we should go there for Groovy.
>
> "academically cool"? as opposed to..."what I already know" cool?
Kenny, you multimethod-loving hippy, you can now consider yourself
officially tarred as an academic! How's the view from up there in the ivory
tower?!
Anton
Anton van Straaten wrote:
> Kenny Tilton wrote:
>
>>More from:
>>
>> http://lists.codehaus.org/pipermail/groovy-dev/2004q1/000723.html
>
> <snip>
>
>>>Agreed. Whilst multi-methods are academically cool; I'm not yet
>>>convinced we should go there for Groovy.
>>
>>"academically cool"? as opposed to..."what I already know" cool?
>
>
> Kenny, you multimethod-loving hippy, you can now consider yourself
> officially tarred as an academic! How's the view from up there in the ivory
> tower?!
I am just picking up my mail. Come back with that question during my
office hours.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
A taste of the Groovy REPL:
Lets get Groovy!
================
Version: 1.0-beta-4 JVM: 1.4.2_03-b02
Type 'exit' to terminate the shell
Type 'help' for command help
1> 1+2
... no answer
2> go
... blank answer
1> println 1+2
... no answer
2> go
3 ... success!
1> println 256*256*256*256
2> go
0
1> 1000000000000+1
2> go
>>> a serious error occurred: (class: CommandLine1, method: run signature: ()Ljava/lang/Object;) Expecting to find integer on stack
>>> stacktrace:
java.lang.VerifyError: (class: CommandLine1, method: run signature: ()Ljava/lang/Object;) Expecting to find integer on stack
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:1610)
at java.lang.Class.getConstructor0(Class.java:1922)
at java.lang.Class.newInstance0(Class.java:278)
at java.lang.Class.newInstance(Class.java:261)
at org.codehaus.groovy.runtime.InvokerHelper.createScript(InvokerHelper.java:337)
at groovy.lang.GroovyShell.parse(GroovyShell.java:281)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:268)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:230)
at groovy.ui.InteractiveShell.run(InteractiveShell.java:145)
at groovy.ui.InteractiveShell.main(InteractiveShell.java:88)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.codehaus.classworlds.Launcher.launchStandard(Launcher.java:410)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:344)
at org.codehaus.classworlds.Launcher.main(Launcher.java:474)
>>> exiting
Regards,
Adam
Hi Frederic Brunel,
> This comes like a public confession about dynamic languages. But
> unfortunately, they still try to put Lisp features (like closure and
> support for lists) without changing any of Java poor syntax, as a
> result, it's just pathetic[2].
Not quite. It's a whitespace sensitive language with optional semicolons.
This is a valid Groovy program:
['Print', 'out', 'a', 'list', 'of', 'strings'].each {println it}
And so is this:
['Print', 'out', 'a', 'list', 'of', 'strings'].each {
println it
}
But this one isn't:
['Print', 'out', 'a', 'list', 'of', 'strings'].each
{println it}
Nor this one:
['Print', 'out', 'a', 'list', 'of', 'strings'].each
{
println it
}
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> But this one isn't:
>
> ['Print', 'out', 'a', 'list', 'of', 'strings'].each
> {println it}
Yuck, and that's supposed to be /groovy/?
--
(espen)
Espen Vestre wrote:
> Adam Warner <······@consulting.net.nz> writes:
>
>
>>But this one isn't:
>>
>>['Print', 'out', 'a', 'list', 'of', 'strings'].each
>> {println it}
>
>
> Yuck, and that's supposed to be /groovy/?
I am reminded of Gregor Kiczales (sp?) at ILC 2003 displaying some
AspectJ to a silent crowd, pausing, then plaintively adding, "When I
show that to Java programmers they stand up and cheer."
The above is like a gawdy Lisp GUI screen shot running on win32 and
linux -- how it looks misses the point: it is /running/. The rest is easy.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> I am reminded of Gregor Kiczales (sp?) at ILC 2003 displaying some
> AspectJ to a silent crowd, pausing, then plaintively adding, "When I
> show that to Java programmers they stand up and cheer."
Ouch. That moment was quite embarassing, I think. But I guess the
audience had very high expectations. I hadn't heard Gregor talk
since at Xerox PARC more than 15 years ago and was really eager
to learn about his AOP stuff. If I was silent, I was probably
paralyzed by the ugliness of those syntax-based hacks :-(
--
(espen)
Kenny Tilton <·······@nyc.rr.com> writes:
> I am reminded of Gregor Kiczales (sp?) at ILC 2003 displaying some
> AspectJ to a silent crowd, pausing, then plaintively adding, "When I
> show that to Java programmers they stand up and cheer."
Humm. AspectJ looks like just the sort of thing "Java programmers"
would like, and I wouldn't, because it can add complications
everywhere and make it harder to figure out what code actually
does -- and in the Java world that would actually happen. I can
already imagine some nightmare "patterns" it could lead to. :(
I say this as someone who has made fairly extensive used of advice in
Lisp, e.g. to add tracing and stepping to an event/message-based
system, as well as, :before, :after, and :around methods.
(This is not to say there couldn't be some very good uses of
AspectJ. I can also think of some things I would use it for,
and some good patterns.)
-- jd
Hi Espen Vestre,
>> But this one isn't:
>>
>> ['Print', 'out', 'a', 'list', 'of', 'strings'].each
>> {println it}
>
> Yuck, and that's supposed to be /groovy/?
1> { println "Hello" }.call()
2> go
Hello
1> { println [1, 2, 3] }.call()
2> go
null
1> { println([1, 2, 3]) }.call()
2> go
[1, 2, 3]
Have fun,
Adam
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Yuck, and that's supposed to be /groovy/?
/grotty/ is more like it...
--
··········@acm.org phone:+49-7031-464-7698 (TELNET 778-7698)
http://www.bawue.de/~jjk/ fax:+49-7031-464-7351
As the air to a bird, or the sea to a fish,
so is contempt to the contemptible. [Blake]
Hi Frederic Brunel,
> This comes like a public confession about dynamic languages. But
> unfortunately, they still try to put Lisp features (like closure and
> support for lists) without changing any of Java poor syntax, as a
> result, it's just pathetic[2].
Not quite. It's partly a whitespace sensitive language with optional
semicolons.
This is a valid Groovy program:
['Print', 'out', 'a', 'list', 'of', 'strings'].each {println it}
And so is this:
['Print', 'out', 'a', 'list', 'of', 'strings'].each {
println it
}
But this one isn't:
['Print', 'out', 'a', 'list', 'of', 'strings'].each
{println it}
Nor this one:
['Print', 'out', 'a', 'list', 'of', 'strings'].each
{
println it
}
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> This is a valid Groovy program ...
> But this one isn't:
>
> ['Print', 'out', 'a', 'list', 'of', 'strings'].each
> {println it}
> Nor this one:
>
> ['Print', 'out', 'a', 'list', 'of', 'strings'].each
> {
> println it
> }
Oh - my - God.
What is the logic behind that?
-- jd
On Thu, 01 Apr 2004 18:30:20 +0100, Jeff Dalton wrote:
> What is the logic behind that?
To (mis-) quote Tina Turner, "What's logic got to do with it, got to do
with it?".
What is this logic of which you speak!? The language is new! It's
trendy! It's hip!! It's GROOOOOOOOOOVYYYYYYY!!!!!
Look at the shiny monkey, damnit!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
faa
Jeff Dalton wrote:
> Adam Warner <······@consulting.net.nz> writes:
>
>
>>This is a valid Groovy program ...
>
>
>>But this one isn't:
>>
>>['Print', 'out', 'a', 'list', 'of', 'strings'].each
>> {println it}
>
>
>>Nor this one:
>>
>>['Print', 'out', 'a', 'list', 'of', 'strings'].each
>>{
>> println it
>>}
>
>
> Oh - my - God.
>
> What is the logic behind that?
The same logic that gave us ... in Matlab, '*' in the 6th (or 5th)
column in Fortran, 'Tab' in make and in.... you know what :)
Cheers
--
marco
Marco Antoniotti <·······@cs.nyu.edu> writes:
> The same logic that gave us ... in Matlab, '*' in the 6th (or 5th)
> column in Fortran, 'Tab' in make and in.... you know what :)
Meaning, that's incompetence at writting a parser.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
From: Joe Marshall
Subject: Re: The Groovy Programming Language
Date:
Message-ID: <brmbgykw.fsf@ccs.neu.edu>
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> Adam Warner <······@consulting.net.nz> writes:
>
>> This is a valid Groovy program ...
>
>> But this one isn't:
>>
>> ['Print', 'out', 'a', 'list', 'of', 'strings'].each
>> {println it}
>
>> Nor this one:
>>
>> ['Print', 'out', 'a', 'list', 'of', 'strings'].each
>> {
>> println it
>> }
>
> Oh - my - God.
>
> What is the logic behind that?
Appeal to Perl lovers.
Hi Jeff Dalton,
> Adam Warner <······@consulting.net.nz> writes:
>
>> This is a valid Groovy program ...
>
>> But this one isn't:
>>
>> ['Print', 'out', 'a', 'list', 'of', 'strings'].each
>> {println it}
>
>> Nor this one:
>>
>> ['Print', 'out', 'a', 'list', 'of', 'strings'].each
>> {
>> println it
>> }
>
> Oh - my - God.
>
> What is the logic behind that?
It removes parentheses from the syntax. It's a widespread condition known
as parenthophobia and it's believed to be highly contagious.
<http://groovy.codehaus.org/faq.html#newline-before-brace>
Things work if I use Suns conventions and put { on the same line, but
if I add a new line things break?
When using closures with method calls we have some syntax sugar in
Groovy which is sensitive to whitespace (newlines to be precise).
Please see this description in common gotchas for a full description
<http://groovy.codehaus.org/javadiff.html>
For example the following is valid groovy
[1, 2, 3].each { println it }
However if you want to specify the { on a separate line then you must
use the more verbose parentheses version like this
[1, 2, 3].each (
{ println it }
)
Lispers do language design with, for example, macros. And they don't need
to trumpet each syntactic change as a gift from developers upon high.
<http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html#forloop>
(Which is why I'd be inclined to target the Java Virtual Machine using the
full power of Lisp at compile time rather than targeting Java-the-language
or Groovy).
Regards,
Adam
Adam Warner wrote:
> Hi Jeff Dalton,
>
>
>>Adam Warner <······@consulting.net.nz> writes:
>>
>>
>>>This is a valid Groovy program ...
>>
>>>But this one isn't:
>>>
>>>['Print', 'out', 'a', 'list', 'of', 'strings'].each
>>> {println it}
>>
>>>Nor this one:
>>>
>>>['Print', 'out', 'a', 'list', 'of', 'strings'].each
>>>{
>>> println it
>>>}
>>
>>Oh - my - God.
>>
>>What is the logic behind that?
>
>
> It removes parentheses from the syntax. It's a widespread condition known
> as parenthophobia and it's believed to be highly contagious.
>
> <http://groovy.codehaus.org/faq.html#newline-before-brace>
>
> Things work if I use Suns conventions and put { on the same line, but
> if I add a new line things break?
>
> When using closures with method calls we have some syntax sugar in
> Groovy which is sensitive to whitespace (newlines to be precise).
> Please see this description in common gotchas for a full description
>
> <http://groovy.codehaus.org/javadiff.html>
>
> For example the following is valid groovy
>
> [1, 2, 3].each { println it }
>
> However if you want to specify the { on a separate line then you must
> use the more verbose parentheses version like this
>
> [1, 2, 3].each (
> { println it }
> )
What about
[1, 2, 3].each
( { println it } )
?
Adam Warner <······@consulting.net.nz> writes:
> Hi Jeff Dalton,
>
> > Adam Warner <······@consulting.net.nz> writes:
> >
> >> This is a valid Groovy program ...
> >
> >> But this one isn't:
> >>
> >> ['Print', 'out', 'a', 'list', 'of', 'strings'].each
> >> {println it}
> >
> >> Nor this one:
> >>
> >> ['Print', 'out', 'a', 'list', 'of', 'strings'].each
> >> {
> >> println it
> >> }
> >
> > Oh - my - God.
> >
> > What is the logic behind that?
>
> It removes parentheses from the syntax. It's a widespread condition known
> as parenthophobia and it's believed to be highly contagious.
Yes, but the usual alternative to parens is keywords.
For example, some languages have parens around "if" and "while"
conditions while others use "if ... then" or "while ... do".
Using weird whitespace rules instead looks like a "very bad idea" (tm)
to me.
> <http://groovy.codehaus.org/faq.html#newline-before-brace>
>
> Things work if I use Suns conventions and put { on the same line, but
> if I add a new line things break?
>
> When using closures with method calls we have some syntax sugar in
> Groovy which is sensitive to whitespace (newlines to be precise).
> Please see this description in common gotchas for a full description
>
> <http://groovy.codehaus.org/javadiff.html>
>
> For example the following is valid groovy
>
> [1, 2, 3].each { println it }
>
> However if you want to specify the { on a separate line then you must
> use the more verbose parentheses version like this
>
> [1, 2, 3].each (
> { println it }
> )
That's even worse!
What is the user's mental model supposed to be? I certainly don't
get it.
Orthogonality should apply to syntax.
> Lispers do language design with, for example, macros. And they don't need
> to trumpet each syntactic change as a gift from developers upon high.
> <http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html#forloop>
Good point.
> (Which is why I'd be inclined to target the Java Virtual Machine using the
> full power of Lisp at compile time rather than targeting Java-the-language
> or Groovy).
Just so. I'm surprised there aren't a lot of Lisps that compile
to Java VM.
-- jd
From: ·······@noshpam.lbl.government
Subject: Re: The Groovy Programming Language
Date:
Message-ID: <4pkzn9uxhdw.fsf@thar.lbl.gov>
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> Just so. I'm surprised there aren't a lot of Lisps that compile
> to Java VM.
>
> -- jd
Bigloo, Kawa, JScheme, and SISC all have backends to the JVM.
http://sisc.sourceforge.net/comp.html
~Tomer
--
()
ArmedBearJ incorporates a common lisp interpreter written in Java, with
a compiler under development.
http://armedbear-j.sourceforge.net/
They just like to pretend it's a nice little text editor.
Pete
Jeff Dalton wrote:
[someone else said that the following don't work in Groovy:]
>>>> ['Print', 'out', 'a', 'list', 'of', 'strings'].each
>>>> {println it}
>>>
>>>> Nor this one:
>>>>
>>>> ['Print', 'out', 'a', 'list', 'of', 'strings'].each
>>>> {
>>>> println it
>>>> }
...and ...
>> For example the following is valid groovy
>>
>> [1, 2, 3].each { println it }
>>
>> However if you want to specify the { on a separate line then you must
>> use the more verbose parentheses version like this
>>
>> [1, 2, 3].each (
>> { println it }
>> )
>
> That's even worse!
>
> What is the user's mental model supposed to be? I certainly don't
> get it.
<conjecture>That a complete expression on a line by itself
is treated as such, whereas when faced with something demonstrably
incomplete (because of pending parens or braces) the interpreter,
or compiler, or whatever it is, carries on reading until it's
got something complete? So [1,2,3].each is an expression, naming
what Python calls a "bound method", but "[1,2,3].each {" isn't
and so more needs to be read.</conjecture>
--
Gareth McCaughan
.sig under construc
Gareth McCaughan wrote:
> <conjecture>That a complete expression on a line by itself
> is treated as such, whereas when faced with something demonstrably
> incomplete (because of pending parens or braces) the interpreter,
> or compiler, or whatever it is, carries on reading until it's
> got something complete? So [1,2,3].each is an expression, naming
> what Python calls a "bound method", but "[1,2,3].each {" isn't
> and so more needs to be read.</conjecture>
<concurrence>
That is my guess. Vax Datatrieve worked the same way. I had to leave a
teaser at the end of each multi-line query typed into the interpreter so
it would know I was not done. So one had to violate normal formatting
instincts and end each line with the first bit of a clause, then finish
that clause on the next line. It was kind of funny to do in a geek kinda
way. It felt like one of those rants that keeps going "and another
thing!" Fortunately when I screwed up after three or four lines I just
typed "edit" as the next command and up came all the lines in the normal
EDT editor. Groovy will need that.
</concurrence>
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Joe Marshall
Subject: Re: The Groovy Programming Language
Date:
Message-ID: <vfkhqgd2.fsf@comcast.net>
Adam Warner <······@consulting.net.nz> writes:
> It removes parentheses from the syntax. It's a widespread condition known
> as parenthophobia and it's believed to be highly contagious.
For some reason, replacing parenthesis (a token you can see) with
whitespace (a token you cannot see), is considered an improvement.
--
~jrm
Joe Marshall wrote:
> For some reason, replacing parenthesis (a token you can see) with
> whitespace (a token you cannot see), is considered an improvement.
Asidefrommakingalanguageineligibleforobfuscatedprogrammingcontests,thebenefitsofwhitespaceshouldbeobvioustojustaboutanyone.Typographershavealottosayonthesubject.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> writes:
> thebenefitsofwhitespaceshouldbeobvioustojustaboutanyone
((But(you)re)not(using(any)token(separator)
now)so(the(analogy)is(flawed))).
s
From: André Thieme
Subject: Re: The Groovy Programming Language
Date:
Message-ID: <c4nb7f$4o2$1@ulric.tng.de>
Sunnan wrote:
> Cameron MacKinnon <··········@clearspot.net> writes:
>
>>thebenefitsofwhitespaceshouldbeobvioustojustaboutanyone
>
>
> ((But(you)re)not(using(any)token(separator)
> now)so(the(analogy)is(flawed))).
>
> s
Should different elements of a list be separated by a non whitespace char?
(+,2,5)
=> 7
Andr�
--
Andr� Thieme <······································@justmail.de> writes:
> Should different elements of a list be separated by a non whitespace char?
No, I'm happy with the way it works now, parens and whitespace in
cooperation.
--
One love,
Sunnan
Hi Cameron MacKinnon,
> Joe Marshall wrote:
>> For some reason, replacing parenthesis (a token you can see) with
>> whitespace (a token you cannot see), is considered an improvement.
>
> Asidefrommakingalanguageineligibleforobfuscatedprogrammingcontests,thebenefitsofwhitespaceshouldbeobvioustojustaboutanyone.Typographershavealottosayonthesubject.
Indeed, the benefit of whitespace to separate logically distinct symbols
should be obvious to anyone. The use of parentheses or some other tokens
to collect groups of symbols together should be equally obvious.
I originally posted this example of evaluation of some Groovy code:
1> { println "Hello" }.call()
2> go
Hello
1> { println [1, 2, 3] }.call()
2> go
null
1> { println([1, 2, 3]) }.call()
2> go
[1, 2, 3]
Making those parentheses optional creates non-obvious changes in the
semantics of the code. There is no way anyone intends to print null
instead of [1, 2, 3] in the second evaluation. As the third evaluation
demonstrates this was caused by omitting the parentheses. As their
inclusion appears to be critical for a program to have acceptable
semantics making them optional was a mistake.
Whether functions are invoked via fn(arg1, arg2, ..., argn) notation or
(fn arg1 arg2 ... argn) notation the function name and arguments are clear
and logically distinction from the surrounding context [and even this
paragraph].
I can design a language superior to Groovy. But I have my doubts about
being able to design a language superior to Common Lisp while making the
costs of transition worthwhile. That's the reason many of us don't
care to create yet another language. Language design is strongly motivated
by ego and a deep desire to improve the state of the art. It's just
unfortunate that most people have no idea what the state of the art even
looks like.
Regards,
Adam
Hi Cameron MacKinnon,
> Joe Marshall wrote:
>> For some reason, replacing parenthesis (a token you can see) with
>> whitespace (a token you cannot see), is considered an improvement.
>
> Asidefrommakingalanguageineligibleforobfuscatedprogrammingcontests,thebenefitsofwhitespaceshouldbeobvioustojustaboutanyone.Typographershavealottosayonthesubject.
Indeed, the benefit of whitespace to separate logically distinct symbols
should be obvious to anyone. The use of parentheses or some other tokens
to collect groups of symbols together should be equally obvious.
I originally posted this example of evaluation of some Groovy code:
1> { println "Hello" }.call()
2> go
Hello
1> { println [1, 2, 3] }.call()
2> go
null
1> { println([1, 2, 3]) }.call()
2> go
[1, 2, 3]
Making those parentheses optional creates non-obvious changes in the
semantics of the code. There is no way anyone intends to print null
instead of [1, 2, 3] in the second evaluation. As the third evaluation
demonstrates this was caused by omitting the parentheses. As their
inclusion appears to be critical for a program to have acceptable
semantics making them optional was a mistake.
Whether functions are invoked via fn(arg1, arg2, ..., argn) notation or
(fn arg1 arg2 ... argn) notation the function name and arguments are clear
and logically distinct from the surrounding context [and even this
paragraph].
I can design a language superior to Groovy. But I have my doubts about
being able to design a language superior to Common Lisp while making the
costs of transition worthwhile. That's the reason many of us don't
care to create yet another language. Language design is strongly motivated
by ego and a deep desire to improve the state of the art. It's just
unfortunate most people have no idea what the state of the art looks like.
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> I originally posted this example of evaluation of some Groovy code:
>
> 1> { println "Hello" }.call()
> 2> go
> Hello
>
> 1> { println [1, 2, 3] }.call()
> 2> go
> null
Nightmare!
> 1> { println([1, 2, 3]) }.call()
> 2> go
> [1, 2, 3]
>
> Making those parentheses optional creates non-obvious changes in the
> semantics of the code. There is no way anyone intends to print null
> instead of [1, 2, 3] in the second evaluation. As the third evaluation
> demonstrates this was caused by omitting the parentheses. As their
> inclusion appears to be critical for a program to have acceptable
> semantics making them optional was a mistake.
"Write-only" languages can be popular, so perhaps Groovy will be too.
But I have a feeling its name will work against it. ;>
Anyway, this shows a serious problem with syntactic experiments.
The people designing and developing the language will tend
to know the language fairly well and write things that work,
missing pitfalls that will trap programmers new to the language
or who don't use it regularly.
But even programmers who know the language well will sometimes
run into them, and an error like the one in example 2 above
will be very hard to spot.
(It's like proofreading something you wrote: you know what you
meant and so you will tend to see it as saying what you intended.
Someone else can often catch errors, ambiguities, and so on
that you missed.)
BTW, the problem with Groovy and the placement of "{"s is not
that whitespace is significant: it's that whitespace is significant
in a particular way that will confuse many programmers.
-- jd
From: Joe Marshall
Subject: Re: The Groovy Programming Language
Date:
Message-ID: <n05lte1v.fsf@ccs.neu.edu>
Cameron MacKinnon <··········@clearspot.net> writes:
> Joe Marshall wrote:
>> For some reason, replacing parenthesis (a token you can see) with
>> whitespace (a token you cannot see), is considered an improvement.
>
> Asidefrommakingalanguageineligibleforobfuscatedprogrammingcontests,thebenefitsofwhitespaceshouldbeobvioustojustaboutanyone.Typographershavealottosayonthesubject.
Is someone advocating removing whitespace altogether?
Joe Marshall wrote:
> Cameron MacKinnon <··········@clearspot.net> writes:
>
>>Joe Marshall wrote:
>>
>>>For some reason, replacing parenthesis (a token you can see) with
>>>whitespace (a token you cannot see), is considered an improvement.
>>
>>Asidefrommakingalanguageineligibleforobfuscatedprogrammingcontests,thebenefitsofwhitespaceshouldbeobvioustojustaboutanyone.Typographershavealottosayonthesubject.
>
> Is someone advocating removing whitespace altogether?
Someone said you can't see whitespace. If someone had said "I don't want
to go back to the days when programming manuals had strings of the
letter 'b', each with with a slash through it, to denote blanks, and
they were an eyesore" I would not have disagreed.
However, Since Lisp requires whitespace, I can't see why lispers should
be critical of the idea elsewhere.
I'm not a Python user, but I think the idea of using whitespace as
syntax is a neat one; since whitespace is required for legibility, why
not leverage that? On the flip side, GCC doesn't warn me when I do this:
if(x)
do_this();
oops_this_always_gets_done();
In languages where whitespace isn't syntactically significant, it can be
considered the most elementary form of comment. And, as Norm Schryer
said, "If the code and the comments disagree, then both are probably wrong."
All that said, there's no way I'll defend those borken Groovy examples
which were posted. THAT'S just a design flaw, no doubt about it.
--
Cameron MacKinnon
Toronto, Canada
From: Joe Marshall
Subject: Re: The Groovy Programming Language
Date:
Message-ID: <y8p4rh99.fsf@ccs.neu.edu>
Cameron MacKinnon <··········@clearspot.net> writes:
> Joe Marshall wrote:
>> Cameron MacKinnon <··········@clearspot.net> writes:
>>
>>>Joe Marshall wrote:
>>>
>>>>For some reason, replacing parenthesis (a token you can see) with
>>>>whitespace (a token you cannot see), is considered an improvement.
>>>
>>>Asidefrommakingalanguageineligibleforobfuscatedprogrammingcontests,thebenefitsofwhitespaceshouldbeobvioustojustaboutanyone.Typographershavealottosayonthesubject.
>> Is someone advocating removing whitespace altogether?
>
> Someone said you can't see whitespace.
I did. You can see whitespace?
Joe Marshall wrote:
> Cameron MacKinnon <··········@clearspot.net> writes:
>
>
>>Joe Marshall wrote:
>>
>>>Cameron MacKinnon <··········@clearspot.net> writes:
>>>
>>>
>>>>Joe Marshall wrote:
>>>>
>>>>
>>>>>For some reason, replacing parenthesis (a token you can see) with
>>>>>whitespace (a token you cannot see), is considered an improvement.
>>>>
>>>>Asidefrommakingalanguageineligibleforobfuscatedprogrammingcontests,thebenefitsofwhitespaceshouldbeobvioustojustaboutanyone.Typographershavealottosayonthesubject.
>>>
>>>Is someone advocating removing whitespace altogether?
>>
>>Someone said you can't see whitespace.
>
>
> I did. You can see whitespace?
Of course. And so can you. The complete proof is above. QED. I'm
confident that everyone else reading (if anyone's left) will see it as I
have :-) You should quit while you're ahead. I'm surprised at myself
for responding to this rather empty thread.
--
Cameron MacKinnon
Toronto, Canada
From: Joe Marshall
Subject: Re: The Groovy Programming Language
Date:
Message-ID: <k70osfm3.fsf@comcast.net>
Cameron MacKinnon <··········@clearspot.net> writes:
>> I did. You can see whitespace?
>
> Of course. And so can you. The complete proof is above. QED. I'm
> confident that everyone else reading (if anyone's left) will see it as
> I have :-) You should quit while you're ahead. I'm surprised at
> myself for responding to this rather empty thread.
Why no comment about the large program I posted at the end of the
previous message? Didn't you see it?
--
~jrm
"Joe Marshall" <·············@comcast.net> wrote in message
·················@comcast.net...
> Cameron MacKinnon <··········@clearspot.net> writes:
>
> >> I did. You can see whitespace?
> >
> > Of course. And so can you. The complete proof is above. QED. I'm
> > confident that everyone else reading (if anyone's left) will see it as
> > I have :-) You should quit while you're ahead. I'm surprised at
> > myself for responding to this rather empty thread.
>
> Why no comment about the large program I posted at the end of the
> previous message? Didn't you see it?
It was very buggy.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
Cameron MacKinnon <··········@clearspot.net> writes:
> Joe Marshall wrote:
> > Cameron MacKinnon <··········@clearspot.net> writes:
> >
> >>Joe Marshall wrote:
> >>
> >>>Cameron MacKinnon <··········@clearspot.net> writes:
> >>>
> >>>
> >>>>Joe Marshall wrote:
> >>>>
> >>>>
> >>>>>For some reason, replacing parenthesis (a token you can see) with
> >>>>>whitespace (a token you cannot see), is considered an improvement.
> >>>>
> >>>>Asidefrommakingalanguageineligibleforobfuscatedprogrammingcontests,thebenefitsofwhitespaceshouldbeobvioustojustaboutanyone.Typographershavealottosayonthesubject.
> >>>
> >>>Is someone advocating removing whitespace altogether?
> >>
> >> Someone said you can't see whitespace.
> > I did. You can see whitespace?
>
> Of course. And so can you. The complete proof is above. QED. I'm
> confident that everyone else reading (if anyone's left) will see it as
> I have :-) You should quit while you're ahead. I'm surprised at
> myself for responding to this rather empty thread.
I bet you can see magnetic fields, too.
--
-Tim
From: André Thieme
Subject: Re: The Groovy Programming Language
Date:
Message-ID: <c58o68$huq$1@ulric.tng.de>
Cameron MacKinnon wrote:
> Cameron MacKinnon <··········@clearspot.net> writes:
>
>
>>> Joe Marshall wrote:
>>>
>>>
>>>> Cameron MacKinnon <··········@clearspot.net> writes:
>>>>
>>>> Someone said you can't see whitespace.
>>>
>>>
>>> I did. You can see whitespace?
>
>
> Of course. And so can you. The complete proof is above. QED. I'm
> confident that everyone else reading (if anyone's left) will see it as I
> have :-) You should quit while you're ahead. I'm surprised at myself
> for responding to this rather empty thread.
I am still not certain if you can really see whitespace. Probably you
can see its replacement, put there by your viewer.
It's not so easy to count how many spaces and how many tabs are coming:
(7 spaces, 3 tabs)
Andr�
--
+ Andr� Thieme <······································@justmail.de>:
| I am still not certain if you can really see whitespace.
(setq-default show-trailing-whitespace t)
| It's not so easy to count how many spaces and how many tabs are coming:
True. It should be easy to instruct emacs to colour tabs and spaces
differently, but there is no readymade code to do it, AFAIK.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Cameron MacKinnon <··········@clearspot.net> writes:
> Joe Marshall wrote:
> > Cameron MacKinnon <··········@clearspot.net> writes:
> >
> >>Joe Marshall wrote:
> >>
> >>>For some reason, replacing parenthesis (a token you can see) with
> >>>whitespace (a token you cannot see), is considered an improvement.
> >>
> >>Asidefrommakingalanguageineligibleforobfuscatedprogrammingcontests,thebenefitsofwhitespaceshouldbeobvioustojustaboutanyone.Typographershavealottosayonthesubject.
> > Is someone advocating removing whitespace altogether?
>
> Someone said you can't see whitespace. If someone had said "I don't
> want to go back to the days when programming manuals had strings of
> the letter 'b', each with with a slash through it, to denote blanks,
> and they were an eyesore" I would not have disagreed.
>
> However, Since Lisp requires whitespace, I can't see why lispers
> should be critical of the idea elsewhere.
GNU Make has a wonderful distinction between tabs and spaces. For
those who missed it, the previous sentence is dripping with sarcasm.
I've heard that Python can get confused with tabs and spaces that are
mixed up. I do know of editors that will substitute tabs for spaces
to save --- space. Trailing space removal is nice though.
My personal view is that spaces should be left for humans. As far as
the compiler is concerned, in the general case, all consecutive
whitespace should be compressed to a single seperator. What to do
inside a literal string gets a little trickier. There are cases where
I would like to continue a string on the next line without having to
use an escape character and without worrying that indentation for
reading in the code will end up being embedded in the string. Oh
well.
Anyone up for implementing WITH-SOURCE-CODE-DWIM?
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
David Steuber <·····@david-steuber.com> writes:
> Cameron MacKinnon <··········@clearspot.net> writes:
>
> > Joe Marshall wrote:
> > > Cameron MacKinnon <··········@clearspot.net> writes:
> > >
> > >>Joe Marshall wrote:
> > >>
> > >>>For some reason, replacing parenthesis (a token you can see) with
> > >>>whitespace (a token you cannot see), is considered an improvement.
> > >>
> > >>Asidefrommakingalanguageineligibleforobfuscatedprogrammingcontests,thebenefitsofwhitespaceshouldbeobvioustojustaboutanyone.Typographershavealottosayonthesubject.
> > > Is someone advocating removing whitespace altogether?
> >
> > Someone said you can't see whitespace. If someone had said "I don't
> > want to go back to the days when programming manuals had strings of
> > the letter 'b', each with with a slash through it, to denote blanks,
> > and they were an eyesore" I would not have disagreed.
> >
> > However, Since Lisp requires whitespace, I can't see why lispers
> > should be critical of the idea elsewhere.
>
> GNU Make has a wonderful distinction between tabs and spaces. For
> those who missed it, the previous sentence is dripping with sarcasm.
I hate to tell you, but this is not a case of the GNU people getting
something wrong, it goes back much further. Every make system uses
tabs specially, it's part of the "charm" of Unix.
> Anyone up for implementing WITH-SOURCE-CODE-DWIM?
Hey, this is a Common Lisp group, get your crazy InterLisp ideas back
where they came from!
( http://catb.org/~esr/jargon/html/D/DWIM.html )
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
David Steuber <·····@david-steuber.com> wrote:
+---------------
| My personal view is that spaces should be left for humans. As far as
| the compiler is concerned, in the general case, all consecutive
| whitespace should be compressed to a single seperator. What to do
| inside a literal string gets a little trickier. There are cases where
| I would like to continue a string on the next line without having to
| use an escape character and without worrying that indentation for
| reading in the code will end up being embedded in the string. Oh well.
+---------------
Why the "Oh well"? Common Lisp gives you this:
> (format nil "A string with ~
line breaks in it ~
that FORMAT elides ~
except this one ·@
which, though, still eats ~
the following whitespace.")
"A string with line breaks in it that FORMAT elides except this one
which, though, still eats the following whitespace."
>
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> David Steuber <·····@david-steuber.com> wrote:
> +---------------
> | My personal view is that spaces should be left for humans. As far as
> | the compiler is concerned, in the general case, all consecutive
> | whitespace should be compressed to a single seperator. What to do
> | inside a literal string gets a little trickier. There are cases where
> | I would like to continue a string on the next line without having to
> | use an escape character and without worrying that indentation for
> | reading in the code will end up being embedded in the string. Oh well.
> +---------------
>
> Why the "Oh well"? Common Lisp gives you this:
>
> > (format nil "A string with ~
> line breaks in it ~
> that FORMAT elides ~
> except this one ·@
> which, though, still eats ~
> the following whitespace.")
>
> "A string with line breaks in it that FORMAT elides except this one
> which, though, still eats the following whitespace."
> >
I did not know about this cool feature. That really is cool. Does it
also work with docstrings? That is actually what I had in mind when I
wrote the above. I don't really know exactly what the reader does
with source code beyond turning the text into Lisp objects. I could
live with docstrings formated as above. I could live quite well with
them.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
Hi David Steuber,
>> > (format nil "A string with ~
>> line breaks in it ~
>> that FORMAT elides ~
>> except this one ·@
>> which, though, still eats ~
>> the following whitespace.")
>>
>> "A string with line breaks in it that FORMAT elides except this one
>> which, though, still eats the following whitespace."
>> >
>
> I did not know about this cool feature. That really is cool. Does it
> also work with docstrings?
Well you can perform any arbitrary calculations during the read process
using the sharpsign dot (#.) macro.
(defun hello ()
#.(concatenate 'string "Prints" #1='(#\space) "Hello" #1# "World!")
(print "Hello World!"))
(describe 'hello) =>
...
Function documentation:
Prints Hello World!
...
Regards,
Adam
On Fri, 09 Apr 2004 09:35:08 -0500, Joe Marshall wrote:
> Cameron MacKinnon <··········@clearspot.net> writes:
>
>> Joe Marshall wrote:
>>> For some reason, replacing parenthesis (a token you can see) with
>>> whitespace (a token you cannot see), is considered an improvement.
>>
>> Asidefrommakingalanguageineligibleforobfuscatedprogrammingcontests,thebenefitsofwhitespaceshouldbeobvioustojustaboutanyone.Typographershavealottosayonthesubject.
>
> Is someone advocating removing whitespace altogether?
and what happens when you try to read it 9 months later ??