On 5/10/2013 4:04 PM, Jonathan M Davis wrote:
> On Friday, May 10, 2013 14:31:00 H. S. Teoh wrote:
>> As they say in information theory: it is the stuff that stands out, that
>> is different from the rest, that carries the most information. The stuff
>> that's pretty much repeated every single time conveys very little
>> information.
>
> This is an excellent way of looking at language design (and program design for
> that matter).

I agree. Wish I'd thought of it!

On Saturday, May 11, 2013 06:12:11 Daniel Murphy wrote:
> Forget planes, this code quite obviously wants to fly! http://www.ioccc.org/1998/banks.c

LOL. Gotta love that.

- Jonathan M Davis

On Fri, May 10, 2013 at 03:02:12PM -0700, Walter Bright wrote:
> On 5/10/2013 2:31 PM, H. S. Teoh wrote:
> >Note how much boilerplate is necessary to make the code work *correctly*.
> 
> It's worse than that. Experience shows that this rat's nest style of code often is incorrect because it is both complex and never tested.

Yeah, some of those if's are very difficult to trigger, and usually nested so deep in the call tree that most people just don't bother trying to trigger it. Besides, the lack of built-in unittests in C means that even if somebody *did* test it at one point, it's very unlikely that the 15 people who came along later and modified the code will repeat the same test. And even if they did, it was probably not a *thorough* test...

Once I was trying to track down a baffling bug that causes a daemon to suddenly stop responding for no discernible reason. We spent many hours trying to figure out what went wrong, but didn't get very far.  The first clue we found was that kill -11 didn't do anything. Now, we have a segfault handler that writes the stacktrace to a log when the daemon segfaults, you see, and when debugging we often deliberately use kill -11 to segfault the daemon then look at the log to find out what it was doing at the time of the signal.  This usually worked, but not this time.  The signal seemed to be completely ignored. Only kill -9 is capable of making the stuck process go away. At first we thought it was a stray call to signal() or sigaction() that removed the stack trace handler, but closer inspection suggested that this was not the case.

It turns out that this mysterious "stuck" state was caused by the stack trace code -- but not in any of the usual ways. In order to produce the trace, it uses fprintf to write info to the log, and fprintf in turn calls malloc at various points to allocate the necessary buffers to do that. Now, if for some reason free() segfaults (e.g., you pass in an illegal pointer), then libc is still holding the internal malloc mutex lock when the OS sends the SEGV to the process, so when the stack trace handler then calls fprintf, which in turn calls malloc, it deadlocks. Further SIGSEGV's won't help, since it only makes the deadlock worse.

All of this came about because we had overlooked the POSIX spec that certain functions are unsafe to call inside signal-handler context. But then again... who hasn't?! (Hands up, those of you who knew that fprintf has undefined behaviour inside a signal handler. Yeah, I thought so.) Eventually we had to rewrite the stack trace handler to only use write() to a pre-opened socket to a logging daemon, since otherwise it was impossible to actually write the stack trace anywhere without risking undefined behaviour.

And none of this has even begun to address the original bug of why free() was passed an illegal pointer in the first place. Isn't it fun when most of the time you spend debugging is actually to fix the error-handler rather than the actual bug?


> While D doesn't make it more testable, at least it makes it simple, and hence more likely to be correct.

It makes a big difference when the language itself supports certain constructs like exceptions or scope guards. Scope guards cut away almost all of the boilerplate cruft in the equivalent C if-and-goto construct, making the attached statement so simple that it's most likely correct, as you said. It also eliminates the need to sprinkle various parts of that code across 2 or 3 different places in an overly-long function with unclear execution path, that in C is almost guaranteed to become buggy after passing through the grubby hands of the next 5 unfortunate coders assigned to work on the code.

And while the scope guard itself may be buggy (DMD bug, say), it does get tested very often -- every D program that uses it constitutes a test case -- so any such bugs are quickly noticed and weeded out.

Seriously, D has so spoiled me I can't stand programming in another language these days. :-P


T

-- 
EMACS = Extremely Massive And Cumbersome System

On 5/10/2013 4:27 PM, H. S. Teoh wrote:
> Seriously, D has so spoiled me I can't stand programming in another
> language these days. :-P

