www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DConf 2013 keynote

reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 09 May 2013 10:26:46 -0400
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 On 5/9/13 10:26 AM, Andrei Alexandrescu wrote:

 With all this focus on technicalities, we forgot to discuss the
 gist of it: what did you guys think of the talk?


 
 That should better go in the digitalmars.D group though...
 


Very good talk! And good production quality, too. This would be a
great thing to point people towards to introduce them to D.

And Walter does a good job on stage. *Never* comes across as
pretentious, or cocky or full-of-...various things...like *cough*a
certain former Apple leader*cough* always did. (Minor nit: Forgot to
mention Mono-D on the last question, though.)

I love the D-like line on the first slide. Kind of a strange API being
used ;), but quintessentially D syntax. Cute :) The "100 lines of
boilerplate" bit was great too. Made me cheer even though no one else
was around.

I don't know whether it's something still under wraps or if I just need
to wait for Manu's presentation video, but I'd love to hear about how
Remedy is, or is planning to, use D. I've complained on occasion about
some of the directions a lot of the game industry has been going, but
Remedy is one developer I've always respected (Max Payne is fantastic,
I have both of them, and I remember enjoying Death Rally back in
the day - anxious to try the new one, too.) Besides, how can anything
born out of Future Crew not be awesome? :)

Maybe I overlooked this somewhere on dconf.org, but just out of
curiosity, about how many attendees did the whole conference have?
May 09 2013
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 09 May 2013 17:32:18 -0400, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:


 I don't know whether it's something still under wraps or if I just need
 to wait for Manu's presentation video, but I'd love to hear about how
 Remedy is, or is planning to, use D.


You will hear.  Was one of my favorites.

-Steve
May 09 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/9/13 5:32 PM, Nick Sabalausky wrote:

 Maybe I overlooked this somewhere on dconf.org, but just out of
 curiosity, about how many attendees did the whole conference have?


60.

Andrei
May 09 2013
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/9/13, Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:

 On Thu, 09 May 2013 10:26:46 -0400
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 On 5/9/13 10:26 AM, Andrei Alexandrescu wrote:

 With all this focus on technicalities, we forgot to discuss the
 gist of it: what did you guys think of the talk?






I liked the talk very much, although I preferred the 2007 talk where
both of you presented the talk together and allowed questions to be
asked during the presentation. Still I'm looking forward to the other
more technical presentations.

P.S. it seems the #dconf hashtag is being hijacked by another conference now:
https://twitter.com/GetApp/status/332770427296419841
May 10 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 10.05.2013 12:15, schrieb Andrej Mitrovic:

 On 5/9/13, Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:

 On Thu, 09 May 2013 10:26:46 -0400
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 On 5/9/13 10:26 AM, Andrei Alexandrescu wrote:

 With all this focus on technicalities, we forgot to discuss the
 gist of it: what did you guys think of the talk?






 I liked the talk very much, although I preferred the 2007 talk where
 both of you presented the talk together and allowed questions to be
 asked during the presentation. Still I'm looking forward to the other
 more technical presentations.

 P.S. it seems the #dconf hashtag is being hijacked by another conference now:
 https://twitter.com/GetApp/status/332770427296419841


I found that presentation the other day by accident. Quite interesting.

--
Paulo
May 10 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 9 May 2013 at 21:32:19 UTC, Nick Sabalausky wrote:

 On Thu, 09 May 2013 10:26:46 -0400
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 On 5/9/13 10:26 AM, Andrei Alexandrescu wrote:

 With all this focus on technicalities, we forgot to discuss 
 the
 gist of it: what did you guys think of the talk?


 
 That should better go in the digitalmars.D group though...
 


 Very good talk! And good production quality, too. This would be 
 a
 great thing to point people towards to introduce them to D.


First good talk. Some tweaking can be done to make it better.

One of them is the plane metaphor. I now know that Walter is a 
big fan of plane (and he knows quite a lot about that !) but the 
problem is that the point is very subjective (the plane want to 
fly).

I'm sure the plane idea can be kept, but must be presented in a 
more factual/less subjective manner.

I'll go through the talk once again if I find time to do it and 
get more details.
May 10 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, May 10, 2013 at 01:09:32PM +0200, deadalnix wrote:
[...]

 First good talk. Some tweaking can be done to make it better.
 
 One of them is the plane metaphor. I now know that Walter is a big
 fan of plane (and he knows quite a lot about that !) but the problem
 is that the point is very subjective (the plane want to fly).
 
 I'm sure the plane idea can be kept, but must be presented in a more
 factual/less subjective manner.


But the thing is, what constitutes "good code" *is* a subjective matter.
How do you define "good code"? Mathematically speaking, anything that
maps input into output correctly is equivalent, so a beautifully-written
piece-of-art code is no better, by this definition, than an IOCCC entry
that does exactly the same thing. But we'd never regard an IOCCC entry
as "beautiful code" by any stretch of the term (even if you were the
author -- I was, once, and it's exactly how Walter describes it: yes it
works, yes there were quite a few ingenious hacks in it, and yes it got
me the dubious honor of my code being featured on ioccc.org, but
afterwards I really just wanted to hide it away somewhere, sweep it
under the rug, etc.).

It's even more subjective when it comes to language design.
Mathematically speaking, the most beautiful language is the most concise
and expressive (and hence the most powerful). By that standard, we
should be programming with Lambda calculus -- after all, every
computation can be expressed by Lambda calculus, so why clutter the
language with redundant constructs? But clearly that's not what we're
doing here. The thing is, we're trying to map our human mental concepts
onto programming space in the nicest possible ways (rather than taking a
purely objective, mathematical approach, i.e., Lambda calculus or Turing
machines), and mental concepts, by definition, are subjective.


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you
wish you hadn't.
May 10 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/10/2013 4:09 AM, deadalnix wrote:

 One of them is the plane metaphor. I now know that Walter is a big fan of plane
 (and he knows quite a lot about that !) but the problem is that the point is
 very subjective (the plane want to fly).


It's not that subjective. An airplane that "wants to fly" is well known among 
airplane designers and pilots. All you have to do is point it down the runway 
and open the throttle. It will take off and fly straight and level without any 
hands on the controls. An airplane can also endure grevious damage, and still
fly.

A helicopter, on the other hand, wants to crash. It requires constant active 
efforts to keep it in the air, and if much of anything goes wrong, it will
crash 
and kill you.

Have you ever driven a high performance car that "wants to go"? I have. The car 
clearly isn't happy being driven slowly and gently. It's only happy when your 
right foot is mashed all the way down :-)
May 10 2013
prev sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"deadalnix" <deadalnix gmail.com> wrote in message 
news:mtmtakrebylsdehnrgvx forum.dlang.org...

 First good talk. Some tweaking can be done to make it better.

 One of them is the plane metaphor. I now know that Walter is a big fan of 
 plane (and he knows quite a lot about that !) but the problem is that the 
 point is very subjective (the plane want to fly).

 I'm sure the plane idea can be kept, but must be presented in a more 
 factual/less subjective manner.


Forget planes, this code quite obviously wants to fly! 
http://www.ioccc.org/1998/banks.c
May 10 2013
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
May 10 2013
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
10-May-2013 01:32, Nick Sabalausky пишет:

 On Thu, 09 May 2013 10:26:46 -0400
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 On 5/9/13 10:26 AM, Andrei Alexandrescu wrote:

 With all this focus on technicalities, we forgot to discuss the
 gist of it: what did you guys think of the talk?


 That should better go in the digitalmars.D group though...


 Very good talk! And good production quality, too. This would be a
 great thing to point people towards to introduce them to D.


