Warp wrote:

> 
>     0 < money
> 

Where that really comes into play is range statements:

if(10 < money && money < 100)
{
  ...
}

which can be read as "if money is between 10 and 100"

Someone I used to work with insisted that you use the same direction in 
comparisons if you had more than 1 comparison. It seemed to make sense 
when he used this example. The equivalent (and probably the way most 
people are familiar with handling ranges) "money > 10 && money < 100" 
isn't as quick to parse what you're looking for. Using that sort of 
statement with a single comparison seems a bit ridiculous to me, though.

I have seen and used the [Constant|Literal] == [Variable] syntax before, 
it's good for preventing assignment where you meant equality bugs. Of 
course, the problem becomes obvious when you begin debugging seemingly 
bizarre behavior. But, the objective is to prevent such behavior in the 
first place.

My favorite syntactical bug was the following:

for(int i = 0; i < cItems; i++);
{
    ... Block of code ...
}

It's subtle, and if your for loops are any more complex than the above 
trivial example, results in headaches. I spent an hour tracking 
something similar down in my early days.

Post a reply to this message

Invisible wrote:

> And that's the sad part. C is a horrid, horrid language, but it's where 
> all the libraries are. All the "good" languages I've seen have a 
> crippling lack of half-decent libraries... [And usually, rather limited 
> documentation and unpolished toolchains.]

Nothing wrong with C or it's derivatives. Once you've acquainted 
yourself with the syntax, it's quite powerful.

Then you can do such convenient things as:

int * DoStuff(int i)
{
   //... code for DoStuff here ...
}

int *(*pfunc)(int);

int main(int argc, char **argv)
{
    pfunc = DoStuff;

    // This will call DoStuff (In C# pfunc would be called a "delegate")
    int *pWhatever = pfunc(4096);
}

Post a reply to this message

Warp wrote:

>   IMO one very important factor for the popularity of C++ is the staggering
> amount of libraries for it. Since almost all C libraries can be used in C++,
> the amount of available libraries is simply enormous.

I'd venture to say C# also has an astounding amount of libraries (at 
least, on the Windows platform ...) the base library for .NET is pretty 
extensive, though not without limitations, but those can easily be 
worked around. I don't know whether the base libraries for Mono are as 
plentiful, as I only have very limited experience with Mono.

The drawback? It's not viewed as a high performance language.

Post a reply to this message

Warp wrote:
>   Btw, often people wonder why C++ is so popular, given that there are
> so many "better" languages out there.

What's wrong with C++? I just found out how to make a dynamic 2d array 
and save numbers to a file via binary representation. The possibilities 
just opened up...

>   IMO one very important factor for the popularity of C++ is the staggering
> amount of libraries for it. Since almost all C libraries can be used in C++,
> the amount of available libraries is simply enormous.

A very big plus :)

>   This is, IMO, often one of the major killers for new languages: Lack of
> libraries. The language may be the most perfect language in the world, but
> if you don't have libraries to do what you want, it's almost useless.
> Nobody wants to reinvent the wheel for every little thing that has been
> already implemented to death by other people.

This is why I'm giving up Euphoria. It was great when I has DOS, but now 
that I have XP, the best graphics library I could find was a sucky 
Allegro implementation. Very buggy and wasteful, since the best it can 
do is a difficult version of triple buffering, and only in certain video 
modes. I used to arrive at a better result using only *one* virtual 
screen...

C++ is great. If I don't like a certain library, I can find a new one. 
My current favorites are SDL (for CA sims) and HGE (for games). Irrlicht 
looks promising, though I haven't played with it much.

Sam

Post a reply to this message

Mike Raiford <mra### [at] hotmailcom> wrote:
> Where that really comes into play is range statements:

> if(10 < money && money < 100)
> {
>   ...
> }

> which can be read as "if money is between 10 and 100"

> Someone I used to work with insisted that you use the same direction in 
> comparisons if you had more than 1 comparison. It seemed to make sense 
> when he used this example. The equivalent (and probably the way most 
> people are familiar with handling ranges) "money > 10 && money < 100" 
> isn't as quick to parse what you're looking for. Using that sort of 
> statement with a single comparison seems a bit ridiculous to me, though.

  I don't have any problem in quickly understanding "money > 10 && money < 100"