Me too. Sometimes it makes it hard to work on the dmd front end!

On Fri, May 10, 2013 at 05:09:18PM -0700, Walter Bright wrote:
> On 5/10/2013 4:27 PM, H. S. Teoh wrote:
> >Seriously, D has so spoiled me I can't stand programming in another language these days. :-P
> 
> Me too. Sometimes it makes it hard to work on the dmd front end!

Now, *that* is not a good thing at all! When are we going to start moving towards bootstrapping D? Did any conclusions ever come of that discussion some time ago about how this might impact GDC/LDC?


T

-- 
When solving a problem, take care that you do not become part of the problem.

On Saturday, 11 May 2013 at 00:09:21 UTC, Walter Bright wrote:
> On 5/10/2013 4:27 PM, H. S. Teoh wrote:
>> Seriously, D has so spoiled me I can't stand programming in another
>> language these days. :-P
>
> Me too. Sometimes it makes it hard to work on the dmd front end!

More I work with D, less I want to work with C++.
Using D is just as funny as I found Java, but with a greater potential and global control of what we do. A lot of things are just as simple as they need and can be.

Sometimes C++ give me hives, it's so error prone and an under-productive language for the actual industry needs, that certainly why Google created the Go.
We border probably unconscious when we use the C + + for certain uses. I am curious to know which languages Google uses for their car without a driver.

On Friday, May 10, 2013 17:14:01 H. S. Teoh wrote:
> On Fri, May 10, 2013 at 05:09:18PM -0700, Walter Bright wrote:
> > On 5/10/2013 4:27 PM, H. S. Teoh wrote:
> > >Seriously, D has so spoiled me I can't stand programming in another language these days. :-P
> > 
> > Me too. Sometimes it makes it hard to work on the dmd front end!
> 
> Now, *that* is not a good thing at all! When are we going to start moving towards bootstrapping D? Did any conclusions ever come of that discussion some time ago about how this might impact GDC/LDC?

Daniel Murphy (yebblies) has an automated C++ to D converted for the front-end that he's been working on (which won't work on general C++ code but works on the front-end's code), and he's been making pull requests to dmd to adjust the code so that it's more easily converted. So, once he's done with that, it'll be trivial to have the same compiler in both C++ and D (with all of the changes going in the C++ code), and we can maintain it that way until we're ready to go pure D. And after that, we can start refactoring the D code and take advantage of what D can do.

- Jonathan M Davis

On Sat, May 11, 2013 at 02:41:59AM +0200, Flamaros wrote: [...]
> More I work with D, less I want to work with C++.

Yup. I think that applies to a lot of us here. :)


> Using D is just as funny as I found Java, but with a greater potential and global control of what we do. A lot of things are just as simple as they need and can be.

I don't know about you, but I find that Java can be very straitjacketed and verbose sometimes. I mean...

	// Java
	class MyLameProgram {
		public static void main(String[] args) throws IOException
		{ ... }
	}

Really?!  In D, we just write:

	// D
	void main(string[] args) { ... }

And then:

	// Java
	BufferedReader reader = new BufferedReader(new FileReader(args[0]));
	System.out.println("Hello world!");

Seriously?  In D we just write:

	// D
	auto lines = stdin.byLine();
	writeln("Hello world!");

Talk about signal-to-noise ratio.

And don't get me started on all those BlahBlahBlahClassWrapper's and BlahBlahBlahClassWrapperFactoryWrapper's. Ugh. And Integer vs. int, and other such atrocities. What, built-in atomic types are defective so we need to wrap them in classes now? Flawed language design, anybody?

I find D superior to Java in just about every possible way. Except perhaps for the GC. *That* one needs a bit of work to get us up to standard. :-P


> Sometimes C++ give me hives, it's so error prone and an under-productive language for the actual industry needs, that certainly why Google created the Go.

