Why I chose D over Ada and Eiffel

QAston qaston at gmail.com
Tue Aug 20 09:51:04 PDT 2013


On Tuesday, 20 August 2013 at 16:49:35 UTC, QAston wrote:
> On Tuesday, 20 August 2013 at 16:40:21 UTC, Ramon wrote:
>> Yes and no.
>> While UTF-8 almost always is the most memory efficient 
>> representation of anything beyond ASCII it does have a 
>> property that can be troublesome a times, the difference 
>> between length and size of a string, i.e. the number of 
>> "characters" vs. the number of bytes used.
>>
>> ---
>>
>> As for another issue I'm getting more and more disappointed: 
>> generics.
>>
>> To put (my mind) bluntly, D does *not* support generics but 
>> rather went into the same ugly trap C++ went into, albeit D 
>> handles the situation way more elegantly.
>>
>> Forgive me seeming harsh here but I just wrote it in the D gui 
>> thread: Any really great solution needs a solid philosophy and 
>> very profound thinking and consistency - and here D failed 
>> bluntly (in my minds eye).
>>
>> With all due respect: Templates are an editors job, not a 
>> compilers.
>> Yes, templates offer some gadgets beyond simple replacement 
>> but basically they are just a comfort thingy, relieving the 
>> programmer from typing.
>>
>> That, however, was *not* the point about generics. They are 
>> about implementing algorithms independent of data types (as 
>> far as possible).
>>
>> Now, I'm looking around at mixins and interfaces in order to 
>> somehow makeshift some kind of a halfway reasonable generics 
>> mechanism. Yuck!
>>
>> Well, maybe it's my fault. Maybe I was foolish to hope for 
>> something like Eiffel but more pragmatically useful and 
>> useable, more C style and way better documented. What I seem 
>> to have found with D is a *very nice* and *way better* and 
>> considerably more useful kind of C++.
>>
>> Why aren't real generics there? I mean it's not that high tech 
>> or hard to implement (leaving aside macho bla bla like "It'd 
>> break the ranges system").
>>
>> why not something like
>>
>> generic min(T:comparable) { // works only with comparable 
>> types/classes
>>  // min magic
>> }
>>
>> This could then at *run time* work with anything that met the 
>> spec for "comparable" which basically came down to anything 
>> that offers "equ" and "gt" (and "not").
>
> Interfaces offer runtime resolution:
>
> interface Comparable
> {
>
> }
> void doStuff(Comparable c)
> {
> }
> will work with anything that meets the specs for comparable.
>
> For compile time resolution you can do this
sorry, I missclicked and then unintentionally posted this 
unfinished by "Send" keyboard shortcut :(


More information about the Digitalmars-d mailing list