What if we solved the readability problem?
I know emacs indents everything nicely but suppose we did the following:
#1. Continue using parentheses to open
#2. Use ] to close remaining open parentheses up to cursor on current line
#3. Use } to close remaining open parentheses up to current line in file
Alternatively, we could:
#4. Use ] to close remaining open parentheses for just the current
argument to a function
#5. Use } for #4 but up to the current line
Rares Marian wrote:
> What if we solved the readability problem?
>
> I know emacs indents everything nicely but suppose we did the following:
> #1. Continue using parentheses to open
> #2. Use ] to close remaining open parentheses up to cursor on current line
> #3. Use } to close remaining open parentheses up to current line in file
>
> Alternatively, we could:
> #4. Use ] to close remaining open parentheses for just the current
> argument to a function
> #5. Use } for #4 but up to the current line
Why didn't we think of this before!? Thanks!!
kenny
ps. What parentheses? k
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
On Mon, 26 May 2008 01:01:32 -0400, Ken Tilton wrote:
<snip>
> Why didn't we think of this before!? Thanks!!
>
> kenny
>
> ps. What parentheses? k
(are (talking (about (am I))) (the (parentheses these)))
I know I didn't get that right.
Rares Marian <············@gmail.com> wrote:
+---------------
| What if we solved the readability problem?
+---------------
*What* "readability problem"?!? There's no no "readability problem"...
[Maybe you need a decent editor?]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Mon, 26 May 2008 04:12:20 -0500, Rob Warnock wrote:
> [Maybe you need a decent editor?]
>
>
> -Rob
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/> San Mateo,
CA 94403
> (650)572-2607
It's hard to explain.
Rares Marian wrote:
> What if we solved the readability problem?
No thanks. It's staying exactly the way it is. Go away.
--
Lars Rune Nøstdal
http://nostdal.org/
On Mon, 26 May 2008 07:59:52 +0200, Lars Rune Nøstdal wrote:
> Rares Marian wrote:
>> What if we solved the readability problem?
>
> No thanks. It's staying exactly the way it is. Go away.
I think I'll stick around. I love lisp. It just makes my eyes bleed with
the parens.
What I find funny though is that most programming languages are prefix
not infix. The only non-prefix aspect is assignment and mathematical
operations.
On May 26, 1:43 am, Dihydrogen Monoxide <············@gmail.com>
wrote:
> I love lisp. It just makes my eyes bleed with the parens.
I use a macro called LETT: (lett x (get-x) ...),
which eliminates two pairs of parens in binding
a single variable, as in (let ((x (get-x))) ...),
or 14 letters when binding a list of variables, as
in destructuring-bind.
Even better than trimming parens is wrapping entire
chunks of your program in macros. A couple parens
here and there can be helpful in parsing the code.
I have a few things documented here:
http://www.prairienet.org/~dsb/myclcode.htm
and there's a recent download bundled with
my pattern-matching library here:
http://common-lisp.net/project/cl-match/
--Dan
------------------------------------------------
Dan Bensen http://www.prairienet.org/~dsb/
cl-match: expressive pattern matching in Lisp
http://common-lisp.net/project/cl-match/
On May 26, 1:43 am, Dihydrogen Monoxide <············@gmail.com>
wrote:
> I love lisp. It just makes my eyes bleed with the parens.
I use a macro called LETT: (lett x (get-x) ...),
which eliminates two pairs of parens in binding
a single variable, as in (let ((x (get-x))) ...),
or 14 letters when binding a list of variables, as
in destructuring-bind.
Even better than trimming parens is wrapping entire
chunks of your program in macros. A couple parens
here and there can be helpful in parsing the code.
I have a few things documented here:
http://www.prairienet.org/~dsb/myclcode.htm
and there's a recent download bundled with
my pattern-matching library here:
http://common-lisp.net/project/cl-match/
--Dan
------------------------------------------------
Dan Bensen http://www.prairienet.org/~dsb/
cl-match: expressive pattern matching in Lisp
http://common-lisp.net/project/cl-match/
danb wrote:
> A couple parens
> here and there can be helpful in parsing the code.
The parentheses are there to tell your editor how to indent the code.
Then you read the indentation.
--
Pertti
danb wrote:
> A couple parens here and there can be helpful
> in parsing the code.
On May 26, 6:34 am, Pertti Kellomäki wrote:
> The parentheses are there to tell your editor
> how to indent the code.
And to help macros parse it.
--Dan
------------------------------------------------
Dan Bensen http://www.prairienet.org/~dsb/
cl-match: expressive pattern matching in Lisp
http://common-lisp.net/project/cl-match/
On Mon, 26 May 2008 06:43:05 +0000, Dihydrogen Monoxide wrote:
> I think I'll stick around. I love lisp. It just makes my eyes bleed with
> the parens.
Not really. You're just not used to absence of the dust of commas and
semicolons. You'll get used to the cleanliness eventually.
--
Andrew
On Mon, 26 May 2008 11:57:45 +0000, Andrew Reilly wrote:
> On Mon, 26 May 2008 06:43:05 +0000, Dihydrogen Monoxide wrote:
>
>> I think I'll stick around. I love lisp. It just makes my eyes bleed
>> with the parens.
>
> Not really. You're just not used to absence of the dust of commas and
> semicolons. You'll get used to the cleanliness eventually.
Actually, successive symbols strings like ))))))) give me a headache. I
call it symbol shock. I don't know why.
I suppose I can live with
)
)
)
Dihydrogen Monoxide <············@gmail.com> writes:
> On Mon, 26 May 2008 11:57:45 +0000, Andrew Reilly wrote:
>
>> On Mon, 26 May 2008 06:43:05 +0000, Dihydrogen Monoxide wrote:
>>
>>> I think I'll stick around. I love lisp. It just makes my eyes bleed
>>> with the parens.
>>
>> Not really. You're just not used to absence of the dust of commas and
>> semicolons. You'll get used to the cleanliness eventually.
>
> Actually, successive symbols strings like ))))))) give me a headache. I
> call it symbol shock. I don't know why.
>
> I suppose I can live with
> )
> )
> )
Please don't live with that. You won't even notice ))))))) once you stop
obsessing over it.
Dihydrogen Monoxide wrote:
> On Mon, 26 May 2008 11:57:45 +0000, Andrew Reilly wrote:
>
>
>>On Mon, 26 May 2008 06:43:05 +0000, Dihydrogen Monoxide wrote:
>>
>>
>>>I think I'll stick around. I love lisp. It just makes my eyes bleed
>>>with the parens.
>>
>>Not really. You're just not used to absence of the dust of commas and
>>semicolons. You'll get used to the cleanliness eventually.
>
>
> Actually, successive symbols strings like ))))))) give me a headache. I
> call it symbol shock. I don't know why.
>
> I suppose I can live with
> )
> )
> )
Listen, I can sympathize. I started programming way back when in Fortran
on a mainframe on punch cards. I was really thrown by the little
rectangular holes punched in the card. What if they were off a little?
What if the angles were not perfectly square? It really gave me a
headache, holding the cards up to the light to debug my code...
hth, kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
On Mon, 26 May 2008 19:30:50 -0400, <···········@optonline.net> wrote:
>
> Listen, I can sympathize. I started programming way back when in Fortran
> on a mainframe on punch cards.
At my second college, I travelled backwards in time to such a world.
I had been in the heady world of interactive computer work with the
exciting ASR-33 or the quieter ADM-3As.
> I was really thrown by the little
> rectangular holes punched in the card. What if they were off a little?
I reused my code...by saving all working punch cards.
> What if the angles were not perfectly square? It really gave me a
> headache, holding the cards up to the light to debug my code...
:-) If I altered a working card a little, I could compare if the holes
changed in the right column.
Hehe, you did the debug on paper, hand stepping thru the pieces
because it was a pita to punch it ... until I understood that the
girls in class used to be found in the 'punch' room regularly and they
wanted 'help'. I then appreciated the value of using ancient
technology, such as parens bound Lisp, without any newfangled modification.
--
One of the strokes of genius from McCarthy
was making lists the center of the language - kt
** Posted from http://www.teranews.com **
Dihydrogen Monoxide wrote:
> On Mon, 26 May 2008 11:57:45 +0000, Andrew Reilly wrote:
>
>> On Mon, 26 May 2008 06:43:05 +0000, Dihydrogen Monoxide wrote:
>>
>>> I think I'll stick around. I love lisp. It just makes my eyes bleed
>>> with the parens.
>> Not really. You're just not used to absence of the dust of commas and
>> semicolons. You'll get used to the cleanliness eventually.
>
> Actually, successive symbols strings like ))))))) give me a headache. I
> call it symbol shock. I don't know why.
>
> I suppose I can live with
> )
> )
> )
yeah, and make it "XML-based" while you're at it
you say you "love lisp" but apparently you do not know anything about lisp .. maybe this works in love, but dunno how far it'll get you
you can go from this:
void someFunction()
{
if(1)
{
a();
b();
c();
}
else
{
d();
e();
f();
}
}
..to this..
void someFunction()
{
if(1) {
a();
b();
c();
}
else {
d();
e();
f();
}
}
..to this..
void someFunction(){
if(1){
a();
b();
c();}
else{
d();
e();
f();}}
..to this..
void someFunction()
if(1)
a();
b();
c();
else
d();
e();
f();
.and instantly know that a, b, c belongs in the then-part and d, e, f belongs in the else-part - in all the examles .. your eyes do not look for syntax, only indentation when looking for structure and meaning at this level
take XML:
<person>
<name>lars</name>
<age>27</age>
</person>
..then fix it:
(person
(name lars)
(age 26))
..there, your turn; "re-fix it" for us and say you "love lisp"
--
Lars Rune Nøstdal
http://nostdal.org/
On May 27, 2:57 am, Lars Rune Nøstdal <···········@gmail.com> wrote:
> you say you "love lisp" but apparently you do not know anything about lisp .. maybe this works in love, but dunno how far it'll get you
I've played with it quite a bit actually.
<snip>
> .and instantly know that a, b, c belongs in the then-part and d, e, f belongs in the else-part >- in all the examles .. your eyes do not look for syntax, only indentation when looking for >structure and meaning at this level
Maybe your eyes. Until recently I couldn't look at anything which
contained whitespace. My lines of code were up to 140 chars long and
had no blank lines between. I've fixed this problem, how I don't know,
I just kept fighting it I guess. Maybe it's the enzymes I've been
taking lately.
Large bits of code require me to use 5pt or even 4pt emacs-snapshot
for the anti-aliasing.
>
> take XML:
>
> <person>
> <name>lars</name>
> <age>27</age>
> </person>
Yuck. The angle brackets create noise for me. I get a headache looking
at that.
> ..then fix it:
>
> (person
> (name lars)
> (age 26))
>
That's ok, I can work with that. Some more complicated code, I can't
read it. I start wanting to do a performance of Bill O'Reilly's
recently found tape when he was at Inside Edition.
> ..there, your turn; "re-fix it" for us and say you "love lisp"
I love any language that can return functions and never gets bored
rereading the same space until its done.
> --
> Lars Rune Nøstdalhttp://nostdal.org/
On May 26, 9:54 pm, Dihydrogen Monoxide <············@gmail.com>
wrote:
> On Mon, 26 May 2008 11:57:45 +0000, Andrew Reilly wrote:
> > On Mon, 26 May 2008 06:43:05 +0000, Dihydrogen Monoxide wrote:
>
> >> I think I'll stick around. I love lisp. It just makes my eyes bleed
> >> with the parens.
>
> > Not really. You're just not used to absence of the dust of commas and
> > semicolons. You'll get used to the cleanliness eventually.
>
> Actually, successive symbols strings like ))))))) give me a headache. I
> call it symbol shock. I don't know why.
>
> I suppose I can live with
> )
> )
> )
You can, but I can't. I won't read your code. Hence you risk writing
write-only code :)
Cheers
--
Marco
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: New notation
Date:
Message-ID: <rem-2008may31-004@yahoo.com>
> From: Dihydrogen Monoxide <············@gmail.com>
> Actually, successive symbols strings like ))))))) give me a
> headache. I call it symbol shock. I don't know why.
There's no reason you have to format your code like that, any more
than doing the equivalent thing in C.
void foo(int arg) {
if (arg<2) return 1;
else {
if (arg%2 == 0) arg=arg/2; else arg=3*arg+1;
if (arg<2) return 2;
else {
if (arg%2 == 0) arg=arg/2; else arg=3*arg+1;
if (arg<2) return 3;
else {
if (arg%2 == 0) arg=arg/2; else arg=3*arg+1;
if (arg<2) return 4;
else {
if (arg%2 == 0) arg=arg/2; else arg=3*arg+1;
if (arg<2) return 5;
else return 99; }}}}}
> I suppose I can live with
> )
> )
> )
Well if the close parens nicely line up with the levels of open
parens and corresponding indentation, then indeed that makes it
easy to read the code. Personally I like to break major levels of
structure on separate lines, and include at most three minor levels
of structure within a single line, so then at most three close
parens occur together, and even three is rare. For example:
(loop for dpr in sor4dprs do
(setq othernode (cadr dpr)) (setq dist (car dpr))
(format t "~& ~A = ~A (d=~,5F C=~,5F)~%" othernode
(get othernode :SATZ) dist (normdist-to-corel dist))
)
See how that parens closing the major level (loop ...) is on a
separate line from the last line of code *within* the LOOP
expression?
Now for binary decision trees based on nested IF expressions, I use
a different convention, not caring about the string of parens at
all, pretending they are invisible, looking only at the
indentation, as one of the other posters in this thread suggested:
(if links1
(if links2
:STET
(q-consider-this-reconnect node2))
(if links2
(q-consider-this-reconnect node1)
(list (q-consider-this-reconnect node1)
(q-consider-this-reconnect node2))))
In most of my code, however, written as a sequence of steps within
a PROG, there aren't any strings of closing parens in the first
place, because each step is at most a SETQ or MULTIPLE-VALUE-SETQ
of a function call, where each parameter to the function is a named
local variable (either a function parameter or a PROG variable
previously assigned within the PROG). For example:
(defun oldlinks+newwt01-m6-to-optwtlinks (oldlinks newwt01)
(prog (midlinks stats optouts optlinks)
(format t "~&Using method-6 to build toward new weight=~F ..." newwt01)
(finish-output)
(setq midlinks (oldlinks+wt0ph1true-method-6 oldlinks newwt01))
(format t " done. Now trying to reduce the number of singly-connected ~
nodes:~%")
(multiple-value-setq (stats optouts optlinks)
(wt01+origwtlinks-to-optwtlinks newwt01 midlinks))
(when (trace3)
(format t "~& Final status=~A, #links=~D, #outliers=~D~%" stats
(length optlinks) (length optouts)))
(return (values stats optouts optlinks))
))
Note how the (DEFUN ... (PROG ... )) is one major level, and each
statement within the PROG is a second major level, hence the pair
of close parens on a line by itself after the last statement within
the PROG.
Really, there's nothing ***wrong*** with PROG!!! Ignore the snobs
who detest it, OK? Dijkstra's three primitives (sequence & choice &
loop) of structured programming start with *sequence*, and PROG is
just about perfect for that first one if you have a mix of lines of
code that produce a new value that needs to be used later and lines
of code that don't produce any usable value, dontcha think. (Not to
mention lines of code that produce more than one value to be used
later, where you want to use MULTIPLE-VALUE-SETQ or
MULTIPLE-VALUE-BIND, and the latter forces you to indent one deeper
from there onward whereas the former in a PROG can sit all at one
level of indentation.) If *every* line of code in a function
produces a value you want to use later, then you can use LET*
instead of PROG, but how many times do you really have that kind of
situation, huh??
OK, just to show you a strawman example, here's the above code
converted to use LET* and MULTIPLE-VALUE-BIND instead of PROG with
SETQ and MULTIPLE-VALUE-SETQ:
(defun oldlinks+newwt01-m6-to-optwtlinks (oldlinks newwt01)
(format t "~&Using method-6 to build toward new weight=~F ..." newwt01)
(finish-output)
(let* ((midlinks (oldlinks+wt0ph1true-method-6 oldlinks newwt01)))
(format t " done. Now trying to reduce the number of singly-connected ~
nodes:~%")
(multiple-value-bind (stats optouts optlinks)
(wt01+origwtlinks-to-optwtlinks newwt01 midlinks))
(when (trace3)
(format t "~& Final status=~A, #links=~D, #outliers=~D~%" stats
(length optlinks) (length optouts)))
(return (values stats optouts optlinks))
)))
What I don't like about that, compared to PROG:
- Extra level of parens in LET* (or LET could have been used here).
- Indentation keeps increasing as new local variables are bound.
- Run of more than two close parens at the very end, which you need
to carefully do differently for each function depending on how
many LET* or MULTIPLE-VALUE-BIND levels you have used.
By comparison, PROG has all statements in the sequence at the same
level of indentation, and *always* has exactly two close parens at
the very end (for the DEFUN and the PROG inside it), which you can
type automatically without having to count parens or slowly watch
EMACS flash back to matching start parens.
Using a PROG instead of LET* and MULTIPLE-VALUE-BIND, the only time
you go extra major levels of parens is when you have an actual
programming flow-of-control mechanism, such as inside a LOOP or
COND etc. You don't go extra levels deep just because you
introduced an additional local variable.
Now anyone who honestly feels that starting to use a new local
variable really deserves a whole new deeper level of indentation,
then ignore everything I said above, and learn to love the long
strings of parens your preference causes you to have to suffer.
But me, I prefer a simple sequence of statements to all be at the
same level of indention regardless of new local variables
introduced along the way. YMMV = DSFDF Viva la PROG!! Long live PROG!!
Here's a function I wrote back in 2001 (part of module to use a
heap to implement a priority queue):
(defun push-heap (oldheap newpr)
(unless (and (consp newpr) (realp (car newpr))) ;Check added 2008.May.14
(error "NEWPR not of form (realNumberPriority . details)~%~S" newpr))
(if (null oldheap)
(cons 1 newpr)
(if (= 1 (car oldheap))
(if (< (car newpr) (car (cdr oldheap)))
(list 2 newpr oldheap)
(list 2 (cdr oldheap) (cons 1 newpr)))
(let* ((here (< (car newpr) (car (cadr oldheap))))
(push1 (< (heapcnt (caddr oldheap)) (heapcnt (cdddr oldheap))))
(prhere (if here newpr (cadr oldheap)))
(prdown (if here (cadr oldheap) newpr))
(hpkeep (if push1 (cdddr oldheap) (caddr oldheap)))
(hpdown (if push1 (caddr oldheap) (cdddr oldheap)))
(recres (push-heap hpdown prdown)))
(list* (+ 1 (car oldheap)) prhere hpkeep recres)))))
Note the consistent indentation for IF
(if test
trueCase
falseCase)
which makes it easy to visually scan from the IF to whichever
sub-form you are interested in at the moment.
Note the only place there's a long string of close parens is at the
very end, and it's trivial to count the opening parens by running
your eye down the main diagonal:
(defun ...
(if (null oldheap)
(if (= 1 (car oldheap))
(let* ...
(list* ...
Can you not easily count the five open parens that need matching?
Note the use of a whole sequence of temporary LET* variables, all
at the same level, with very simple expressions to compute their
values, instead of trying to nest expressions deeply.
Now I suppose I *could* have flattened those first two IFs by using
a COND instead of nesting two IFs. Which way would you-all have
liked better?
One thing I probably would have done differently today is to define
auxillary functions/macros for the sub-heaps within a HEAP object
with count at least 2 (heaps of count 0 and 1 have a simpler
structure that doesn't involve any sub-heaps):
(defun heap2-left (heap2) (caddr heap2))
(defun heap2-right (heap2) (cdddr heap2))
then call those functions/macros instead of calling CADDR & CDDDR directly.
Likewise I might define the location of the pair in both cases:
(defun heap1-pair (heap1) (cdr heap1))
(defun heap2-pair (heap2) (cadr heap2))
That would have made the code slightly more legible, but is off-topic
for this thread about whether/how to avoid long strings of close parens.
Dihydrogen Monoxide <············@gmail.com> wrote in news:ZZs_j.2459
········@nlpi070.nbdc.sbc.com:
> I think I'll stick around. I love lisp. It just makes my eyes bleed with
> the parens.
What fonts have you tried? Which part of your eye is bleeding? Have you
tried Tahoma, Georgia, etc.?
Do you wear contact lenses? Make sure none of the parens are getting
caught between the lens and your eye.
Rares Marian <············@gmail.com> writes:
> What if we solved the readability problem?
>
> I know emacs indents everything nicely but suppose we did the following:
> #1. Continue using parentheses to open
> #2. Use ] to close remaining open parentheses up to cursor on current line
> #3. Use } to close remaining open parentheses up to current line in file
>
> Alternatively, we could:
> #4. Use ] to close remaining open parentheses for just the current
> argument to a function
> #5. Use } for #4 but up to the current line
Go fetch paredit.el!
--
__Pascal Bourguignon__
On Mon, 26 May 2008 16:17:09 +0200, Pascal J. Bourguignon wrote:
> Rares Marian <············@gmail.com> writes:
>
>> What if we solved the readability problem?
>>
>> I know emacs indents everything nicely but suppose we did the
>> following: #1. Continue using parentheses to open #2. Use ] to close
>> remaining open parentheses up to cursor on current line #3. Use } to
>> close remaining open parentheses up to current line in file
>>
>> Alternatively, we could:
>> #4. Use ] to close remaining open parentheses for just the current
>> argument to a function
>> #5. Use } for #4 but up to the current line
>
> Go fetch paredit.el!
Done.
Symbol shock is bad for me.
Rares Marian <············@gmail.com> writes:
I know emacs indents everything nicely but suppose we did the following:
#1. Continue using parentheses to open
#2. Use ] to close remaining open parentheses up to cursor on current line
#3. Use } to close remaining open parentheses up to current line in file
I believe some old dialects of lisp (pc-lisp maybe?) used ]
to close all remaining forms up to top-level. I guess one
could get used to that, but it seems like it could be a
nuisance when you find that you want to splice something in,
as with a new optional argument in some buried expression.
On 26 Mag, 06:17, Rares Marian <············@gmail.com> wrote:
> What if we solved the readability problem?
Simply use the PC - Parenthesis Compressor:
http://i25.tinypic.com/wk664x.png
j.oke wrote:
> On 26 Mag, 06:17, Rares Marian <············@gmail.com> wrote:
>> What if we solved the readability problem?
>
> Simply use the PC - Parenthesis Compressor:
>
> http://i25.tinypic.com/wk664x.png
>
haha .. great idea! :)
--
Lars Rune Nøstdal
http://nostdal.org/
On May 26, 2:17 pm, Rares Marian <············@gmail.com> wrote:
> I know emacs indents everything nicely but suppose we did the following:
> #1. Continue using parentheses to open
> #2. Use ] to close remaining open parentheses up to cursor on current line
> #3. Use } to close remaining open parentheses up to current line in file
You're using emacs. I'm sure you're capable of finding a script
online or writing one yourself.
If it helps, parenface.el will dim your parens with a minimum of fuss.
On 26 May, 05:17, Rares Marian <············@gmail.com> wrote:
> What if we solved the readability problem?
Which readability problem? I don't think there is a single unified
critique of Lisp's notation. Different detractors object to different
aspects of it.
Presumably the reason to solve the problem is to make Lisp more widely
used. I think what prevents that happening is not the specific
notation, per se.
Since the creation of Lisp, programming has changed from being the
exclusive domain of skilled artisans to be dominated by generic,
highly disposable, code-monkeys. Companies want programming languages
where any idiot programmer can understand what a piece of code does.
They don't want languages where the code might take several weeks for
a mediocre programmer to comprehend, even if the programmer would be
far more productive with it after expending the effort.
Lisp isn't going to win until you remove the features which make it
Lisp. Changing the notation slightly doesn't do that, it just annoys
people used to the normal notation. Changing the notation completely
gives you a different language, which is fine, but many people
wouldn't consider the result to be Lisp.
1. There is no hugely influential company pushing for the use of Lisp,
in contrast to languages like Java and C#.
2. Its notation is not C derived. There are plenty of people who
object to Visual Basic solely because of its non-C-like syntax, rather
than the more obvious reason to dislike it.
3. It doesn't have a standard massive library containing a GUI
toolkit, test framework, networking interface, etc.
4.
> I know emacs indents everything nicely but suppose we did the following:
> #1. Continue using parentheses to open
> #2. Use ] to close remaining open parentheses up to cursor on current line
> #3. Use } to close remaining open parentheses up to current line in file
What readability problem do you think this would solve? I don't
imagine there are many people who dislike closing parentheses
exclusively. It could be convenient to set those keys up as bindings
to insert real parentheses. That wouldn't effect readability, though.
> Alternatively, we could:
> #4. Use ] to close remaining open parentheses for just the current
> argument to a function
That's what ) already does.
> #5. Use } for #4 but up to the current line
Which is like ) except it doesn't insert anything if the function
you're in didn't start on the current line. Not quite sure what you're
getting at with this one.
On May 29, 1:48 pm, ···········@c4l.co.uk wrote:
> On 26 May, 05:17, Rares Marian <············@gmail.com> wrote:
>
> Presumably the reason to solve the problem is to make Lisp more widely
> used.
Nope. Reading fatigue. I get headaches when I see ()(())))()())))).
Dihydrogen Monoxide <············@gmail.com> writes:
> On May 29, 1:48 pm, ···········@c4l.co.uk wrote:
>> On 26 May, 05:17, Rares Marian <············@gmail.com> wrote:
>>
>
>> Presumably the reason to solve the problem is to make Lisp more widely
>> used.
>
> Nope. Reading fatigue. I get headaches when I see ()(())))()())))).
Unbalanced parens give me a headache too, but a good editor will help
you avoid those.
On May 30, 4:11 am, Dihydrogen Monoxide <············@gmail.com>
wrote:
> On May 29, 1:48 pm, ···········@c4l.co.uk wrote:
>
> > On 26 May, 05:17, Rares Marian <············@gmail.com> wrote:
>
> > Presumably the reason to solve the problem is to make Lisp more widely
> > used.
>
> Nope. Reading fatigue. I get headaches when I see ()(())))()())))).
I know it's Scheme, but...
http://img264.imageshack.us/img264/1397/lispnd7.png
What sort of chump reads the parens? That's like reading the
semicolons and braces in a C-like language. The only reason people
like it is because it's what they grew up with.
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: New notation
Date:
Message-ID: <rem-2008may31-006@yahoo.com>
> From: Tung Nguyen <·········@gmail.com>
> What sort of chump reads the parens? That's like reading the
> semicolons and braces in a C-like language.
Indeed, when scanning from one line to the next, it's the
indentation not the parens/braces nesting that a human eye follows.
In this sense, Lisp is a clear winner, with one standard for
prettyprinting whereas C has four conflicting standards:
main()
{
int exp,pwr; float x;
x = 0.1;
exp=0; pwr=1;
while (exp<30)
{
exp += 1; pwr *= 2;
printf("0.1 * 2**%d = %f\n", exp, x*pwr);
}
}
main() {
int exp,pwr; float x;
x = 0.1;
exp=0; pwr=1;
while (exp<30) {
exp += 1; pwr *= 2;
printf("0.1 * 2**%d = %f\n", exp, x*pwr);
}
}
main() {
int exp,pwr; float x;
x = 0.1;
exp=0; pwr=1;
while (exp<30) {
exp += 1; pwr *= 2;
printf("0.1 * 2**%d = %f\n", exp, x*pwr);
}
}
main()
{int exp,pwr; float x;
x = 0.1;
exp=0; pwr=1;
while (exp<30)
{exp += 1; pwr *= 2;
printf("0.1 * 2**%d = %f\n", exp, x*pwr);
}
}
The first is most like the way people write HTML and XML, sigh.
The third and fourth are most like Lisp-PrettyPrint.
(Hmm, the more I look at that fourth way, the more I like it!)
The reason why Lisp wins is because in Lisp the open parens is
*before* the keyword operator that introduces the form (the
function name such as printf/format or special operator such as
while/loop) rather than after, so that parens is naturally at the
*starting* identation level, so you don't have a choice whether to
put it on the same line (far to the right) or the next line after
the starting keyword (wasting a whole line), so there's no debate
where to put it.
> The only reason people like it is because it's what they grew up with.
That's a valid explanation *only* for people who already knew how
to program using C (or Java or C++). How do you explain brand-new
CS/codingMonkey students claiming they like C syntax better than
Lisp s-expressions? Is it that C-proselytizers have gotten to them
first, before they ever wrote their first line of code, showing
them what software sourcecode *should* look like? If so, we need to
beat them to the punch!
OK, here's a philosophic point to score:
There are two ways to look at a rule of logic, such as Deny Disjunction:
-1- Premise: -Happy
Built-in inference rule: -Happy -> Sad
Conclusion: Sad
-2- Premise#1: -Happy
Premise#2: Happy .OR. Sad
Inference schema "Deny Disjunction": [-#1] + [#1 .OR. #2] ==> [#2]
Instantiation of inference schema by binding parameters (#1=Happy #2=Sad):
[-Happy] + [Happy .OR. Sad] ==> [Sad]
Conclusion: Sad
Note how in -1- the domain-specific knowledge that Happy .OR. Sad
is taken for granted and compiled together with Deny Disjunction
into such built-in rules of inference as -Happy -> Sad, like if you
tell a child you aren't happy the child without thinking will
presume that you are sad,
whereas in -2- the Happy .OR. Sad is an ordinary premise, only the
Deny Disjunction schema is taken for granted, and the two premises
are fed to Deny Disjunction "at runtime".
(By the way, you can go an extra level deep in avoiding
pre-compiled rules of logic, by having Modens Ponens as the *only*
rule of logic, whereby Deny Disjunction is a formal third premise.)
Now we make a similar distinction when applying a function to arguments:
-1- Input data: 64
Built-in function: SQRT
Feed 64 through the function SQRT, and out comes 8.
-2- Input data: 64
Input function: #'SQRT
FUNCALL that function to that data, and out comes 8.
Note the distinction between -1- where SQRT is treated as a
built-in part of the language to be taken for granted and executed
directly as if a machine instruction, and -2- where #'SQRT is a
first-class function object that is passed to FUNCALL rather than
executed directly.
The corresponding natural diagrams are:
-1- 64 --->[dataSlot]
[BuiltInFunctionSQRT]---> 8
-2- 64 ------>[dataSlot]
[BuiltInSchemaFUNCALL]---> 8
#'SQRT -->[functionSlot]
The corresponding natural textual representations are:
-1- 64 SQRT (Forth or HP-calculator syntax)
SQRT(64) (Fortran or Algol or C syntax)
-2- #'SQRT 64 FUNCALL (Forth syntax)
FUNCALL(#'SQRT, 64) (Fortran or Algol or C syntax except for #' Lispness)
Now given that in Lisp we have a natural way to represent lists of
data values by putting them between parens, -2- can now be expressed as:
(#'SQRT 64) --EVAL-> 8
where EVAL decomposes the list of two values to be a function
followed by an ordinary argument, then calls FUNCALL on those
parameters. Now just make EVAL implicit as the thing that happens
whenever you type anything, and allow it to automatically wrap #'
around the first element in the list which is always supposed to
be a function anyway, and you have:
Typed input: (sqrt 64)
Result typed out: 8
Our good old friend the Read-Eval-Print loop!
(More generally, in principle EVAL calls (mapcar #'EVAL (cdr <form>))
to get the list of evaluated arguments, then calls APPLY instead o
FUNCALL which takes a list of arguments within a single schema
instead of each argument separately with different schemas for each
different number of arguments.
Thus instead of separate schemas for each of these:
(fn arg1) => (funcall1 fn (eval arg1))
(fn arg1 arg2) => (funcall2 fn (eval arg1) (eval arg2))
(fn arg1 arg2 arg3) => (funcall3 fn (eval arg1) (eval arg2) (eval arg3))
we have a single schema:
(fn . args) => (apply fun (mapcar #'eval args))
See how nice it is the Lisp s-expr eval way?
No wonder the original idea of M-expressions was abandoned!!)
So the whole philosophical difference is as to whether SQRT and
other functions are treated as part of the built-in syntax of the
language (in Fortran Algol and C), or as first-class function
objects passed around just like any other kind of data and
interpreted by some more general (Funcall or Apply or Eval) schema
which *is* built-in (in Lisp).
If you have first-class function objects, then you just naturally
have s-expressions and EVAL, instead of M-expressions. :-)
Hey, KentMP and PascalB and KennyT, do I get some kind of award for this essay?
Dihydrogen Monoxide <············@gmail.com> writes:
> On May 29, 1:48 pm, ···········@c4l.co.uk wrote:
>> On 26 May, 05:17, Rares Marian <············@gmail.com> wrote:
>>
>
>> Presumably the reason to solve the problem is to make Lisp more widely
>> used.
>
> Nope. Reading fatigue. I get headaches when I see ()(())))()())))).
Ignore them. Use indentation rather than parenthesis counting. Use an
editor that takes care of matching/closing parens and manipulating
s-expressions.
BTW, I don't really get your proposal as I can't see how it would make
your reading problem any less of an issue and if you use something like
paredit under emacs, much of what you appear to want is already there.
Tim
--
tcross (at) rapttech dot com dot au
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: New notation
Date:
Message-ID: <rem-2008may31-005@yahoo.com>
> From: ···········@c4l.co.uk
> Presumably the reason to solve the problem is to make Lisp more
> widely used. I think what prevents that happening is not the
> specific notation, per se.
Not to mention that using Lisp to implement specialized "languages"
for each different problem domain can perhaps completely eliminate
the syntax "problem" for the kinds of programmers/monkeys you
mention below.
> Since the creation of Lisp, programming has changed from being
> the exclusive domain of skilled artisans to be dominated by
> generic, highly disposable, code-monkeys.
There we go: For each problem domain, maybe even for each **part**
of each problem domain, implement a different domain-specific
"language". Then write a tutorial that coaches newly-hired code
monkeys how to do their job and/or write a
computer-assisted-instruction module which trains and tests
proficiency. In fact the tutorial and/or CAI module could be made
available to prospective applicants *before* they are approved for
hire. If they can't pass an automated test of acquired skills at
writing code using each of the required DSLs, they aren't
considered for employment yet, and have to either spend more time
with the tutorial and/or CAI module or look for employment
elsewhere.
> Companies want programming languages where any idiot programmer
> can understand what a piece of code does.
How about instead:
Any idiot programmer WHO HAS PASSED A PRE-EMPLOYMENT DSL EXAM
can understand what a piece of code USING THAT PARTICULAR DSL does?
So when there's a shortage of code monkeys for some particular DSL,
a job opening is announced, with the tutorial and/or CAI module,
and the final-exam, for that particular DSL, made available for
prospective applicants. Anyone who passes the final exam is then
provided with an individualized employment-application. If the
application also looks reasonable, an interview is granted. If the
interview goes well, the applicant is immediately hired on a
temporary basis to eliminate the backlog for that particular DSL,
and any spare time is used to learn other DSLs that have become
needy in the mean time. If the already-hired person can learn the
second DSL and pass the final exam for it before a brand-new
applicant does likewise, the job goes to that already-hired person.
> They don't want languages where the code might take several weeks for
> a mediocre programmer to comprehend, even if the programmer would be
> far more productive with it after expending the effort.
There's a difference between writing applications and writing tools
to aid software development. Code monkeys who learn DSLs should be
adequate for just writing applications using those particular DSLs.
*Real* programmers, such as myself, would be needed to write tools,
such as implementing the DSLs themselves.
Note that DSLs are recursive in the following sense: There would of
course be a DSL for writing tutorials and for writing CAI modules
and for writing DSL-final-exams. A code monkey who has learned one
of those three meta-DSLs and who is smart enough to understand a
new DSL for which tutorial/CAI/exam doesn't yet exist ought to be
able to devise a halfway decent tutorial or CAI module or
final-exam, and then experience would suggest upgrades until the
tutorial is really sufficient to explain the new DSL or the CAI
module is really sufficient to teach the new DSL or the final-exam
is really sufficient to weed out people who don't understand the
new DSL. (Note: My previous major paying job involved a DSL for
expressing an entire course of CAI for differential calculus and
related problem solving and analytic-geometry graphics to
illustrate problems. The CAI-DSL was an extension to a CAI-DSL for
a online course for symbolic first-order-logic that had been
available at Stanford previously whereby students were given
premises and a goal and needed to specify the steps of a
derivation. My first task, after *taking* the online FOL class to
get a feel for the machinery, was to propose additional mechanisms
to include differential-calculus logic-steps within that basic
framework.)
> Lisp isn't going to win until you remove the features which make it
> Lisp. Changing the notation slightly doesn't do that, it just annoys
> people used to the normal notation. Changing the notation completely
> gives you a different language, which is fine, but many people
> wouldn't consider the result to be Lisp.
That is all moot if you go the multi-DSL route.
> 1. There is no hugely influential company pushing for the use of Lisp,
> in contrast to languages like Java and C#.
Good point. We gotta win on merit instead of P.R. and machinations.
DSLs can make programming so easy that anybody can do it, without
needing extensive training, just a few hours to learn and actually
become almost proficient at each new DSL.
For example, a DSL for recipes for cooking food, with a very strict
syntax, but with vocabulary so close to ordinary cooking jargon
that it's easy for just about any computer-literate cook to convert
an ordinary recipe into the provided forms/templates to generate
statements of the DSL. The benefit is that the compiler for the
recipe then automatically makes a list of *all* ingredients and
*all* cooking utensils etc. needed, without making any mistake
whatsoever, which is a great boon to novices trying to follow the
recipe that is generated (in plain English, or Spanish, or French,
or German, or Italian, or Greek, or Hebrew, or Russian, or Chinese,
or Tagalog, etc., all automatically). One thing I really hated
about recipes (when I used to actually have money to buy all the
ingredients) was that halfway through the recipe, after the eggs
were already broken and the milk and vegetable oil measured and
mixed with half the ingredients, I'd realize that I need some
utensil I didn't have or some spice that wasn't listed in the list
of ingredients because every real cook takes it for granted that
such spices are always available in any real kitchen and every real
kitchen has a complete set of utensils. Recipes compiled from our
cooking-recipe-DSL would always have a 100% complete list of
ingredients and utensils explicitly listed at the top to avoid such
a disaster. You can't take time out for a trip to the supermarket
to buy a spice or a utensil while the yeast in the partially mixed
ingredients are already bubbling!!!
> 2. Its notation is not C derived. There are plenty of people who
> object to Visual Basic solely because of its non-C-like syntax,
> rather than the more obvious reason to dislike it.
Like I said a few weeks ago, this can be avoided by not having any
syntax at all presented to the application programmer!! Have a
library of functions/methods available, indexed according to the
type of data you have at hand and the type of output data you need
to generate from that input. For example, you want to find the
index of the first occurrance of a particular character within a
string. So first you somehow get the string, and the character,
then you submit a search of the library of functions/methods
available to find what's available that combine a string and a
character to yield an integer. You come up with these search results:
(position <item> <sequence> &key :from-end :test :test-not :start :end :key)
(count <item> <sequence> &key :from-end :test :test-not :start :end :key)
(remove-and-count <item> <sequence> ...) => values: newsequence count
(delete-and-count <item> <sequence> ...) => values: modifiedsequence count
(substitute-and-count <newitem> <olditem> <sequence> ...) => values: newsequence count
(nsubstitute-and-count <newitem> <olditem> <sequence> ...) => values: modifiedsequence count
Obviously POSITION is what the programmer was looking for, so the
application programmer selects that function, and selects
checkboxes if any for keyword options that are desired.
The search engine doesn't *really* show the open-parens
function-name etc. as above, but instead shows a HTML form with
radio buttons for the various functions, and within each function
template it shows menus for the parameters (select some value
already created, or leave some value open to be filled in later by
top-down programming methodology), and checkboxes for the keyword
options (with additional menus for each of them that requires more
than a boolean parameter).
( ) COUNT [itemMenu:preferredCharacter] [sequenceMenu:preferredString]
[ ] :from-end (if checked, T is supplied automatically)
( ) :test ( ) :test-not (*) neither [predicateMenu]
[ ] :start [integerMenu]
[ ] :end [integerMenu]
[ ] :key [functionMenu]
Note how COUNT can take any arbitrary Lisp object as the <item>,
and any sequence as the <sequence>, but since the search query was
specifically for character and string as input the form is
automatically specialized to prefer the <item> being a character
and the <sequence> being a string.
> 3. It doesn't have a standard massive library containing a GUI
> toolkit, test framework, networking interface, etc.
That needs to be provided. The following environments should be supported:
- stdio
- CGI/HTML
- GUI (MS-Windows, Mac System 6 or 7, Mac System X, Linux, FreeBSD, etc.)
- RMI/SOAP
For GUI, Java has two different styles of implementation, one that
uses the system-provided widgets as much as possible (awt) and one
that uses only the barebones windows/panes from the system and does
all the painting and sub-controls itself (swing). Would it be
useful for Lisp to do it both ways too? Or is awt obsolete and only
the swing way should be provided by Lisp? What does CLIM do?
(I need to ask because the only GUI-CL I ever had access to was
MACL 1.2.2 which had its own object-oriented window system, off in
a different direction from CLIM, before CLIM was standardized.)
Are there any really good open-source modules for any of those
environments, including proper support for Unicode internally and
UTF-8 externally for network/file I/O?
Which reminds me. Java suffered growing pains when it needed to
accomodate Unicode (disconnecting type Character from elements of
Strings in the process). Has Common Lisp crossed that bridge yet,
or is portable/ANSI Common Lisp still US-ASCII for all practical
purposes?
On May 31, 6:34 am, ···················@spamgourmet.com (Robert Maas,
http://tinyurl.com/uh3t) wrote:
> *Real* programmers, such as myself, would be needed to write tools,
> such as implementing the DSLs themselves.
Mel, is that you?
<http://www.catb.org/jargon/html/story-of-mel.html>
···················@spamgourmet.com (Robert Maas,
http://tinyurl.com/uh3t) writes:
>> From: ···········@c4l.co.uk
>> Presumably the reason to solve the problem is to make Lisp more
>> widely used. I think what prevents that happening is not the
>> specific notation, per se.
>
> Not to mention that using Lisp to implement specialized "languages"
> for each different problem domain can perhaps completely eliminate
> the syntax "problem" for the kinds of programmers/monkeys you
> mention below.
>
>> Since the creation of Lisp, programming has changed from being
>> the exclusive domain of skilled artisans to be dominated by
>> generic, highly disposable, code-monkeys.
>
> There we go: For each problem domain, maybe even for each **part**
> of each problem domain, implement a different domain-specific
> "language". Then write a tutorial that coaches newly-hired code
> monkeys how to do their job and/or write a
> computer-assisted-instruction module which trains and tests
> proficiency. In fact the tutorial and/or CAI module could be made
> available to prospective applicants *before* they are approved for
> hire. If they can't pass an automated test of acquired skills at
> writing code using each of the required DSLs, they aren't
> considered for employment yet, and have to either spend more time
> with the tutorial and/or CAI module or look for employment
> elsewhere.
>
This is very close to a talk by Paul Graham that I listened
to. Essentially, he said that the way to go was to have your best
programmers write tools for the code monkeys to use to develop the
application and your code monkeys just have to learn how to use the
tools. Part of his argument is that good programmers often like to write
tools to make the problem domain easier to work with and that they
usually wrote good tools because of their higher interest and skill
set. He also believed that many good programmers will just get bored and
leave if they are forced to work on repetitive development and
maintenance tasks. A good set of tools means you will get consistency
from your code monkeys and keep your skilled programmers interested in
developing better tools and better understanding of the problem
domain. It also means you can keep just a few really good prorammers and
rely on less skilled, easily replaceable code monkeys for the rest and
more mundane tasks.
Personally, I have a little trouble with the whole concept of code
monkeys and the arguments based on the understanding that only 20% of
programmers are really interested and keen or talented. I've known a lot
of talented programmers who have essentially given up because their
skills are not recognised by management. There are a lot of very average
programmers out there, but I also suspect there are a lot of potentially
above average programmers who have not reach their potential because of
a lack of good mentoring and because all too often, management just
doesn't understand or recognise the value of experience and programming
skills. My last manager actually argued with me that he was a
good/competant programmer because he had written some word and excel
macros. He had no concept of abstract data types, algorithms,
efficiency, complexity or issues of maintenance. As long as the result
looked pretty and appeared to meet most of the clients requirements, he
was happy. It did not matter that the system was full of bugs and would
experience exponential growth in maintenance costs or would be nearly
impossible to update to meet evolving client requirements. He was an
idiot who has been promoted and is now the CEO and this is despite his
track record, which when examined over longer terms shows that with one
exception, every place he has managed has shown initial cost reduction,
but has been followed by huge cost blowouts 2-3 years later and huge
drops in client statisfaction and loss of business. The exception was in
his first IT management role, where he took over control in a totally
disfunctional team that had completely failed to deliver anything for a
long time. A big issue here is in the short-term focus of modern
management. His replacement has argued that we only need graduates in
the programming/technical role and that after a couple of years at that
level, management skills are all that matter. This is despite the fact
I've demonstrated very clearly and with quantitative as well as
qualitative evidence that the work done by more experienced and skilled
programmers is nearly always better in the sense that it meets client
requirements with fewer iterations, has less bugs reported and takes
less resources to maintain and extend in the long term.
Tim
--
tcross (at) rapttech dot com dot au
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: New notation
Date:
Message-ID: <rem-2008jun01-003@yahoo.com>
> From: Tim X <····@nospam.dev.null>
> ... a talk by Paul Graham ... He also believed that many good
> programmers will just get bored and leave if they are forced to
> work on repetitive development and maintenance tasks.
In a recession when there's been no paying work in Lisp for over
fifteen years, some of us (including yours truly) would be *glad*
to do any Lisp task no matter how boring and repetitive if it would
result in earned income. Back when I first became unemployed in
1991, I got an interview for a job doing CAD using an embedded
Lisp, just writing trivial scripts to specify the locations of
holes to drill in a piece of metal. The interviewer kept nagging at
me that I'd probably be bored, but I believe he was wrong, but I
never got the chance to prove him wrong because he didn't hire me.
If somebody will *now* offer me a paying job doing some boring
repetitive tasks using Lisp, I'll still available.
> It also means you can keep just a few really good prorammers and
> rely on less skilled, easily replaceable code monkeys for the rest
> and more mundane tasks.
Unfortunately all advertised jobs I would otherwise qualify for in
recent years require at least three years with WebSphere and JBoss.
Apparently nobody is really interested in putting good software
programmers back into paying employment.
> My last manager actually argued with me that he was a
> good/competant programmer because he had written some word and
> excel macros. He had no concept of abstract data types, algorithms,
> efficiency, complexity or issues of maintenance. ...
Too bad you couldn't convince him to "need" some task that would
demonstrate your manager's lack of skills (unable to accomplish the
task no matter how much time given) and your comparative good
skills (able to get the first version up+running in 2 hours, while
your manage was at a meeting and hence not watching over your
shoulder), to make a specially good impression.
> I've demonstrated very clearly and with quantitative as well as
> qualitative evidence that the work done by more experienced and
> skilled programmers is nearly always better in the sense that it
> meets client requirements with fewer iterations, has less bugs
> reported and takes less resources to maintain and extend in the
> long term.
Unfortunately all that hiring managers care about is years of
experience on very specific platforms (such as JBoss and WebSphere
that I mentionned earlier). 22+ years experience at designing new
algorithms and implementing them means *nothing* to any of them,
except in a negative sense that if I have 22+ years experience then
I must be over 40 hence too old to be of any value and I must cost
more than they have available to pay. (Truth is I'd be willing to
work at the legal minimum wage if I were offered a software
development position using Lisp. I'd even be willing to work
without pay for a few days, long enough to implement an underlying
structure for a new application, and a few use cases, just to
demonstrate my skills, if that will result in employment. But if I
say that, they decide I'm worthless. There's just no way to get
anyone to even consider me for employment. They insist on believing
I'm either worthless or too expensive, neither of which is actually
true.)
···················@spamgourmet.com (Robert Maas, http://tinyurl.com/uh3t) writes:
> Unfortunately all that hiring managers care about is years of
> experience on very specific platforms (such as JBoss and WebSphere
> that I mentionned earlier). 22+ years experience at designing new
> algorithms and implementing them means *nothing* to any of them,
> except in a negative sense that if I have 22+ years experience then
> I must be over 40 hence too old to be of any value and I must cost
> more than they have available to pay. (Truth is I'd be willing to
> work at the legal minimum wage if I were offered a software
> development position using Lisp. I'd even be willing to work
> without pay for a few days, long enough to implement an underlying
> structure for a new application, and a few use cases, just to
> demonstrate my skills, if that will result in employment. But if I
> say that, they decide I'm worthless. There's just no way to get
> anyone to even consider me for employment. They insist on believing
> I'm either worthless or too expensive, neither of which is actually
> true.)
As I see it you have two choices:
- develop (start-up mode) an application some customers will want to
pay to be able to use it (and then you get to choose the programming
language ;-)).
- learn JBoss and WebSphere (you've proved you can do it!), and get
hired.
--
__Pascal Bourguignon__
On Mon, 02 Jun 2008 17:21:59 +0200, <···@informatimago.com> wrote:
>
> - learn JBoss and WebSphere (you've proved you can do it!), and get
> hired.
What happens when you get done learning them, but the wizzers have
decided the latest shiny thing to know has moved on to todays fad?
--
One of the strokes of genius from McCarthy
was making lists the center of the language - kt
** Posted from http://www.teranews.com **
GP lisper <········@CloudDancer.com> writes:
On Mon, 02 Jun 2008 17:21:59 +0200, <···@informatimago.com> wrote:
>>
>> - learn JBoss and WebSphere (you've proved you can do it!), and get
>> hired.
What happens when you get done learning them, but the wizzers have
decided the latest shiny thing to know has moved on to todays fad?
You die.
GP lisper <········@CloudDancer.com> writes:
> On Mon, 02 Jun 2008 17:21:59 +0200, <···@informatimago.com> wrote:
>>
>> - learn JBoss and WebSphere (you've proved you can do it!), and get
>> hired.
>
> What happens when you get done learning them, but the wizzers have
> decided the latest shiny thing to know has moved on to todays fad?
Yes, you have to be a fast learner :-P
--
__Pascal Bourguignon__
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: New notation
Date:
Message-ID: <rem-2008jun04-003@yahoo.com>
> From: ····@informatimago.com (Pascal J. Bourguignon)
> As I see it you have two choices:
> - develop (start-up mode) an application some customers will want to
> pay to be able to use it (and then you get to choose the programming
> language ;-)).
So-far I've never been able to find any ideas for new applications
that anybody would be willing to pay for me to develop. And when
I've posted ideas about some new applications I'd like to make,
nobody has expressed any interest in such applications. Do you have
any ideas of what somebody might want? Do you know anyone willing
to pay money for an otherwise unemployed person to develop a custom
application?
> - learn JBoss and WebSphere (you've proved you can do it!), and get
> hired.
That's not really an option. I suppose I could read a tutorial on
the net that explains them, but without even a moment's hands-on
experience I'm pretty sure I wouldn't be able to convince a
potential employer that I have three years experience with them. I
don't know anyone with either who would let me get onto his/her
system and play with them to teach myself how to use them. Perhaps
you have them on your computer and would grant me access to them?
<http://www.roseindia.net/jboss/>
This lesson shows you how to build you [sic] web application and install
on the Jboss 3.0 application server. After the completion of this
lesson you will be able to compile, assemble and deploy your J2EE
application on Jboss 3.0 application server.
...
Since in this lesson we are developing one servlet and one jsp files [sic]
so our deployment descriptor is very simple.
Sigh, we've lost our programming and customer support jobs to
India, and now we have to suffer Indian tutorials.
(after .ear file has been built by 'ant', just as I used to do when
Tomcat was the J2EE application server:)
...
Statrt [sic] Jboss 3.0 and copy example2.ear file into the
JBOSS_HOME/server/default/deploy directory. ...
Where are instructions how to start Jboss??
... Jboss application server
automatically deploys the application. Open web browse and type
http://localhost:8080/example2 in the web browser.
That's nice.
Browse should show the screen something like this:
[lession2a.gif]
That's not helpful to me here on VT100 dialup through Unix shell and lynx.
By the way, what is a "lession"?? Is that another Indian typo?
Ant utility is very power full [sic] and it reduces the development
time significantly.
Ant on my laptop took about 4.5 hours to build a trivial demo J2EE
application. And then when I changed the source code, it refused to
recompile, said nothing needs updating, so there was no way to
modify the application except to rename all the source and config
files and spend another 4.5 hours building the demo under a
different name.
In general, this tutorial has nothing to say that I didn't already
know from my experience with Ant+TomCat, except that I need to
somehow find out how to start the Jboss server, which it doesn't
tell me how to do.
Rares Marian <············@gmail.com> wrote in
·······················@nlpi070.nbdc.sbc.com:
> What if we solved the readability problem?
Lisp readability problems can be caused by dyslispia. With dyslexia it can
become dyslipsia.
Rares Marian <············@gmail.com> writes:
> What if we solved the readability problem?
What if you studied history?
>
> I know emacs indents everything nicely but suppose we did the following:
> #1. Continue using parentheses to open
> #2. Use ] to close remaining open parentheses up to cursor on current line
> #3. Use } to close remaining open parentheses up to current line in file
This is a complexified version of what Interlisp (at least) did
decades ago. ] was the metabracket: It closed all parens open to that
point. Thus, '((1 2 3) (4 5 6) (7 8 9] was considered a complete
form. This makes more sense if you're typing forms directly into a
bare-bones REPL as opposed to launching Lisp as a subordinate process
from Emacs.
So, why did Common Lisp not take metabracket along with everything
else? Certainly the relevant implementors knew how to implement
it. Had it passed from fashion by the time the Common Lisp process had
begun?
From: Daniel Weinreb
Subject: Re: Why did Common Lisp not include metabracket? (Was: New notation)
Date:
Message-ID: <4842B488.4070705@alum.mit.edu>
Chris Barts wrote:
> Rares Marian <············@gmail.com> writes:
>
>> What if we solved the readability problem?
>
> What if you studied history?
>
>> I know emacs indents everything nicely but suppose we did the following:
>> #1. Continue using parentheses to open
>> #2. Use ] to close remaining open parentheses up to cursor on current line
>> #3. Use } to close remaining open parentheses up to current line in file
>
> This is a complexified version of what Interlisp (at least) did
> decades ago. ] was the metabracket: It closed all parens open to that
> point. Thus, '((1 2 3) (4 5 6) (7 8 9] was considered a complete
> form. This makes more sense if you're typing forms directly into a
> bare-bones REPL as opposed to launching Lisp as a subordinate process
> from Emacs.
>
> So, why did Common Lisp not take metabracket along with everything
> else? Certainly the relevant implementors knew how to implement
> it. Had it passed from fashion by the time the Common Lisp process had
> begun?
For one thing, it messes up your ability to do useful commands
like "forward sexp" and "kill sexp" in Emacs.
None of the Lisp dialects that were merged to form Common Lisp
used metabrackets. Of course we all knew about the idea, from
Interlisp, and various people had hacked up implementations, but
we didn't want them.
From: Pascal Costanza
Subject: Re: Why did Common Lisp not include metabracket? (Was: New notation)
Date:
Message-ID: <6afp0rF17pt3oU1@mid.individual.net>
Chris Barts wrote:
> Rares Marian <············@gmail.com> writes:
>
>> What if we solved the readability problem?
>
> What if you studied history?
>
>> I know emacs indents everything nicely but suppose we did the following:
>> #1. Continue using parentheses to open
>> #2. Use ] to close remaining open parentheses up to cursor on current line
>> #3. Use } to close remaining open parentheses up to current line in file
>
> This is a complexified version of what Interlisp (at least) did
> decades ago. ] was the metabracket: It closed all parens open to that
> point. Thus, '((1 2 3) (4 5 6) (7 8 9] was considered a complete
> form. This makes more sense if you're typing forms directly into a
> bare-bones REPL as opposed to launching Lisp as a subordinate process
> from Emacs.
>
> So, why did Common Lisp not take metabracket along with everything
> else? Certainly the relevant implementors knew how to implement
> it. Had it passed from fashion by the time the Common Lisp process had
> begun?
I think it's a good idea that Common Lisp didn't adopt this. It mixes up
language definition and development environment concerns. I wouldn't
want to see metabrackets as part of source code. This has nothing to do
with making it more convenient to type in source code.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Mon, 26 May 2008 04:17:09 GMT, <············@gmail.com> wrote:
>
> What if we solved the readability problem?
What 'readability' problem? Parens don't exist to the experienced
eye, and if noobs are incapable of getting to that point, they will
fail soon anyways. Let Darwin rule!
--
One of the strokes of genius from McCarthy
was making lists the center of the language - kt
** Posted from http://www.teranews.com **