Surprisingly enough, before I found D, I actually considered ditching C++ for C. I only stayed with C++ because it has certain niceties, like exceptions, (and no need to keep typing 'struct' everywhere on a type that's blatantly obviously a struct) that in C is a royal pain in the neck. C++ is just over-complex, and its complexity in different areas interact badly with each other, making it an utter nightmare to work with beyond trivial textbook examples. OO programming in C++ is so nasty, it's laughable -- if I wanted OO, Java would be far superior. I found that C++ is only tolerable when I use it as "C with classes". Its OO features suck.

At my day job, we actually migrated from C++ back to C, because the person (people?) who wrote the original C++ framework overengineered the whole thing, to the point that making a single function call involves up to 6 layers of abstraction (in one case involving fread and fwrite of function parameters, and *then* serialization/deserialization across an RPC link). Eventually 80% of that elaborate framework was never used, because the guy who wrote it left the project, and nobody else understood it. Everyone just hacked their way around it, resulting an a gigantic mess that had who knows how many bugs just lurking beneath the surface, waiting to be exposed by a completely unrelated change elsewhere in the code. (There were some *dtors* that were doing useful work and had side-effects... talk about OO gone wrong.)

We were so traumatized by the experience that the team lead put his foot down and said, "no more C++, we're going back to C". My then-supervisor had perhaps one of the happiest days of his employment here mass-deleting all the subdirectories containing the C++ code, after the new C-based infrastructure was ready for use. (My only regret was that there are still modules written in C++ lying around.  They still suffer from the same issues, albeit to a smaller scale. At least the pain is below the tolerable threshold now.)

Of course, C has own its share of nasty gotchas and pain, but, believe it or not, it's actually better than our experience of C++, in spite of C++ being supposedly the successor to C. If I only had a say in these things, I would switch to D in an instant, no questions asked. Sigh. D may still have its wrinkles to be worked out, but it's far, far superior in comparison.


> We border probably unconscious when we use the C + + for certain uses. I am curious to know which languages Google uses for their car without a driver.

If the automated car is running on C++ code, I'd be very, very careful *not* to own one. Or, if I had to, I'd willingly shell out a fortune for my life insurance. :-P (Hey, I might even consider becoming an insurance agent, it'd be good money!) ;-)


T

-- 
Everybody talks about it, but nobody does anything about it!  -- Mark Twain

On Fri, May 10, 2013 at 09:41:07PM -0400, Jonathan M Davis wrote:
> On Friday, May 10, 2013 17:14:01 H. S. Teoh wrote:
> > On Fri, May 10, 2013 at 05:09:18PM -0700, Walter Bright wrote:
> > > On 5/10/2013 4:27 PM, H. S. Teoh wrote:
> > > >Seriously, D has so spoiled me I can't stand programming in another language these days. :-P
> > > 
> > > Me too. Sometimes it makes it hard to work on the dmd front end!
> > 
> > Now, *that* is not a good thing at all! When are we going to start moving towards bootstrapping D? Did any conclusions ever come of that discussion some time ago about how this might impact GDC/LDC?
> 
> Daniel Murphy (yebblies) has an automated C++ to D converted for the front-end that he's been working on (which won't work on general C++ code but works on the front-end's code), and he's been making pull requests to dmd to adjust the code so that it's more easily converted. So, once he's done with that, it'll be trivial to have the same compiler in both C++ and D (with all of the changes going in the C++ code), and we can maintain it that way until we're ready to go pure D. And after that, we can start refactoring the D code and take advantage of what D can do.
[...]

Excellent!!

What about GDC/LDC though? Or are we hoping that the GCC (LDC) maintainers will be willing to accept a bootstrapping D compiler by the time we're ready to go pure D?


T

-- 
In theory, there is no difference between theory and practice.

On Saturday, 11 May 2013 at 02:01:13 UTC, H. S. Teoh wrote:
> On Sat, May 11, 2013 at 02:41:59AM +0200, Flamaros wrote:
> [...]
>> More I work with D, less I want to work with C++.
>
> Yup. I think that applies to a lot of us here. :)
>
>
>> Using D is just as funny as I found Java, but with a greater
>> potential and global control of what we do. A lot of things are just
>> as simple as they need and can be.
>
> I don't know about you, but I find that Java can be very straitjacketed
> and verbose sometimes. I mean...
>
> 	// Java
> 	class MyLameProgram {
> 		public static void main(String[] args) throws IOException
> 		{ ... }
> 	}
>
> Really?!  In D, we just write:
>
> 	// D
> 	void main(string[] args) { ... }
>
> And then:
>
> 	// Java
> 	BufferedReader reader = new BufferedReader(new FileReader(args[0]));
> 	System.out.println("Hello world!");
>
> Seriously?  In D we just write:
>
> 	// D
> 	auto lines = stdin.byLine();
> 	writeln("Hello world!");
>
> Talk about signal-to-noise ratio.
>
> And don't get me started on all those BlahBlahBlahClassWrapper's and
> BlahBlahBlahClassWrapperFactoryWrapper's. Ugh. And Integer vs. int, and
> other such atrocities. What, built-in atomic types are defective so we
> need to wrap them in classes now? Flawed language design, anybody?
>
> I find D superior to Java in just about every possible way. Except
> perhaps for the GC. *That* one needs a bit of work to get us up to
> standard. :-P
>
>
>> Sometimes C++ give me hives, it's so error prone and an
>> under-productive language for the actual industry needs, that
>> certainly why Google created the Go.
>
> Surprisingly enough, before I found D, I actually considered ditching
> C++ for C. I only stayed with C++ because it has certain niceties, like
> exceptions, (and no need to keep typing 'struct' everywhere on a type
> that's blatantly obviously a struct) that in C is a royal pain in the
> neck. C++ is just over-complex, and its complexity in different areas
> interact badly with each other, making it an utter nightmare to work
> with beyond trivial textbook examples. OO programming in C++ is so
> nasty, it's laughable -- if I wanted OO, Java would be far superior. I
> found that C++ is only tolerable when I use it as "C with classes". Its
> OO features suck.
>
> At my day job, we actually migrated from C++ back to C, because the
> person (people?) who wrote the original C++ framework overengineered the
> whole thing, to the point that making a single function call involves up
> to 6 layers of abstraction (in one case involving fread and fwrite of
> function parameters, and *then* serialization/deserialization across an
> RPC link). Eventually 80% of that elaborate framework was never used,
> because the guy who wrote it left the project, and nobody else
> understood it. Everyone just hacked their way around it, resulting an a
> gigantic mess that had who knows how many bugs just lurking beneath the
> surface, waiting to be exposed by a completely unrelated change
> elsewhere in the code. (There were some *dtors* that were doing useful
> work and had side-effects... talk about OO gone wrong.)
>
> We were so traumatized by the experience that the team lead put his foot
> down and said, "no more C++, we're going back to C". My then-supervisor
> had perhaps one of the happiest days of his employment here
> mass-deleting all the subdirectories containing the C++ code, after the
> new C-based infrastructure was ready for use. (My only regret was that
> there are still modules written in C++ lying around.  They still suffer
> from the same issues, albeit to a smaller scale. At least the pain is
> below the tolerable threshold now.)
>
> Of course, C has own its share of nasty gotchas and pain, but, believe
> it or not, it's actually better than our experience of C++, in spite of
> C++ being supposedly the successor to C. If I only had a say in these
> things, I would switch to D in an instant, no questions asked. Sigh. D
> may still have its wrinkles to be worked out, but it's far, far superior
> in comparison.
>
>
>> We border probably unconscious when we use the C + + for certain
>> uses. I am curious to know which languages Google uses for their car
>> without a driver.
>
> If the automated car is running on C++ code, I'd be very, very careful
> *not* to own one. Or, if I had to, I'd willingly shell out a fortune for
> my life insurance. :-P (Hey, I might even consider becoming an insurance
> agent, it'd be good money!) ;-)
>
>
> T

I work something like 6 month with Java on a Web server, and the pair with Eclipse is nice. Having tools like Unitests well integrated or auto-fix suggestion is really great, but that true Java just can't leave with a good IDE to generate verbose code. Java is also provide with a great Framework and majority of libraries are well licensed that help a lot to be productive.

Personally I can't be ok with a language that put performances on the side, and never allow to access the hardware, but before D a choice had to be done on which language is better for our future project.

For me D joins best of two worlds : productivity and effectiveness. This without any other tool than the compiler.