Index » General » Impressed (page 2)

July 27, 2012
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
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
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
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
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
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
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
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
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
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 7 8 9 10 11 12
Top | Discussion index | About this forum | D home