Indeed and I can actually hear questions :)
BTW these were quite interesting in their own right like "if there is a 
way to cleanly manipulate carry bit within the language".


 And Walter does a good job on stage. *Never* comes across as
 pretentious, or cocky or full-of-...various things...like *cough*a
 certain former Apple leader*cough* always did. (Minor nit: Forgot to
 mention Mono-D on the last question, though.)


I loved the warm informal atmosphere here, too bad I've been stuck with 
visa approval at the last moment. The idea to smuggle myself in some 
crate of rice doesn't seem half-bad now ;)


-- 
Dmitry Olshansky
May 10 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 09, 2013 at 05:32:18PM -0400, Nick Sabalausky wrote:

 On Thu, 09 May 2013 10:26:46 -0400
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 

 On 5/9/13 10:26 AM, Andrei Alexandrescu wrote:

 With all this focus on technicalities, we forgot to discuss the
 gist of it: what did you guys think of the talk?


 
 That should better go in the digitalmars.D group though...
 


 
 Very good talk! And good production quality, too. This would be a
 great thing to point people towards to introduce them to D.


+1. I listened to the talk yesterday... it was awesome! Can't wait for
the other videos to be put up.

One tiny nitpick, though. In the example about sorting lines in a file,
there was a syntax error in the code (missing '.' and the end of the
first/second line). I know, I know ... but it was distracting me from
what Walter was saying, my brain keeps going "but there's a syntax
error! Is he going to talk about the syntax error? It's a syntax
error!..." :-P


[...]

 I love the D-like line on the first slide. Kind of a strange API being
 used ;), but quintessentially D syntax. Cute :) The "100 lines of
 boilerplate" bit was great too. Made me cheer even though no one else
 was around.


[...]

Yeah, pretty much sums up how I feel about IDEs. But OTOH, the question
at the end from the professor/lecturer proves that the majority of
today's coders expect IDEs. I would vote for better education, but you
can't deny the need for IDEs to at least smooth the transition from
other languages.

In any case, I totally agree that if a language *needs* an IDE in order
to cope with the amount of required boilerplate, then something is
clearly very, very wrong at a fundamental level. I guess that's why I'm
a D fan. :)


T

-- 
Food and laptops don't mix.
May 10 2013
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 10.05.2013 16:29, schrieb H. S. Teoh:

 Yeah, pretty much sums up how I feel about IDEs. But OTOH, the question
 at the end from the professor/lecturer proves that the majority of
 today's coders expect IDEs. I would vote for better education, but you
 can't deny the need for IDEs to at least smooth the transition from
 other languages.


I grew up with IDEs, the first being Turbo Pascal 3.0 foloowed by quite 
many variations, including Smalltalk and Lisp environments.

Then I got my first contact with UNIX in 1994 with Xenix, followed by 
DG/UX. It was a shock! It felt to me as if I was still in 1970 using the 
original UNIX.



 In any case, I totally agree that if a language *needs* an IDE in order
 to cope with the amount of required boilerplate, then something is
 clearly very, very wrong at a fundamental level. I guess that's why I'm
 a D fan. :)


 T


I think the same of any language that needs any form of tooling to make 
it better. For example, C requires lint+MISRA C to give the language the 
safety I get out of the box with D, Extended Pascal, Modula-2, Ada and 
similar.

--
Paulo
May 10 2013
prev sibling parent reply "sk" <abcdefg gmail.com> writes:
 In any case, I totally agree that if a language *needs* an IDE 
 in order to cope with the amount of required boilerplate, then 
 something is clearly very, very wrong at a fundamental level.


May be this is true for expert or professional programmers. But 
for people like me who only use D occasionally an IDE is a must.

IDE mainly helps me in reducing the amount of things I need to 
memorize or remember like API, building tool names, command 
syntaxes, etc. This is very important as my main profession is 
not programming.

I think lack of IDEs will prevent many beginners from trying out 
a new language. Especially after getting spoiled with IDEs like 
netbeans, visual studio etc.

Currently using DIDE, not perfect but better than nothing. 
VisualD seems to have good reviews but I cannot install it as it 
requires admin privileges.

All the above will still be true even for a "perfect" programming 
language.
May 10 2013
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 10 May 2013 21:55:57 +0200
"sk" <abcdefg gmail.com> wrote:


 In any case, I totally agree that if a language *needs* an IDE 
 in order to cope with the amount of required boilerplate, then 
 something is clearly very, very wrong at a fundamental level.


 
 May be this is true for expert or professional programmers. But 
 for people like me who only use D occasionally an IDE is a must.
 
 IDE mainly helps me in reducing the amount of things I need to 
 memorize or remember like API, building tool names, command 
 syntaxes, etc. This is very important as my main profession is 
 not programming.
 
 I think lack of IDEs will prevent many beginners from trying out 
 a new language. Especially after getting spoiled with IDEs like 
 netbeans, visual studio etc.
 
 Currently using DIDE, not perfect but better than nothing. 
 VisualD seems to have good reviews but I cannot install it as it 
 requires admin privileges.
 
 All the above will still be true even for a "perfect" programming 
 language.


While that's all true, none of it really contradicts what was said. Ie,
that "The IDE can auto-generate boilerplate" is a very poor excuse for a
language to lack ways of minimizing the need for boilerplate in the
first place.
May 10 2013
parent "sk" <abcdefg gmail.com> writes:
Ah, makes sense, sorry for the misunderstanding.
May 10 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, May 10, 2013 at 09:55:57PM +0200, sk wrote:

In any case, I totally agree that if a language *needs* an IDE in
order to cope with the amount of required boilerplate, then
something is clearly very, very wrong at a fundamental level.


 
 May be this is true for expert or professional programmers. But for
 people like me who only use D occasionally an IDE is a must.


My point was that while an IDE is helpful (e.g. for people who aren't
professional programmers, just want to get the job done, etc.), a
language should not *depend* on an IDE to insert boilerplate. I concede
that IDEs are helpful and needed for newbies and non-professional
programmers, but the *language* itself should be usable without one.
Requiring one because otherwise the amount of required boilerplate would
be unmanagable, is a symptom that there is something wrong with the
language's design.


[...]

 I think lack of IDEs will prevent many beginners from trying out a
 new language. Especially after getting spoiled with IDEs like
 netbeans, visual studio etc.


[...]

Agreed. But my point was that the language shouldn't *depend* on an IDE
in order to be usable. If a language requires an IDE because you need to
insert 100 lines of boilerplate in every program you write, then one has
to wonder, why not make those 100 lines *implicit*? They are not
conveying anything useful about the program, because they will be
identical (or mostly identical) every single time. The fact that the
language did *not* make it implicit then begs the question of what went
wrong in its design that you have to repeatedly specify what should
already be obvious to the language/compiler.

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 why newspaper headings tend to leave out very
common words like "the", "a", "is", etc., because these words take up
space but convey little to no additional information -- you can drop
them and still get the gist of what the headlines are saying.

A good programming language is one where the code says all the important
things, and leaves out most of the unimportant or obvious things. It's
just like Walter said in the talk: the file-reading function without
scope guards was full of goto's and error-checking, stuff that pretty
much is (or should be) done everywhere. It clutters the code and
obscures the salient points. It's a headline with all the "the"'s,
"a"'s, "is"'s. In contrast, the version with scope guards can be read
sequentially -- all the peripheral if's and goto's are nicely abstracted
away, leaving only the salient points of the code: allocate a buffer,
read the data, return the data. A glance at the code immediately tells
you its key points. No distracting sidelines of error-checking, goto's,
labels, or any of that nonsense.

