View mode: basic / threaded / horizontal-split · Log in · Help
July 27, 2012
Re: Impressed
On Friday, July 27, 2012 03:23:27 Era Scarecrow wrote:
> On Friday, 27 July 2012 at 00:57:15 UTC, bearophile wrote:
> > Stuart:
> >> Why does D have GOTO? I haven't used GOTO in over a decade,
> >> because it's truly evil.
> > 
> > Gotos are not so evil. Just use them when they are useful and
> > they can't be replaced by structured programming. In D I create
> > finite state machines at compile-time that use gotos, they are
> > quick.
> 
>   As mentioned, why would GOTO be evil?
> 
>   http://en.wikipedia.org/wiki/BASIC
> 
>   I'm remembering back when i used an Atari (For others,
> Commodore64 and Apple IIe), where the BASIC programming language
> supplied (via rom or built in) didn't have function calling and
> instead everything used GOTO statementes (Or GOSUB).

That's precisely the sort of environment where goto was originally vilified. It 
was being used heavily for flow control. if statements, while loops, function 
calls, etc. all effectively use goto. They just do it for you. it was 
originally being argued that safer constructs  should be used instead of 
gotos. Now, we have way more safe constructs for moving around in code then 
was the case when goto was originally vilified, and everyone is using those 
constructs rather than goto. But the stigma remains and everyone is used to 
thinking of goto as evil.

>   Obviously spaghetti came about easily, but when the GOTO is
> dropped to only being a logical jump when no other options are
> available. Consider half a dozen GOTO's with labels nearby vs
> thousands.

Exactly. Talking about goto as being evil now is almost silly when you think 
about it. It's been almost universally reduced to being use in the cases where 
it's truly useful. It's just not used anymore in the cases where it _is_ 
arguably evil. So, the problem that existed when goto was originally vilified 
has pretty much gone away, and reflexively declaring goto evil and freaking out 
over any use of it is actually harmul. It's a useful construct when used 
properly. It just shouldn't be used when there are better alternatives.

- Jonathan M Davis
July 27, 2012
Re: Impressed
On 07/26/2012 08:54 PM, Jonathan M Davis wrote:
> On Friday, July 27, 2012 02:46:20 Adam D. Ruppe wrote:
>> On Friday, 27 July 2012 at 00:25:49 UTC, Jonathan M Davis wrote:
>>> scope on local variables is going to be deprecated, because
>>> it's unsafe. scope
>>> on function parameters and scope statements are here to stay.
>>
>> There's also scope(exit), scope(success), and scope(failure),
>> which aren't going anywhere.
>
> Yeah. Those are scope statements.
>
> It's just scope on local variable declarations which is going away.
>
> - Jonathan M Davis

Stuart & other readers:

I just asked about this in the other thread, and Jonathan mentioned that 
std.typecons.scoped can be used to accomplish the same thing.  So the 
functionality isn't being removed; it's just being moved from the 
language and into the library.

I think this is worth mentioning so that it doesn't look like we are 
depriving folks of things that they had come to expect from D.
July 27, 2012
Re: Impressed
On Friday, 27 July 2012 at 00:10:31 UTC, Brad Anderson wrote:
> D uses ranges instead of iterators. You can read more about 
> them here: http://ddili.org/ders/d.en/ranges.html
>
> I find ranges to be a vast improvement over iterators 
> personally (I use iterators extensively in C++ for my job and 
> lament not having ranges regularly).
>
>
On Friday, 27 July 2012 at 00:17:21 UTC, H. S. Teoh wrote:
> D has something far superior: ranges.
>
> 	http://www.informit.com/articles/printerfriendly.aspx?p=1407357&rll=1
>
> Even better, they are completely implemented in the library. No
> unnecessary language bloat just to support them.

I'm not very well up on ranges. I understand the general [1 ... 
6] type of ranges, but I really don't see how custom range 
functions could be as useful as the Yield support in VB.NET. I 
mean, here's an example of an iterator in VB.NET:

   Public Function InfiniteSequence(StartValue As Int32, Step As 
Int32) As IEnumerable(Of Int32)
      Do
         Yield StartValue
         StartValue += Step
      Loop
   End Function

Usage:

   For Each N in InfiniteSequence(2, 2)
      ... do something with this sequence of even numbers ...
   Next

Notice how this function is written like a synchronous loop, yet 
yields a lazy-initialised infinite sequence of numbers. Granted, 
it's not a particularly useful example, but trust me: Iterators 
and Yield in .NET is *really* damn useful. I would go so far as 
to say it was one of the language's best features.

I may be wrong, but it looks like I'd have to code a new class - 
not to mention several specific functions and some kind of state 
variable - just to simulate this functionality in D. Can anyone 
clarify this for me?
July 27, 2012
Re: Impressed
On Friday, 27 July 2012 at 00:23:54 UTC, Ali Çehreli wrote:
> Welcome! :)
>
> GOTO is evil; 'goto' is not! ;) goto makes switch-case 
> statements safer in D:

Well, kinda. "Goto case" and such are one thing, but allowing the 
arbitrary use of goto for jumping around from label to label.... 
I just don't understand why the language even supports this. 
Anyone using 'goto label' in their code is doing it wrong. Period.
July 27, 2012
Re: Impressed
On Friday, 27 July 2012 at 00:25:49 UTC, Jonathan M Davis wrote:
>
> scope on local variables is going to be deprecated, because 
> it's unsafe.

Um...could you explain why? I thought scope on locals was a 
really nice feature. I was looking forward to making use of it 
for deterministic resource deallocation.

