Safer casts

Yigal Chripun yigal100 at gmail.com
Sat May 10 12:00:50 PDT 2008


Disclaimer: this post reflects my personal opinion only and should not
start yet another flame war about tango vs phobos. feel free to disagree
with everything I say.

based on what I know:
phobos uses the C IO. this is both bad for performance (yet another
layer) and the interface is ugly. Tango's IO much more powerful, more
efficient, and more flexible. the cost of it is that it's more complex
(compared to the  C-like functions phobos provides).
phobos is ill organized mixing the run-time library (which you as a user
should never touch) with the user code. Why is the GC internals in the
same library as the string manipulation functions?? also the namespace
in tango is much better organized into packages and modules (although,
sometimes it's too much, like the collections being nested in utils). I
prefer Tango's tango.io.Stdout vs std.stdio. I think Stdout is lame but
at least it's inside an IO package. what's the deal with using 8-letter
acronyms that are hard to remember anyway? we are not limited by DOS' 8
chars length for file names anymore.
Tango has much more functionality, is optimized for performance, has
less bugs and more maintainers than phobos. Walter is a genius compiler
writer but he can't spend all his time on phobos, And I really dislike
the C++ smell from all of the code Andrei added to phobos. He's a C++
Wizard, But that C++ mindset that templates solve everything is bad IMO.
sometimes, the language does need to provide proper syntax. D needs a
good tuple support and not a template Tuple!(...)  for example. another
example would be all the templates in std.algorithm. I'd prefer a reduce
function that takes a delegate rather than a reduce template.

Regarding C++ and STL: it is useful for C++, however it is designed in a
way to take into account all the deficiencies of C++ (which D doesn't
have). an error in your c++ code that uses STL will produce a screen
full of text which is unrelated to the problem, making it useless. STL
does not use polymorphism in any way so that if i used an iterator and
decided to reverse the iteration I need to make sure I change the
Iterator type, which is lame (had this bug, once). this complete lack of
polymorphism is plain wrong. simple example: I use a vector to go over
series of values and then decide to use a linked-list instead. I need to
go and change my code everywhere, since there are no common interfaces
like Java's List or collection for that matter. in java i can have:
List<C> list = new ArrayList<C> ();
changed to:
List<C> list = new LinkedList<C> ();
and that's it! no need to search and replace all my functions (since
they use the general List<C> anyway. Isn't that so much more productive?
 C++ needs to add language extensions (i.e. concepts) to make that work.
My point is that I do not want that design of the STL. also, C++ uses
iterators extensively, and this design can be replaced by more advanced
concepts like generators and HOF. I prefer smalltalk and ruby way of
collection.each { code } vs. C++ more primitive:
for (collection::iterator i = collection.begin(); i != collection.end()
; ++i) { code }
which one of those is better?
smalltalk has map:, select: inject:into: etc, built into the collections
classes, which is SO much better than using C++ iterators.
STL does provide similar constructs but they are so verbose that no one
ever uses them.
D needs to become a compiled efficient ruby-like language more than a
slightly more readable C++.

Those are my rumblings, If somebody got offended, than I'm truly sorry
for that. I just wish for a better D future.

--Yigal



More information about the Digitalmars-d mailing list