In contrast, consider a language like C. The *correct* way of writing C
code is something like this:

	int myfunc(struct A *a, struct B *b, struct C *c) {
		/* Boilerplate: to avoid slip-ups with uninitialized
		 * pointers, must always set them to NULL. */
		void *buf = NULL;
		struct D *d = NULL;

		/* Boilerplate: check for NULL pointers */
		if (!a || !b || !c)
			/* Boilerplate: everybody and their neighbour's
			 * dog defines their own set of macros for
			 * return values; how do you remember which one
			 * goes with which function(s)? */
			return INVALID_ARGS_ERROR;

		buf = malloc(some_size);

		/* Boilerplate: must check NULL return from malloc,
		 * every single time. */
		if (!buf)
			return MEMORY_ERROR;

		/* Boilerplate: every function call must be wrapped in
		 * an if-goto, because the function may have returned an
		 * error. */
		if (anotherfunc(a, buf) != OK)
			goto ERROR;

		/* And yes, technically, you need to do this for things
		 * like printf too! Guess how many C coders do this?
		 * That's right, nobody does. It's wrong, and leads to
		 * hilarious problems when stdout isn't pointing to what
		 * the programmer thought it was. Or not-so-hilarious,
		 * if stdout was closed and a database handle was
		 * reopened and reused stdout's file descriptor
		 * number...
		 */
		if (printf("Hello, world!\n") != 0)
			goto ERROR;

		/* More boilerplate */
		if ((d = create_instance_of_d()) == NULL)
			goto ERROR;

		/* Now our boilerplate needs to use a different goto
		 * label, 'cos now we have to cleanup d, whereas we
		 * didn't need to before! Can you imagine the hilarity
		 * after 20 people change this code later on in the
		 * project's life, and one of them forgets the fact that
		 * after this point a different goto label is needed? */
		if (yetanotherfunc(b, d) != OK)
			goto ERROR2;

		if (yesmoreboilerplate(c, buf) != OK)
			goto ERROR2;

		/* Finally, success! */

		/* Um... not just yet, need more boilerplate: cleanup
		 * after ourselves */
		free(d);
		free(buf);

		/* Sigh... about time we got done */
		return OK;

		/* Caveat: the order of labels must be the *reverse* of
		 * the order they appear in the code, to ensure things
		 * are destroyed in the right order. Don't laugh -- I've
		 * seen "enterprise" code that gets this wrong. */
	ERROR2:
		/* Problem: by this point in the code, do you remember
		 * that d was supposed to be freed? */
		free(d);
	ERROR:
		/* Or buf? */
		free(buf);

		/* Problem: what if the caller forgets to check our
		 * return code? Or checks it against the wrong set of
		 * error macros? */
		return ERROR_CODE;

		/* Hope and pray the program won't crash when it gets
		 * back to the caller who forgets to check for error
		 * codes and just barges ahead blindly. */
	}

Note how much boilerplate is necessary to make the code work
*correctly*. (Yes I know you can merge the error and non-error returns
by checking for NULL in *buf and *d, thereby getting rid of the
duplicated calls to free(), but that doesn't get rid of the problem,
just dresses it differently.) The most obvious way to write this code
leaks memory and doesn't handle errors.  In fact, the above code
actually isn't good enough: printf sets errno, and to *really* get the
code right, you should be checking and possibly propagating, the value
of errno after the printf call fails.  Yes, more boilerplate. Lots more.
Every single time you call a system function.

This is one of the things I can't stand about C. Seriously, C coders
should use an IDE to get basic things like this right, even if most of
them are too macho to admit it.

This is what I mean when the language is basically unusable without an
IDE. Yes, IDEs can help adoption of a language, and I don't dispute
that, but when code in that language cannot be written correctly without
an IDE (or at least, not easily), then something is horribly, horribly
wrong with that language.

(The D version of the above function, by contrast, is vastly more
readable and maintainable on almost every count, and requires no IDE to
get it right.)


T

-- 
"640K ought to be enough" -- Bill G., 1984. "The Internet is not a primary goal
for PC usage" -- Bill G., 1995. "Linux has no impact on Microsoft's strategy"
-- Bill G., 1999.
May 10 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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. While D doesn't make 
it more testable, at least it makes it simple, and hence more likely to be
correct.
May 10 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
May 10 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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!
May 10 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
May 10 2013
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.1184.1368231351.4724.digitalmars-d puremagic.com...

 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?


We already are!  Check out pull requests tagged with [DDMD].
May 10 2013
prev sibling next sibling parent reply "Flamaros" <flamaros.xavier gmail.com> writes:
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.
May 10 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
May 10 2013
next sibling parent reply "Flamaros" <flamaros.xavier gmail.com> writes:
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.
May 10 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, May 11, 2013 at 04:52:31AM +0200, Flamaros wrote:
[...]

 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.


One advantage Java has is widespread adoption and corporate support,
which made it possible to have an extensive standard library (and many
more 3rd party libraries) that can pretty much do anything you want --
you just have to put the pieces together. So in that sense you can get
the job done "faster", because you don't have to keep reinventing the
wheel. D isn't quite there yet, though that should get better once more
people adopt D.

In terms of expressive power within the language itself, though, I think
D is far better.



 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.


Right, and D is still in development, which makes certain PTBs nervous
about adoption, even if it is actually already production-ready for most
common tasks. But that can only improve as we continue refining the
language.



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


Yes, which is why I love D so much. All I need is a text editor and the
compiler, and I can do everything. Even unittesting and coverage are all
integrated. No need for external tools, no need to install a whole bunch
of support software, all the essentials are bundled with the compiler.
How much more compelling can it get?


T

-- 
"640K ought to be enough" -- Bill G., 1984.
"The Internet is not a primary goal for PC usage" -- Bill G., 1995.
"Linux has no impact on Microsoft's strategy" -- Bill G., 1999.
May 10 2013
next sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 05/11/2013 12:45 AM, H. S. Teoh wrote:

 Yes, which is why I love D so much. All I need is a text editor and the
 compiler, and I can do everything. Even unittesting and coverage are all
 integrated. No need for external tools, no need to install a whole bunch
 of support software, all the essentials are bundled with the compiler.
 How much more compelling can it get?


I can get by with a hammer and nails too, but if I was a professional 
roofer I'd be an idiot not to use a nail gun. That's the problem with 
all this focus on boilerplate. An IDE does so much more to make you 
productive in any language, especially one that has static types.
May 11 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/11/2013 1:07 PM, Jeff Nowakowski wrote:

 I can get by with a hammer and nails too, but if I was a professional roofer
I'd
 be an idiot not to use a nail gun. That's the problem with all this focus on
 boilerplate. An IDE does so much more to make you productive in any language,
 especially one that has static types.


I didn't say an IDE was bad for D, I only said that if you need an IDE to 
generate boilerplate for you, then there's something wrong with the language.

IDE's have lots of other valuable uses.
May 11 2013
next sibling parent reply "Diggory" <diggsey googlemail.com> writes:
 I didn't say an IDE was bad for D, I only said that if you need 
 an IDE to generate boilerplate for you, then there's something 
 wrong with the language.

 IDE's have lots of other valuable uses.


There is one case of generating boilerplate code which can hardly 
be avoided and would at least partially solve a problem that 
keeps coming up in one form or another:

