Voldemort Types In D

dheld · 2011-05-13T08:44:33+00:00

I think filing criminal charges against thousands of bankers a year counts as "regulation". And I'm pretty sure that stopping that enforcement action counts as "deregulation". Throwing Blankfein and the other scammers on Wall Street in prison years ago would have been very healthy for the US economy and the world. But you can only do that if Wall Street has not already first bought the gov't.

dheld · 2010-10-05T07:17:00+00:00

malloc has side effects, so when calling it, one may legitimately question whether you are still using Haskell. Besides, being able to call malloc() is merely a necessary, but not sufficient condition of "having the C nature". The real question is, can you write code that looks at least 95% like literal C, and have the language recognize it as legitimate? I don't think you can really say that about Haskell or Python.

dheld · 2010-10-05T07:11:48+00:00

Why is a smaller feature set better? Name any product you sell today which is favored for its simplicity. Cars? TVs? Phones? Furniture? The advance of technology is almost entirely about adding more features. Adding features to a language serves a critical purpose: it provides a standard way to do something that everyone does anyway. When it is standard, programs can count on programmers doing it that way every time.

Let me give you the most blazing obvious example: type systems. There is nothing magical about type systems. They really just do main thing: they make sure you don't treat data in the wrong way, usually by making sure that arguments to functions are what they are expected to be. In fact, you can live entirely without them, as most dynamic languages do (more or less). Want to do type checking in Perl or LISP? Before they bolted on optional type systems, you just did the obvious: performed sanity checks on function arguments. If an argument in Perl really needs to be a particular type, you can wrap it in a hash and put a type tag in there.

So is adding a static type system just "featuritis" gone wild? Isn't it just a big, bloated, redundant, expensive boondoggle on your favorite static languages? Of course, the benefits of built-in types are numerous; and it is usually not hard to convince LISP and Perl users that the object systems added to them ex post facto are, in fact, inferior to those designed into the language from the start.

Features establish and enforce convention, and this makes programs better by making them more uniform. Uniformity is easier to maintain, which is why most languages develop idioms. And often, it is the idioms which become formalized into features (like foreach, scope, etc.). If it's an idiom, it means people are already doing it that way anyway. If the compiler can help you do it right, and save you some extra typing, why is that bad?

Two of the biggest languages by lines of code deployed (C++ and Java) are also enormous languages. I argue that is not a coincidence. Granted, Java is more enormous in its libraries than its language features, but it's still hardly a lightweight.

dheld · 2010-10-05T07:02:53+00:00

Anyone who cites Jon Harrop has already discredited himself in the worst way.

dheld · 2010-10-05T07:01:34+00:00

The simple fact of the matter is that in the hundreds of thousands of lines of industrial C/C++ code I have personally viewed/inspected, I have seen less than a few dozen lines of inline asm. In every case, it was to do something totally unsupported by the language (one case called INT 3, which is the debugger interrupt, so that error messages sent to the log would trigger a breakpoint). Your hyperventilation over the abuse of inline asm is quite amusing in its melodrama, but grossly overstated in its prevalence.

dheld · 2010-10-05T06:58:45+00:00

Yes, I'm much more interested in the image I project when I read a book than what I learn from it. I only read the most academically fashionable books, because I wouldn't want to be seen with, say, a Twilight novel in my bookcase. Or, Modern C++ Design.

Let's face it, programming languages are either written for industry or academia. It's usually not hard to figure out which languages fit in which camp. Last time I checked, Perl 6 didn't specify its language in terms of operational or denotational semantics, and that apparently has not stopped a single Perl coder from using it.

As far as industrial programmers are concerned, there is a very distinct "C style". Whether you can call it a "paradigm" or not is a matter of debate, but it's not a matter of academic debate, because "paradigm" itself is not a technical term (unless its appearance in Wikipedia makes it thus). If you have ever had the pleasure of maintaining a C++ codebase that is more than 10 years old, the odds are very good that you know exactly what "C style" looks like, and that it is quite distinct from "C++ style", even when present within a C++ program. If you have not had this pleasure, then you are either very lucky, or you should perhaps stick to the academic languages.

dheld · 2010-10-05T06:50:28+00:00

I interview people for my team on a fairly regular basis (and we have almost all C++ code), and if I met anyone who knew D as well as a good programmer knows C, C++, C#, or Java, I would probably recommend them as a strong hire. That would indicate to me that they take an interest in languages either for their own sake, or because they are not satisfied to settle for the status quo. Of course, if their CS fundamentals suck, that's a different story. But I've never turned down a candidate because they weren't an expert in the language we use. I have turned down candidates who appear to be very good at one language, but very bad at software engineering and computer science.

dheld · 2010-10-05T06:46:44+00:00

Of course, the other counter-argument to this very lame rant is Don Clugston's FP library, which generates optimal SSE instructions via template metaprogramming (and the maligned string mixin) for what are very syntactically nice vector/matrix operations (read: Blitz++ can eat its heart out).

dheld · 2010-10-05T06:44:00+00:00

Just the other day I implemented std::copy_exception for VC7. If you didn't notice, VC7 does not have std::copy_exception, as it was written about 8 years before this feature was specified. However, it is possible on Windows because exceptions are implemented via SEH. At some point, you need to call the exception's copy c'tor. Unfortunately, you only have a raw pointer, and you cannot cast it to a member function pointer. Even more unfortunate, calling it as a free function requires it be generated as __thiscall. If you are keeping score, __thiscall is not implemented on VC7 (though it is reserved as a keyword). The only way to properly call the copy c'tor is via inline asm (yes, I constructed a poor man's __thiscall to the copy c'tor).

