Re: DConf Day 1 Panel with Walter Bright and Andrei Alexandrescu
On Friday, 27 June 2014 at 20:39:10 UTC, Walter Bright wrote: On 6/27/2014 12:53 PM, Dicebot wrote: http://youtu.be/TNvUIWFy02I Ack, need to work on my posture :-( I just got a chance to watch this, and one thing that I found more unsettling than your posture was your assertion that destructors and finalizers are "the same thing", in contrast to Hans-J. Boehm, who asserts that C++ destructors and Java finalizers "are completely different facilities". I assume that you've read Boehm's report http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html and if so I'd be interested in why you think he is mistaken, since both of your statements can't be correct.
Re: Interview at Lang.NEXT
On Thursday, 5 June 2014 at 12:46:24 UTC, Atila Neves wrote: I don't know, but the only language I've used with no static types that made me comfortable was Common Lisp. That was a long time ago, but I think it was the ease of manually testing the code in a REPL that did it. Obviously today I'd write unit tests anyway. Atila There are languages with good static type systems (OCaml, F#, Scala, to name a few) that have REPLs as well, and they're quite useful there too. I'm fond of Lisp, and I think Lisp macros are very powerful and useful. I like Python's (really ISWIM's) indentation sensitive syntax. But, as someone who uses 'dynamically typed' languages daily, I think static typing is a huge win and don't understand why anyone would not want to use a language with static types, especially if they were mostly inferred and so the annotation burden was minimal. ML is the language of the future ;-)
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Thursday, 29 May 2014 at 18:52:53 UTC, Brian Schott wrote: On Thursday, 29 May 2014 at 18:12:10 UTC, Dmitry Olshansky wrote: And no, it doesn't matter how the current frontend implements it, because you can argue next to any decisions this way. When issues like this come up the spec is almost always changed to match the DMD front end instead of the other way around. I believe that the result of this policy will be that the D community will need to have Scott Meyers or someone like him to explain some of these issues. :-) It may not be as bad as C++, but is that how we want to measure a language design? "Sure, it looks bad, but it could have been so much worse!" Why are we afraid of breaking code that relied on behavior that was not in the language specification? My guess is that the fear of 'breaking' some users' code is too great right now. That was one of the things I took from Meyers' talk; the D designers still have an opportunity to be bold in introducing changes that make the entire design better (more easily explainable) while in C++ that opportunity has probably passed. That makes it almost impossible to fix accepts-invalid bugs. It's a problem that needs to be addressed. Thanks for your efforts and for continually reminding people. I really liked your lightning talk; it could have followed Meyers' and maybe the right people would have been shamed into action.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On Wednesday, 28 May 2014 at 23:07:07 UTC, Walter Bright wrote: Some of the inconsistencies you mentioned and Brian mentioned in his talk are actually the result of consistencies. I know this is a bit of a difficult thing to wrap one's head around, but having something be mathematically consistent and humanly consistent are often at severe odds. Could you elaborate? Using some of the examples Brian gave, which ones do you think are are mathematically consistent/human inconsistent and which the inverse?