For every new language feature that uses some form of attributes 
(ie. almost all of them) there is the problem of how 
automatically the attributes are applied, generally with these 
possibilities:

- The attribute is a purely internal concept used and deduced by 
the compiler. This has the problem that unless these attributes 
are in some way stored in the .di file the compiler has now way 
to determine them when it cannot see the code. It also leaks 
implementation details into the interface.

- The attribute is explicitly defined but inferred in some cases 
by the compiler.
This has the problem that it's now not obvious whether the 
attribute can be inferred or not, there are more rules to know 
about when automatic deduction is done, and there will still be 
many cases where the attributes cannot be safely inferred without 
leaking implementation detail, but the programmer forgets to add 
them.

- The attribute is explicitly defined but is inferred when "auto" 
is present.
This has the problem that there's no good way to finely tune 
which attributes "auto" should infer, and no way to un-set 
attributes. When "auto" is used on methods for use by external 
code it is again leaking implementation detail.

None of these are very satisfactory. A good solution should make 
it clear to the programmer which attributes are applied, make it 
easy to apply all the attributes which can be inferred but also 
easy to then change them, and not change when the implementation 
changes.

An IDE command which automatically infers all the attributes 
would seem to be the only way to solve this well. Unfortunately 
it doesn't exist yet... Anyway it would be worthwhile deciding on 
a consistent way to handle attributes as the number of them 
increase, and it would be worth making sure that whatever way is 
chosen is compatible with such a potential IDE feature.

Another option would be to add an attribute called "default" or 
something like that, and have the compiler issue a message if it 
finds a function with no attributes that tells the programmer 
what attributes the function COULD have so it's a reminder to 
either add them, or put "default" after it.
May 11 2013
parent "Dicebot" <m.strashun gmail.com> writes:
On Saturday, 11 May 2013 at 22:11:25 UTC, Diggory wrote:

 ...




That provokes another argument about attribute inference, 
off-topic one :) Must resist!
May 12 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 11 May 2013 at 21:06:28 UTC, Walter Bright wrote:

 On 5/11/2013 1:07 PM, Jeff Nowakowski wrote:

 I can get by with a hammer and nails too, but if I was a 
 professional roofer I'd
 be an idiot not to use a nail gun. That's the problem with all 
 this focus on
 boilerplate. An IDE does so much more to make you productive 
 in any language,
 especially one that has static types.


 I didn't say an IDE was bad for D, I only said that if you need 
 an IDE to generate boilerplate for you, then there's something 
 wrong with the language.


I keep repeating myself, but this is true, unless the boilerplate 
is here for the very reason of IDE integration.

Stupid inexpressive language are easier to write tools for, this 
is the very reason why java have such a great tooling.


 IDE's have lots of other valuable uses.
May 11 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/11/2013 10:57 PM, deadalnix wrote:

 Stupid inexpressive language are easier to write tools for, this is the very
 reason why java have such a great tooling.


You run the risk of having a write-only language if the expressivity is in the 
tools rather than the language.
May 12 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 12 May 2013 at 08:40:11 UTC, Walter Bright wrote:

 On 5/11/2013 10:57 PM, deadalnix wrote:

 Stupid inexpressive language are easier to write tools for, 
 this is the very
 reason why java have such a great tooling.


 You run the risk of having a write-only language if the 
 expressivity is in the tools rather than the language.


Tools don't have to show you what is in the text file. That is 
the beauty of it. IntelliJ for instance, don't show java source 
code as it is in the source.
May 12 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/12/2013 1:42 AM, deadalnix wrote:

 On Sunday, 12 May 2013 at 08:40:11 UTC, Walter Bright wrote:

 On 5/11/2013 10:57 PM, deadalnix wrote:

 Stupid inexpressive language are easier to write tools for, this is the very
 reason why java have such a great tooling.


 You run the risk of having a write-only language if the expressivity is in the
 tools rather than the language.


 Tools don't have to show you what is in the text file. That is the beauty of
it.
 IntelliJ for instance, don't show java source code as it is in the source.


I.e. you've invented another language that has Java as its output so the user 
never sees Java because Java is not presentable to users.
May 12 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 12 May 2013 at 08:53:59 UTC, Walter Bright wrote:

 On 5/12/2013 1:42 AM, deadalnix wrote:

 On Sunday, 12 May 2013 at 08:40:11 UTC, Walter Bright wrote:

 On 5/11/2013 10:57 PM, deadalnix wrote:

 Stupid inexpressive language are easier to write tools for, 
 this is the very
 reason why java have such a great tooling.


 You run the risk of having a write-only language if the 
 expressivity is in the
 tools rather than the language.


 Tools don't have to show you what is in the text file. That is 
 the beauty of it.
 IntelliJ for instance, don't show java source code as it is in 
 the source.


 I.e. you've invented another language that has Java as its 
 output so the user never sees Java because Java is not 
 presentable to users.


What is presented to the user isn't a text format anymore.
May 12 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/12/13 5:32 AM, deadalnix wrote:

 On Sunday, 12 May 2013 at 08:53:59 UTC, Walter Bright wrote:

 On 5/12/2013 1:42 AM, deadalnix wrote:

 On Sunday, 12 May 2013 at 08:40:11 UTC, Walter Bright wrote:

 On 5/11/2013 10:57 PM, deadalnix wrote:

 Stupid inexpressive language are easier to write tools for, this is
 the very
 reason why java have such a great tooling.


 You run the risk of having a write-only language if the expressivity
 is in the
 tools rather than the language.


 Tools don't have to show you what is in the text file. That is the
 beauty of it.
 IntelliJ for instance, don't show java source code as it is in the
 source.


 I.e. you've invented another language that has Java as its output so
 the user never sees Java because Java is not presentable to users.


 What is presented to the user isn't a text format anymore.


Looks like text to me. http://www.jetbrains.com/idea/. Did I look at the 
wrong product?

Andrei
May 12 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 12 May 2013 at 13:04:31 UTC, Andrei Alexandrescu wrote:

 Looks like text to me. http://www.jetbrains.com/idea/. Did I 
 look at the wrong product?


Yes, it is text based, but you can do many manipulation you can't 
do with a regular text presentation.

This is text++
May 12 2013
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 12 May 2013 14:14, deadalnix <deadalnix gmail.com> wrote:


 On Sunday, 12 May 2013 at 13:04:31 UTC, Andrei Alexandrescu wrote:


 Looks like text to me. http://www.jetbrains.com/idea/**. Did I look at
 the wrong product?


 Yes, it is text based, but you can do many manipulation you can't do with
 a regular text presentation.

 This is text++


Looks like *shivers* ASP....

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
May 12 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/12/2013 2:32 AM, deadalnix wrote:

 On Sunday, 12 May 2013 at 08:53:59 UTC, Walter Bright wrote:

 On 5/12/2013 1:42 AM, deadalnix wrote:

 On Sunday, 12 May 2013 at 08:40:11 UTC, Walter Bright wrote:

 On 5/11/2013 10:57 PM, deadalnix wrote:

 Stupid inexpressive language are easier to write tools for, this is the very
 reason why java have such a great tooling.


 You run the risk of having a write-only language if the expressivity is in the
 tools rather than the language.


 Tools don't have to show you what is in the text file. That is the beauty of
it.
 IntelliJ for instance, don't show java source code as it is in the source.


 I.e. you've invented another language that has Java as its output so the user
 never sees Java because Java is not presentable to users.


 What is presented to the user isn't a text format anymore.