Besides, if scope(exit) is still allowed, how is that any 
different?
July 27, 2012
Re: Impressed
On Friday, 27 July 2012 at 01:25:45 UTC, F i L wrote:
>
> I know many are attached at the hip to Visual Studios, but I 
> recommend MonoDevelop + Mono-D plugin for D programming. It's 
> very nice, with the exception of a few bug, it offers is 
> *similar* experience to Visual Studios C#/VB. Plus it's cross 
> platform, if/when you take your projects to other platforms it 
> helps a lot to use a consistent tool.

I've had a lot of bad experience with other IDEs. Eclipse, for 
example, and D-IDE. I don't know about you guys, but I couldn't 
get either of those environments to even compile my code, let 
alone provide any kind of intellisense or debugging facilities. 
Maybe I'm doing it wrong, I dunno. Is MonoDevelop good? Does it 
do intellisense? Does it have a decent debugger?

Incidentally, none of that answered my original question, which 
is "why does VisualD crash?"

The only other thing I don't like about VisualD is that the 
intellisense kinda blows. It's very hit-and-miss. Why is this?
July 27, 2012
Re: Impressed
On Friday, July 27, 2012 03:58:52 Stuart wrote:
> On Friday, 27 July 2012 at 00:23:54 UTC, Ali Çehreli wrote:
> > Welcome! :)
> > 
> > GOTO is evil; 'goto' is not! ;) goto makes switch-case
> 
> > statements safer in D:
> Well, kinda. "Goto case" and such are one thing, but allowing the
> arbitrary use of goto for jumping around from label to label....
> I just don't understand why the language even supports this.
> Anyone using 'goto label' in their code is doing it wrong. Period.

You're going to find plenty of people who disagree with you when dealing with a 
systems language. Particularly when dealing with low level code, gotos can be 
very useful. Granted, if code is littered with them, there's no question that 
there's a problem, but there are definitely cases where using goto actually 
improves code - especially when efficiency is a major concern. They're just 
relatively rare. Other, good, language constructs make them far less necessary 
than they once were.

- Jonathan M Davis
July 27, 2012
Re: Impressed
On Friday, 27 July 2012 at 01:45:35 UTC, Jonathan M Davis wrote:
> Now, we have way more safe constructs for moving around in code 
> then was the case when goto was originally vilified,
> and everyone is using those constructs rather than goto.
> But the stigma remains and everyone is used to thinking of goto 
> as evil.

So if everyone uses these other constructs, why even provide a 
goto? I seriously have not needed a goto in over ten years; and 
the way I see it, if your program uses one, it needs to be 
refactored. Just my opinion.

> It's a useful construct when used properly. It just shouldn't 
> be used when
> there are better alternatives.

I can't think of ANY situation where goto would be the only 
viable option. Loops, ifs, switches - these cover 100% of 
requirements, surely? If it really is necessary in some cases, 
how have I managed to avoid goto for so long? And what are these 
cases?
July 27, 2012
Re: Impressed
On Friday, 27 July 2012 at 01:54:16 UTC, Chad J wrote:
>
> Stuart & other readers:
>
> I just asked about this in the other thread, and Jonathan 
> mentioned that std.typecons.scoped can be used to accomplish 
> the same thing.  So the functionality isn't being removed; it's 
> just being moved from the language and into the library.
>
> I think this is worth mentioning so that it doesn't look like 
> we are depriving folks of things that they had come to expect 
> from D.

Oh, that's alright then. Although, I'd still like to know why 
it's unsafe. Also, is there any documentation on how to *use* the 
scope feature from the library? I mean, do we just "import 
std.typecons.scoped" and suddenly the keyword pops back into 
existence, or do we need to use some kind of new syntax?
July 27, 2012
Re: Impressed
On Friday, July 27, 2012 04:00:56 Stuart wrote:
> On Friday, 27 July 2012 at 00:25:49 UTC, Jonathan M Davis wrote:
> > scope on local variables is going to be deprecated, because
> > it's unsafe.
> 
> Um...could you explain why? I thought scope on locals was a
> really nice feature. I was looking forward to making use of it
> for deterministic resource deallocation.

It's inherently unsafe. What happens if you returned a reference to foo from 
someFunc? Or if you assigned a reference to foo to anything and then tried to 
use it after someFunc has returned? You get undefined behavior, because foo 
doesn't exist anymore. If you really need foo to be on the stack, then maybe 
you should make it a struct. However, if you really do need scope for some 
reason, then you can use std.typecons.scoped, and it'll do the same thing.

scope on local variables is going away for pretty much the same reason that 
delete is. They're unsafe, and the fact that they're in the core language 
encourages their use. So, they're being removed and put into the standard 
library instead.

> Besides, if scope(exit) is still allowed, how is that any different?

scope(exit) doesn't necessarily have anything to do with deallocating memory. 
It's far more general than that. It just runs an arbitrary statement when 
exiting the scope that it's declared in. There's nothing inherently unsafe 
about that. You _can_ do unsafe operations in it, but you can do that pretty 
much anywhere. So, if you were to free GC-allocated memory in a scope 
statement, then you'd be in exactly the same sinking boat that scope puts you 
in.

Freeing GC-allocated memory is inherently unsafe. It's the GC's job to do 
that. If you really want to be managing memory yourself, then you should be 
using malloc and free. But for those occasions when you really do end up 
needing that sort of control with GC memory, we have stuff like 
std.typecons.scoped and core.memory. They just shouldn't be used under normal 
circumstances, and you have to be careful with them, so you should only used 
them when you know what you're doing - which is in stark contrast to having 
delete and scope in the core language where everyone sees them and thinks that 
they're perfectly safe to use, completely ignoring or being completely unaware 
of the dangers involved. We give you the power to blow your foot off if you 
want to, but we don't want to prime the gun and hand it to you, just make it 
available if you need it.

- Jonathan M Davis
1 2 3 4 5 6
Top | Discussion index | About this forum | D home