because I use it so much.

  (OTOH, one could argue that understanding "0 < money" becomes easy when
you use it a lot...)

  The form you suggest becomes a bit counter-productive when the expression
is not a pure "between x and y", like for example:

if(10 < money*money && money*12 < 100)

  Now it becomes much harder to understand quickly what's going on.

> I have seen and used the [Constant|Literal] == [Variable] syntax before, 
> it's good for preventing assignment where you meant equality bugs. Of 
> course, the problem becomes obvious when you begin debugging seemingly 
> bizarre behavior. But, the objective is to prevent such behavior in the 
> first place.

  In most cases the compiler will issue a warning anyways if you make
the mistake. Never been a problem to me.

> My favorite syntactical bug was the following:

> for(int i = 0; i < cItems; i++);
> {
>     ... Block of code ...
> }

> It's subtle, and if your for loops are any more complex than the above 
> trivial example, results in headaches. I spent an hour tracking 
> something similar down in my early days.

  If the loop of the body uses 'i' (as is rather usual) you'll get a
compiler error.

-- 
                                                          - Warp

Post a reply to this message

Mike Raiford <mra### [at] hotmailcom> wrote:
> I'd venture to say C# also has an astounding amount of libraries (at 
> least, on the Windows platform ...) the base library for .NET is pretty 
> extensive, though not without limitations, but those can easily be 
> worked around. I don't know whether the base libraries for Mono are as 
> plentiful, as I only have very limited experience with Mono.

> The drawback? It's not viewed as a high performance language.

  And rather Windows-only.

-- 
                                                          - Warp

Post a reply to this message

stbenge <stb### [at] hotmailcom> wrote:
> What's wrong with C++?

  Some people don't like the fact that memory management requires great care.

-- 
                                                          - Warp

Post a reply to this message

Invisible wrote:
> But alas, it's not purely functional,

Yeah. I don't think you could get a real distributed language with 
everything being truly functional, could you? Certainly you couldn't do 
things like talking to device drivers in a *purely* functional way, 
methinks.  I mean, what's the functional equivalent of "the machine 
running the calculation just burst into flames"? :-)  What's the 
functional equivalent of "we've just released a new version of this 
function"?

> and the general style just seemed 
> untidy and complicated. It's just not my cup of tea...

Yep. Altho the language itself seems pretty simple and straightforward, 
the infrastructure used to support installs and reliability and such is 
pretty dense. Lots of forward references to stuff I haven't read yet, 
and I haven't yet found the roadmap to the right order to read things 
in. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Mike Raiford wrote:
> Nothing wrong with C or it's derivatives.

There's lots wrong with it, and it isn't particularly powerful. On the 
other hand, it's straightforward and doesn't take a whole lot of runtime 
support, and it's simple enough that pretty much everyone does it the 
same way. (Unlike all the flavors of LISP, for example.)

(As for what's wrong with it, I simply cite autoconf and buffer overruns.)

>    // This will call DoStuff (In C# pfunc would be called a "delegate")

No it wouldn't.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

>> But alas, it's not purely functional,
> 
> Yeah. I don't think you could get a real distributed language with 
> everything being truly functional, could you?

Um... why?

> I mean, what's the functional equivalent of "the machine 
> running the calculation just burst into flames"? :-)

Throwing an exception, as a guess. Like a division by zero error, but 
less deterministic. (??!?!) ;-)

> What's the 
> functional equivalent of "we've just released a new version of this 
> function"?

Now that's an interesting question...

>> and the general style just seemed untidy and complicated. It's just 
>> not my cup of tea...
> 
> Yep. Altho the language itself seems pretty simple and straightforward, 

If by "simple and straight forward" you mean "assumes referential 
transparency but doesn't actually enforce it or make any attempt to 
check that it's there", then sure. Go knock yourself out. ;-)

> the infrastructure used to support installs and reliability and such is 
> pretty dense. Lots of forward references to stuff I haven't read yet, 
> and I haven't yet found the roadmap to the right order to read things 
> in. :-)

Gotta love documentation where you can't figure out what order to read 
it in...

OTOH, try just *finding* a good reference for Haskell for beginners...!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message