I think that is irrelevant to my point. A language doesn't have to be text
based.
May 12 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 12 May 2013 at 18:09:59 UTC, Walter Bright wrote:

 I think that is irrelevant to my point. A language doesn't have 
 to be text based.


Textual format have proven theur usefullness again and again. 
Programming languages, json, xml, even dark stuff like LLVM IR 
have a textual representation. This is easier to debug.

In that regard, if you consider IntelliJ, java has become a 
textual representation. It is important as the compiler would be 
much harder to create otherwize.
May 12 2013
parent "Diggory" <diggsey googlemail.com> writes:
On Sunday, 12 May 2013 at 18:42:22 UTC, deadalnix wrote:

 On Sunday, 12 May 2013 at 18:09:59 UTC, Walter Bright wrote:

 I think that is irrelevant to my point. A language doesn't 
 have to be text based.


 Textual format have proven theur usefullness again and again. 
 Programming languages, json, xml, even dark stuff like LLVM IR 
 have a textual representation. This is easier to debug.

 In that regard, if you consider IntelliJ, java has become a 
 textual representation. It is important as the compiler would 
 be much harder to create otherwize.


Languages have been stored textually yes, and that is clearly 
beneficial, but editing code even in fairly basic editors is far 
beyond simple text editing.

Automatic indentation, symbol selection, symbol renaming, symbol 
navigation, code folding, auto-completion, quick info, 
intellisense, syntax highlighting, etc. mean that editing code is 
far closer to editing a complex tree-like data structure than 
editing text, even displaying it is not the same, and that's how 
it should be for maximum productivity. Conceptually we think 
about code in a way much closer to an AST than a bunch of lines 
of text.

Joke or not, I would amend "real programmers use notepad" to 
"real programmers *should be able* to use notepad".
May 12 2013
prev sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 05/11/2013 05:06 PM, Walter Bright wrote:

 I didn't say an IDE was bad for D, I only said that if you need an IDE
 to generate boilerplate for you, then there's something wrong with the
 language.

 IDE's have lots of other valuable uses.


Two points. One, the person I responded to (and quoted in my reply) 
said, "Yes, which is why I love D so much. All I need is a text editor 
and the compiler, and I can do everything."

Second, in the Q&A session of your talk, you said, "I'm sorely tempted 
to say that real men don't use IDEs..." The fixation on boilerplate as 
to why people "need" IDEs is just a symptom of the more general sentiment.
May 12 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/12/2013 9:42 AM, Jeff Nowakowski wrote:

 Second, in the Q&A session of your talk, you said, "I'm sorely tempted to say
 that real men don't use IDEs..."


Yes, but I said that as a joke.



 The fixation on boilerplate as to why people
 "need" IDEs is just a symptom of the more general sentiment.


No, the sentiment was that an IDE was not the solution to a language's
deficiencies.
May 12 2013
next sibling parent Jeff Nowakowski <jeff dilacero.org> writes:
On 05/12/2013 02:08 PM, Walter Bright wrote:

 On 5/12/2013 9:42 AM, Jeff Nowakowski wrote:

 Second, in the Q&A session of your talk, you said, "I'm sorely tempted
 to say
 that real men don't use IDEs..."


 Yes, but I said that as a joke.


It was said jokingly, but I have very little doubt it conveyed your true 
feelings. You have a history of brushing off concerns about IDEs by 
relying on a remark from David B. Held that Java needs an IDE to 
generate boilerplate, which I will say to the contrary is one of the 
lower priority reasons of why I find IDEs so useful for Java.

Do you use an IDE? Have you even tried one in the past 10 years?


 No, the sentiment was that an IDE was not the solution to a language's
 deficiencies.


That's fine, but when somebody asks you about D support for IDEs, 
"joking" about "real men" not needing one doesn't inspire confidence you 
actually understand the value. Maybe in your next keynote you can talk 
about how D has first-class support for IDEs, much like you did for unit 
tests.

One way to get first-class support is to make the compiler amenable to 
being used as a library, something that's been suggested before. I'd be 
happy to be told I'm out of date, and this support is already in the 
works or at least on the radar.
May 12 2013
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 12 May 2013 19:08, Walter Bright <newshound2 digitalmars.com> wrote:


 On 5/12/2013 9:42 AM, Jeff Nowakowski wrote:


 Second, in the Q&A session of your talk, you said, "I'm sorely tempted to
 say
 that real men don't use IDEs..."


 Yes, but I said that as a joke.


As we all know that real men use vim.   :o)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
May 13 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 10 May 2013 21:45:06 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:

 
 Yes, which is why I love D so much. All I need is a text editor and
 the compiler, and I can do everything. Even unittesting and coverage
 are all integrated. No need for external tools, no need to install a
 whole bunch of support software, all the essentials are bundled with
 the compiler. How much more compelling can it get?
 


The nicest thing of all, IMO, about not strictly needing all that
support software is that basic things like
editing/navigating/opening/closing code is always and forever 100%
unobstructed by things like startup delays and keyboard input lag which
have no business existing on the rocket-engined supercomputers we now
call "a PC".
May 11 2013
parent reply "Juan Manuel Cabo" <juanmanuel.cabo gmail.com> writes:
On Sunday, 12 May 2013 at 03:58:04 UTC, Nick Sabalausky wrote:

 The nicest thing of all, IMO, about not strictly needing all 
 that
 support software is that basic things like
 editing/navigating/opening/closing code is always and forever 
 100%
 unobstructed by things like startup delays and keyboard input 
 lag which
 have no business existing on the rocket-engined supercomputers 
 we now
 call "a PC".


I'm using a little known IDE for D known as Poseidon:
     http://www.dsource.org/projects/poseidon/wiki/Screenshots
it is very fast, loads very quickly, and the editor is very 
responsive. The keyword autocompletion is mostly broken in D2 but 
I can live without it. It is a bit sad that it has gone 
unmantained for more than a year.

These are the things that I cannot live without for my big D2 
project:
     - Syntax highlighting.
     - Tree like structure for navigating all the many source 
files of my project.
     - Search in multiple files.
     - Debugging (breakpoints, step by step, go to line that 
crashed). It suprisingly still works in Poseidon.
     - Can go to file/line when double-clicking on compiler error.
     - Compile/run/debug just by hitting SHIFT-F5, and other keys.
     - No need for a makefile. It feeds all source files 
(hundreds) and libraries to dmd.

For smaller D projects I use Vim/makefiles though.

Again, I'm a bit sad that it has gone unmantained for so long, 
but it's totally usable still. This is the faster IDE that I've 
found.

--jm
May 12 2013
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 12 May 2013 18:35:25 +0200
"Juan Manuel Cabo" <juanmanuel.cabo gmail.com> wrote:


 On Sunday, 12 May 2013 at 03:58:04 UTC, Nick Sabalausky wrote:

 The nicest thing of all, IMO, about not strictly needing all 
 that
 support software is that basic things like
 editing/navigating/opening/closing code is always and forever 
 100%
 unobstructed by things like startup delays and keyboard input 
 lag which
 have no business existing on the rocket-engined supercomputers 
 we now
 call "a PC".


 
 I'm using a little known IDE for D known as Poseidon:
      http://www.dsource.org/projects/poseidon/wiki/Screenshots
 it is very fast, loads very quickly, and the editor is very 
 responsive. The keyword autocompletion is mostly broken in D2 but 
 I can live without it. It is a bit sad that it has gone 
 unmantained for more than a year.
 


Looks interesting. Now that you mention it, I do seem to recall hearing
about it back then. Personally, I've been a huge fan of Programmer's

