LISP format (happy to read)
Cad Bilbao
First of all, thank you very much for answering.
You mentioned that I should change my way of writing my
code:
>(setf myList '())
> (with-open-file (f "c:/input.txt" :direction :input)
> (loop for line = (read-line f nil nil)
> while line
> do (
> (setf myList(append myList line)
> );end-do
> );end-while
> );end-loop
> );end-with
to: setf myList (append myList line)))))
Is it very important???? I'd prefer my annotation, because
I come from Java and C++...
Kent M Pitman
Is it important to make 99% of Lisp programmers happy? Some code is
written in the dark of night and will never be shown to others, and
you can put the parens where you like. But if you plan to show it to
others, then it IS important. Languages should be written for others
familiar with the language to receive the information. There is no
material debate about correct style on this point in the Lisp
community. You will be routinely berated on this point if you waste
this much vertical screen space on a non-issue and clutter code with
comments that are painful to change (or easily overlooked) if the
operator name at the other end changes. In correctly written Lisp
code, you can tell by indentation that the parens are matched. Doing
what you have done is like riding a bike with training wheels. It
exposes how nervous you are about the parens at all, and it gets in
the way of any easy change to the code by a sophisticated user. You
REALLY do not want to write it this way and will thank people for
making you do it the other way once you get used to it.
There are occasional exceptions in very long code where the close
paren is several pages back and the paren may look visually detached
and perhaps out of place. Usually the cure is not to write long code
blocks, but sometimes it's unavoidable.
Even in the exception cases, you DEFINITELY should not write end-do
since end-do since it will be ambiguous whether you are closing an
end-do form for ending a do form. Either just write the operator name
or, as some like myself do in this RARE case, use the operator name
backward. (The practice of writing backwards is somehow historically
attributed to djikstra, but regardless, has the continuing virtue of
being painful to do and making you not want to do it a lot. ;-)
Will Deakin
> (The practice of writing backwards is somehow historically
> attributed to djikstra, but regardless, has the continuing virtue of
> being painful to do and making you not want to do it a lot. ;-)
I concur. The thought of typing ssalc-denifeder-fof-ecnatsni-etadpu
lots put me off too...
;)w
Pierre R. Mai
> Hi all!
>
> First of all, thank you very much for answering.
>
> You mentioned that I should change my way of writing my
> code:
>
> >(setf myList '())
> > (with-open-file (f "c:/input.txt" :direction :input)
> > (loop for line = (read-line f nil nil)
> > while line
> > do (
> > (setf myList(append myList line)
> > );end-do
> > );end-while
> > );end-loop
> > );end-with
>
> to: setf myList (append myList line)))))
Rather to
(defun read-my-input ()
(with-open-file (stream "c:/input.txt" :direction :input)
(loop for line = (read-line stream nil nil)
while line
collect line)))
Or, if you really want to collect the lines by hand, to
(defun read-my-input ()
(with-open-file (stream "c:/input.txt" :direction :input)
(do ((my-list '() (cons line my-list))
(line (read-line stream nil nil) (read-line stream nil nil)))
((null line)
(nreverse my-list)))))
Or, to really mirror your own approach:
(defun read-my-input ()
(let ((my-list '())) ; Use let instead of setf here!
(with-open-file (stream "c:/input.txt" :direction :input)
(loop for line = (read-line stream nil nil)
while line
do
(setf my-list (cons line my-list))))
(nreverse my-list)))
Note that in the second and third version, I'm putting new line items
at the front of the list, and reverse the list at the end, instead of
using append or nconc to place new items at the back. This is a
common idiom, because append/nconc have to traverse (and copy in the
case of append) the whole list on each iteration. This will turn your
algorithm from being O(n) into O(n^2). Doing the reversed collection
trick, you get O(2n) = O(n) performance.
> Is it very important???? I'd prefer my annotation, because
> I come from Java and C++...
It is very important! Consider how you would react if I wrote my C++
code like this:
int demo()
{for
(int x=0;
x<N;
x++)
{printf("%i\n",x);}}
For Common Lisp, we have very simple and globally accepted indentation
rules, which not only aid readability of code (people read code based
on indentation, not based on counting '(' and ')' characters), but
also manupulation of code with intelligent editors, like Emacs, which
will also automatically indent your code correctly, if you let it.
Regs, Pierre.
--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Takehiko Abe
> You mentioned that I should change my way of writing my
> code:
>
> >(setf myList '())
> > (with-open-file (f "c:/input.txt" :direction :input)
> > (loop for line = (read-line f nil nil)
> > while line
> > do (
> > (setf myList(append myList line)
> > );end-do
> > );end-while
> > );end-loop
> > );end-with
>
> to: setf myList (append myList line)))))
>
> Is it very important???? I'd prefer my annotation, because
> I come from Java and C++...
When reading a code, we look at the shape of the whole form
to see which form encloses which and where a form ends.
We don't bother to find out which paren of "))))))))" at the
end of the form closes which open parenthesis. When writing,
we rely on our editor to do the indentation and paren balancing
for us.
Anyway, just assume the lisper's conventional style is better
than yours for a while and try by yourself. I think this is
a kind of thing you can't appreciate without trying. (and don't
forget to get a good editor.)
abe
--
<keke at mac com>
Jeff Mincy
That is exactly the point.
Putting parenthesis indented on their own line, or annotating
parenthesis, as you have here shows that you are writing C code and
not lisp, and that you are thinking of the problem as a C programmer
would.
See past the parens and see the form. Indentation and tools like
emacs help.
-jeff
Tim Bradshaw
>
> Is it very important???? I'd prefer my annotation, because
> I come from Java and C++...
It's only important if you want to talk to other people. It's just
the same as if you chose to write Inglish, wyth stranj
punktyouayshon-AND-speling, or decide to wash once a year - you can do
so, but people will probably not want to talk to you very much.
Adhering to community norms is useful if you want to interact with the
community in a productive way
--tim
(And if you get the connotation that Lisp people consider that
C++/Java people use odd punctuation and spelling and don't wash enough
- why, that's more-or-less correct, especially for the C++ people who,
you must admit, are notoriously smelly, their feet, ick.)
Erik Naggum
| Is it very important???? I'd prefer my annotation, because
| I come from Java and C++...
Yes, it is just as important as not ending Java/C++ bodies with }}}}}.
You are writing in Common Lisp, now. If you continue to write in Java or
C++, may I suggest that you get a compiler that agrees with that choice?
I cannot _fathom_ what people are thinking when they start to use a new
programming language but are so stuck in their old programming language
that they have stopped listening to their surroundings and have stopped
taking in new information very relevant to their ability to learn the new
language. I do not understand why people think their past conclusions
and observations are _fundamentally_ more important than their future
conclusions and observations, either. And why does this happen so often
to programmers in explicitly and statically typed languages? Is it
because they are used to, indeed _need_ to, put a seal on all the new
information that keeps coming in, in order not to keep changing the code
and the class hierarchies and whatnot, because no matter when you design
these things, it is overspecified and premature? This may be such an
ingrained psychological factor that it may not even be conscious, but
then it is even more annoying. It may be one of the hardest thing to
unlearn from an old language, because it is such an unspoken thing that
it is mainly learned from fear and frustration, but even if that is the
case, it _should_ dawn on people that these feelings are out of place in
a better language. Instead, Common Lisp programmers have to deal with
the very annoying habit of immigrants from other programming languages to
want to pretend they are still living in their old cultures. Sigh.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
michael wolf
> I cannot _fathom_ what people are thinking when they start to use a new
> programming language but are so stuck in their old programming language
> that they have stopped listening to their surroundings and have stopped
> taking in new information very relevant to their ability to learn the new
> language.
I can't answer that in the general case (maybe it's a case of relating
what's new to what you know to an unhappy extreme), but the case of
people using Lisp and leaving )s in places more or less analogous to
}s in C is probably due to poor instruction.
Some people are introduced to lisp as part of an AI subject, and
getting into too much detail is viewed as tangential to the overall
goal of learning AI. If a poor lecturer doesn't require students to
buy a book such as Graham and instead gives out some handouts, and if
those handouts sometimes "confuse" )s with }s, well, that'll be the path
of least resistance.
Actually, it won't be the path of least resistance, but it'll appear
to be on first glance. (Writing lisp when you're thinking in C is
pretty frustrating.)
Trying to explain from experience, not defend.
mike
--
Michael Wolf
http://www.netspace.net.au/~mwolf/pgp.txt
F433 5BBB CDA1 AAB3 0EE8 8A25 CBAC B8A3 372A BCDF
Nils Goesche
> * Cad Bilbao
> | Is it very important???? I'd prefer my annotation, because
> | I come from Java and C++...
>
> Yes, it is just as important as not ending Java/C++ bodies with }}}}}.
> You are writing in Common Lisp, now. If you continue to write in Java or
> C++, may I suggest that you get a compiler that agrees with that choice?
>
> I cannot _fathom_ what people are thinking when they start to use a new
> programming language but are so stuck in their old programming language
> that they have stopped listening to their surroundings and have stopped
> taking in new information very relevant to their ability to learn the new
> language. I do not understand why people think their past conclusions
> and observations are _fundamentally_ more important than their future
> conclusions and observations, either.
Oh, I do understand that. I still remember the time when I knew
nothing but some Assembler, BASIC, Pascal, C: I thought all
programming languages where the same, more or less anyway (don't most
programmers still think so? I still meet programmers everywhere who
believe precisely that), and when Emacs came with (Emacs) Lisp, I
thought all I had to do was to learn yet another syntax. I didn't
understand all the talk about s-expressions anyway and simply assumed
that the closing parentheses meant about the same as the closing brace
in C. Where should I have known that Lisp was different? C
programmers much better than me told me all the time that all
languages differed only by syntax and were all inferior to C, anyway
:-) Stupid, sure, but it led me, too, to indent the way Mr. Bilbao
did. But only for a few days because it didn't work at all for (now)
obvious reasons.
It just took some time, I guess, to find out just how many of the
firm, old believes were wrong. You start out thinking that you know
pretty much all there is to know about programming and gradually find
out that you really know..., well, more like, nothing at all?
Consider nowadays some 24 year old programmer (no, that's not me :-),
still going to college, knows nothing but Java, but is already paid
lots of money for programming some servlets and told by everybody
around what a great hotshot he is... he may not really understand
what's going on in his computer science courses, but why should he
care very much? Doesn't that only show how `impractical' those
courses are, considering how great and important his own work is?
People need some time to grow up ;-)
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Erik Naggum
| I can't answer that in the general case (maybe it's a case of relating
| what's new to what you know to an unhappy extreme), but the case of
| people using Lisp and leaving )s in places more or less analogous to
| }s in C is probably due to poor instruction.
Speaking of poor instruction, most people seem to learn by copying
examples these days. I wonder why they have this urge to override the
examples they copy in certain ways. I attribute this to a misguided
notion that "I know enough now", but maybe there is something else going
on that causes people to stop listening to advice.
Håkon Alstadheim
> c...@bilbao.com (Cad Bilbao) wrote in message news:<604dab8.01112...@posting.google.com>...
> >
> > Is it very important???? I'd prefer my annotation, because
> > I come from Java and C++...
>
> It's only important if you want to talk to other people. It's just
> the same as if you chose to write Inglish, wyth stranj
> punktyouayshon-AND-speling, or decide to wash once a year - you can
> do so, but people will probably not want to talk to you very much.
> Adhering to community norms is useful if you want to interact with
> the community in a productive way
It is more like trying to learn French, but insisting on keeping
English spelling. If you don't give in to the lisp way all the way,
you will never get your mind around the lisp way of thinking. Lisp is
different, if you try to comfort yourself by keeping old habits, you
will never "get it".
--
Håkon Alstadheim, Montreal, Quebec, Canada
Erik Naggum
| I still remember the time when I knew nothing but some Assembler, BASIC,
| Pascal, C: I thought all programming languages where the same, more or
| less anyway (don't most programmers still think so? I still meet
| programmers everywhere who believe precisely that),
Hm. I just realized that I have always approached every language as if
it was all new to me. This probably explains why I seem unable to wrap
my head around Perl, which is _nothing_ if you start from scratch and try
to figure out what various constructs in it actually _mean_ before you
use them. Philosophically speaking, Perl must be the answer to this
fundamental epistemological mistake of wanting things to remain the same
while being different in some new, useful ways.
I keep hearing people with degrees in so-called "computer science" who
think that syntax is immaterial, which, if they are snotty and arrogant
enough when they teach it, can probably lead young, impressionable people
to believe that the "underlying" languages are indeed all the same, which
they sort of kind of are only in an extremely theoretical, fundamental
sense which nobody _should_ care about, anyway,
| I didn't understand all the talk about s-expressions anyway and simply
| assumed that the closing parentheses meant about the same as the closing
| brace in C. Where should I have known that Lisp was different?
Did it not look sufficiently different from everything else to either
trigger a SIGWTF to the seasoned C/Unix programmer? The typical C/Unix
programmer halts and dumps core and consequently thinks (Common) Lisp is
unintelligible and "weird" and invents some stupid reason his brain went
into overload, like too many parenthesis, already the source and focal
point of pain in the C language family (they signal trouble whenever they
are needed apart from the simple function call), but some appear to have
installed a reasonable handler for it and manage to keep running. I have
not heard about anybody who had decided to ignore SIGWTF, before, though.
| C programmers much better than me told me all the time that all languages
| differed only by syntax and were all inferior to C, anyway :-)
But that would be the only way they would differ from C that made them
all inferior to C. Goes to show how, if you want to conclude something
badly enough, the task is only to find the matching premises.
| It just took some time, I guess, to find out just how many of the firm,
| old believes were wrong.
In order to get a good grasp on new things, and all things are new in
some sense, it is better to assume that one's future observations and
conclusions are superior to one's past observations and conclusions.
| You start out thinking that you know pretty much all there is to know
| about programming and gradually find out that you really know..., well,
| more like, nothing at all?
But where does this stupid arrogance from ignorance come from? The only
way this can be "observed" is if you are surrounded by idiots and not
even a single person knows more or better than you. I find this very,
very unlikely to actually to anyone. So it has to be an attitude that
comes from somewhere else.
| Consider nowadays some 24 year old programmer (no, that's not me :-),
24? That is, like, 6 years too _old_, man. For a while, at least, only
those who were so young they were fascinated by absolutely _anything_
(think of a dog, who goes through its entire life being excited about the
same old things every day) could find satisfaction working with the buggy
browsers and the braindamaged web stuff that has consequently become the
most labor-intensive industry we currently have on this planet.
| still going to college, knows nothing but Java, but is already paid lots
| of money for programming some servlets and told by everybody around what
| a great hotshot he is...
There are strict laws against child labor, but none against ignorant
labor. Maybe it should be the other way around.
| Doesn't that only show how `impractical' those courses are, considering
| how great and important his own work is?
The problem is that many of them _are_ impractical.
| People need some time to grow up ;-)
Well, this is true. As long as they realize they need to, and that they
never stop needing to, I can accept that. The problem is when they never
grow up because they think they do not have to, anymore. Such as because
some manager fresh out of his mind (and business school) chose the wrong
way to run his business and hired some jerk to try to fix it with HTML
and JavaScript. I mean, what do they learn in business school these days
that could cause anyone who is let out of them to make such mistakes?
Maybe they have not grown up, either. I tend to think that educating
people barely out of their teens in business administration, when they
know what being an employee means, let alone what they do, is completely
insane, but the whole market is like that, now. Stupid, well-educated,
ignorant youths who had no time to grow up before they got control over
so much money, can do nothing but harm. Hiring people who have had no
time to grow up seems to be a highly communicable "mental disease".
Rob Warnock
+---------------
Especially when one considers typos -- I suspect that
should probably be ssalc-denifeder-fo-ecnatsni-etadpu, yes? ;-}
-Rob
-----
Rob Warnock, 30-3-510 <rp...@sgi.com>
SGI Network Engineering <http://www.meer.net/~rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: aaan...@sgi.com and zedw...@sgi.com aren't for humans ]
Frank A. Adrian
> Maybe they have not grown up, either. I tend to think that educating
> people barely out of their teens in business administration, when they
> know what being an employee means, let alone what they do, is completely
> insane, but the whole market is like that, now. Stupid, well-educated,
> ignorant youths who had no time to grow up before they got control over
> so much money, can do nothing but harm. Hiring people who have had no
> time to grow up seems to be a highly communicable "mental disease".
Yes. Because they're "cheaper". Note the quotes. We all know that they
actually aren't cheaper, that the time they spend hacking with
brain-damaged languages, with ill- (or non-) conceived designs, with the
defects they introduce into their code, will all cost much more over the
long run. But to a COO, steeped in the culture of humans as fungible labor
units, they *are* all the same. Same burden cost, same average output, and
same result as everyone else who runs a company.
Inexperienced workers are also more maleable and easy to control. Unable
to see insane decisions for what they are (How else can you account for the
popularity of Dilbert among engineers? Dilbert is not a farce, it's a
tragedy), they can be driven into long hours of overwork by selling them a
heroic vision of themslves and their leaders, rather than seeing the issue
as what it really is - using substandard strategies and tools with
employees having knowledge that reaches only the submoronic level that
sadly *is* standard today.
I'd like to think that the marketplace in programmers and platform choices
(not to mention managers) is somehow rational, but I have seen little
evidence of it recently.
faa
Software Scavenger
> Inexperienced workers are also more maleable and easy to control. Unable
Consider a hypothetical situation. A young and relatively
inexperienced middle manager, call him X, is going to hire an
employee. X has a choice between hiring Y or Z. Y or Z will then be
working for X. Y is even younger and less experienced than X, while Z
is older and more experienced than X. Factors for X to consider
include not only why X needs Y or Z, but also why Y or Z needs X. If
X hires Z, Z might make X redundant. If X hires Y, their careers
might grow in harmony, with X always being Y's boss, as the two of
them advance through the levels of management.
The only one of the three who can really learn a lesson from this is
Z. X and Y are already doing what will help them the most. What Z
needs to learn is that the person to apply to for a job is someone
older, wiser, and more experienced than Z. That might mean applying
for a job as vice president instead of as programmer. But a vice
president can do a lot of programming, especially if there are better
ways to do things with computers to make the company more successful.
Z has to sell those ideas to the president. The fact that Z can do
the work without hiring programmers should be seen as a big selling
point.
Translating the above paragraphs to Lisp, (> Z (* X Y)).
Paolo Amoroso
wrote:
> Erik Naggum wrote:
[...]
> > so much money, can do nothing but harm. Hiring people who have had no
> > time to grow up seems to be a highly communicable "mental disease".
>
> Yes. Because they're "cheaper". Note the quotes. We all know that they
[...]
> long run. But to a COO, steeped in the culture of humans as fungible labor
> units, they *are* all the same. Same burden cost, same average output, and
> same result as everyone else who runs a company.
From "The Entrepreneur's Manual" (by Richard M. White Jr., Chilton Book,
1977): "Surround yourself with the highest caliber people. Remember that
first rate people hire first rate people--while second rate people hire
third rate people".
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Gareth McCaughan
> Either just write the operator name
> or, as some like myself do in this RARE case, use the operator name
> backward. (The practice of writing backwards is somehow historically
> attributed to djikstra, but regardless, has the continuing virtue of
> being painful to do and making you not want to do it a lot. ;-)
One of Knuth's books or articles mentions a student of his
who was moved to write, somewhere in his code,
do
[stuff]
od; comment bletch tnemmoc
which seems about right to me. :-)
--
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc
Thomas F. Burdick
> Inexperienced workers are also more maleable and easy to control. Unable
> to see insane decisions for what they are (How else can you account for the
> popularity of Dilbert among engineers? Dilbert is not a farce, it's a
> tragedy), they can be driven into long hours of overwork by selling them a
> heroic vision of themslves and their leaders, rather than seeing the issue
> as what it really is - using substandard strategies and tools with
> employees having knowledge that reaches only the submoronic level that
> sadly *is* standard today.
I really don't understand how some of you all can stand this
environment. Some of you out there have decently sane jobs, but some
of you are pinning away for Lisp in an insane world of Java and UML.
I've worked as a programmer before, but I've also decided that if I
wanted to keep my sanity and love of code, I'd do better to work in a
cafe, shipyard, bindery. Even just the mechanics of it -- after a
long day of typing, I don't have too much more typing in me. Part of
the reason I want to go to CS grad school (in addition to that it
sounds like the process itself would be enjoyable -- or could be) is
because I think that'll increase my chance of getting work programming
that's fun, at least some of the time. Otherwise -- well, I've got
other skills that can be me paid, and not kill my love of code.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Kenny Tilton
coolest hacks I pulled off in tall buildings were in COBOL. The macro
language underlying both was COPY...REPLACING. :)
OTOH, it's a good idea to get an advanced degree while you are still
young enough to take academic BS seriously. :)
kenny
clinisys
"Thomas F. Burdick" wrote:
>
> I really don't understand how some of you all can stand this
> environment. Some of you out there have decently sane jobs, but some
> of you are pinning away for Lisp in an insane world of Java and UML....
Alain Picard
> I really don't understand how some of you all can stand this
> environment.
It's even _worse_ than you think. That is, a majority of the
people in that environment (which, coincidentally (?) has a large
overlap to users of Visual Anytool++) don't even _realize_ they're
in hell, and that the hell is of their own devising. Thus they
are blinded to the possibility of getting out of hell.
In case you're wondering: no, I am NOT being ironic, sarcastic, etc.
I am in dead earnest.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <1995May29....@netlabs.com>
Peder O. Klingenberg
> Especially when one considers typos -- I suspect that
> should probably be ssalc-denifeder-fo-ecnatsni-etadpu, yes? ;-}
Or even ssalc-denifeder-rof-ecnatsni-etadpu.
HTH :)
...Peder...
--
Cogito ergo panta rei.
Rob Warnock
+---------------
| rp...@rigden.engr.sgi.com (Rob Warnock) writes:
| > Especially when one considers typos -- I suspect that
| > should probably be ssalc-denifeder-fo-ecnatsni-etadpu, yes? ;-}
|
| Or even ssalc-denifeder-rof-ecnatsni-etadpu.
Yikes! In my haste, I miscorrected Will's typo. ["Always check the
CLHS before posting; *always* check the CLHS!", he berates himself.]
Thanks for setting me straight...
Will Deakin
> Yikes! In my haste, I miscorrected Will's typo. ["Always check the
> CLHS before posting; *always* check the CLHS!", he berates himself.]
Thanks for this. It made *me* laugh anyway,
:)w
Tim Bradshaw
> should probably be ssalc-denifeder-fo-ecnatsni-etadpu, yes? ;-}
I can feel an emacs macro coming on here...
--tim
Josh Huber
> I can feel an emacs macro coming on here...
I'm sure there's a better way to do this, but here it is:
(defun reverse-string (start end)
(interactive "r")
(let ((reversed (concat (reverse (string-to-list
(buffer-substring start end))))))
(kill-region start end)
(insert reversed)))
yojne,
--
rebuH hsoJ
Erik Naggum
| I'm sure there's a better way to do this, but here it is:
How annoying. Emacs Lisp does not allow a string argument to reverse. Foo!
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
Kenny Tilton
Alain Picard wrote:
>
> t...@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > I really don't understand how some of you all can stand this
> > environment.
>
> It's even _worse_ than you think. That is, a majority of the
> people... don't even _realize_ they're
> in hell, and that the hell is of their own devising. Thus they
> are blinded to the possibility of getting out of hell.
>
> In case you're wondering: no, I am NOT being ironic, sarcastic, etc.
> I am in dead earnest.
I can confirm this. Worked in a dreadful shop where they considered it
normal to get paged at all hours of the day every day just to get
through the day's production jobs. Meanwhile I and every other
consultant never stopped telling them what they were doing wrong and how
easy it would be to mend their ways. Blank stares. Consultants wrote new
code while staff baby-sat production day and night. We seriously
estimated our effectiveness to be downgraded 80-90% by their practices.
The dubious good news is how much money and work they threw at anyone
who could get anything done in that environment. Dubious because it was
the old golden handcuffs thing: too much money to walk away from no
matter how onerous the conditions.
And one good thing in general about the Real World is that while the
conditions are tough you can still do great work and develop a superstar
rep, winning all sorts of perks, plum assignments, money, maybe even
someday influence things.
meanwhile, is academia all that great? I cannot answer, never went past
a BA. But what happens to programming when it gets detached from the
pressure of delivering systems efficiently?
Hell, I stumbled onto Semaphors just trying to layout a fraction in a an
educational math program, and now I am doing utterly insane stuff with
Semaphors for (yawn) a clinical trial management package. And while
Semaphors IMHO are breaking new ground in real-world information
processing, the academic Constraints research programme is dead. (Don't
tell the current researchers that. <g>) And the reason the academic
program went nowhere is precisely because they were doing research for
research's sake, while I am just trying to deliver apps. They went after
the Grail of multi-way partial constraints out of admirable curiosity,
but faced with a job to do I went with boring one-way, spreadsheet-like
dataflow and am having a ball producing unusually complex, unusually
bug-free applications.
Pardon the rant. :)
kenny
clinisys
Matthew X. Economou
Erik> Speaking of poor instruction, most people seem to learn by
Erik> copying examples these days. I wonder why they have this
Erik> urge to override the examples they copy in certain ways. I
Erik> attribute this to a misguided notion that "I know enough
Erik> now", but maybe there is something else going on that causes
Erik> people to stop listening to advice.
In some cases, it's because the examples are all the documentation the
programmer in question has. I know in my case, all of the Emacs Lisp
I have ever written (i.e. not much) has been cribbed from various
examples, with a little help from apropos, describe-variable, and
describe-function. This is because I have been unable to find
documentation (other than code itself) for most Emacs Lisp software,
including Emacs itself. As a result, my Elisp is naive at best, and
generally wrong/ugly/inefficient.
--
"We know for certain only when we know little. With knowlege, doubt
increases." - Goethe
Brian P Templeton
access the Emacs Manual, the Elisp Reference, and the Elisp Tutorial.
--
BPT <b...@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Tim Bradshaw
>
> It's even _worse_ than you think. That is, a majority of the
> people in that environment (which, coincidentally (?) has a large
> overlap to users of Visual Anytool++) don't even _realize_ they're
> in hell, and that the hell is of their own devising. Thus they
> are blinded to the possibility of getting out of hell.
Yes, I hate that. You spend all this time trying to explain to people
that they don't *have* to hammer nails into their own heads all the
time, only to discover that they *like* it because it's all they've
ever known.
--tim