Hey
Recently, I researched using C++ for game programming and here is what
I found:
C++ game developers spend a lot of their time debugging corrupted
memory. Few, if any, compilers offer completely safe modes.
Unsurprisingly, there is a very high failure rate among projects using
C++ for modern game development.
You can not even change function definitions while the program is
running and see the effects live (the ultimate debugging tool).
Alternatively, you can't execute a small portion of the program
without compiling and linking the whole thing, then bringing your game
into a specific state where your portion of the code is being executed.
The static type system locks you into a certain design, and you can't
*test* new ideas, when they come to you, without redesigning your
whole class hierarchy.
C++ is so inflexible, even those who do use it for games, have to
write their game logic in some other language (usually very slow,
inexpressive and still garbage collected). They also have to interface
the two languages.
C++ lacks higher-order functions. Function objects emulate them
poorly, are slow and a pain to use. Additionally, C++ type system does
not work well with function objects.
C++ programs can not "think" of new code at run-time, and plug that
new code into themselves in compiled form. Not easily, anyway.
C++ coding feels very repetitive, for example, when writing class
accessors, you often have to write const and non-const methods with
completely identical function bodies. Just look at STL.
When programming in C++ you feel like a blind person trying to draw
something. You don't _see_ the data structures that your procedures
will operate on. Lisp programming is much more visual.
Constructors and smart pointers make it hard to tell cheap operations
from expensive ones.
C++ lacks automatic memory management and so it encourages copying
objects around to make manual memory management manageable.
Reference-counting schemes are usually slower than modern garbage
collectors and also less general.
Most important, C++ syntax is irregular, and you often find yourself
typing repetitive patterns again and again - a task easily automated
in languages with simpler syntax. There are even books on C++
patterns, and some C++ experts take pride in being able to execute
those patterns with computer-like precision - something a computer
should be doing to begin with.
C++ programs are slow: even though the compilers are good at
micro-optimizing the code, programmers waste their time writing
repetitive patterns in C++ and debugging memory corruption instead of
looking for better algorithms that are far more important for speed
than silly micro-optimizations.
It's hard to find good programmers for C++ projects, because most of
the good programmers graduated to languages like Lisp or avoided C++
altogether. C++ attracts unimaginative fellows with herd mentality.
For creative projects, you want to avoid them like a plague.
It is my opinion that all of the above makes C++ a very bad choice for
commercial game development.
Jul 22 '05
761  27928 
Paul Foley posted: On Fri, 29 Oct 2004 08:51:02 GMT, JKop wrote:
A question:
Why do people still talk about C?
As far as I'm aware, C++ is and can do everything that C can do, but
has more features. Would anyone be able to inform me of any reason why
Yes. Obligatory car analogy: C is a Ferrari. C++ is a Ferrari with
helicopter rotors, 18" naval guns, and those 8 foot diameter wheels.
While I understand the intention of your analogy, still...
It's incorrect in that, if one were not to make use of the 18" navals guns
or of those 8 foot diameter wheels, then the mass of these extra objects
would act as a hinderance for the vehicle: A greater force would be needed
to accelerate and deccelerate the vehicle.
While... with C++ ( comparing it to C ), the extra features in no way
hinder. So if I were to expand on your original analogy:
C is a Ferrari. C++ is a Ferrari with helicopter rotors which increase the
Ferrari's mass by 0, and its volume also by 0, also it has 18" naval guns
and 8 foot diameter wheels which increase both its mass and volume by 0. people still programme in C, or why they even talk about it?
For one thing, you can link to it from other languages without wanting
to tear your hair out.
Hmm... static libraries (ie. object files) or DLL's (ie. actual machine
code) ?
Would this not be adequeately achieved with:
extern "C" {
?
-JKop
Computer Whizz wrote: (+ 2/3 2/3 1/3) => 5/3
Jesus!
*covers eyes*
It took me a couple of minutes to decipher that...
If the syntax of "(+ 2/3 2/3 1/3)" confuses you, then I expect you will
have massive problems when you encounter C++'s templates, parameterized
types, and STL!! :-) :-) :-)
But I expect those are pleasures that still lie in store for you!
For instance, cam you understand the following easily?
It's just a random snippet from yesterday's std C++ list.
template <typename E, typename T>
friend std::basic_ostream< E, T>& operator<<
( std::basic_ostream< E, T>& os, const A& obj)
If you can, but still experience difficulty with "(+ 2/3 2/3 1/3)", then
I expect you have a mind that works in a very interesting way....
"Mario S. Mommer" <m_******@yahoo.com> wrote in message
news:fz************@germany.igpm.rwth-aachen.de...
JKop <NU**@NULL.NULL> writes: But this doesn't work, because 1/2 is always 0 in C++
1.0 / 2.0
Fair enough.
Anyway, this is a nice counter example to the (rather outrageous, IMO)
claim that C++ has a natural syntax. You write 1/2 and it actually
means... zero.
Personally I find 1/2 against natural writing (at least in maths).
I put everything above a /2 ...
So the equation would be: (a*sqr(t)+v*t)/2
Although I come from a BASIC background and don't know about the / in C++ .
--
=========
Comp Whizz
=========
(The C++ beginner)
"André Thieme" <ad****************************@justmail.de> wrote in message
news:cl**********@ulric.tng.de... Computer Whizz schrieb:
Yes... While x has no parameters passed (or does it?). Does forgetting
the space (or common typo) mean that (f xy z) causes an error.
same in C:
f(xy, z);
André
--
http://nase.black-entity.de/?nasigoreng
In C you'd get a type mismatch or the fact that the correct parameters
aren't passed... But if there's a variable named xy that's passed to a
function with variable... I'll just stop myself there shall I...
"...and if we went to the moon and back, and added 3 to the square root
of..."
I'll just say that I find C syntax easier to use and that's that.
--
=========
Comp Whizz
=========
(The C++ beginner)
* JKop (NU**@NULL.NULL)
.... While... with C++ ( comparing it to C ), the extra features in no way
hinder.
a) So what. Why use a tool with loads of extra features that
simply aren't used?
b) There are some parts that *do* hinder and make C code not
compile as C++.
.... Hmm... static libraries (ie. object files) or DLL's (ie. actual machine
code) ?
You seem not to have understood what they are.
Andreas
--
np: 4'33
"André Thieme" <ad****************************@justmail.de> wrote in message
news:cl**********@ulric.tng.de... Frank Buss schrieb:
André Thieme <ad****************************@justmail.de> wrote:
C++ does not have complex numbers, Lisp does, and you write them down
this way:
#C(real i)
for example #C(3 3)
C++ has complex numbers, defined as a template:
http://www.roguewave.com/support/doc...f/complex.html
Yes, that's right. However, they are still not so easy accessible like the
infix operators in our earlier discussions. Therefore complex numbers
would need to be included in the base language. If you need them for just
one part in your program, then do this in C++:
(+ #C(3 4) 25)
Just look at the example program on the site you posted.
Have fun
André
--
http://tinyurl.com/64x7y
True, C++ does have some missing things from it's "base" language (Oh how I
sorely missed strings at first glance when I first tried C++)...
But I did get to realise about using chr[] and chr* quite soon, and then
including the <string> library.
I read a bit on that D programming language mentioned somewhere, about
complex numbers being much easier to use - and indeed it seemed so.
And no - the trouble with Lisp to begin with is trying to find the "core" ()
and work outwards from there - kind of backward to my natural way of
thinking... Like reading right-to-left.
The one's I've quoted are short.
So before I pass out - I shall post this message and retire.
--
=========
Comp Whizz
=========
(The C++ beginner)
Andreas Krey posted: * JKop (NU**@NULL.NULL)
... While... with C++ ( comparing it to C ), the extra features in no way
hinder.
a) So what. Why use a tool with loads of extra features that
simply aren't used?
So if I tell you that you can also use a pen as a stabbing weapon, are you
suddenly not going to use it to write anymore based upon the premise that is
has an extra feature that isn't used?
b) There are some parts that *do* hinder and make C code not
compile as C++.
Just as how Delphi code won't compile as C++ code.
Pick a language, C or C++.
I see no reason whatsoever to not choose the latter which evolved from the
former.
If tomorrow a new programming language were to come out called "C+=2" or
"D" (yes, I know this name is taken!), then I'd abandon C++ in a heartbeat
in favour of its "latest evolution".
But for the foreseeable future, it doesn't look like C++ will change its
name. It looks like we'll just have Standard 1998, Standard 2003, and so
on...
People still programming in C is like a C++ programmer writing 1998 Standard
code -- it's been superseeded.
So I'm wondering, why do people write C code today, October 29th 2004?
... Hmm... static libraries (ie. object files) or DLL's (ie. actual machine
code) ?
You seem not to have understood what they are.
What *what* are?
-JKop
"Computer Whizz" <ol*********@hotmail.com> writes: "André Thieme" <ad****************************@justmail.de> wrote in message
news:cl**********@ulric.tng.de... Computer Whizz schrieb:
Yes... While x has no parameters passed (or does it?). Does forgetting
the space (or common typo) mean that (f xy z) causes an error.
same in C:
f(xy, z);
André
--
http://nase.black-entity.de/?nasigoreng
In C you'd get a type mismatch or the fact that the correct parameters
aren't passed... But if there's a variable named xy that's passed to a
function with variable... I'll just stop myself there shall I...
"...and if we went to the moon and back, and added 3 to the square root
of..."
Its not clear what would happen. Does f() have a declaration? Is xy
a variable or a function? If a function, does it have a declaration?
And what about z?
A Lisp compiler will give a number of warnings about unrecognized
symbols and mismatched/missing parameters in the scenario- without the
need of any additional context that a reader will need to decypher
what a C compiler will do.
I'll just say that I find C syntax easier to use and that's that.
Spend some time with Lisp and you'll find C syntax isn't "easier".
And really, you can't honestly make that statement until you're
familiar with both anyhow.
Gregm
Andreas Krey <yy********@gmx.de> writes: b) There are some parts that *do* hinder and make C code not
compile as C++.
See: http://david.tribble.com/text/cdiffs.htm
**
To /read/ a C++ program, one has to learn all the features of
C++ that might appear in such a program. "C++ is already too
large" according to Message-ID: <25***@alice.att.com> by
Bjarne Stroustrup.
C++ is full of exceptions and special rules. For example, an
initialization "int const v = 7;" is allowed within a class
specifier, while "double const v = 7.0;" is not. In
"std::vector<std::vector<int>> v;" the ">>" is parsed as the
operator ">>". "T t(u);" defines a variable t with type "T"
and initial value "u", while "T t();" declares a function "t".
Now guess, whether "std::vector<int> v(
std::istream_iterator<char>( cin ),
std::istream_iterator<char>() );" defines and initializes an
object "v" or declares a function "v". The type "vector<bool>"
is neither a container nor does it contain bool-objects, while
other "vector<...>"-classes are containers containing the
"..."-objects. To hide an external function from other
compilation units, one might use "namespace { ... }" or
"static", while "static" within a class has a completely
different meaning, and "static" within a function has
still another meaning.
JKop wrote:
If tomorrow a new programming language were to come out called "C+=2" or
"D" (yes, I know this name is taken!), then I'd abandon C++ in a heartbeat
in favour of its "latest evolution".
Hmmm... you'd jump at "D", were it available, based only
on the name, and since you know it IS available, ... ?
JKop on Fri, 29 Oct 2004 12:42:14 GMT writes: While... with C++ ( comparing it to C ), the extra features in no way
hinder.
a) So what. Why use a tool with loads of extra features that
simply aren't used?
So if I tell you that you can also use a pen as a stabbing weapon, are you
suddenly not going to use it to write anymore based upon the premise that is
has an extra feature that isn't used?
Not a good example.
Another example: You need a watch, what watch do you choose:
1) the one with just time and chrono
2) the one that has incorporated: mp3 player, photo-camera, radio,
and walkie-talkie?
I prefer the `1', more elegant, more lightweight, likely less prone to
faults.
If I would consider useful some features of `2', maybe I would
consider taking `2', or I may consider to get `1' plus a separate
device implementing the desired function.
b) There are some parts that *do* hinder and make C code not
compile as C++.
Just as how Delphi code won't compile as C++ code.
You pointed out <<extern "C">> as compatibility tool.
I see no reason whatsoever to not choose the latter which evolved from the
former.
Are you sure that the latter is better? For any purpose?
C++ is not a superset of C, it is another language.
If tomorrow a new programming language were to come out called "C+=2" or
"D" (yes, I know this name is taken!), then I'd abandon C++ in a heartbeat
in favour of its "latest evolution".
So you base your language chooses on hype.
People still programming in C is like a C++ programmer writing 1998 Standard
code -- it's been superseeded.
So I'm wondering, why do people write C code today, October 29th 2004?
Because they prefer C to C++. Or because C fits better some particular
domain.
Please note, while I prefer C to C++, I'm not blaming C++.
--
Marco Parrone <ma***@autistici.org> [0x45070AD6]
In article <MP***********************@news.verizon.net>, ch**************@NOTplayTHISstationBIT.sony.com says... In article <MP************************@news.indigo.ie>,
ge****@DELETETHISindigo.ie says... [...]
If I feel the need to learn and use Lisp I will do so. So far I don't
see any good reason to interest myself in it.
How about learning it in order to perhaps get a clue about
what you're talking about. (I realize it's a novel thought
for you, but you really should try it some time.)
Have you heard of the concept "secondary source"? You don't need to
host a brain slug to know it's a bad idea. You just look at the people
who host them.
I am familiar with the basic concepts of Lisp, I am familiar with the
arguments in favour of Lisp put forward by enthusiasts, and I am
familiar with the generally weak profile of Lisp enthusiasts in terms of
actually delivering product. The success of one group of talented
developers despite a plainly idiotic choice of development tools
notwithstanding. [I even quoted them, the Lisp users, to justify my
opinions.]
Learning to use Lisp idiomatically would take some time. I can find
better uses for that time. I don't buy the crap about it
revolutionising thinking processes, because of the general lack of
revolutionary Lisp-based software. So it's just another language. I
have programmed in about a dozen languages - I don't keep count. If I
need to learn one of the various versions of Lisp sometime, I'll learn
it.
Nowhere in my posts have I criticised any element of Lisp as a language
per se. But based on observation I have criticised the notion that
games development productivity would be enhanced dramatically by a
switch to Lisp, which was the thrust of the posts on this thread,
particularly the initial one. Since you yourself have now admitted that
you prefer to stick with C++, it is rather clear that similar arguments
hold sway with you.
- Gerry Quinn
In article <E0******************@newscontent-01.sprint.ca>, hs@hartmann.schaffernet says... Gerry Quinn wrote:
I'm not hearing the touted benefits of Lisp here. Correct me if I'm
wrong, but according to many posts in this thread, isn't Lisp supposed
to be the magical wand that fixes things like the above?
reading the points you quoted, they boil down to two arguments:
1. the programmer who considered it "code encryption" weren't familiar
with the language and either lazy or slow learners
According to some they are geniuses whose decision to use Lisp should be
a guiding light for us moronic hordes. But in point of fact, I don't
see how it boils down to that. From the basic fact of problems arising,
we can't decide whether GOAL or its users were inadequate. But since
the post-mortem referred to bugs and missing features in GOAL, the
developers seem to be putting the blame on it.
2. they used a tool that was still in development
now imagine a post mortem from programmers who were unfamiliar with
C/C++ on a project were the C/C++ compiler is written while they develop
the product. do you think it would be any different?
No. Those who used such an environment in such circumstances, while
mature technologies were available, would have made a stupid choice and
would probably fail. Even if they succeeded despite themselves, those
who copied them would still be idiots.
- Gerry Quinn
>>>>> "GQ" == Gerry Quinn <ge****@DELETETHISindigo.ie> writes:
[...]
GQ> I am familiar with the basic concepts of Lisp, I am familiar
GQ> with the arguments in favour of Lisp put forward by
GQ> enthusiasts, and I am familiar with the generally weak profile
GQ> of Lisp enthusiasts in terms of actually delivering product. [...]
"Enthusiasts" who do things for fun are not expected to deliver
"product" regardless of what langauge they use. If you have reason to
say this about people who use lisp professionally compared to users of
other languages, then perhaps you could tell us that reason? (AI
that wasn't in the 80s doesn't count).
cheers,
BM
Frank Buss <fb@frank-buss.de> writes: "C++ is already too large" according to Message-ID:
<25***@alice.att.com> by Bjarne Stroustrup.
but this was a statement from 1993:
http://groups.google.com/groups?as_u...ice.att.com%3E
I don't know the details of the C++ standard, some things might
be better in the current standard.
I believe that the standard of 1998 (and now: 2003) has
even more features than C++ as of 1993.
In any case, the standard ISO/IEC 14882:1998(E) has about 776
pages and is is based on the then C standard ISO/IEC 9899:1990
(E) with about 219 pages - which is needed as a reference and
to interpret the C++ standard, which refers to it not only for
the C standard library but also for behaviour of parts of the
C++ library. These are about 1000 pages for the language
specification. Nowadays, that old C standard is difficult to
obtain at all, so the whole specification even isn't
accessible easily.
**
Did I mention yet, than in many C++ implementations the
expression
-1 < 3000000000
is false, while
-1 < 2000000000
is true?
"Computer Whizz" <ol*********@hotmail.com> writes: "André Thieme" <ad****************************@justmail.de> wrote in message
news:cl**********@ulric.tng.de... Frank Buss schrieb:
And no - the trouble with Lisp to begin with is trying to find the "core" ()
and work outwards from there - kind of backward to my natural way of
thinking... Like reading right-to-left.
The one's I've quoted are short.
I think you are fundamentally misunderstanding Lisp program structure.
Unless you've happened to land in the middle of some huge FP example,
Lisp reads like any other procedural language.
Gregm
* Frank Buss (fb@frank-buss.de)
.... but this was a statement from 1993:
http://groups.google.com/gr*********...ice.att.com%3E
I don't know the details of the C++ standard, some things might be better
in the current standard.
No way. C++ is awfully convoluted and full of nasty traps many of which
you need to be actively aware of. A few days ago I had the line
clid = v;
corrupting an iterator. Now, v is a Some *, while clid is a SomeRef,
and it turned out that the SomeRef(Some *) constructor was broken
and only called because I forgot the SomeRef::operator=(Some *)
assignment operator. But class SomeRef would also have been seriously
broken if I just *omitted* the SomeRef::operator=(const SomeRef)
assignment operator.
C++ is also awfully wordy to write. Even the simple STL iteration
is a very lengthy expression. But then it is handy not to have
to do all this stuff yourself (in a typesafe way), and this is
the reason I finally (re)started to use C++.
Andreas
--
np: 4'33
* JKop (NU**@NULL.NULL) Andreas Krey posted:
..... Hmm... static libraries (ie. object files) or DLL's (ie. actual machine
code) ?
You seem not to have understood what they are.
What *what* are?
Static libraries and DLLs. They both contain machine code and
linkage information.
Andreas
--
np: 4'33
In article <cl**********@uns-a.ucl.ac.uk>, a.********@ucl.ac.uk says...
[My apologies for the double post on c.l.lisp. The previous poster is
one of those twits who silently change follow-ups.] Well, if you say that most of it was written in their Lisp-based engine,
I will not argue the point. And you don't seem to dispute my point that
it's the one company that gets cited over and over...
Just go to the website of a Lisp vendor and look at the "success stories"
section or equivalent. Lots of interesting real-world applications, e.g.
http://www.franz.com/success/custome.../harvard.lhtml.
Not as many as other languages.
I'm not hearing the touted benefits of Lisp here, folks. Here are some
briefer excerpts from 'What went wrong' - I'm sure you can put some spin
on them to say it's not really Lisp's fault, just the fault of the big
bad horrible world that doesn't love Lisp, or re-writes Lisp programs in
different languages as part of the big plot to keep it down:
These are all problems with the hastily written /compiler/, not with Lisp.
If there was a mature Lisp compiler targetting PS these wouldn't have been
issues. So these are merely arguments against using Lisp on the PS, so far
as I can see. Clearly the arguments were not compelling enough to prevent
Naughty Dog from using the same technique again.
Repeating mistakes does seem to be human nature.
If Lisp grows in popularity among those who are more interested in
products than in programming, I will likely take a look at it.
Because of course you can only get ahead in technology by copying what
everyone else is doing.
Unless you are selling the technology, or unless a technology gives you
special capabilities that those not using it don't have, "getting ahead
in technology" is a fool's motivation. Mature technology is cheaper and
more reliable as a general rule.
Regarding code obfuscation in Lisp, I think it's fair to say that Lisp
macros are just a bit easier to understand than template-metaprogramming in
C++. Also, if some guy decides to write some stupidly complex Lisp code,
that's not really Lisp's fault, is it? The stock response to criticism of
C++ seems to be "that wouldn't happen if you coded sensibly".
Template metaprogramming as such is never used by most sensible
programmers. Macros, by contrast, are ubiquitous in Lisp as I
understand it. And if the development environment had been an object-
based system with proper interfaces, it shouldn't have mattered whether
his code was comprehensible. Something for addicts of 'generic
programming' to ponder. But that's all beside the point. I don't know
what particular aspects of the program were incomprehensible to the
other developers, I just threw it out as one of the problems that
afflicted the one games development team famous for developing in Lisp
and still actually achieving something.
- Gerry Quinn
Ian Wild <ia******@eurocontrol.int> writes: Hmmm... you'd jump at "D", were it available, based only on the
name, and since you know it IS available, ... ?
Just in case you mean to imply that D is not available, there's plenty
to read here: http://www.digitalmars.com/d/
--
Steven E. Harris
JKop wrote:
<snip> If tomorrow a new programming language were to come out called "C+=2"
<snip>
If it's going to follow the sequence semantically, it would have to be
called "C+=2, C".
Stewart.
"Gerry Quinn" <ge****@DELETETHISindigo.ie> wrote in message
news:MP************************@news.indigo.ie... In article <cl**********@uns-a.ucl.ac.uk>, a.********@ucl.ac.uk says... > Well, if you say that most of it was written in their Lisp-based
> engine,
> I will not argue the point. And you don't seem to dispute my point
> that
> it's the one company that gets cited over and over...
Just go to the website of a Lisp vendor and look at the "success stories"
section or equivalent. Lots of interesting real-world applications, e.g.
http://www.franz.com/success/custome.../harvard.lhtml.
Not as many as other languages.
With all due respect to conflicting subjective points of view, all it takes
is a single counter example to refute the often voiced opinion that "lisp
may very well be <yada yada> but you cannot write real world applications
with it"
I don't think any body will dispute there are fewer lisp success stories
than C++ ones but that is as useful a data point as there are many more C++
failure stories than lisp ones.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
Frank Buss wrote: Frank Buss <fb@frank-buss.de> wrote:
The Lisp version:
(reduce '+ (mapcar (lambda (x) (* x x)) '(-1.2 0.99 23)))
sorry, is a bit longer :-)
(sqrt (reduce '+ (mapcar (lambda (x) (* x x)) '(-1.2 0.99 23))))
But the C++ version is longer, too, because I've omitted all the includes,
"using namespace std" and the main-function.
The others are fair, but I don't think you could include main in that
statement of omission.
Recall the purpose of main: It works as the starting point for a standalone
executable. An interactive C++ REPL presumably wouldn't require you to type
it in between each expression, so we'll drop that.
A Lisp program that was meant to create a standalone executable would, in
fact, include pretty much the same amount of code as that main function to
do it.
That said... Oh my, is that really the best C++ code for the purpose?
"David Steuber" <da***@david-steuber.com> wrote in message
news:87************@david-steuber.com... "Maahes" <ma****@internode.on.net> writes:
> But of course, no Lisp programmer would write it this way. If you want
> a
> list, which contains all elements from n to 0, you can write it like
> this:
>
> (defun make-down-list (n)
> (when (>= n 0)
> (cons n (make-down-list (1- n)))))
I'll stress one last time - IMHO, the reason your not getting any
converts
to Lisp from this thread is that those three lines look very complex to a
C
program, simply because of the 5 brackets at the end of the last line. If
I
wrote an IF statement with that many brackets, I have to be very careful
with it.. and I certainly wouldn't want to deal with that on every one of
my
statements...
FWIW you really do not notice all those parens after you get used to lisp
expressions and they are less intinidating when you realize they take the
place of all of ,;}) in C/C++ (not in every instance of course)
Besides, not everyone (myself included) would write the above as it is, I
never use recursion for an iterative problem.
(defun make-down-list (n)
(loop for i from n downto 0
collect i))
And its certainly a simple enough language to write your own compiler so
maybe I can play with that for a game. I doubt I'd have any luck
convincing
anyone at work that our scripting language should be Lisp though... I
don't
think most of our designers could handle all those brackets...
Scheme is something you could write a compiler for in a reasonable
time. Common Lisp is a bit more complex.
I think he may have meant "compiler" in the sense of macros are like
compilers for your own domain specific language on top of lisp rather than
re-implementing the language(?).
Stick with Commn Lisp.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
André Thieme wrote: Frank Buss schrieb:
André Thieme <ad****************************@justmail.de> wrote:
C++ does not have complex numbers, Lisp does, and you write them down
this way:
#C(real i)
for example #C(3 3)
C++ has complex numbers, defined as a template:
http://www.roguewave.com/support/doc...f/complex.html
Yes, that's right. However, they are still not so easy accessible like
the infix operators in our earlier discussions. Therefore complex
numbers would need to be included in the base language. If you need them
for just one part in your program, then do this in C++:
(+ #C(3 4) 25)
At this point I'd like to point out that, although complex numbers are part
of the standad CL library, if they weren't, it would be fairly easy to add
them.
Add a "complex" type, shadow the built-in arithmetic functions to make them
understand it, add a read-macro to make the #C(n m) syntax work... all in
all, not terribly much work, and you'd end up with the exact same syntax
that is used for the (built-in) complex types we have today.
Of course, the concept of a built-in type does tend to blur somewhat when a
simple two-key chord lets me look at the compiler's/library's definition of
any given function.
The point is, if someone needs anything CL lacks, they can simply add it. If
you need matrix-capable functions you can write them yourself, and they'll
work just like the built-in arithmetic functions even if you want to call
them something different.
That, for me, is one of the greatest features of CL.
Pascal Bourguignon wrote: So you'd want to program like this:
(deformula "
1 2
S = --- a t + v t
2 i
")
Note that in ASCII-art, it's still quite parseable.
Actually, I'd like to use a math-aware editor that would take special
keystrokes and interpret them to build a mathematical expression visually.
Like Mathematica does, if you've used it. (Or Lyx, although not as well.)
That's neither here nor there, though; no language known to me does that,
although I'm sure I could make Lisp do it with the appropriate editor
extensions. The same goes for C, though, even if I *would* have to use
comments for things they were never meant to do.
André Thieme <ad****************************@justmail.de> wrote in message news:<cl**********@ulric.tng.de>... Maahes schrieb:
Well, sounds like its probably very different to the lisp we used 15 years
go. All we could seem to do is have lots of brackets with calls to functions
embedded..
2*(5+Speed)+Velocity
looked something like:
(+ (* 2 (5 Speed +)) Velocity)
One might easily think that Lispers accepted the brackets but still
don't like them. In fact most Lispers even love them. The brackets (or
any other mechanism that tells the compiler where an expression starts
and ends) make many things easy.
What if you want to compute something like that:
a + b + c + d + e + f + g + h + i + j + k + l;
(with usefull names)
Here Lisp only needs one +:
(+ a b c d e f g h i j k l)
These are the technical, objective advantages of Lisp syntax:
- precedence and associativity do not exist, and so there are no
ambiguities
- every well-formed syntax corresponds to a data structure. There is a
bidirectional conversion path between a data structure and syntax,
allowing Lisp programs to manipulate Lisp source code.
- a few simple rules can be applied to format Lisp syntax in a
readable way, even if it has very deep nesting. Lisp can be written as
a sideways tree (think of a Windows tree control, for instance):
a +--- b +-- e
| |
| +-- f
|
+--- c
|
+--- d --- e
Just add parentheses and keep basically the same shape:
(a (b e
f)
c
(d e))
From this you can tell right away that there is a main list headed by
the main connective A, with three other constituents. They all start
on separate lines and are at the same indentation level.
This formatting can be applied to very deep expressions to make sense
out of them.
You cannot nicely format deeply nested infix expressions, because the
connectives are sandwiched between the constituents; they do not
nicely pop out on one side for a sideways diagram.
In the prefix notation, the main connective comes first, which allows
you to put the other ones to the left and on separate lines, without
rearranging the lexical order of the tokens.
Given (+ a b) you can write that as:
(+ a
b)
But given A + B, you cannot write that as:
A
+
B
because the order has been permuted. Your compiler won't take it.
There isn't any nice order in which you can separate the connective
from the constituent expressions.
Sometimes I use this style in C++,
A +
B
So that say ((A || B) && C) && !(X || Y) becomes (oh boy, I can't even
see what the main connective is):
((A || B) && C) &&
!(X || Y)
then
((A ||
B) &&
C) &&
!(X ||
Y)
Blech, anomaly with the ! operator which is prefix. This quickly
becomes way too ugly and the main connective doesn't stick out; it's
still buried. The first && sticks out to the far right, looking more
prominent. Maybe:
((A ||
B) &&
C) &&
!(X ||
Y)
now we at least have a sideways tree shape of sorts. But this is ugly
as sin. If we translate to Lisp we get:
(and (and (or a
b)
c)
(not (or x
y)))
Beautiful. I can mentally convert that to a combinational logic
circuit diagram flowing right to left.
We can selectively fold obvious pieces to one line:
(and (and (or a b)
c)
(not (or x y)))
(and (and (or a b) c)
(not (or x y)))
(and (and (or a b) c) (not (or x y)))
These kinds of transformations are easy to do back and forth,
particularly with Lisp-aware editors.
Even in the completly flat version, I know right away that the main
opeation is an AND, without having to parse through the whole thing.
"Computer Whizz" <ol*********@hotmail.com> wrote in message news:<cl**********@news7.svr.pol.co.uk>... "André Thieme" <ad****************************@justmail.de> wrote in message
news:cl**********@ulric.tng.de... Frank Buss schrieb:
André Thieme <ad****************************@justmail.de> wrote:
C++ does not have complex numbers, Lisp does, and you write them down
this way:
#C(real i)
for example #C(3 3)
C++ has complex numbers, defined as a template:
http://www.roguewave.com/support/doc...f/complex.html
Yes, that's right. However, they are still not so easy accessible like the
infix operators in our earlier discussions. Therefore complex numbers
would need to be included in the base language. If you need them for just
one part in your program, then do this in C++:
(+ #C(3 4) 25)
Just look at the example program on the site you posted.
Have fun
André
--
http://tinyurl.com/64x7y
True, C++ does have some missing things from it's "base" language (Oh how I
sorely missed strings at first glance when I first tried C++)...
But I did get to realise about using chr[] and chr* quite soon, and then
including the <string> library.
I read a bit on that D programming language mentioned somewhere, about
complex numbers being much easier to use - and indeed it seemed so.
And no - the trouble with Lisp to begin with is trying to find the "core" ()
What trouble with Lisp? What is your Lisp experience?
and work outwards from there - kind of backward to my natural way of
thinking... Like reading right-to-left.
The one's I've quoted are short.
That is actually wrong; to properly understand a Lisp expression, you
must work from outside in. You first consider it to be a list, where
the first element denotes the identity of the operator. Otherwise you
can get tripped up. For instance, suppose you had:
(defclass a (foo b c) ..)
If you were looking from the inside out, you might think that there is
a function call (FOO B C). But in fact, this is a DEFCLASS form, where
class A is being defined, and its base classes (multiple inheritance)
are FOO, B and C. The DEFCLASS operator has complete control over the
interpretation of the rest of the form; you have to know its semantics
in order to understand that form.
You read the form left to right. The main connective is always
leftmost. Its constituents can be read from left to right, and their
connectives are also on the left and so forth. Speaking of Forth, that
is the language you must be thinking of which requires some right to
left thinking.
The C and C++ languages have plenty of prefix forms. Function calls:
f(g(x, y), z); // analogous to (f (g x y) z)
sizeof (char *); // sizeof operator is prefixed
return 3; // return operator
if ...
for ...
while ...
switch ...
class ...
All prefix operators, like in Lisp. Oh yes and there are lists all
over the place in C++ source. Lists of function and template
arguments, lists of declarations and statements, lists of base
classes, lists of base class initializers, lists of this lists of
that. They all have inconsistent syntax with each other! Semicolon
terminators here, comma separators there. Initial colon elsewhere. In
Lisp source code, anything that is a list has the same syntax as any
other list, whether it be a list of arguments, list of base classes,
list of variable forms in a LET or whatever.
As to your other point, it is actually infix syntax which forces you
to get to the ``inner core'' just to discover what operation is being
done and get the gist of the expression. Consider the case where you
have:
< ... some long expression ...> + < .. some long expression ...>
You have to parse the thing just to find out that the + buried in the
middle is the main connective. To parse it you have to take into
account operator precedence, associativity and all that. Until you do
the parse, you don't even know that it's an additive expression.
Lisp was deliberately designed so that the main connective is easy to
find without parsing. This isn't a coincidence; it makes it easier to
write code which analyzes and processes code. Such code is found in
Lisp macros, which are parts of a Lisp program that extend the
language with new syntax and semantics that other parts of a program
use.
So before I pass out - I shall post this message and retire.
Please tell us it's for good.
Stewart Gordon posted: JKop wrote:
<snip> If tomorrow a new programming language were to come out called "C+=2"
<snip>
If it's going to follow the sequence semantically, it would have to be
called "C+=2, C".
Stewart.
C += 2, C
In the above expression, would the former not be evaluated before the
latter?
-JKop
Svein Ove Aas <sv*******@aas.no> wrote in message news:<cl**********@services.kq.no>... André Thieme wrote:
Frank Buss schrieb:
André Thieme <ad****************************@justmail.de> wrote:
C++ does not have complex numbers, Lisp does, and you write them down
this way:
#C(real i)
for example #C(3 3)
C++ has complex numbers, defined as a template:
http://www.roguewave.com/support/doc...f/complex.html
Yes, that's right. However, they are still not so easy accessible like
the infix operators in our earlier discussions. Therefore complex
numbers would need to be included in the base language. If you need them
for just one part in your program, then do this in C++:
(+ #C(3 4) 25)
At this point I'd like to point out that, although complex numbers are part
of the standad CL library, if they weren't, it would be fairly easy to add
them.
Also, I'd like to point out that some things you can do with Lisp
complex numbers are difficult in C++.
Firstly, if you use CLOS methods for arithmetic operations, you can
support all of the combinations. C++ can only do this statically,
because dynamic dispatch (virtual functions) is done on what is
effectively the leftmost argument of a method (i.e. the object, or
``this'' pointer).
In Lisp, some block of code can receive two numbers whose type is not
statically apparent, and call an operation. The right operation is
selected based on both their types. This is called multiple dispatch:
the method selection takes into account the type of all objects---the
run-time type---somewhat analogously to how C++ overload resolution
does it over static types.
There are hacks to do this in C++ such as the Visitor Pattern.
Dynamically dispatch on the left argument to get to implementation i
of virtual function X, which then dynamically dispatches an
implementation of Y_i on the right argument. If you want three
arguments, the complexity explodes further; you then want to write a
Perl script to just generate the tedious C++ from a condensed spec.
Secondly, the Lisp numeric type system incorporates the idea that
value influences type. For instance, a complex number whose imaginary
part is zero is a real number. Or a rational number whose denominator
is one has integer type. The return value of an arithmetic computation
does not have some fixed declared type; the type is determined by the
value that is produced. If you divide 2 and 3, you get the rational
2/3. If you divide 4 by 2 using exactly the same function, you get
integer 2. Take the square root of -1 with (sqrt -1) and you get the
complex number #c(0 1). And so on.
Lastly, the two components of a complex number are not necessarily
real numbers. They can be fixed integers or bignums. This is largely
transparent.
For example, suppose you add these two complex numbers like this:
(+ #c(-1 -1) #c(1 1))
The result is 0. That is, to say, *integer* zero. Not a complex zero,
or real zero. The real and imaginary parts of these complexes are
integers, and they all nicely cancel out to produce a pure zero.
These types of robust properties of the Lisp numeric tower make it
useful for solving numeric problems, with clear, concise code in which
The Right Thing happens.
Computer Whizz schrieb: I am also pointing out the fact that if Lisp is supposed to be good for the
"newbie" then how come it looks WORSE off than every other programming
language that I have "gazed" upon?
If the person is a newbi, how can he/she know that not all programming
languages look like that? ;-)
Also: give it a try for three days. There will be no problem anymore.
André
--
"If Java is your hammer every problem will look like a thumb"
JKop schrieb: A question:
Why do people still talk about C?
As far as I'm aware, C++ is and can do everything that C can do, but has
more features. Would anyone be able to inform me of any reason why
people still programme in C, or why they even talk about it?
-JKop
You might take a C++ compiler to get C code. In theory they should be
able to produce the same output.
Anyway, a program compiled with a C++ compiler which is not using any
features of C++ is still a C program. So if you don't use classes,
operator overloading, templates, exception handling etc.. then you are
programming in C. The fact that you use a C++ compiler to make machine
language out of your sources does not make your program any C++isher.
As soon you begin to use the more complex features of C++.. a fight will
start. You will run into problems where you need to think how you can
tell it (=what you want to achieve) the compiler. The problem itself is
history.. first you need to fight with the language to get things done,
then you can come back to the real problem itself.
André
-- http://tinyurl.com/64x7y ka*@ashi.footprints.net (Kaz Kylheku) wrote in message news:<cf**************************@posting.google. com>...
[ ... ] And no - the trouble with Lisp to begin with is trying to find the "core"
()
What trouble with Lisp? What is your Lisp experience?
Lisp has a number of problems, particularly fragmentation. The
fragmentation _has_ reduced considerably since CL was invented, but
unfortunately CL is, in some ways, the worst possible dialect.
I can't speak for the person to whom you were posting, but my Lisp
experience includes having used it off and on for 20+ years, and
having written three (or four, depending on your viewpoint)
implementations during that time.
[ ... ]
Speaking of Forth, that
is the language you must be thinking of which requires some right to
left thinking.
While Forth (using RPN) obviously does, Lisp does as well, for at
least some situations, particularly mathematical ones, and for almost
exactly the same reason: in both cases, what starts as a mathematical
expression has to be transcribed into the language so the syntax
directly expresses the precedence of operations that are implied in
the original expression.
OTOH, none of the above really compares with APL for right-to-left
reading.
[ ... ]
if ...
for ...
while ...
switch ...
class ...
All prefix operators, like in Lisp.
Pardon my pointing out the obvious, but in C or C++, none of the above
is an operator at all.
Oh yes and there are lists all
over the place in C++ source. Lists of function and template
arguments, lists of declarations and statements, lists of base
classes, lists of base class initializers, lists of this lists of
that. They all have inconsistent syntax with each other! Semicolon
terminators here, comma separators there. Initial colon elsewhere. In
Lisp source code, anything that is a list has the same syntax as any
other list, whether it be a list of arguments, list of base classes,
list of variable forms in a LET or whatever.
Partly true, but not entirely so -- in particular, see below about
M-expressions.
[ ... ]
Lisp was deliberately designed so that the main connective is easy to
find without parsing. This isn't a coincidence; it makes it easier to
write code which analyzes and processes code. Such code is found in
Lisp macros, which are parts of a Lisp program that extend the
language with new syntax and semantics that other parts of a program
use.
When John McCarthy designed Lisp, the intent was that S-expressions
would be used for data. Programmers were intended to write code using
M-expressions, which have a syntax more like other languages,
including some inconsistencies, such as using a mixture of parentheses
and square brackets, as well as sometimes putting the first item in a
list outside the brackets and sometimes inside.
The original intent was that M-expressions would be translated to
S-expressions, and then those would be interpreted. As a first step,
an interpreter that accepted S-expressions was written. Before a
front-end, or even a syntax for the language it would accept, was
finished, the S-expression syntax had been accepted to the extent that
M-expressions never materialized.
You might (even well be right to) believe that Lisp is better off for
this, but claiming it was a deliberate design, at the very best,
distorts the facts beyond recognition.
--
Later,
Jerry.
The universe is a figment of its own imagination.
[snips]
On Thu, 28 Oct 2004 18:56:10 +0000, Alex Drummond wrote: * Closures
Don't know about those, I'll check the thread - but are these particularly
significant, given that C++ (and presumably C, and presumably umpteen
other similar languages) don't support them? I mean, they can hardly be
the be-all and end-all of programming, right? Just how much of an
improvement _do_ they make over not having them?
* Macros (ability to add your own control structures, etc.)
Not sure what you mean here, but last I checked, C++ did support macros.
* More sophisticated OO system (multiple dispatch, etc.)
Great. C++'s model is already sufficiently complex to be annoying, and
you want a more complex model?
* Garbage collection.
Never seen this one defended as being actually useful for anything but
hand-holding of incompetent coders.
* More sophisticated exception handling system (allows restarts).
Not sure what "allows restarts" means; if I catch an exception, it's up to
me how to proceed: free some resources and try the operation again, for
example.
Better idioms for resource control (e.g. unwind-protect). * More
paradigms suppported: Imperative, OO, functional, logic (if you use a
library like Screamer).
Okay, this sounds reasonable. Not that I've ever needed imperative or
logic coding, but if one needs them and they can't be accomplished in C or
C++, then, sure.
In article <pa****************************@xxnospamyy.lightsp eed.bc.ca>,
Kelsey Bjarnason <ke*****@xxnospamyy.lightspeed.bc.ca> wrote: * More sophisticated exception handling system (allows restarts).
Not sure what "allows restarts" means; if I catch an exception, it's
up to me how to proceed: free some resources and try the operation
again, for example.
With one important difference - in C++ once you get in the handler the
stack has already been unwound. Once this happens, you've lost all your
state, and if there was a way to recover you now have to tediously
rebuild it.
The Common Lisp condition system does not require this - the exception
handler can be run in the dynamic environment of the exception, not the
handler.
More importantly, however, it provides a protocol to present multiple
ways of resolving the error and restarting the computation. These can
be selected either interactively or programatically. The restart is a
function that will usually perform some corrective procedure and then
transfer control to a point where computation can continue.
Of course, if you want "C++-style" exception behavior, where handlers
run after the stack unrolls, it's available.
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Kelsey Bjarnason wrote: [snips]
On Thu, 28 Oct 2004 18:56:10 +0000, Alex Drummond wrote:
* Closures
Don't know about those, I'll check the thread - but are these particularly
significant, given that C++ (and presumably C, and presumably umpteen
other similar languages) don't support them? I mean, they can hardly be
the be-all and end-all of programming, right? Just how much of an
improvement _do_ they make over not having them?
Closures are a terrific advantage.
* Macros (ability to add your own control structures, etc.)
Not sure what you mean here, but last I checked, C++ did support macros.
The previous poster is talking about Lisp macros; C and C++ support
nothing like them. C and C++ macros are entirely different animals.
Specifically, C and C++ macros are string substitutions at preprocessing
time; Lisp macros are syntax-tree-to-syntax-tree transformations
performed by a Lisp runtime, with all Lisp operators available to the
code that performs the transformation.
* More sophisticated OO system (multiple dispatch, etc.)
Great. C++'s model is already sufficiently complex to be annoying, and
you want a more complex model?
'Sophisticated' and 'complex' don't mean the same thing. CLOS is not
distinguished by a startlingly large number of features, but by the
great power CLOS provides for constructing object-oriented language
features.
* Garbage collection.
Never seen this one defended as being actually useful for anything but
hand-holding of incompetent coders.
People used to say the same thing about subroutines and recursive
function calls. Like those two once-controversial features, GC makes
programming much easier and less error-prone.
* More sophisticated exception handling system (allows restarts).
Not sure what "allows restarts" means
It refers to one of the features provided by the CL condition system.
Lisp systems are interactive. When something breaks, you enter an
interactive debugger with the incremental compiler built into it; you
can inspect the state of the runtime, redefine functions and data
structures interactively, and restart the computation from where it
broke. Restarts are user-definable options for resuming computation
after an exception occurs. They can be used either during development,
or to provide exception-handling features in a delivered app, or both.
This kind of exception-handling leads to an idiosyncratic form of
top-down and test-driven development, because you can start with the
toplevel function or with a test definition, and just run it. When it
hits an undefined function or data structure it will of course break,
but you can just define the missing features from the debugger and
continue, repeating that process until the toplevel function runs to
completion, or the test succeeds.
"Alex Gian" <sp******@junkmail.for.alex.com> wrote in message
news:Rc***************@fe1.news.blueyonder.co.uk.. . Computer Whizz wrote:(+ 2/3 2/3 1/3) => 5/3
Jesus!
*covers eyes*
It took me a couple of minutes to decipher that...
If the syntax of "(+ 2/3 2/3 1/3)" confuses you, then I expect you will
have massive problems when you encounter C++'s templates, parameterized
types, and STL!! :-) :-) :-)
But I expect those are pleasures that still lie in store for you!
For instance, cam you understand the following easily?
It's just a random snippet from yesterday's std C++ list.
template <typename E, typename T>
friend std::basic_ostream< E, T>& operator<<
( std::basic_ostream< E, T>& os, const A& obj)
If you can, but still experience difficulty with "(+ 2/3 2/3 1/3)", then I
expect you have a mind that works in a very interesting way....
Why do people always think it's the easiest, fraction part of the original
post I referred to?
Simply because I replied right at the end? Perhaps it's reading that Lisp,
meaning the middle to the last then the first - or some other peculiarity?
*dodges flames from last comment*
And I understand most of that C++ statement, as I haven't fully covered
Types yet... I also need to do some practice as I've only compiled a handful
of my own dodgy code.
--
=========
Comp Whizz
=========
(The C++ beginner)
"Kaz Kylheku" <ka*@ashi.footprints.net> wrote in message
news:cf**************************@posting.google.c om... "Computer Whizz" <ol*********@hotmail.com> wrote in message
news:<cl**********@news7.svr.pol.co.uk>...
And no - the trouble with Lisp to begin with is trying to find the "core"
()
What trouble with Lisp? What is your Lisp experience?
Very little experience, I have only seen what is in this newsgroup thread.
I do however correct myself and claim "my" trouble.
and work outwards from there - kind of backward to my natural way of
thinking... Like reading right-to-left.
The one's I've quoted are short.
That is actually wrong; to properly understand a Lisp expression, you
must work from outside in. You first consider it to be a list, where
the first element denotes the identity of the operator. Otherwise you
can get tripped up. For instance, suppose you had:
(defclass a (foo b c) ..)
As Jerry has replied - it is indeed important to find the core in maths
problems (all/99%) of which I have see in here, while also some function
calls. You need to scan to see a rough idea, then re-scan to perhaps see the
parameters and then rescan again to see the function calls.
The above looks at a quick scan (without paying attention to defclass) as a
function foo being called, as you say below... But after moving leftward the
mind is corrected.
If you were looking from the inside out, you might think that there is
a function call (FOO B C). But in fact, this is a DEFCLASS form, where
class A is being defined, and its base classes (multiple inheritance)
are FOO, B and C. The DEFCLASS operator has complete control over the
interpretation of the rest of the form; you have to know its semantics
in order to understand that form.
You read the form left to right. The main connective is always
leftmost. Its constituents can be read from left to right, and their
connectives are also on the left and so forth. Speaking of Forth, that
is the language you must be thinking of which requires some right to
left thinking.
The C and C++ languages have plenty of prefix forms. Function calls:
f(g(x, y), z); // analogous to (f (g x y) z)
Now here it is much better for C/C++ IMO.
parameters are passed using the ()'s to group them together, and the
function outside. While in Lisp, the function and parameters are in exactly
the same place.
For me it's exactly like writing this post but removing all the comma's,
full stops etc and just leaving the words and spaces - the flow seems to
dissapear.
So before I pass out - I shall post this message and retire.
Please tell us it's for good.
Thanks!
And no, I do not back down on my own personal views until I am satisfied
with what I am given.
--
=========
Comp Whizz
=========
(The C++ beginner)
"Kaz Kylheku" <ka*@ashi.footprints.net> wrote in message
news:cf**************************@posting.google.c om...
These are the technical, objective advantages of Lisp syntax:
Objective is right.
- precedence and associativity do not exist, and so there are no
ambiguities
- every well-formed syntax corresponds to a data structure. There is a
bidirectional conversion path between a data structure and syntax,
allowing Lisp programs to manipulate Lisp source code.
- a few simple rules can be applied to format Lisp syntax in a
readable way, even if it has very deep nesting. Lisp can be written as
a sideways tree (think of a Windows tree control, for instance):
a +--- b +-- e
| |
| +-- f
|
+--- c
|
+--- d --- e
Just add parentheses and keep basically the same shape:
(a (b e
f)
c
(d e))
That is horrible in my eyes, almost as horrible as the C++ mess you made
below.
From this you can tell right away that there is a main list headed by
the main connective A, with three other constituents. They all start
on separate lines and are at the same indentation level.
All I can tell if that there's a mess.
This formatting can be applied to very deep expressions to make sense
out of them.
You cannot nicely format deeply nested infix expressions, because the
connectives are sandwiched between the constituents; they do not
nicely pop out on one side for a sideways diagram.
In the prefix notation, the main connective comes first, which allows
you to put the other ones to the left and on separate lines, without
rearranging the lexical order of the tokens.
Given (+ a b) you can write that as:
(+ a
b)
But given A + B, you cannot write that as:
A
+
B
Why?
A +
B - is fine enough.
because the order has been permuted. Your compiler won't take it.
There isn't any nice order in which you can separate the connective
from the constituent expressions.
Sometimes I use this style in C++,
A +
B
So that say ((A || B) && C) && !(X || Y) becomes (oh boy, I can't even
see what the main connective is):
((A || B) && C) &&
!(X || Y)
That is good enough. You can see that The first and last needs to be true
etc.
I think that two liner is fine, breaks the code into two suitable parts.
then
((A ||
B) &&
C) &&
!(X ||
Y)
Blech, anomaly with the ! operator which is prefix. This quickly
becomes way too ugly and the main connective doesn't stick out; it's
still buried. The first && sticks out to the far right, looking more
prominent. Maybe:
((A ||
B) &&
C) &&
!(X ||
Y)
Now this is just a right mess... I need to parse the WHOLE thing into your
head and try to seperate it out.
now we at least have a sideways tree shape of sorts. But this is ugly
as sin. If we translate to Lisp we get:
(and (and (or a
b)
c)
(not (or x
y)))
Beautiful. I can mentally convert that to a combinational logic
circuit diagram flowing right to left.
Beauty is in the eye of the beholder indeed!
I can mentally convert that into a bit less of a mess.
But perhaps it's that I don't convert it into such a diagram but merely
understand what happens to lead into the next. I can see the Lisp is easier
for a diagram - but personally harder for me to understand.
We can selectively fold obvious pieces to one line:
(and (and (or a b)
c)
(not (or x y)))
(and (and (or a b) c)
(not (or x y)))
Alot better - just like the C++ example above.
(and (and (or a b) c) (not (or x y)))
These kinds of transformations are easy to do back and forth,
particularly with Lisp-aware editors.
Even in the completly flat version, I know right away that the main
opeation is an AND, without having to parse through the whole thing.
In my eyes the two liner C++ code looks better since the && is on the right,
in the middle of the two - where I naturally look when I want to know what
is happening...
The Lisp two-liner is actually nicer on the eye, it just looks cleaner. But
I can't be sure that isn't because of all the lower case.
As alot of things, it's subjective on your mindset - so I'm questioning if
I'm actually adding to this discussion, or am simply getting tired of this
whole thread as neither syntax will come out on top - since it's ALL
subjective.
Let the replies of "this is better because" continue...
--
=========
Comp Whizz
=========
(The C++ beginner)
"André Thieme" <ad****************************@justmail.de> wrote in message
news:cl**********@ulric.tng.de... Computer Whizz schrieb:
I am also pointing out the fact that if Lisp is supposed to be good for
the "newbie" then how come it looks WORSE off than every other
programming language that I have "gazed" upon?
If the person is a newbi, how can he/she know that not all programming
languages look like that? ;-)
Also: give it a try for three days. There will be no problem anymore.
André
--
"If Java is your hammer every problem will look like a thumb"
I shall investigate it pretty soon, as I shall be getting alot more free
time... I shall then just pop in to your lisp newsgroup to post my
thoughts... Don't expect anything of me though - the mindset is boggling!
--
=========
Comp Whizz
=========
(The C++ beginner)
Computer Whizz wrote:
"Alex Gian" <sp******@junkmail.for.alex.com> wrote in message
news:Rc***************@fe1.news.blueyonder.co.uk.. . Computer Whizz wrote:(+ 2/3 2/3 1/3) => 5/3
Jesus!
*covers eyes*
It took me a couple of minutes to decipher that...
If the syntax of "(+ 2/3 2/3 1/3)" confuses you, then I expect you will
have massive problems when you encounter C++'s templates, parameterized
types, and STL!! :-) :-) :-)
But I expect those are pleasures that still lie in store for you!
For instance, cam you understand the following easily?
It's just a random snippet from yesterday's std C++ list.
template <typename E, typename T>
friend std::basic_ostream< E, T>& operator<<
( std::basic_ostream< E, T>& os, const A& obj)
If you can, but still experience difficulty with "(+ 2/3 2/3 1/3)", then
I expect you have a mind that works in a very interesting way....
Why do people always think it's the easiest, fraction part of the original
post I referred to?
Simply because I replied right at the end? Perhaps it's reading that Lisp,
meaning the middle to the last then the first - or some other peculiarity?
*dodges flames from last comment*
And I understand most of that C++ statement, as I haven't fully covered
Types yet... I also need to do some practice as I've only compiled a
handful of my own dodgy code.
Well, he didn't *have* to write it that way; I find it overly complex
myself, no pun intended. The (complex) function dynamically constructs
complex numbers, but when it's done with constants, I'd prefer something
like this:
(+ #C(3 3) #C(3 -3) 3) => 9
It's still a bit confusing, but I challenge you to come up with anything
simpler in C++. More usefully, the compiler will constant-fold this down to
9 in the first place (function calls or no function calls), whereas the C++
compiler I tried it in notably didn't.
Gerry Quinn wrote: There's still a strong element of subjectivity: as well as
some languages being better for some *tasks*, some are better
for some *people*. I find that (to take three somewhat different
examples) C, Python and Lisp fit my brain a bit more naturally
than C++, Perl and ML. So if I say "Perl is a mess" or "C++
is too easy to screw yourself with" you can, I suppose, put it
down to my idiosyncrasies. But if I say "Lisp's macros make it
easy to do things that are unbearably painful in C++", that's
a verifiable (or falsifiable, though as it happens it's true)
statement that anyone can check given a little time and an
open mind.
I don't dispute it. Self-modifying code is one example. But it's an
example that suggests to me that Lisp programmers are generally more
interested in programming than in shipping software.
I don't understand how it can do that, since Lisp doesn't use
self-modifying code.
For what it's worth, I've seen no evidence that Lispers are
either more or less prone than C++ers to get caught up in the
details of programming rather than actually getting things
completed. I've certainly seen Lispers in that state. I've
seen C++ers in the same state, and at least one famous (and
rather good, in its way) C++ book seems to me to be a fine
example. I don't think this tells us anything about either
language. It tells us that people who do something that's
(at least sometimes) both difficult and interesting, like
writing software, will sometimes find they're more interested
in the process than in the product. It happens plenty outside
the world of software, too.
It's one of
several things that give me that impression. Another is the simple
enthusiasm of its advocates. There's nothing like an unfinished project
to generate enthusiasm for a programming language. You're doing the fun
stuff, not tidying up the loose ends.
So a language whose programmers are enthusiastic about it
is likely to be one that isn't used for getting real work
done? That rules out almost every language I've either
used or seen except, maybe, COBOL.
If I feel the need to learn and use Lisp I will do so. So far I don't
see any good reason to interest myself in it. If that's my loss, so be
it.
That's fine. No one, I hope, is trying to force you to do
anything you don't want to. Certainly not me.
--
Gareth McCaughan
..sig under construc
Computer Whizz wrote: And I understand most of that C++ statement, as I haven't fully covered
Types yet... I also need to do some practice as I've only compiled a handful
of my own dodgy code.
Good luck with your C++, anyway.
When you get to the standard C++ lbraries (STL), you may find it helpful
to study the influence that Lisp had on them.
I know it helped me undestand them better...
--
My apologies for not leaving a handy e-mail address for spammers.
Use alex_gian ATT yahoo Decimal cawm (if you must)
You know how to compose this...
"Computer Whizz" <ol*********@hotmail.com> wrote in message news:<cl**********@newsg1.svr.pol.co.uk>... The C and C++ languages have plenty of prefix forms. Function calls:
f(g(x, y), z); // analogous to (f (g x y) z)
Now here it is much better for C/C++ IMO.
parameters are passed using the ()'s to group them together, and the
function outside. While in Lisp, the function and parameters are in exactly
the same place.
How are they in the same place? The function is in the leftmost
position, and the arguments are not!
The function belongs with the arguments; enclosing it together with
them expresses this grouping.
Consider what happens when the prefix syntax where functions are
outside of the group is combined with infix operators:
x * f(x, y)
Now what is the grouping? Is it (x * f)(x y)? Or do you just assume
that the prefix operator always has a higher precedence than the
binary *, whatever it is? That doesn't quite work:
x + f(x, y); // additive expression, function call is tighter
foo::bar(x, y); // C++ scope resolution, foo goes with bar
obj.func(x, y); // member selection, obj goes with func.
But:
(obj.*pmemb)(x, y); // .* low precedence, parens needed!
Ooops.
If you move the function to the right of the parenthesis, these
ambiguities disappear.
For me it's exactly like writing this post but removing all the comma's,
full stops etc and just leaving the words and spaces - the flow seems to
dissapear.
The text is in fact mostly words and spaces. The, punctuation, is,
quite, minimal, compared, to, C++, Pascal, Etc. What a waste of
keystrokes; what do the commas accomplish? They disambiguate things
like x, ++y versus x++, y. One syntactic sdidiocy is patched over
with another. What a false economy; just so that you could have these
prefix operators and whatnot, you have to type extra punctuation even
when you are not using them!
"Maahes" <ma****@internode.on.net> writes: By bottom-up, I mean, your grouping all your lowest expression together and
then operating on them, and then operating on the result of that.
For instance (an example someone posted).
C:
for (int i=0; i<=10; i++) list.push(i);
list.reverse();
List:
(let ((lst 0))
(dotimes (i 11)
(push i lst))
(reverse lst))
In the C version, I am typing straight out of my head in left -> right
fashion and appending new work as I go along. In the Lisp one, it seems you
have to group the (push i lst), the (i 11), as they are the bottom level
actions. Then wrap that in a (dotimes a b) framework, then wrap that in a
let (a b) framework.
No, you type the code exactly as you read it: from left to right. You
could type the C code by doing list.push(i) first and then adding the
for loop and then doing the reverse, but I'm sure that won't make any
sense to you. In the same way, what you describe makes no sense to me.
Although, I would write that code in Lisp as:
(loop for i below 11 collect i)
;)
The main thing you fail to realize, due to the complexity of C syntax,
is that C code has just as much structure as Lisp code (more actually,
because the structure goes immediately to semantically significant
constructs), but that structure is obfuscated by the variety of
characters used to delimit various semantic constructs. In Lisp, we just
have one set of characters to delimit all constructs and the semantics
are determined by the operator at the beginning of a form.
I'm not even sure why there are 2 brackets around the
lst 0. This seems to make a mockery of Lisp having consistent syntax.
The bindings list of a LET form is just that, a list, so it needs to
have that extra level of nesting.
On top of all that, there are so many darn brackets there that I find that
it takes me a few seconds to match them up in my head to see which groups
are arguments to which functions, though I expect your quite used to the
indenting so it makes instant sense to you. I would imagine a far more
complex line, with a dozen brackets, would be a major brainstrain to
comprehend.
Your problem is that you're looking at the parens, not at the shape of
the code. Do you actually look for the semicolons at the end of every
statement in C or do you simply let your editor line up the code so that
all statements in the same block have their starting line indented to
the same level and any further lines (because of lots of chained
function calls or because of lots of parameters split up onto multiple
lines) indented further in?
--
Rahul Jain rj***@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Jerry Coffin wrote: ...
When John McCarthy designed Lisp, the intent was that S-expressions
would be used for data. Programmers were intended to write code using
M-expressions, which have a syntax more like other languages,
including some inconsistencies, such as using a mixture of parentheses
and square brackets, as well as sometimes putting the first item in a
list outside the brackets and sometimes inside.
The original intent was that M-expressions would be translated to
S-expressions, and then those would be interpreted. As a first step,
an interpreter that accepted S-expressions was written. Before a
front-end, or even a syntax for the language it would accept, was
finished, the S-expression syntax had been accepted to the extent that
M-expressions never materialized.
iirc, one of the many texts on the history of lisp went into detail abut
that: the people working on and with this interpreter discovered
macros, used then heavily, and saw no way how to preserve their power
when switching to M-expressions
...
hs
Kelsey Bjarnason <ke*****@xxnospamyy.lightspeed.bc.ca> writes: This is not a language issue; this is a _tools_ issue. This is a question
of whether or not your _debugger_ allows you to do this sort of thing;
nothing in the C or C++ language specs prevents it.
You mean that there's a specified protocol for updating instances of a
class when the class's definition has changed in C++? Interesting.
--
Rahul Jain rj***@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Maahes wrote: I'm not even sure why there are 2 brackets around the lst 0.
(Should be (lst '()), anyway, as someone already commented.
This seems to make a mockery of Lisp having consistent syntax.
No, its perferctly consistent.
It's because you might want to initialise more than one variable for the
loop. So,
(let ((i 0)(j 100)) (...))
would coreespond to C++'s
for (int i=0, int j=100; <testcondition>; <loop-ops, e.g i++,j-->) {}
--
My apologies for not leaving a handy e-mail address for spammers.
Use alex_gian ATT yahoo Decimal cawm (if you must)
You know how to compose this...
"Computer Whizz" <ol*********@hotmail.com> writes: And no - the trouble with Lisp to begin with is trying to find the "core" ()
and work outwards from there - kind of backward to my natural way of
thinking... Like reading right-to-left.
The one's I've quoted are short.
Not even the compiler is supposed to read your code from the inner
parens and work out. The compiler must arrange for evaluation of the
code from left to right, as this is how the code is read (being based on
the English language).
--
Rahul Jain rj***@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Peter Lewerin |
last post by:
peter.lewerin@swipnet.se (Peter Lewerin) wrote
> There is a paradigm
> difference between CLOS and non-OOP Lisp code, but the language is the
> same, and it's quite possible to mix the two.
...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| |