is that it's Windows-only. I want to switch to Linux for my primary
system, but the lack of PN2 is one of the roadblocks (there are other
roadblocks, though).


 These are the things that I cannot live without for my big D2 
 project:
      - Syntax highlighting.
      - Search in multiple files.
      - Can go to file/line when double-clicking on compiler error.
      - Compile/run/debug just by hitting SHIFT-F5, and other keys.


Yea, PN2 has all of that. Essential stuff IMO too.


      - Tree like structure for navigating all the many source 
 files of my project.


PN2 has that for files, although it looks like Poseidon goes another
step further and puts funcs/classes/etc into the tree, too. I heavily
use PN2's FF-like QuickFind for that sort of thing. Obviously not as
good, but it gets me where I'm going ;)


      - Debugging (breakpoints, step by step, go to line that 
 crashed). It suprisingly still works in Poseidon.


Yea, that's something PN2 doesn't have. (Un)Luckily for me, I've spent
a lot of time in the past on things where I didn't have a debugger
available (one time my only debugging aid was a single LED! Royal
PITA!), so I've gotten so accustomed to printf debugging that I find I
usually prefer it.

Debuggers are great, I'd never deny that, but one thing I love about
printf-style is you can trivially go back-and-forth in time just by
scrolling. Debuggers only give you one time-slice at a time, and can
usually only progress forwards.

Of course, printf-style debugging really needs a language that compiles
fast. Fine for D, but it's no so fun with C/C++.


      - No need for a makefile. It feeds all source files 
 (hundreds) and libraries to dmd.
 


I used to swear by Visual Studio (until it got bloated, somewhere
around one of the earlier .NET versions) and I loved the whole
approach of "no makefiles, just feed all the project files to the
compiler".

