In article <ey3hehhtmai....@cley.com>, Tim Bradshaw <t...@cley.com> wrote:
> * marcin wrote:
> > What countries other than the UK use left-hand? > > (Yes, I know who wrote this)
> Japan, I think. New Zealand, Australia, India. Probably lots of > other former British colonies (not that Japan was a colony, but ...)
Japan certainly. My car was imported to NZ from Japan in used condition (around 100,000 km), and the same is true of more than half of the first time NZ registrations. We couldn't do that if the Japanese built their domestic model cars for the wrong side of the road...
All the Pacific Islands of which I am aware (Fiji, Tonga, Western Samoa, Vanuata...), with the obvious exceptions of New Caledonia, Tahiti, and Hawaii. I'm not aure about American Samoa.
In article <cc0d708e.0208261334.21c1b...@posting.google.com>, anisotro...@hotmail.com (Will Deakin) wrote:
> [2] although having spoken to people from the states recently, it is > apparent that roundabouts are a bit of a european foible.
Americans seem to prefer 4-way stop signs or traffic lights. Which I *hate*!!! With light-to-medium traffic flows roundabouts are just *so* easy and fast to use -- and fuel efficient, too. You only have to look in *one* direction to see if you have to stop or not.
Christopher Browne <cbbro...@acm.org> writes: > Hazarding a guess, I'd be totally unsurprised if the "Chunnel" traffic > were arranged in vertical layers, so that there wouldn't be any "left" > or "right" in the tunnel. If there were two lanes on a particular > layer, both would be travelling either towards France or towards > England. And the "parity" of the lanes would get managed at the ends, > with big irritating signs saying things like:
> "Entering England: Fromage-Eaters be aware you will enter on the > LEFT side of the road. Don't get it wrong, you frogs..." > and > "Bienvenue a France! Ici on conduit les automobiles vers le droit!"
zi...@netvision.net.il (Ziv Caspi) wrote in message <news:3d69f031.166956420@newsvr>... > in C for an embedded computer. Reading the LISP sources from printouts > was incredibly painful when compared with C, despite the fact that it > was shorter by a factor of three.
When people learn a new language, they tend to blame the language for their difficulties, especially when it's very different from their native language. A big breakthrough in their learning comes when they learn to respect the language as it is rather than trying to make it fit their image of how it should be. Gradually it becomes transparent to them, and they no longer remember how hard it was for them while learning.
Some people never really learn a particular language, but always approach it superficially and painfully, and try to avoid it as much as possible. The essence of learning Common Lisp is reaching the synergy that comes from understanding lots of its features well. That synergy gives you a kind of power that makes you start to love the language and want to learn it completely.
> (I also remember reading that there is a thing near Dover where, in > conjunction with big signs, people are employed to stop drivers if > they look like the are driving on the wrong side of the road or going > round roundabouts[2] the wrong way.)
Assuming there is a wrong way...there's the "magic roundabout" in Hemel Hempstead that you can go either way around(!)
-- For þæm se þe his cræft forlætt, se bið fram þæm cræfte forlæten. -- Ælfric (setq reply-to (concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))
* zi...@netvision.net.il (Ziv Caspi) | 1. It doesn't help you when you're reading printouts.
Why do you consider it important that programming languages be optimized for printouts? And what kind of printouts? Line printers with 132-column zebra paper? Does processing with lgrind and printing on 1200dpi laser printers solve your problems? How about color printers? Please let us know how we can solve your printout problems while we continue to read source code on high-resolution graphical workstations with coloration aid and dynamic collapsing and expansion of structure.
| 2. Editors can also get confused.
Are you arguing against me because you have some misguided notion of perfection such that since my position does not live up to your standard of perfection since you can invent all sorts of bogus non-problems, you should discard it entirely without even thinking about it?
/Something/ is clearly confused here.
| > Sorry, but this is nonsense. | | Don't be sorry. Rather, explain your position. Is the proper response | to "this is nonsense" is "no, it's not"?
I note that you choose to criticize me rather than explain your own position better. You had the opportunity to expand on what you meant and make it make more sense, but chose to address my behavior, instead, which makes me think that you have absolutely no defense whatsoever against my charge that it is nonsense. And as nonsense, it merits absolutely no further comment on my part. It is /your/ position. Deal more productively with rejection.
If you post more unproductive articles, I am unlikely to want to respond.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
>> On 26 Aug 2002 02:08:08 +0000, Erik Naggum <e...@naggum.no> wrote: >> [...]
>> > If you /understand/ proper nesting, there is no problem. If you do not want >> > to understand it further than you already have, that will be evidenced in >> > the choice of a verbose end-tag and tags that close at the wrong point as >> > seen by the user. Whether you use \i{foo} or @i{foo} or <i foo> does not >> > matter much, but using <i>foo</i> is a major disaster as far as teaching the >> > users the value of structuring information is concerned.
>> And yet the question of proper nesting is different than the question >> of redundant information in end-tags. XML has proper nesting, >> redundant end-tags information, and I've yet to see an XML document >> where the author got it wrong.
>Yes, but this what is stupid. The rules of the language says you >*must* properly nest the tags. However, the syntax suggests that not >nesting is possible. Why else introduce the verbose closing tag >unless you could close something else than the last opened tag?
To help readers (both human and mechanized) catch errors closer to the source. XML parsers are *required* to refuse to accept documents with non-matching end-tags, and they all do so, easily. The possibility-of-error you talk about is theoretical (at least I never met it in practice).
>It is a case of the rules pointing in one direction and the syntax >pointing in the exact opposite way. Furthermore, the only thing the >verbose closer offers over a generic close is the chance to get it >wrong. This is simply not helpful in any way.
No, it is very helpful for people who write XML/TeX/LaTeX documents by hand and tend to make mistakes. As a preemptive strike, I'd like to mention that editors don't help much here. If it's limiting you to only "well-formed" syntax (to use an XML term), the editor is too annoying; if it's free-form and only provide paren matching, once you have an error you need a long time to find it.
Consider that people generally write XML/Tex/LaTeX as one (sometimes large) tree per file. Indentation of such large files is often unpractical, because the maximum depth can become very large. If you don't have obvious "markers" in the document to help you recover from errors, you're basically screwed.
>I do not need extra opportunities to lose.
>The bloat is simply insult to the above injury.
Many error-detection algorithms rely on redundancy. This particular tradeoff is very common in the document-creation world (SGML, HTML, XML, TeX, LaTeX. The developers of XML (who came from the SGML world) were perfectly aware of the expansion in document size, as well as the problems of "extra opportunities to lose". I think it's clear they had a different perspective on the utility of this feature (which you might call a bug).
>> It is not obvious that use of \i{foo} (or {i foo}) is always better >> than use of <i>foo</i>. In TeX and LaTeX, for example, once the scope >> gets "too big", a switch is made to the \start{}...\stop{} way of >> doing things. While redundant, it helps in catching the types of >> mistakes people (as opposed to computers and geeks) tend to make.
>Indentation helps in lisp. It also helps with largish quoted material >in printed matter. Why shouldn't indentation help here? What if TeX >used [] and a lispy style?
>This equation >[equation > x = 42 y + 39 z] >will be useful to us later.
>Nesting is easy >[quote > The slithy toves, did gyre and gimbal in > [equation > a = 2[pi]r^2]] >and indentation helps tremendously and perhaps some party colors could >help further depending upon taste.
And if we could rely on users never making mistakes, we could rid ourselves of code to check for user input errors, right?
Assume a large document created according to this scheme. Now assume a user cuts a single ']' at one point, forgetting to put it back. The error can only be detected at the end, and very difficult to diagnoze. The following is properly balanced:
[ [ [ ] [ ] ] ]
Now remove one closing ]:
[ [ [ closing-bracket-no-longer-here [ ] ] ]
You can only detect that error at the end, and the error you'd get is that the first bracket is not closed. If your editor auto-indents, and you ask it to do that right after you cut that ], you're in for a VERY long search, because the entire indentation would be ruined. (Yes, editors should refuse to indent on these cases; but most do anyway.)
>> You make some misleading remarks with your (+ 2 2) vs. 2 + 2 example. >> (+ 2 2) can certainly appear in a scope that modifies it to mean any >> number of things other than 4. The difference between LISP and >> Algol-like languages (say, C) here is that in C it is usually quite >> easy to determine where the enclosing context that might affect the >> expression starts and stops (assuming this is not a string/remark/etc, >> you can limit your reading to the area between the previous and next >> semicolons, for example).
>Curiously, I have exactly the opposite opinion.
>Have you seen what C calls macros?
>#define MIN(X,Y) ((X) < (Y) ? (X) : (Y))
>#define ISWAP(X,Y) do { int Z; Z = (X); (X) = (Y); (Y) = (Z) } while (0)
>Automatic code generation loses its way >immediately and infix is harder to properly parenthesize.
This newsgroup surely doesn't need *me* to tell it that C-macros suck when compared with LISP's, now does it?
> And for >human written/readable code, once expressions get complicated, the C >way with its myriad of implicit rules becomes difficult to sort out.
This is a statement without justification -- I'm not sure what implicit rule you're referring to (there are so many :-) But most competent C programmers I know don't find this very restricting. One doesn't find a lot of code mixing binary arithmetic, logical operators, and integer arithmetic in a single expression (not in my experience, and certainly not in my code).
>> The difference between LISP and >> Algol-like languages (say, C) here is that in C it is usually quite >> easy to determine where the enclosing context that might affect the >> expression starts and stops (assuming this is not a string/remark/etc, >> you can limit your reading to the area between the previous and next >> semicolons, for example). This cannot be said about LISP.
>It cannot be said about C either. The "enclosing context" includes all >the #include files, where all manner of nastiness can (and often does) >reside.
It's true for the original example (if you find "/*... */; int a = 2+2; /*...*/" in a file, does 2+2 mean 4?).
Indeed, people can (and sometimes do) #define int to float and have other nasty side effects. Putting aside obfuscation competitions (both in C and LISP), however, generally in C you have a lot less context to sweep, and its easier to sweep that context because statement separation is done via other means than compounds, and compounds generally don't nest as much in a typical C program.
(The picture is muddier in C++, because you can have nested classes. Personally, I think that nested classes, like Pascal's nested procedures, are from the devil.)
Erik Naggum <e...@naggum.no> writes: > would burn out completely in less than three months. The reason Perl is > used mostly for small programs is that the immune system kicks in if you > overdose on it
ROTFL!
(I guess I'm a "both generations" lisp hacker since I "came home to lisp" after having OD'd on perl) -- (espen)
>> in C for an embedded computer. Reading the LISP sources from printouts >> was incredibly painful when compared with C, despite the fact that it >> was shorter by a factor of three.
>When people learn a new language, they tend to blame the language for >their difficulties, especially when it's very different from their >native language. A big breakthrough in their learning comes when they >learn to respect the language as it is rather than trying to make it >fit their image of how it should be. Gradually it becomes transparent >to them, and they no longer remember how hard it was for them while >learning.
Is it possible for one to respect the language as it is but still find some of its aspects lacking? (And just so that we're clear, when I begun that project I had several years of LISP in my mind, and I had much more LISP experience than C)
>Some people never really learn a particular language, but always >approach it superficially and painfully, and try to avoid it as much >as possible.
I assure you that isn't the case: I love LISP.
>The essence of learning Common Lisp is reaching the >synergy that comes from understanding lots of its features well. That >synergy gives you a kind of power that makes you start to love the >language and want to learn it completely.
Ask any programmer in any other language, and he'll count you several features in his language that he doesn't like. Ask Stroustrup about C++, and he'll admit tradeoffs had been made and some aspects of the result are not as well-done as the others. Why is this not true for LISP as well?
* Johan Kullstam | Yes, but this what is stupid. The rules of the language says you | *must* properly nest the tags. However, the syntax suggests that not | nesting is possible. Why else introduce the verbose closing tag | unless you could close something else than the last opened tag?
Historically, the idea was that omitted start- and end-tags should be inferrable. This is a bad idea for a large number of very good reasons, and XML did away with them, which is the same kind of improvement that drowning at a depth of 10 feet is an improvement over drowning at a depth of 100 feet, but in a Stroustrupesque move, XML decided to keep the antiquated end-tags which had now survived their usefulness. The whole syntax was an improvement over its predecessors in 1970, but after it had been adopted, it should have been further improved. As it transpired, that never happened and central figures in the SGML community resisted all changes that would make SGML obsolete. Ironically, this is precisely what happened with XML.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
>> 1. It doesn't help you when you're reading printouts.
>If your expressions are properly indented, scope will become visually >apparent through indentation. This is works just as well on a print >out as it does within your editor display.
>> 2. Editors can also get confused. Try, for example, the following: >> delete a closing paren somewhere in the middle of a file, and add one >> at the end. Ask your editos to indent-sexp (did I guess right? :-). >> Good luck locating the error.
>This is quite an easy error to spot using the very technique you have >alluded to. After programmatically indenting the entire body of >source code containing the transposed closing parenthesis, forms that >would normally only be top-level definers would never appear against >the left margin beginning at the position after the error. Therefore, >the last open parenthesis to appear on the left margin is the start of >the form which introduced the error.
The problem is not finding the start of the form. It's finding where in the form.
Yes, the best method is to locate those forms that you don't expect to see anywhere other than top. This only shows my point, however -- that these "special markers" are what helps you find errors. Ironically, this technique is based on the fact that forms in a file are not a list, and that some forms are restricted at the nesting level at which they appear.
>For decades, syntax-aware Lisp editors have had the ability to find >unbalanced parenthesis. It really does work quite well.
Note that the example I gave is *not* about unbalanced parenthesis.
* zi...@netvision.net.il (Ziv Caspi) | I assure you that isn't the case: I love LISP.
Yet it does not have a syntax you can live with? Could you please make up your mind before the "troll" verdict is handed down?
| Ask any programmer in any other language, and he'll count you several | features in his language that he doesn't like.
I highly doubt that this is true. First, you are now talking about /all/ programmers even though you object when you were not even included in a statement that made you think you were included. Gross generalizations are seldom welcome. Second, "doesn't like' is such an unqualified position. There are things I would like to change in Common Lisp (my current favorite is 32-bit fixnums on 32-bit hardware and then I have taken to use a local macro `set´ instead of `setq´ and `setf´, but the fact that I can is good), but from wanting to change to "do not like" is actually a /very/ long way for normal people. Third, if you have found /that/ many programmers who actively "do not like" features in their programming language and spend time on things they do not like, it could be because you are such a killjoy that you inspire people to complain. It is surprising what people will complain about if they think it is only acceptable to complain and how constructive they are if they think it is only acceptable to be constructive. Whining losers like yourself are a problem in a community that tries to /solve/ problems and stay excited about something. A lot of people come to this newsgroup and do nothing but complain about Lisp. I think maybe they are such heavy complainers that they think they read comp.lain.lisp.
| Why is this not true for LISP as well?
I fear you might have acquired too much experience with things you do not like in your life. This is actually a fixable condition. As you grow older, you realize that what life you have left is not worth wasting on things you do not like and you do something about it. Many young people never figure
this out until they lose their ability to like /anything/. In fact, that elusive ability to "stay young" is to continue to look for things to like and instead of disliking something, just leave it and go look for something else to like. So far, you seem like an amazingly grumpy old fart, yet you do not even appear to have reached your thirties. I find people like you very annoying since they will always conjure up some sort of "problem" to take away from other people's enjoyment.
People who survived the 80's and 90's tend to write Lisp, not 70'sish LISP.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
Raymond Toy <t...@rtp.ericsson.se> writes: > Yes, that was it! I understand that one day Sweden just decided to > switch sides and it was done. I wonder how many accidents there were > on that day? :-)
As I understand, they spent months putting "alternate" street signs everywhere, and covered them in cloth sacks. Then one night, with much trepidation, they moved the sacks over to the original signs. Everyone was obviously _so_ terrified that the accident rate _decreased_ significantly (for a while) as everyone drove in ultra-paranoid mode.
What a great story. Any chance England might see the light? :-)
(p.s. I live in Australia... and can finally drive without being a menace, after 5 years!)
* Paul Foley wrote: > Assuming there is a wrong way...there's the "magic roundabout" in > Hemel Hempstead that you can go either way around(!)
Actually, the Hemel magic roundabout is really a ring of little roundabouts connected by a short, circular, road. So really it's not a roundabout at all. I think (in fact I'm sure) there are others now, but it was the first and caused a lot of confusion.
--tim (grew up worryingly close to Hemel Hempstead)
* Ziv Caspi wrote: > Is it possible for one to respect the language as it is but still find > some of its aspects lacking? (And just so that we're clear, when I > begun that project I had several years of LISP in my mind, and I had > much more LISP experience than C)
Yes. I often describe CL to people as the `least bad programming language I know'.
*However*, the bitter experience of this group is that people whose problems are stated as `Reading the LISP sources from printouts was incredibly painful when compared with C, despite the fact that it was shorter by a factor of three' are generally failing to get past the surface layers to understand the problems that Lisp (and in particular CL) does have.
There are plenty of things I think could be improved about CL - that's why I belonged to X3J13 for a while - but issues of readability of source code are so far down the list as to be not there. I suspect that this is true for most other serious Lisp users as well.
> Ask any programmer in any other language, and he'll count you several > features in his language that he doesn't like. Ask Stroustrup about > C++, and he'll admit tradeoffs had been made and some aspects of the > result are not as well-done as the others. Why is this not true for > LISP as well?
It is true for Lisp as well, it's just that the things we (or I) think are wrong are often not the things that people seem to complain about in newsgroups. (As an example: I *really* want better hooks into the reader and in particular I want to be able to intervene at the point just before a token gets made into an object. I also want a standard code walker & environment introspection stuff, standard MOP (at least the outer layers). And that's just the core language stuff I can think of off the top of my head.)
* Ziv Caspi wrote: > Assume a large document created according to this scheme. Now assume a > user cuts a single ']' at one point, forgetting to put it back. The > error can only be detected at the end, and very difficult to diagnoze. > The following is properly balanced:
Curiously enough, after writing a lot (many thousands of lines) of SGML & XML by hand (well, using emacs's excellent PSGML mode) I did two things:
Firstly when having to write a 3 day course in HTML, I wrote it entirely in my `htout' lisp syntax, which looks more or less like:
(:p "this is a paragraph with " (:b "bold") " text")
This is obviously painful, but I found it significantly less bad than HTML. It was helped by very close integration with the server, so for instance examples in the course were just code that the server evaluated.
After doing this I invented another syntax, called TML (trivial markup language), which looks like:
<p|this is a paragraph with <b|bold> text>
TML is trivially translatable to XML / SGML documents, but it's much easier to type, and in some ways more powerful, because attributes can have structure:
<foo :l (this is a lisp list) :l 1.0s0 <bar|text>>
We now use something called DTML, which is TML with macros, for almost all our documentation. Although I'm speaking only for a very small user base (2 or 3 people), I think that we find TML enormously better than XML or SGML to type. I it enough better that I am gradually converting fairly substantial sets of HTML documents into DTML.
zi...@netvision.net.il (Ziv Caspi) writes: > Ask any programmer in any other language, and he'll count you several > features in his language that he doesn't like. Ask Stroustrup about > C++, and he'll admit tradeoffs had been made and some aspects of the > result are not as well-done as the others. Why is this not true for > LISP as well?
Who said this is not true for Lisp as well? Most Common Lisp programmers can give you a list of things they'd have done differently if it were up to them. (Mine available on request). Just because few of us consider "reading code from printouts" to be a significant problem doesn't mean the language doesn't have _tradeoffs_
With regard to that particular stumbling block, btw, you night want to
(1) Consider that the code is three times as dense (your figure) and therefore you should _expect_ it to take three times as long to read as you would C, if you approach it in the same level of detail. Perhaps it's only painful because you're telling yourself you should be reading faster?
(2) "Don't Do That Then": use the facilities of your Lisp environment and editor (who-calls, find definition, syntax colouring, arglist/docstring lookup etc) to browse code on the screen instead. I rarely print code out unless I am about to engage in fairly serious refactoring, and then I'm usually looking at the broad shape of it rather than the minutiae anyway.
Ziv Caspi <zi...@netvision.net.il> wrote: >[...] >(The picture is muddier in C++, because you can have nested classes. >Personally, I think that nested classes, like Pascal's nested >procedures, are from the devil.)
In article <3239429564044...@naggum.no>, Erik Naggum <e...@naggum.no> wrote:
> | Ask any programmer in any other language, and he'll count you several > | features in his language that he doesn't like.
> I highly doubt that this is true. First, you are now talking about /all/ > programmers even though you object when you were not even included in a > statement that made you think you were included. Gross generalizations are > seldom welcome. Second, "doesn't like' is such an unqualified position. > There are things I would like to change in Common Lisp (my current favorite > is 32-bit fixnums on 32-bit hardware
Just so Ziv isn't unnecessarily confused, perhaps you should emphasise that this not a problem with the *language*, but only with the implementation(s) you currently have.
-- Bruce thinks Common Lisp is the next-to-least bad language
