null references redux + Looney Tunes

Justin Johansson no at spam.com
Sun Oct 4 13:10:09 PDT 2009


Jeremie Pelletier Wrote:

> Walter Bright wrote:
> > Jeremie Pelletier wrote:
> >> language_fan wrote:
> >>> I admitted that later. Some of the keywords have a strong 
> >>> justification behind them. Others feel irritatingly unnecessary.
> >>
> >> I would rather have many different specialized keywords than a few 
> >> keywords with many different meanings. Its *much* easier to remember a 
> >> large set of simple words than a small set of complex words.
> > 
> > Many of the keywords come from each basic type having its own keyword. 
> > Sure, it could be done like C does with "unsigned long", etc., but those 
> > were always hard to grep for.
> 
> I agree, especially since most libraries redefine these types to not 
> have to use "unsigned long" and others all over the place and to 
> abstract different compilers.
> 
> Having standard types in D is one of it's best features, just makes 
> everything much easier.
> 
> > Also, the complex and imaginary types will be removed at some point and 
> > replaced with a library type; there goes 6 keywords.
> 



> > Many of the keywords come from each basic type having its own keyword. 
> > Sure, it could be done like C does with "unsigned long", etc., but those 
> > were always hard to grep for.

Agree 110%.  Not only hard to grep for, but also an example of orthogonality not actually helping.
The number of C/C++ programs that I've had to deal over the years, all defining their own standard
library int types just to nail down the bit size is mind boggling.
UINT8, uint8, UInt8, SINT8, int8, Int8, int8_t, uint8_t, ubyte, sbyte ...  and these just some of the
8 bit variations.

Then to make thinks worse, someone invents compiler switches to make ints signed
or unsigned by default.  What madness.

> Why? What's the rationale behind such a move? These types will always be 
> handled the same no matter what library implements them. These are 
> always tricky to use in C since different compilers implement them 
> differently, why do the same in D?

I'm with Jeremie on this one .. or at least the jury should still be out.

Imaginary numbers have the same right to life as real numbers.  How many scientific, engineering,
applied maths problems have been solved because of the invention or discovery of complex numbers?
I like the idea of a language treats its complex numbers as first class citizens.

Come to think of it, it was one of the first salient features of D that drew me to the language.

I speak not only with an emotive affection towards complex numbers but with many years of practical
experience with DSP (digital signal processing) software, software development at the coalface using
GMM (gaussian mixture models) for speech processing, FFT (Fast Fourier Transforms) in general and the
FFTW (The Fastest Fourier Transform in the West*) C FFT library (which by the way, the authors thereof
received a prestigious award for their contribution to numerical software**).

* http://www.fftw.org/

** http://www.mcs.anl.gov/research/opportunities/wilkinsonprize/3rd-1999.php

It's a difficult challenge to get high performance, readable and maintainable code out of complex number
intensive algorithms.   Use of library types for complex numbers has, in my experience been problematic.
Complex numbers should be first class value types I say.

My $0.05

-- Justin Johansson




More information about the Digitalmars-d mailing list