But these days I prefer RDMD-style approaches ("pass the one main
source file to a cmdline tool and it figures out the rest") because
they're trivially scriptable and don't cause a specific editor (or any
editor at all) to become a build requirement. I find that especially
important for OSS and cross-platform projects.

Ever dealt with automated building of a multi-part project that
included building a Visual Studio project or (worse) a Flash project as
just one part of the overall process? Blech. It's awful.



 For smaller D projects I use Vim/makefiles though.
 
 Again, I'm a bit sad that it has gone unmantained for so long, 
 but it's totally usable still. This is the faster IDE that I've 
 found.
 
 --jm
May 12 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-12 21:31, Nick Sabalausky wrote:


 Looks interesting. Now that you mention it, I do seem to recall hearing
 about it back then. Personally, I've been a huge fan of Programmer's

 is that it's Windows-only. I want to switch to Linux for my primary
 system, but the lack of PN2 is one of the roadblocks (there are other
 roadblocks, though).


Take a look at Sublime Text. It's ridicules fast and cross platform. The 
only problem is that it's not free. You can download it for free and 
dismiss a dialog popping up once in a while.

http://www.sublimetext.com/


 But these days I prefer RDMD-style approaches ("pass the one main
 source file to a cmdline tool and it figures out the rest") because
 they're trivially scriptable and don't cause a specific editor (or any
 editor at all) to become a build requirement. I find that especially
 important for OSS and cross-platform projects.


The problem here is when you need to use a couple of compiler switches. 
You need a file to put that in, usually a shell script. Unfortunately 
that doesn't work on Windows. So you need to duplicate that file for 
Windows.

-- 
/Jacob Carlborg
May 12 2013
next sibling parent reply Dmitry S <ds.dlang gmail.com> writes:
I know some folks who use Sublime Text and love it.

On Mon, May 13, 2013 at 2:52 AM, Jacob Carlborg <doob me.com> wrote:


 On 2013-05-12 21:31, Nick Sabalausky wrote:

  Looks interesting. Now that you mention it, I do seem to recall hearing

 about it back then. Personally, I've been a huge fan of Programmer's

 is that it's Windows-only. I want to switch to Linux for my primary
 system, but the lack of PN2 is one of the roadblocks (there are other
 roadblocks, though).


 Take a look at Sublime Text. It's ridicules fast and cross platform. The
 only problem is that it's not free. You can download it for free and
 dismiss a dialog popping up once in a while.

 http://www.sublimetext.com/


  But these days I prefer RDMD-style approaches ("pass the one main

 source file to a cmdline tool and it figures out the rest") because
 they're trivially scriptable and don't cause a specific editor (or any
 editor at all) to become a build requirement. I find that especially
 important for OSS and cross-platform projects.


 The problem here is when you need to use a couple of compiler switches.
 You need a file to put that in, usually a shell script. Unfortunately that
 doesn't work on Windows. So you need to duplicate that file for Windows.

 --
 /Jacob Carlborg
May 13 2013
parent Matt Soucy <msoucy csh.rit.edu> writes:
On 05/13/2013 10:19 AM, Dmitry S wrote:

 I know some folks who use Sublime Text and love it.
=20
 On Mon, May 13, 2013 at 2:52 AM, Jacob Carlborg <doob me.com> wrote:
=20

 On 2013-05-12 21:31, Nick Sabalausky wrote:

  Looks interesting. Now that you mention it, I do seem to recall heari=




ng

 about it back then. Personally, I've been a huge fan of Programmer's








 is that it's Windows-only. I want to switch to Linux for my primary
 system, but the lack of PN2 is one of the roadblocks (there are other=







 roadblocks, though).


 Take a look at Sublime Text. It's ridicules fast and cross platform. T=




he

 only problem is that it's not free. You can download it for free and
 dismiss a dialog popping up once in a while.

 http://www.sublimetext.com/


  But these days I prefer RDMD-style approaches ("pass the one main

 source file to a cmdline tool and it figures out the rest") because
 they're trivially scriptable and don't cause a specific editor (or an=






y

 editor at all) to become a build requirement. I find that especially
 important for OSS and cross-platform projects.


 The problem here is when you need to use a couple of compiler switches=




=2E

 You need a file to put that in, usually a shell script. Unfortunately =




that

 doesn't work on Windows. So you need to duplicate that file for Window=




s.

 --
 /Jacob Carlborg


=20


It's really nice, even with the nagware, which isn't even that bad. It
only pops up something like every 50 times you save. Even better, it has
built in support for Makefiles within a project, and it's fairly
straightforward to work with other build systems. (I have a simple DUB
one working)
May 13 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 13 May 2013 08:52:47 +0200
Jacob Carlborg <doob me.com> wrote:


 On 2013-05-12 21:31, Nick Sabalausky wrote:
 

 Looks interesting. Now that you mention it, I do seem to recall
 hearing about it back then. Personally, I've been a huge fan of

 about it though is that it's Windows-only. I want to switch to
 Linux for my primary system, but the lack of PN2 is one of the
 roadblocks (there are other roadblocks, though).


 
 Take a look at Sublime Text. It's ridicules fast and cross platform.
 The only problem is that it's not free. You can download it for free
 and dismiss a dialog popping up once in a while.
 
 http://www.sublimetext.com/
 


Hmm, yea I've looked at that before. There's some nice things about it,
but honestly, I can't stand non-native UIs (both looks and behavior).
Plus the settings don't seem to work (tried changing one, saved,
restarted, and it had no effect), and the text seems a little blurry,
and I'm kind of uneasy about relying on closed-source for something I
rely on as much as a text editor. Don't like being completely at some
company's mercy for any changes/fixes I may need.



 But these days I prefer RDMD-style approaches ("pass the one main
 source file to a cmdline tool and it figures out the rest") because
 they're trivially scriptable and don't cause a specific editor (or
 any editor at all) to become a build requirement. I find that
 especially important for OSS and cross-platform projects.


 
 The problem here is when you need to use a couple of compiler
 switches.


That's not a true problem at all. Nobody ever said RDMD, or anything
else like it, can't be invoked from another tool to provide whatever
additional functionality is needed. In fact, such things already
exist. But try adding on functionality using IDE-based build tools
as a building block - *and* then make it work for anyone who uses a
different editor.


 You need a file to put that in, usually a shell script.
 Unfortunately that doesn't work on Windows. So you need to duplicate
 that file for Windows.
 


If all you're doing is passing a few switches to a DMD/RDMD call,
then having both BAT and shell is absolutely trivial. I do it all the
time myself:

1. Replace the shebang line with  echo off
2. Replace "$ " with %*
3. If you invoke anything in the current dir, remove the prefixed ./
(or change it to .\)

Done. If you need anything fancier than that (like handling steps that
fail, or really any actual logic at all), then shell scripting is
probably not the best idea anyway - even if you don't care about
Windows at all. Just use a shell one-liner to invoke the real script.

*Or* you can just use (or create) any other compiler-invoking, or
RDMD-invoking, tool that provides whatever functionality your project
happens to need.

IDE-driven building is great...*if* it happens to already provide
everything you need (otherwise you might be pretty much screwed - and
yes, I've run into such problems before) *AND* you happen to be working
in isolation with nobody else ever needing to build your code.
May 13 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-13 23:52, Nick Sabalausky wrote:


 Hmm, yea I've looked at that before. There's some nice things about it,
 but honestly, I can't stand non-native UIs (both looks and behavior).
 Plus the settings don't seem to work (tried changing one, saved,
 restarted, and it had no effect), and the text seems a little blurry,
 and I'm kind of uneasy about relying on closed-source for something I
 rely on as much as a text editor. Don't like being completely at some
 company's mercy for any changes/fixes I may need.


There are two kind of settings. System wide settings and user settings. 
I don't know if that had something to do with it. Don't know about the 
text, it looks good on Mac OS X.


 That's not a true problem at all. Nobody ever said RDMD, or anything
 else like it, can't be invoked from another tool to provide whatever
 additional functionality is needed. In fact, such things already
 exist. But try adding on functionality using IDE-based build tools
 as a building block - *and* then make it work for anyone who uses a
 different editor.


If I would use an IDE I would prefer it to invoke a build tool/rdmd, 
just because of this. I don't want to lock someone in, to force them use 
a specific editor/IDE.


 If all you're doing is passing a few switches to a DMD/RDMD call,
 then having both BAT and shell is absolutely trivial. I do it all the
 time myself:

 1. Replace the shebang line with  echo off
 2. Replace "$ " with %*
 3. If you invoke anything in the current dir, remove the prefixed ./
 (or change it to .\)


But there's still two files that needs to be maintained. Then you need 
some linker switches, which are system specific. I'm not that 
comfortable with the linker on Windows so I'm not sure I always get the 
flags correctly. That's why I really would like to have a build tool 
that handles this. It should have a system independent way of specifying 
common flags, like which libraries to link with.

-- 
/Jacob Carlborg
May 13 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 14 May 2013 08:46:29 +0200
Jacob Carlborg <doob me.com> wrote:


 On 2013-05-13 23:52, Nick Sabalausky wrote:
 

 Hmm, yea I've looked at that before. There's some nice things about
 it, but honestly, I can't stand non-native UIs (both looks and
 behavior). Plus the settings don't seem to work (tried changing
 one, saved, restarted, and it had no effect), and the text seems a
 little blurry, and I'm kind of uneasy about relying on
 closed-source for something I rely on as much as a text editor.
 Don't like being completely at some company's mercy for any
 changes/fixes I may need.


 
 There are two kind of settings. System wide settings and user
 settings. I don't know if that had something to do with it.


Hmm, yea, I don't know. I first opened the user settings, saw
it was nothing more than a blank configuration file (aside from an empty
JSON object) and didn't deal with it further. Then I went to the
"default" settings, changed "remember_open_files" from true to false,
saved, exited, checked task manager to make sure it wasn't still
running, started it again, and it auto-opened the default settings file.

I did grab the "portable install" version of it, maybe it's just broken
in that? Or maybe it's just that one setting that doesn't work. I
don't know, I haven't investigated further.


 Don't
 know about the text, it looks good on Mac OS X.
 


It's possible that one could have just been my imagination, maybe
because of its default color scheme being lower-contrast than I'm used
to, or because it's bold and I'm used to non-bold. I dunno. OTOH, I
have noticed Apple seems to like heavy anti-aliasing (or at least
heavier than I like), so maybe you're just used to it ;)



 If all you're doing is passing a few switches to a DMD/RDMD call,
 then having both BAT and shell is absolutely trivial. I do it all
 the time myself:

 1. Replace the shebang line with  echo off
 2. Replace "$ " with %*
 3. If you invoke anything in the current dir, remove the prefixed ./
 (or change it to .\)


 
 But there's still two files that needs to be maintained.


True, but they're very small, few in number, and updated in lockstep.
So it's entirely feasable and nowhere near as painful as, say, C/C++
headers.

But that said, yea, I'd also certainly prefer only having one file to
update.


 Then you
 need some linker switches, which are system specific. I'm not that 
 comfortable with the linker on Windows so I'm not sure I always get
 the flags correctly. That's why I really would like to have a build
 tool that handles this. It should have a system independent way of
 specifying common flags, like which libraries to link with.
 


Yea, I agree. (Although that's orthogonal to "IDE-based building" vs
"CLI-based building": In either case, having to specify
linker-specific switches manually is bad, and having it nicely
abstracted (when possible) is good.)
May 14 2013
prev sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Monday, 13 May 2013 at 21:52:28 UTC, Nick Sabalausky wrote:

 On Mon, 13 May 2013 08:52:47 +0200
 Jacob Carlborg <doob me.com> wrote:

 
 Take a look at Sublime Text. It's ridicules fast and cross 
 platform.
 The only problem is that it's not free. You can download it 
 for free
 and dismiss a dialog popping up once in a while.
 
 http://www.sublimetext.com/
 


 Hmm, yea I've looked at that before. There's some nice things 
 about it,
 but honestly, I can't stand non-native UIs (both looks and 
 behavior).
 Plus the settings don't seem to work (tried changing one, saved,
 restarted, and it had no effect), and the text seems a little 
 blurry,
 and I'm kind of uneasy about relying on closed-source for 
 something I
 rely on as much as a text editor. Don't like being completely 
 at some
 company's mercy for any changes/fixes I may need.


Are you using a higher DPI? If so, you'd want to disable DPI 
scaling (32-bit version only, Rightclick -> Properties -> 
Compatability) and just increase the font size. Otherwise, it'll 
be rendering text at a lower resolution and appear blurry and 
ugly.
May 14 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-05-12 18:35, Juan Manuel Cabo wrote:


 I'm using a little known IDE for D known as Poseidon:
      http://www.dsource.org/projects/poseidon/wiki/Screenshots
 it is very fast, loads very quickly, and the editor is very responsive.
 The keyword autocompletion is mostly broken in D2 but I can live without
 it. It is a bit sad that it has gone unmantained for more than a year.

 These are the things that I cannot live without for my big D2 project:
      - Syntax highlighting.
      - Tree like structure for navigating all the many source files of
 my project.
      - Search in multiple files.
      - Debugging (breakpoints, step by step, go to line that crashed).
 It suprisingly still works in Poseidon.
      - Can go to file/line when double-clicking on compiler error.
      - Compile/run/debug just by hitting SHIFT-F5, and other keys.
      - No need for a makefile. It feeds all source files (hundreds) and
 libraries to dmd.


