Thursday, January 16, 2003

whine->whine(whine);


When the slashdot article

The D Language Progresses
appeared last weekend, I didn't expect
anything useful from the article comments ("This language will change
the world!" "We don't need another language!" "Beowulf Cluster!"), but I
took the opportunity to check out the latest language spec.



I'd seen the language before, and I approve of the general goal: create a
statically-typed, compiled, garbage-collected, module-based language which
is as similar to C++ as possible while excising the nastier bits.
If it were complete and well-supported, that's the kind of language
that I'd seriously consider switching to. However, a look through the spec revealed a language feature that's all
too common, and which makes me cranky.




On the list of C++ "features to
drop", D mentions



  • Creating object instances on the stack. In D, all class objects are by
    reference.


RRGH! This is true of too many otherwise promising languages. Several
native value types are supported (int, float,
string, etc), but
user-defined value types are prohibited. Instead, all user-defined types
are "by reference", which means every class instance is heap-allocated individually.



For most of the programs I write (graphics, physics, etc),
int, float, and string aren't the only value
types I'm interested in. What about 3-dimensional points? Matrices?
Colors? These value types all simplify programming enormously,
especially when combined with operator overloading
(which D does support, incidentally). I'm not suggesting that D should support these natively; these
are just the sorts of custom types I expect to be able to
create with the class mechanism.



And it's important for these types to be true value types, and not
"by reference". Why? Because I commonly pack thousands of
instances into arrays for transport and manipulation. If all class
instances are "by reference", then arrays of those instances are
actually arrays of pointers, not arrays of the objects themselves.
The objects themselves get heap-allocated willy-nilly, and memory
coherence goes all to hell.



(It doesn't have to be this way, I suppose. You could prohibit instances on the stack but support
tightly packed instances in arrays on the heap. But
I see no evidence that D does this.)



The D documentation justifies its decision thusly.



This eliminates the need for copy constructors, assignment operators,
complex destructor semantics, and interactions with exception handling
stack unwinding. Memory resources get freed by the garbage collector,
other resources are freed by try-finally blocks.



True enough, though I'd much rather have "complex destructor semantics" for some objects if it means I can pack thousands of them into an array.



'Course, I'm really just saying "D doesn't seem appropriate for math-intensive,
very data-heavy applications." And perhaps that's not profound, or even
interesting. After all, garbage-collection is similarly
ill-suited to manipulating enormous datasets since dead
values don't get deleted right away. But I like garbage collection in general. I guess I want a language where some values can be garbage collected,
with other deleted explicitly. Or where large
structures can be tracked differently by the garbage collector, so they get deleted right away.



So my complaint may be irrelevant to D. But it still makes me cranky, because the only language I've found that's good at data-heavy stuff and general-purpose app work is C++. And C++ is, well... C++.



3 comments:

  1. Programming language debates all often decay into simple religious arguments. "Static scoping!" "Dynamic scoping!" "Static typing!" "Run time typing!" " Polymorphic typing!" All too often the real point of using a programming language gets lost.
    I use programming languages to write programs that solve problems. Programs that run on real machines that I can buy at Fry's. It doesn't help to have the greatest language in the universe if I can't run it on machines that I have. It also doesn't help for me to have a language whose own semantics are complicated enough that they dwarf the complexity of the problem that I am trying to solve.
    C++ is largely an abomination. I'm reminded of a discussion I had with Will Clinger, author of the Revised Report on Scheme about the differences between Scheme and CommonLisp. Will's philosophy as guardian of the Scheme specification was that each time someone proposed something be added to the Scheme Specification, they would have to demonstrate that the addition created some new capability that didn't exist before, that that capability was important, and that the proposed implementation was the best of all available alternatives. Clinger contrasted this with Guy Steele's work as the manager of the CommonLisp specification, whose attitude was that if each proposed addition only added a little ugliness and didn't actually harm the core, they should let it in because somebody somewhere might like it.
    C++ has many, many features, mostly tied together in an ill-conceived whole. It is incredibly difficult to keep the semantics of constructors and destructors straight (particularly in the presence of exception handling). The template syntax is gruesome. Initialization of singleton objects (particularly
    in cases with dynamic loading or separate linking) is painful. Yes, it does provide for greater encapsulation, but I think on a whole more is lost than gained.
    I still program in C. I find it almost entirely adequate
    to the tasks I put for it. I've been writing C in an object oriented style for over fifteen years. If I am going to
    have to pass objects as references, I see no reason to shift
    to D to do so. I can keep the semantics of C in my head. I see little advantage to push out other useful knowledge to put C++ in there.

    ReplyDelete
  2. I'm a little surprised there isn't a more visible "we know C++ and we still program in C" movement out there, given that so many people seem to feel that way.
    Does anybody here know of such an organization?
    I still program in C, not C++, including at my job. And the same is true of my previous one (Broadcom and Palm respectively). And that's because of company/department policy, not just me being difficult :-)

    ReplyDelete
  3. Với các dịch vụ vận chuyển, ship hàng toàn quốc mà chúng tôi đang cung cấp. Đảm bảo sẽ phục vụ nhu cầu Tết cũng như nhu cầu vận chuyển hằng ngày của quý khách hàng. Cụ thể chúng tôi sẽ cung cấp dịch vụ chuyển quà tết. Chúng tôi sẽ giúp bạn với dịch vụ vận chuyển hàng hóa trong nước giá rẻ sẽ chuyển hàng đến tay người thân, bạn bè ở xa một cách nhanh chóng nhất. Đảm bảo giá cả hợp lý chất lượng dịch vụ tuyệt vời. Ngoài ra chúng tôi còn cung cấp nhiều dịch vụ khác như dịch vụ ship hàng cod, giao hàng cho shop, chuyển phát nhanh giá rẻ trong nước,... Nếu cần chuyển hàng hãy nhớ liên hệ với chúng tôi nhé.

    ReplyDelete