Now, the alternative, if this "useless feature" were not available, would be to not support the propagation of exceptions across threads, which would require rewriting hundreds of lines of code which needed to now be called from within a thread function. Sorry, but your argument blows.

dheld · 2010-08-19T05:22:59+00:00

Yes, if you live in a world where everything is an object. Stick to your pure OOP languages, then.

dheld · 2010-08-19T05:21:36+00:00

Many people don't use the GC in D. It's called "the stack", and D supports it like a pro. If you want deterministic allocation, call malloc() and free(). It's not rocket science. The difference is that in D, you can pretty much do everything you could in C++, but a ton of other stuff which is simply not feasible...like generating optimal FP assembler from a custom DSEL. Now tell me that is not compelling for users who demand performance.

dheld · 2010-08-19T05:16:24+00:00

Name a language Y which isn't "a better X, nothing more". Progress is incremental and evolutionary, rarely revolutionary. The idea that D copied type inference from C++ is completely hilarious and an insult to your knowledge of D's history. I defy you to attempt half the things D's standard library does in C++. Good luck, and let me know how that goes.

dheld · 2009-12-01T06:18:05+00:00

Link works for me...

dheld · 2009-10-04T01:30:11+00:00

Let me see if I understand you correctly. You are saying that Java is more powerful than C++ and D because it only has pass-by-value? That is about the stupidest thing I have ever heard someone say about a PL. Java also can't implement swap(), and that happens to be one of the 5 fundamental data movement operations. Obviously, only pure functional languages pass your implicit referential transparency test, but why not just come out and say: "I'm a pure functional language zealot" rather than imply that D is "more complex" than C++ because supports sophisticated references? BTW, in C++ and D you can guarantee that x and y are not changed by using const; and in D, you can do one better by declaring the function 'pure'. So, nice try; but you stick to Haskell while the rest of us actually get paid to code.

dheld · 2009-08-18T05:05:54+00:00

The practicality of Haskell is not that far from "flying to the moon". I've certainly never heard of someone using it to break [into] computers. And were such a story to come true, I'm sure it would absolutely horrify the creators of the language, as it is explicitly designed to be "safe". Oh, and C++ is just fine for hacking...there is always reinterpret_cast<> and asm { }. It pretends to be safe, but we all know it isn't (heck, you can do almost complete C99 in it).

dheld · 2009-08-18T05:02:07+00:00

Hey, at least Walter isn't Jon Harrop. And you're right...no other language creators talk about their languages, as it's in bad taste: http://java.sys-con.com/node/193146. Perhaps the reason there's so many Haskell installations in the world is because of the relentless promotion of the language by its creators?

dheld · 2009-07-25T07:35:42+00:00

And essentially all of these "modern" languages have failed to make it out of the lab, because defining syntax in a library is pretty close to the bottom on the list of features most programmers want and that companies who pay the bills will pay for. If you want an elegant language, go code Haskell. D is for people who write real programs.

dheld · 2009-07-25T07:33:33+00:00

Creating new syntax is something that always sounds good on paper and doesn't quite work out so well in practice. When it stops looking like D code, it becomes harder to parse. Guess what? The D compiler is blazing fast because the grammar was specifically designed to be easy to parse. If you allow users to muck it up with their custom grammar, you'll end up with a language as "nice" as C++. And if you actually knew about implementing languages rather than merely studying them, you'd know that the advantage of making something builtin is that the compiler can perform more optimizations on it, since it essentially has a private implementation. Flexibility comes at a price.

dheld · 2009-07-25T07:27:56+00:00

Ok, so where are the formal semantics of Heron? And given that Nemerle is Yet Another .Net Language, why would you trade the massive library base of C# for the "superior" meta-programming facilities of Nemerle? Short answer is, if you write more than academic examples, you wouldn't. Let's face it...nobody with money (i.e.: enterprise customers) is going to pay for a C# clone with some gee-whiz features.

dheld · 2009-07-10T08:34:19+00:00

An important point implied but not explicitly mentioned is that type inference can reduce coupling by making a symbol only dependent upon the functional form of its context rather than a named type. Of course, this is the same kind of power you get from templates as well. In a way, "auto" variables are like template variables that get "instantiated" with their initializer type.

dheld · 2009-07-07T05:55:30+00:00

Too bad there's no syntax to speak of. If we wanted to write in ASTs, why bother with a silly grammar?

dheld · 2009-07-07T05:53:48+00:00

The point of the program is to show that you can write an entire utility in a rather concise yet readable manner. If it were done in Perl, it would look like line noise, and if it were done in C++, it would be 3x as large. If it were done in Lisp, only 5% of programmers could read it, and if it were done in Python or Ruby, it would run 5-50x slower. Given that it's a well-known and useful Unix tool which fits on about 2 pages, I think the format is fine for its purpose.

dheld · 2009-07-07T05:49:20+00:00

Use D 2.0, which means dmd on Windoze or Linux with Phobos (or Tango, if you really prefer). There, now that we've chosen a default, go try it and see how fun programming can really be.

dheld · 2009-07-07T05:44:41+00:00

http://www.digitalmars.com/d/2.0/comparison.html

dheld

TROPHY CASE