I can do that with TextMate, except the debugging.

-- 
/Jacob Carlborg
May 12 2013
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 10 May 2013 18:59:23 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:

 


[...snip Java vs D samples...]

 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


[..snip..]

 

 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. 
 


Yea. Somewhere close to 10 years ago, it was precisely the nightmarish
combination of C++ and Java that pushed me to do some language
searching which led me to (an early) D.

Learning Java taught me all the reasons to hate C++, but then Java also
went and threw away the *good* things about C/C++, too. As those
were the languages I needed to use the most, the constant "Which hell
do I want? Hell A or Hell B?" damn near soured me on programming in
general.



generics, and MS's continued disinterest in fixing them, finally drove
me to ditch it forever. D by contrast has only gotten better with age.


 I found that C++ is only tolerable when I
 use it as "C with classes".


That's always been my strategy with C++. Originally because I didn't
know any of its fancier stuff, and now because I just don't want to
deal with any of its "frills".

Funny thing: I absolutely can't stand highly dynamic languages, period,
but after re-introducing myself to C/C++ on a project last year, I'm
understanding much better why so many game devs are so big on Lua.
May 11 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
May 10 2013
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
May 10 2013
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.1188.1368237816.4724.digitalmars-d puremagic.com...

 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?


The GDC/LDC maintainers are onboard.  It is at least theoretically ok to 
have a frontend written in a language other than C/C++.

We also aren't going pure D, just the frontend.  The backend and glue layer 
will still be in C++.
May 10 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/11/13 2:49 AM, Daniel Murphy wrote:

 "H. S. Teoh"<hsteoh quickfur.ath.cx>  wrote in message
 news:mailman.1188.1368237816.4724.digitalmars-d puremagic.com...

 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?


 The GDC/LDC maintainers are onboard.


Walter and I are also on board.

Andrei
May 11 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On May 11, 2013 2:30 PM, "Andrei Alexandrescu" <
SeeWebsiteForEmail erdani.org> wrote:

 On 5/11/13 2:49 AM, Daniel Murphy wrote:

 "H. S. Teoh"<hsteoh quickfur.ath.cx>  wrote in message
 news:mailman.1188.1368237816.4724.digitalmars-d puremagic.com...

 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?


 The GDC/LDC maintainers are onboard.



 Walter and I are also on board.

 Andrei


If the flurry of activity from myself, David and Daniel isn't a clear
sign.  We are all on the same page.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
May 11 2013
parent "David Nadlinger" <see klickverbot.at> writes:
On Saturday, 11 May 2013 at 14:42:38 UTC, Iain Buclaw wrote:

 On May 11, 2013 2:30 PM, "Andrei Alexandrescu" <
 SeeWebsiteForEmail erdani.org> wrote:

 On 5/11/13 2:49 AM, Daniel Murphy wrote:

 "H. S. Teoh"<hsteoh quickfur.ath.cx>  wrote in message
 news:mailman.1188.1368237816.4724.digitalmars-d puremagic.com...

 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?


 The GDC/LDC maintainers are onboard.



 Walter and I are also on board.

 Andrei


 If the flurry of activity from myself, David and Daniel isn't a 
 clear
 sign.  We are all on the same page.


We are indeed.

As far as LDC goes, upstream issues aren't a potential source of 
trouble, as we are not an official LLVM project anyway.

GDC is likely to be more of an issue in this regard, but I'll 
leave it to Iain to judge that.

David
May 11 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 10 May 2013 at 23:29:33 UTC, H. S. Teoh wrote:

 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.


This is the very reason why the NullPointerError handler build a 
fake stack frame and hijack the EIP register in order to NOT do 
that kind of stuff into the signal handler.

This is very confusing and must be put into some runtime code and 
never used directly by users.
May 11 2013
prev sibling parent "sk" <abcdefg gmail.com> writes:
Thank you, nicely explained.
May 13 2013
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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).

- Jonathan M Davis
May 10 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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!
May 10 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 10 May 2013 19:04:31 -0400
"Jonathan M Davis" <jmdavisProg gmx.com> 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).
 


Not to mention data compression ;)
May 11 2013
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, May 11, 2013 23:59:44 Nick Sabalausky wrote:

 On Fri, 10 May 2013 19:04:31 -0400
 
 "Jonathan M Davis" <jmdavisProg gmx.com> 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).


 
 Not to mention data compression ;)


LOL. Yes. That's pretty much what you have to look at in data compression by 
definition - that and finding ways to make more of the data which is different 
the same without losing too much information or quality (at least with lossy 
compression).

- Jonathan M Davis
May 11 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 05/12/2013 05:59 AM, Nick Sabalausky wrote:

 On Fri, 10 May 2013 19:04:31 -0400
 "Jonathan M Davis" <jmdavisProg gmx.com> 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).


 Not to mention data compression ;)


A program is a compressed representation of its possible executions.
May 12 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 12 May 2013 14:16:18 +0200
Timon Gehr <timon.gehr gmx.ch> wrote:


 On 05/12/2013 05:59 AM, Nick Sabalausky wrote:

 On Fri, 10 May 2013 19:04:31 -0400
 "Jonathan M Davis" <jmdavisProg gmx.com> 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).


 Not to mention data compression ;)


 
 A program is a compressed representation of its possible executions.


Indeed. And generally with an absolutely enormous compression ratio -
often even infinite (when there's infinite possible executions). Or
at least "effectively infinite" even if not truly infinite in a strict
mathematical sense, simply due to finite memory.
May 12 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 10 May 2013 at 19:55:58 UTC, sk wrote:

 In any case, I totally agree that if a language *needs* an IDE 
 in order to cope with the amount of required boilerplate, then 
 something is clearly very, very wrong at a fundamental level.


 May be this is true for expert or professional programmers. But 
 for people like me who only use D occasionally an IDE is a must.

 IDE mainly helps me in reducing the amount of things I need to 
 memorize or remember like API, building tool names, command 
 syntaxes, etc. This is very important as my main profession is 
 not programming.


Especially since we aren't very good at API consistency.
May 11 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, May 09, 2013 17:32:18 Nick Sabalausky wrote:

 On Thu, 09 May 2013 10:26:46 -0400
 
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 On 5/9/13 10:26 AM, Andrei Alexandrescu wrote:

 With all this focus on technicalities, we forgot to discuss the
 gist of it: what did you guys think of the talk?


 
 That should better go in the digitalmars.D group though...


 
 Very good talk! And good production quality, too. This would be a
 great thing to point people towards to introduce them to D.


Indeed.


 And Walter does a good job on stage. *Never* comes across as
 pretentious, or cocky or full-of-...various things...like *cough*a
 certain former Apple leader*cough* always did.


Walter may be very stubborn and opinionated, but he definitely isn't 
pretentious.

- Jonathan M Davis
May 10 2013
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/10/13, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 One tiny nitpick, though. In the example about sorting lines in a file,
 there was a syntax error in the code (missing '.' and the end of the
 first/second line).


Walter already used these slides for a previous talk where the missing
dot was mentioned during the talk. He probably just forgot to update
the pdf. :)

Actually that previous talk was a little bit more descriptive in what
the code does (and people kept asking questions too). I'm not sure
exactly what talk it was, maybe it was on nwcpp..
May 10 2013