▲ 238 points
back
74 comments
Reading this article and the HN comments, I'm realising something nice: to me, Walter Bright was always up there with the unapproachable gurus of programming. Clearly, he doesn't see himself like that at all, which is a very encouraging thing to realise. It's nice to be reminded that many people I look up to are really just down here, feet on the ground, and that maybe I could accomplish similarly great things by just (keeping) giving it a go.
This is surprisingly the case for lots of craftsmen in all fields. You may enjoy The Mundanity Of Excellence, by Daniel Chambliss, about how ordinary Olympic swimmers actually are. http://www.visakanv.com/blog/2014/01/the-mundanity-of-excell...
Sad reminder of Ian Thorpe. I hope he gets through his illness, although I hear it's unlikely that he'll swim again.
Reading the D forums you see how friendly and approachable he really is. Hand in hand with that is great patience, I'd say.
Where I fall down is that without encouragement I'm not a 'completer-finisher'. Walter has that great ability to grind out the finished quality product. I love D for its expressiveness and speed, here's hoping it wins out.
Enjoyed this a lot. Points I could identify with:
- being motivated by people telling you you can't do it.
- writing what you need instead of what other people say the world needs.
- having a weakness for getting into arguments with people who are "wrong." :)
- being inclined to work solo, and being uncomfortable giving up control but realizing at some point that you have to cede some.
> being motivated by people telling you you can't do it.
I'm saddened by all the stories I see posted here and on Reddit where people are discouraged from doing things by negative remarks from others.
You only hear about the people who succeeded when everyone told them they would fail. The many that failed when everyone said they'd fail don't often make the news.
People usually have good reasons why they say negative things. It's worth understanding the negative sentiment.
For example, victims of certain types of fraud are often warned repeatedly by friends and family that they are going to be defrauded. Some still go ahead and lose staggering sums of money.
It's important to really listen to the naysayers, if only to understand the risks. Then you can make an informed choice as to if you'll try your hand at something that's potentially costly.
It's funny (not really) that the set of people who actually do things and the set of people who reflexively post negative comments on the internet barely intersect, if at all.
> I'm glad I didn't listen to the naysayers, the Debbie Downers, and of course that nameless C guru from long ago, whom I owe thanks to.
That's great to hear that you didn't let the negativity stop you.
I was recently told "If you're going to get bogged down trying to get the lexer/parser to work, you're not ready to work on a full blown language/compiler." Hopefully my story will go the same way as yours.
Nice article! I tried out D a while back and I liked it a lot. I'm not sure I'll pick it back up again but it's certainly a possibility, especially if I feel compelled to write C++ again... yikes. I'm a language geek myself; I'm working on a language, my third so far but this one is the farthest I've yet gotten and I'm really excited about it.
One question I have for Walter, when you were writing your compilers (both back in the day, and for D), how much did you just try to figure out yourself, and how much did you rely on literature to guide you? I tend to find it more fun to just try to do it myself, and only turn to literature when I'm really stuck. But obviously there's a bunch of valuable things to be found in books and articles, and they can save you from bad decisions or going down fruitless rabbit holes. As someone who's very experienced in language implementation, do you tend to invent your own algorithms, or rely more on academic and industry literature?
I tended to have many amazing insights, only to discover I'd just reinvented the wheel. It's because I do not have an academic comp sci background.
I learned how to do data flow analysis by taking a short course put on by Ullman and Hennessy.
I learned about GC from the famous GC book.
I learned a lot from people who started out saying "Walter, you damned ignorant fool! [...]"
I've learned a lot about things that sound like great ideas but just don't work, from bitter experience. I try to pass this stuff on to the next generation, but they are usually determined to make the same mistakes. Oh well.
I try to pass this stuff on to the next generation, but they are usually determined to make the same mistakes. Oh well.
As someone working in the area of compilers... Do you have that advice written down anywhere?
Walter, always wanted to ask you - what do you do for living? Is it something related to D or compilers in general (consulting maybe?). Also interesting if Digital Mars commercial compiler had/has any success.
Excuse my ignorance, but which book on GC is the famous GC book, I recently looked at a book on GC from the Uni library, and it was pretty awful.
Is there other books, papers, authors you would recommend related to compilers, optimisations, runtimes (vm or otherwise) and programming lanugauges?
How would one compare/contrast D vs. Rust? Both concerning the problems they try to solve / the niches they target, and the way they choose to solve them.
I almost never heard/read something about Rust from a D developer and the other way around, it's a bit like they live in different parallel universes :)
There was an interesting discussion on a golang thread about Go vs C++ vs D, with great insights in conversation between Andrei Alexandrescu and some of the Go guys (can't remember where to look for the link right now...), but it only made clear the fact that Go and D target very different niches and it was basically an apples to oranges comparison... but D and Rust would be an interesting comparison, they really are in the same "zone" but the communities seem very different and each seems not to know or care about what the others are doing (there was a Rust guy on that thread mentioning the way Rust uses the pointer types system for memory safety and the others were something a long the lines of "can a type system really be used for that?!" that clearly suggested the two groups didn't share their ideas a lot).
EDIT+: this might be the link to the thread I was referring: https://groups.google.com/forum/#!topic/golang-nuts/8k59Rgke...
Rust and D will largely inhabit the same conceptual space (both can easily be used to write efficent, low-level programs) but their individual styles are so different that I think in practice any given programmer will have a clear preference for one or the other, with little overlap between the communities.
Rust has an overriding emphasis on guaranteeing memory safety and correctness, and when the programmer must resort to potentially unsafe code it isolates the unsafe portions of the source code so that they can be more easily audited by hand and thoroughly tested. It specifically incorporates safety features with zero runtime overhead (with the exception of array bounds checking, which can be turned off on a case-by-case basis) in order to appeal to C++ programmers who need to work close to the metal.
D also emphasizes greater safety than C++, but not to the fanatical degree that Rust does. D smooths and streamlines the experience of writing C++-level code and favors expressiveness, with especially impressive compile-time programming abilities.
The most important conceptual division between D and Rust is that D guarantees memory safety via garbage collection (which can be disabled, at the cost of losing memory safety), whereas Rust guarantees memory safety via compile-time checks (which makes Rust code less convenient to write, since it forces you to think about the lifetimes of your data, but provides the benefits of memory safety in environments where GC overhead is unacceptable or where the code must run without an accompanying runtime present).
Both languages share many similarities to C++, but this is merely convergent evolution. D deliberately began with a very strong C++ influence, whereas Rust began as more of an OCaml-like language and gradually evolved toward C++ due to the pressures of designing a production-grade systems language. The result is that Rust favors ideas more prevalent in functional languages: immutability-by-default, algebraic data types, everything-is-an-expression, and so on.
A good oversimplification might be something like: D was conceived by people who were tired of how clunky C++ is. Rust was conceived by people who were tired of how unsafe C++ is.
I guess it is a matter of how both communities look into the problems.
Currently I spend more time on D forums than Rust ones, and to be honest given my type of work I can only use JVM/.NET/C++ languages, as customers have the last word.
However as language/compiler geek I do follow many discussions.
Trying to avoid a flamewar here.
D has a GC and follows the school of thought from Cedar, Oberon, Modula-3 and so forth, where it is assumed you can have a systems programming language with GC, which also allows for manual allocation when required to do so.
Still room to improvement there in terms of performance, though.
Rust leaves GC to the library, at the expense of a complexer type system as a means to allow the compiler to reason about automatic memory usage.
Both provide very powerful and modern abstraction mechanisms.
Which one is better? I think it is a question of use cases.
"I confided this to a colleague, and he suggested a lunch with him and the local C guru"
This stood out to me as the #1 difference between me and successful people. I always notice it in every article or bio of someone successful. Something that has never, and would never happen to me at any point in time, but in the bios, it's always there:
The first person I mentioned my idea to suggested a lunch.
Don't forget the food they might have eaten: an appetizer of salami and mimolet followed by shwarma with lots of red onions in it.
Successful people affirm the consequent [0]. For example, naming your language "D".
[0] http://en.wikipedia.org/wiki/Affirming_the_consequent
Edit: add scholarly footnote and tighten up language.
"Successful people affirm the consequent" - Not sure what you mean here; you're linking to a description of a logical fallacy.
If you never go to lunch, you can never plan out your idea on a napkin.
there are plenty of napkins at the bar, however ;-)
Also, successful people generally tend to have very vast social networks (in the real sense, not Facebook)
Anyone who knew me then would laugh at the idea that I had a vast social network. My colleague sat next cubicle over at work.
Why would this never happen to you?
I believe the parent comment is implying that in every biography by someone who does something impressive, there are moments that show the environment they where in. Some things to note about the statement "I confided this to a colleague, and he suggested a lunch with him and the local C guru"
1. He had a colleague to speak to about this issue. This indicates he and the colleague had a relationship conducive to speaking about such problems, and was in a position to speak to him in the first place.
2. That colleague was engaged enough to want to hear more.
3. The colleague knew a "local C guru" and in turn had enough of a relationship with that guru to arrange a lunch between the three of them.
All of these things point to an environment that helps foster this kind of work. It shows that the author was hard working enough already to be in that position.
I don't know if others interpreted his statement to mean the same things, but that's what I have.
Great read!
I once used D to implement a toy LISP language under a thousand lines including the native and loads of built-in functions. I can't imagine doing it this easily, this cleanly and this performant using either C or C++ (I even had fixnums and clojure-like vectors and maps, although not persistent.)
There's a lot of features to learn, and a lot of ways to use them. But the result is something almost as powerful as LISP, almost as safe as Haskell, as low-level as C and even more with inline assembly, and most importantly as productive as Ruby. Definitely a lot to digest as a first language!
Congrats on making the top 20 most used languages, well deserved!
It's interesting how games have driven the development of computer systems. Unix, for example, was motivated by Ken Thompson's work porting his game Space Travel* to the PDP-7.
I loved his Zortech compiler, esp. the nice GUI which beat all others, but mostly his C library which came with it. I used a lot of his libraries for while, until I decided that C/C++ is a dead end.
With D he found his mojo, but people are still raving about Rust and are still mostly ignoring Walter. Big thanks to Facebook for deciding on D. Only ObjC came close but D is better.
[The guru's] contemptuous response is still etched on my brain, "Who the hell do you think you are thinking you can write a C compiler?"
I guess this guy never heard of Leor Zolman and the BD Software C Compiler [0] :-)
I got a lot of use out of that compiler back in the day, but I can tell you, Leor had no idea what he was doing when he started.
Leor's a great guy and is still actively programming.
Yeah, he and I traded emails briefly 7 or 8 years ago, I think, but didn't really have that much to talk about.
But we go way back -- we were in the same class and same dorm at MIT (before he dropped out and wrote BDS C), and were housemates for about a year c. 1981-82.
Ever hear of MINCE? It was a micro-Emacs that first ran on CP/M, later MS-DOS. The first version was developed using BDS C.
I have a bachelors in mech engg. I eventually moved to software and Walter Bright exactly echoes why:
My degree was in mechanical engineering. But mechanical engineering was frustrating because of the large expense involved with building anything ... With programming, on the other hand, I could build the most intricate machines imaginable at no expense, needing only access to a computer.
I had a rather critical view of D at first. Another C like again, we never get rid of these bracket-oriented languages! Then came Go and Rust, and my opinion has changed, I see it more favorably, as it does not seem to be the worst of them.
What kind of things do people use D for? If there was an ARM compiler I'd use it for embedded work in a (bounds-checked!) heartbeat.
This page lists some: http://wiki.dlang.org/Current_D_Use
Work is happening with ARM, but it needs more pre-early adopters. http://wiki.dlang.org/GDC/Cross_Compiler
Love D, I'm going to SF D conf!
totally off topic, but programmers, I need your help...
I was thinking Andrei Alexandrescu did invent the D language.
Nope, D hit 1.0 before Andrei got involved in development, or it was at least very close.
Why do they use a name that would make it almost impossible to search information on it? I can understand "C" on a pre-internet world, but "D" in 2014?
While your point stands, it was "D" in 2001.
Googling "D language" works just fine. No problems.
The name expresses the intent very well, does it not?
yah they should've named it Gdheegh.
TL;DR: He wants the D.