www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Impressed

reply "Stuart" <stugol gmx.com> writes:
I'm quite new to D, and I've just been reading the guides. I just 
wanted to say I'm very impressed with some of the features I'm 
reading about. Slices, closures, the scope keyword(!!!), class 
variable initialisers, anonymous array literals, array 
concatenation, synchronisation... even decent exception support 
is a breath of fresh air compared to C++.

I'm primarily a .NET coder these days, but sometimes you really 
need more performance. Writing an OpenGL game in VB.NET is just 
pointless - it doesn't execute fast enough to be of any use, even 
using display lists. So, next time I need something a little more 
C-like, I'll be loading up D straight away.

I have a couple of questions though. Why does the VisualD plugin 
crash Visual Studio if I double-click a .sln file in Windows 
Explorer? I mean, every single time? I'm using VS2010 on Windows 
7 64-bit; and the problem only happens with D projects, and only 
when loading an .sln file by association. If I load VS and use 
the menu to open the solution, it works fine.

Why does D have GOTO? I haven't used GOTO in over a decade, 
because it's truly evil.

How good is the Entice Designer? I'd like to write some GUI apps 
in D, but I need to know that the designer won't fall over 
halfway through; and I'll be damned if I'm writing my GUI code by 
hand. Even MFC programmers have a "dialog designer".

One thing I really think D ought to have is iterators, like 
VB.NET and C# have. Trust me, they're really damn useful. Any 
chance of them being implemented? The implementation of .NET 
iterators is well-known and fairly straightforward; all we need 
is compiler support.
Jul 26 2012
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 26 July 2012 at 23:59:13 UTC, Stuart wrote:
 I'm quite new to D, and I've just been reading the guides. I 
 just wanted to say I'm very impressed with some of the features 
 I'm reading about. Slices, closures, the scope keyword(!!!), 
 class variable initialisers, anonymous array literals, array 
 concatenation, synchronisation... even decent exception support 
 is a breath of fresh air compared to C++.

 I'm primarily a .NET coder these days, but sometimes you really 
 need more performance. Writing an OpenGL game in VB.NET is just 
 pointless - it doesn't execute fast enough to be of any use, 
 even using display lists. So, next time I need something a 
 little more C-like, I'll be loading up D straight away.

 I have a couple of questions though. Why does the VisualD 
 plugin crash Visual Studio if I double-click a .sln file in 
 Windows Explorer? I mean, every single time? I'm using VS2010 
 on Windows 7 64-bit; and the problem only happens with D 
 projects, and only when loading an .sln file by association. If 
 I load VS and use the menu to open the solution, it works fine.

 Why does D have GOTO? I haven't used GOTO in over a decade, 
 because it's truly evil.

 How good is the Entice Designer? I'd like to write some GUI 
 apps in D, but I need to know that the designer won't fall over 
 halfway through; and I'll be damned if I'm writing my GUI code 
 by hand. Even MFC programmers have a "dialog designer".

 One thing I really think D ought to have is iterators, like 
 VB.NET and C# have. Trust me, they're really damn useful. Any 
 chance of them being implemented? The implementation of .NET 
 iterators is well-known and fairly straightforward; all we need 
 is compiler support.

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). Regards, Brad Anderson
Jul 26 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-07-27 02:10, 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).

Note that iterators in .NET and C++ are a bit different. .NET has language support with the "yield" keyword. -- /Jacob Carlborg
Jul 26 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-07-27 09:42, Nick Sabalausky wrote:

 I wonder how that works under the hood. Like, if it's somewhat similar
 to opApply. Or maybe more like an Asm-style "messin' with the call
 stack's return addresses". I would hope it wouldn't involve fiber
 context switches, unless they're somehow much faster than D fiber
 context switches (which would seem weird, being in a VM).

I have no idea. But Ruby uses a similar approach: def foo yield 1 yield 2 yield 3 end foo do |e| puts e end Results in: 1 2 3 But in Ruby that's basically syntax sugar for: def foo (&block) block.call(1) block.call(1) block.call(1) end Which in D would be the same as: void foo (void delegate (int) dg) { dg(1); dg(2); dg(3); } foo((e){ writeln(e); }); Which is basically how opApply works. -- /Jacob Carlborg
Jul 27 2012
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/27/12 9:10 AM, Stuart wrote:
 On Friday, 27 July 2012 at 03:00:25 UTC, Brad Anderson wrote:
 D equivalent: iota(0, int.max, 2).map!(a => /* do something with even
 numbers */)();

I think you're missing the point. The purpose isn't to generate a sequence of numbers, but to illustrate how the Yield keyword is used in VB.NET. Sure, getting a sequence of numbers may be straightforward, but what about a lazy-populated list of all files on a computer? That can be done using Yield - and more importantly, WRITTEN like a normal synchronous function. Let's see you do that with map.

I think it's fair to say yield makes some things easier to do than ranges, and ranges makes some other things easier to do than yield. Of course, ideally you'd have both, but for the time being we don't have yield. Andrei
Jul 27 2012
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 27-Jul-12 20:15, Jesse Phillips wrote:
 On Friday, 27 July 2012 at 13:10:46 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 03:00:25 UTC, Brad Anderson wrote:
 D equivalent: iota(0, int.max, 2).map!(a => /* do something with even
 numbers */)();

I think you're missing the point. The purpose isn't to generate a sequence of numbers, but to illustrate how the Yield keyword is used in VB.NET. Sure, getting a sequence of numbers may be straightforward, but what about a lazy-populated list of all files on a computer? That can be done using Yield - and more importantly, WRITTEN like a normal synchronous function. Let's see you do that with map.

You wouldn't use map for that, that would be silly. Taking a look at DirIteratorImpl[1] in std.file suggest there is a lot of setup to navigate the filesystem on Windows. How does Yield help with that logic?

It should be more straightforward as DirIteratorImpl does maintain stack of directories/searches as it goes. The yield version could simply use recursion and yield a-la opApply version that was there before. But this advantage is unimportant since arbitrary deep recursion is a security risk (especially for servers that typically use threads with tiny stacks).
 1.
 https://github.com/D-Programming-Language/phobos/blob/master/std/file.d#L2397


 Seriously I'll take my composing ranges over iterators any day.

-- Dmitry Olshansky
Jul 27 2012
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 27-Jul-12 23:09, Paulo Pinto wrote:
 On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 16:28:50 UTC, Dmitry Olshansky wrote:
 But this advantage is unimportant since arbitrary deep recursion is a
 security risk (especially for servers that typically use threads with
 tiny stacks).

I would like to point out here that the example VB.NET code I just gave for lazy-populating a list of all files on a drive uses NO recursion whatsoever.


It sure thing would. Just list your code to do so. Recursively scan all files on drive does involve stack or recursion. If you mean list all files shallowly then of course no recursion takes place (but then ranges will do the same no problem).
 Recursion isn't just a security risk - it's a performance hit as well.

Only in languages without tail call optimizations.

Tail call won't do. Precisely because call in this function saves state. In effect you maintain the same stack of directories but implicitly so though hardware call stack with locals. -- Dmitry Olshansky
Jul 27 2012
prev sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 28-07-2012 09:36, Stuart wrote:
 On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 On Friday, 27 July 2012 at 19:14:29 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 19:09:27 UTC, Paulo Pinto wrote:
 On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
 Recursion isn't just a security risk - it's a performance hit as well.

Only in languages without tail call optimizations.

Which is pretty much all of them. Scheme does it, and probably HOPE too; but bugger-all you could write a real program in, like .NET or C++. I mean, we're in bloody FORTRAN territory here. What use is that for writing Windows applications? Does D have tail call optimisation?

Well, at least all of these: - Scheme - Haskell - OCaml - F# - Erlang - Clojure - Some C and C++ compilers (gcc, Intel, MSVC in release mode) - Most commercial Lisp compilers

So, as I said, nothing you can write a real program in - except possibly for F#. The possibility of "some" C compilers supporting it doesn't mean you can rely on the feature being present.

Are you serious........?
 Yes D compilers also do tail call optimizations in certain cases, even
 if not specified in the language spec

If it's not specified in the language spec - and if it's only "in certain cases" - how can you rely on it?

You can't. -- Alex Rønne Petersen alex lycus.org http://lycus.org
Jul 28 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 28-07-2012 09:58, Stuart wrote:
 On Saturday, 28 July 2012 at 07:45:20 UTC, Alex Rønne Petersen wrote:
 On 28-07-2012 09:36, Stuart wrote:
 On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 - Scheme
 - Haskell
 - OCaml
 - F#
 - Erlang
 - Clojure
 - Some C and C++ compilers (gcc, Intel, MSVC in release mode)
 - Most commercial Lisp compilers

So, as I said, nothing you can write a real program in - except possibly for F#. The possibility of "some" C compilers supporting it doesn't mean you can rely on the feature being present.

Are you serious........?

Uh, yeah? Aside from C (which doesn't always support tail call optimisation), and F#, none of these languages would seem to have any purpose on a desktop computer. I don't know of any way, in this day and age, to write application software (e.g. Notepad) for a 32 or 64-bit Windows 7 machine, in goddamn Haskell. I may be mistaken.

Some of the most robust and reliable server systems are written in Erlang. OCaml is basically F# but in native code. It isn't actually much different from using D in terms of capabilities. Clojure runs on the JVM. It can do native invokes just like Java. Scheme has FFI.
 As I understand it, languages like Scheme and Cojure exist solely to
 keep mathematicians happy. If you can't call API functions in it, what's
 the use of it?

-- Alex Rønne Petersen alex lycus.org http://lycus.org
Jul 28 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/28/12 10:04 AM, Paulo Pinto wrote:
 On Saturday, 28 July 2012 at 12:42:47 UTC, Stuart wrote:
 On Saturday, 28 July 2012 at 09:37:47 UTC, Paulo Pinto wrote:
 I tend to favour F# instead of OCaml due to three things

I've never really seen the point of F#. Aside from maths, what is F# good for that a standard imperative language is not? Especially when you consider that all flavours of .NET have native support for LINQ.

Let me see: - Symbolic code manipulation; - Metaprogramming; - Easy parallelization of code thanks to immutable data structures and workflows - Type providers (comming in F# 3.0) to manipulate remote data as language data types - The right way of doing type inference (shared by all ML languages) - Asynchronous programming builtin without having to wait for ..NET 4.5 - Algebraic data types Microsoft wouldn't have brought F# into Visual Studio if it wasn't worth it, Microsoft is a business, not a language charity company.

It was for Basic :o). Anyhow, indeed, the tools around it make F# pretty cool (just not all that original as a language). Andrei
Jul 28 2012
next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 28/07/2012 18:07, Andrei Alexandrescu a écrit :
 Microsoft wouldn't have brought F# into Visual Studio if it wasn't worth
 it, Microsoft is a business, not a language charity company.

It was for Basic :o). Anyhow, indeed, the tools around it make F# pretty cool (just not all that original as a language). Andrei

Indeed, it is damn close to Caml.
Jul 30 2012
prev sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 28-07-2012 18:07, Andrei Alexandrescu wrote:
 On 7/28/12 10:04 AM, Paulo Pinto wrote:
 On Saturday, 28 July 2012 at 12:42:47 UTC, Stuart wrote:
 On Saturday, 28 July 2012 at 09:37:47 UTC, Paulo Pinto wrote:
 I tend to favour F# instead of OCaml due to three things

I've never really seen the point of F#. Aside from maths, what is F# good for that a standard imperative language is not? Especially when you consider that all flavours of .NET have native support for LINQ.

Let me see: - Symbolic code manipulation; - Metaprogramming; - Easy parallelization of code thanks to immutable data structures and workflows - Type providers (comming in F# 3.0) to manipulate remote data as language data types - The right way of doing type inference (shared by all ML languages) - Asynchronous programming builtin without having to wait for ..NET 4.5 - Algebraic data types Microsoft wouldn't have brought F# into Visual Studio if it wasn't worth it, Microsoft is a business, not a language charity company.

It was for Basic :o). Anyhow, indeed, the tools around it make F# pretty cool (just not all that original as a language). Andrei

What makes you say that? I guess that opinion stems from F# being based on OCaml's syntax? (But then to be fair, we would have to call D very unoriginal too...) Either way, F# adds a *ton* of stuff on top of OCaml that makes it a far superior language: * Reified generics: http://msdn.microsoft.com/en-us/library/dd233215(v=vs.110) * Inline functions (I'm still amazed D doesn't have this yet): http://msdn.microsoft.com/en-us/library/dd548047(v=vs.110) * Type extensions, a (IMO) much cleaner approach to artificially extending types: http://msdn.microsoft.com/en-us/library/dd233211(v=vs.110) * Pattern matching (oh how I miss this in compiler code): http://msdn.microsoft.com/en-us/library/dd547125(v=vs.110) * Annotations: http://msdn.microsoft.com/en-us/library/dd233179(v=vs.110) * Units of measure: http://msdn.microsoft.com/en-us/library/dd233243(v=vs.110) * Computation expressions (F#'s humanly understandable take on monads): http://msdn.microsoft.com/en-us/library/dd233182(v=vs.110) * Code quotations, making for metaprogramming that can do things even D's metaprogramming can't: http://msdn.microsoft.com/en-us/library/dd233212(v=vs.110) * Async workflows (actually a library solution built through computation expressions): http://msdn.microsoft.com/en-us/library/dd233250(v=vs.110) * Query expressions (again, based on computation expressions): http://msdn.microsoft.com/en-us/library/hh225374(v=vs.110) * Automatic generalization: http://msdn.microsoft.com/en-us/library/dd233183(v=vs.110).aspx * Type providers (type-safe data access): http://msdn.microsoft.com/en-us/library/hh156509(v=vs.110).aspx There are probably lots of other features that I have forgotten. I don't think calling F# unoriginal is fair... -- Alex Rønne Petersen alex lycus.org http://lycus.org
Jul 30 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/30/12 3:33 PM, Alex Rønne Petersen wrote:
 There are probably lots of other features that I have forgotten. I don't
 think calling F# unoriginal is fair...

I stand corrected! Andrei
Jul 30 2012
prev sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 28-07-2012 10:16, Nick Sabalausky wrote:
 On Sat, 28 Jul 2012 09:45:19 +0200
 Alex Rnne Petersen <alex lycus.org> wrote:

 On 28-07-2012 09:36, Stuart wrote:
 On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 - Scheme
 - Haskell
 - OCaml
 - F#
 - Erlang
 - Clojure
 - Some C and C++ compilers (gcc, Intel, MSVC in release mode)
 - Most commercial Lisp compilers

So, as I said, nothing you can write a real program in - except possibly for F#. The possibility of "some" C compilers supporting it doesn't mean you can rely on the feature being present.

Are you serious........?

I would tend to agree with him, unless you're being overly literal. Obviously you *can* do real programs in C/C++, hell I've done it (and I am doing it, much to my dismay) - but it's notoriously painful. As for the rest, yea, sure, stuff *has* been written in them, but regardless, most of them still just aren't *realistically* suitable for most software development. It's just like how somebody once write a high-precision Pi calculator in MS Batch. They pulled it off, and it works, but that doesn't mean Batch is realistically suitable as a numeric processing language. Writing real software in, for example, Haskell is like calculating high-precision Pi in Batch. It can be done, but it takes a masochist.

Pointing out the most extreme cases is not really a good way to make a point about language usability IMO. Most of the languages mentioned are very usable for the areas they were intended to be used in. Use them in an area they aren't meant for and you're pretty much asking for whatever you end up with. Batch sure as hell wasn't meant for calculation of *any* kind... Of course C and C++ are painful. No argument there. But that's due to them being designed decades ago. Erlang, OCaml, Clojure, etc are fairly sane. Scheme, too, if you (don't (mind (the (parentheses))). :) (I know, I know, that isn't valid Scheme...) -- Alex Rnne Petersen alex lycus.org http://lycus.org
Jul 28 2012
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 07/27/12 20:47, Stuart wrote:
 On Friday, 27 July 2012 at 15:09:38 UTC, Graham Fawcett wrote:
 On Friday, 27 July 2012 at 13:10:46 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 03:00:25 UTC, Brad Anderson wrote:
 D equivalent: iota(0, int.max, 2).map!(a => /* do something with even numbers
*/)();

I think you're missing the point. The purpose isn't to generate a sequence of numbers, but to illustrate how the Yield keyword is used in VB.NET. Sure, getting a sequence of numbers may be straightforward, but what about a lazy-populated list of all files on a computer? That can be done using Yield - and more importantly, WRITTEN like a normal synchronous function. Let's see you do that with map.

That's easy: [...elided code...] auto entries = dirEntries(BASE_DIR, SpanMode.breadth);

Ah, but that depends upon the pre-existence of the dirEntries() function. I think perhaps you're missing the point - which is that "Yield" allows you to WRITE a function synchronously which will then be executed lazily, as an iterator. What you have demonstrated there is USING a lazy function. How would I write, in D, a function that would lazily assemble some data and return it as a lazy collection? I mean, without calling existing lazy functions.

A more or less direct translation of your original example would be: auto infiniteSequence1(T, S)(T startValue, S step) { struct IS { auto opApply(scope int delegate(ref T) yield) { while (1) if (auto r = yield(startValue)) return r; else startValue += step; } } return IS(); } void main() { import std.stdio; foreach(n; infiniteSequence(2, 2)) { writeln(n); if (n>13) break; } } and a D-style range based version could look like this: auto infiniteSequence(T, S)(T startValue, S step) { static struct IS { T startValue; S step; enum empty = false; property ref front() { return startValue; } void popFront() { front += step; } } return IS(startValue, step); } which both are as lazy as it gets. Returning direntries would be done similarly. Is this just about the syntax (which isn't much different)? artur
Jul 27 2012
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 27-Jul-12 22:58, Stuart wrote:
 On Friday, 27 July 2012 at 16:15:46 UTC, Jesse Phillips wrote:
 Taking a look at DirIteratorImpl[1] in std.file suggest there is a lot
 of setup to navigate the filesystem on Windows. How does Yield help
 with that logic?

Well, off the top of my head, you could use something like: Public Iterator Function AllFiles(RootDirectory As String) As IEnumerable(Of String) Dim Roots As New Queue(Of String) From {RootDirectory} While Roots.Any Dim Root = Roots.Pop Roots.AddRange(IO.Directory.GetDirectories(Root)) For Each Filename in IO.Directory.GetFiles(Root) Yield Filename Next End While End Function

Then it's not in anyway better then ranges. You again maintain stack (or queue, whatever). The only difference is that for is replaced with a function front/popFront that do one iteration of the same state machine. -- Dmitry Olshansky
Jul 27 2012
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 28-Jul-12 11:49, Stuart wrote:
 On Friday, 27 July 2012 at 22:38:46 UTC, Dmitry Olshansky wrote:
 On 27-Jul-12 22:58, Stuart wrote:
 Well, off the top of my head, you could use something like:

    Public Iterator Function AllFiles(RootDirectory As String) As
 IEnumerable(Of String)
       Dim Roots As New Queue(Of String) From {RootDirectory}
       While Roots.Any
          Dim Root = Roots.Pop
          Roots.AddRange(IO.Directory.GetDirectories(Root))
          For Each Filename in IO.Directory.GetFiles(Root)
             Yield Filename
          Next
       End While
    End Function

Then it's not in anyway better then ranges.

I assume you mean "any way" - "anyway" has a different meaning. And I don't know much about ranges, because there's very little documentation. But as I understand it, for ranges I'd need to write a whole new class.

struct. Yeah, you need it.
 Here, I'm writing a SINGLE FUNCTION in standard imperative style.

That implicitly constructs Iterator. It's just a sugar. In fact you can do template mixin to generate most of range boilerplate.
 You again maintain stack (or queue, whatever).

There is a difference between recursion (stack) and state variables. To claim that my function is recursive is sheer nonsense.

I haven't claimed that in this post. Like I said, you indeed create a state automation. That is a function + state struct (bunch of state vars). It's not a SINGLE FUNCTION in the end. It's a sugar for special object with member function "next" or whatever. Also this object should implement all members of Iterator, meaning it's polymorphic and uses virtual calls. What I tried to point out is that the end result is the same, with yield you just generate state object automatically (and wrap it in polymorphic Iterator?).
 Recursion is
 costlier than a local queue.

Not necessarily. Again, hardware stack is faster, but saves more stuff (unlike your queue that saves only filenames). So recursion is not extremely costly on its own, I'd say even faster. In fact, incredibly popular PCRE uses recursion to process regular expressions. At least there it was faster then explicit stack, the only problematic thing is requirement to have big thread stack. -- Dmitry Olshansky
Jul 28 2012
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 28-Jul-12 13:00, Stuart wrote:
 On Saturday, 28 July 2012 at 08:53:43 UTC, Dmitry Olshansky wrote:
 On 28-Jul-12 11:49, Stuart wrote:
 But as I understand it, for ranges I'd need to write a whole new class.

struct. Yeah, you need it.
 Here, I'm writing a SINGLE FUNCTION in standard imperative style.

That implicitly constructs Iterator. It's just a sugar. In fact you can do template mixin to generate most of range boilerplate.

I think the basic thrust of my point is: Sugar is good. The compiler converting an imperative function into a state-machine class is helpful. Having to write it yourself every damn time is a pain in the arse.

fact look at opApply it's approach is the other way around - instead of generating object it packs function as delegate and passes it to some internal iteration mechanism: for(v; a){ v++; } ---> a.opApply(x => x++); where a's opApply can do whatever it wants to with this delegate and elements.
 I've been reading about ranges at
 [http://ddili.org/ders/d.en/ranges.html], and don't understand
 something. Where it says:

     struct StudentRange {
      Student[] students;

      this(School school) {
          this.students = school.students;
      }

      [...code...]

 Surely "students" is copied here? Isn't the whole point NOT to copy the
 array? Perhaps it should say:

     this.students = school.students[];

 ?

It copies 2 words: pointer and length. Thus students points to the same array in both cases. To make a full copy use .dup. You really need to checkout Steven's D slices article can't recall link offhand. -- Dmitry Olshansky
Jul 28 2012
parent Mike Parker <aldacron gmail.com> writes:
On 7/28/2012 6:07 PM, Dmitry Olshansky wrote:

 To make a full copy use .dup. You really need to checkout Steven's D
 slices article can't recall link offhand.

http://dlang.org/d-array-article.html
Jul 28 2012
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/27/12 6:38 PM, Dmitry Olshansky wrote:
 Then it's not in anyway better then ranges. You again maintain stack (or
 queue, whatever). The only difference is that for is replaced with a
 function front/popFront that do one iteration of the same state machine.

I'd say this argument on which is "better", yield or ranges, is a problem ill posed. "yield" adds real, nontrivial value, and is not entirely implementable as a library. Walter and I saw some uses of it in C# at Lang.NEXT that were quite impressive. On the other hand yield's charter is limited when compared to that of ranges. Yield goes with the very simple "go through everything once" functionality, which is essentially input ranges - only a tiny part of ranges can do. Andrei
Jul 28 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 27, 2012 at 01:59:12AM +0200, Stuart wrote:
 I'm quite new to D, and I've just been reading the guides. I just
 wanted to say I'm very impressed with some of the features I'm reading
 about. Slices, closures, the scope keyword(!!!), class variable
 initialisers, anonymous array literals, array concatenation,
 synchronisation... even decent exception support is a breath of fresh
 air compared to C++.

I think certain usages of the scope keyword is being phased out? (Somebody else can clarify this.) [...]
 Why does D have GOTO? I haven't used GOTO in over a decade, because
 it's truly evil.

You don't have to use it. In my experience with C++ and D, I've never needed to use goto. (I do use it sometimes in C mainly because error handling is so horrible in C otherwise.) [...]
 One thing I really think D ought to have is iterators, like VB.NET and
 C# have.

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. T -- Ph.D. = Permanent head Damage
Jul 26 2012
prev sibling next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Welcome! :)

On 07/26/2012 04:59 PM, Stuart wrote:

 Why does D have GOTO? I haven't used GOTO in over a decade, because it's
 truly evil.

GOTO is evil; 'goto' is not! ;) goto makes switch-case statements safer in D: http://dlang.org/statement.html#GotoStatement
 iterators

Here is a paper that compares different approaches: http://www.informit.com/articles/printerfriendly.aspx?p=1407357 Ali
Jul 26 2012
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 07/26/2012 06:58 PM, Stuart wrote:
 On Friday, 27 July 2012 at 00:23:54 UTC, Ali Çehreli wrote:

 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.

Unlike C++, the language disallows unsafe jumping forward (or is it dmd that disallows it?). Hmmm... Maybe I am wrong... (?) I swear, the following code used to generate a compilation error: if (aCondition) { goto label; // Jumps over s's constructor call } auto s = S(7); label: s.foo(); The error used to say: "Error: cannot goto forward into different try block level." The code is allowed by dmd 2.059. The code is allowed for classes as well but of course there is a segmentation faault due to foo() on the null object. Strange...
 Anyone using 'goto
 label' in their code is doing it wrong. Period.

I agree. Ali
Jul 26 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 27-07-2012 05:32, Ali Çehreli wrote:
 On 07/26/2012 06:58 PM, Stuart wrote:
  > On Friday, 27 July 2012 at 00:23:54 UTC, Ali Çehreli wrote:

  > 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.

 Unlike C++, the language disallows unsafe jumping forward (or is it dmd
 that disallows it?). Hmmm... Maybe I am wrong... (?) I swear, the
 following code used to generate a compilation error:

      if (aCondition) {
          goto label;    // Jumps over s's constructor call
      }

      auto s = S(7);

 label:

      s.foo();

 The error used to say:

    "Error: cannot goto forward into different try block level."

 The code is allowed by dmd 2.059.

 The code is allowed for classes as well but of course there is a
 segmentation faault due to foo() on the null object. Strange...

  > Anyone using 'goto
  > label' in their code is doing it wrong. Period.

 I agree.

 Ali

Jumping over initialization isn't as problematic in D because variables are guaranteed to have a default initialization value (if not initialized to void). It's worse in languages like C where the value of variables would be undefined. -- Alex Rønne Petersen alex lycus.org http://lycus.org
Jul 26 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 27-07-2012 09:41, Simen Kjaeraas wrote:
 On Fri, 27 Jul 2012 06:36:57 +0200, Alex Rønne Petersen
 <alex lycus..org> wrote:

 Jumping over initialization isn't as problematic in D because
 variables are guaranteed to have a default initialization value (if
 not initialized to void).

And how is that supposed to work, when you just skipped that piece of code?

The compiler does control flow analysis to ensure that all reads of the value will, at the very least, see a default-initialized variable. It's really quite trivial to do in the compiler.
 It's worse in languages like C where the value of variables would be
 undefined.

It's *better* in languages like C, where the value of the variable would be undefined anyway, so you'd have to deal with that anyway.

Undefined behavior is never useful, better, or desirable in any way, shape, or form. With a well-defined default initialization value, it's trivial to discover that you skipped initialization. This is why D initializes floats to NaN, chars to 0xff, etc.
 I would go as far as to say this is part of the reason this is in the spec:

 "It is illegal for a GotoStatement to be used to skip initializations."[1]


 [1]: http://dlang.org/statement.html#GotoStatement

-- Alex Rønne Petersen alex lycus.org http://lycus.org
Jul 27 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, July 26, 2012 17:18:38 H. S. Teoh wrote:
 On Fri, Jul 27, 2012 at 01:59:12AM +0200, Stuart wrote:
 I'm quite new to D, and I've just been reading the guides. I just
 wanted to say I'm very impressed with some of the features I'm reading
 about. Slices, closures, the scope keyword(!!!), class variable
 initialisers, anonymous array literals, array concatenation,
 synchronisation... even decent exception support is a breath of fresh
 air compared to C++.

I think certain usages of the scope keyword is being phased out? (Somebody else can clarify this.)

scope on local variables is going to be deprecated, because it's unsafe. scope on function parameters and scope statements are here to stay.
 [...]
 
 Why does D have GOTO? I haven't used GOTO in over a decade, because
 it's truly evil.

You don't have to use it. In my experience with C++ and D, I've never needed to use goto. (I do use it sometimes in C mainly because error handling is so horrible in C otherwise.)

If you're using goto much in code, then you're doing somethnig wrong, but it would be a problem for a systems language _not_ to have a goto statement. On rare occasions (especially when writing low level code), they end up being very useful. Now, D has made goto even less necessary than it is in most languages (e.g. it has labeled break and labeled continue which go to a label in a loop), but the language should still have it. - Jonathan M Davis
Jul 26 2012
next sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
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.
Jul 26 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-07-27 02:25, 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.

"scope" on class declarations as well. -- /Jacob Carlborg
Jul 26 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-07-27 08:41, Jonathan M Davis wrote:
 On Friday, July 27, 2012 08:36:17 Jacob Carlborg wrote:
 On 2012-07-27 02:25, 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.

"scope" on class declarations as well.

I didn't even know that you could do that, and I have no idea what that would do.

If I recall correctly it forces you do use "scope" when declaring a variable of the class. http://dlang.org/class.html#auto -- /Jacob Carlborg
Jul 26 2012
prev sibling parent travert phare.normalesup.org (Christophe Travert) writes:
Jonathan M Davis , dans le message (digitalmars.D:173382), a crit:
 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.
 

I don't mind scope going away, since it can be replaced with a library solution. But scope is not more dangerous than a static array, or simple function variables. Slice them, or take their reference, and you're up for troubles. Do you think they should be removed as core features of the langage?
Jul 30 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Jul 26 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jul 26 2012
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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. Bye, bearophile
Jul 26 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 27-07-2012 14:56, Stuart wrote:
 On Friday, 27 July 2012 at 02:41:21 UTC, Nick Sabalausky wrote:
 On Fri, 27 Jul 2012 04:09:36 +0200
 "Stuart" <stugol gmx.com> wrote:

 I can't think of ANY situation where goto would be the only viable
 option.

Duff's device.

According to Wikipedia, Duff's device (about which, until just now, I knew nothing) can be implemented without goto. Then again, this might be due to "features" of C++ that are not present in D. In any case, isn't it the job of the compiler to unroll loops? Why should the coder have to do this himself? Unless of course he's using a thin shitty wrapper over assembly language that claims falsely to be a high-level language - i.e. C.

It was a high-level language at the time it was created. -- Alex Rønne Petersen alex lycus.org http://lycus.org
Jul 27 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 27-07-2012 20:50, Stuart wrote:
 On Friday, 27 July 2012 at 15:27:58 UTC, Alex Rønne Petersen wrote:
 On 27-07-2012 14:56, Stuart wrote:

 In any case, isn't it the job of the compiler to unroll loops? Why
 should the coder have to do this himself? Unless of course he's using a
 thin shitty wrapper over assembly language that claims falsely to be a
 high-level language - i.e. C.

It was a high-level language at the time it was created.

Quite possibly. But the definition of "high level" has since changed, and C no longer qualifies. Yet proponents of C/C++ continue to froth at the mouth and claim it's a decent language. Why is D so awesome? Because it's not C.

In all fairness, I think C still has its place. The advantage of writing software in C is that when you want to port it to a new platform/architecture, there will almost always be a C compiler available. This isn't the case for D yet - but hopefully will be in the future. But note, even then, that D only targets 32-bit architectures and up, while C can handle 16-bit architectures. -- Alex Rønne Petersen alex lycus.org http://lycus.org
Jul 27 2012
next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Stuart" <stugol gmx.com> wrote in message 
news:vjaspnvbihpgvxgqmccr forum.dlang.org...
 On Saturday, 28 July 2012 at 02:38:47 UTC, Jonathan M Davis wrote:
 On Saturday, July 28, 2012 04:31:40 Alex Rnne Petersen wrote:
 But note, even then, that D only targets 32-bit architectures
 and up, while C can handle 16-bit architectures.

True, but I'm kind of shocked that anything 16-bit even still exists. _32-bit_ is on its way out. I thought that 16-bit was dead _years_ ago. I guess that some embedded stuff must use it. But really, I wouldn't expect the lack of 16- bit support to be much of an impediment - if any at all - and in the long run, it'll mean absolutely nothing.

Embedded systems mostly use Java now in any case, as I understand it.

Your understanding is obviously quite limited.
Jul 28 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-07-28 09:52, Stuart wrote:

 Ah. So, in essence, C has a purpose because [a] it supports incredibly
 obsolete hardware that nobody in their right mind would be using; and
 [b] nobody's ported D to MacOS (or whatever) yet.

If you refer to Mac OS X, I use D on it every day. If you're actually referring to MacOS then who cares, it's a dead operating system and has been for at least ten years. -- /Jacob Carlborg
Jul 28 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 28-07-2012 14:41, Stuart wrote:
 On Saturday, 28 July 2012 at 11:43:14 UTC, Jacob Carlborg wrote:
 On 2012-07-28 09:52, Stuart wrote:

 Ah. So, in essence, C has a purpose because [a] it supports incredibly
 obsolete hardware that nobody in their right mind would be using; and
 [b] nobody's ported D to MacOS (or whatever) yet.

If you refer to Mac OS X, I use D on it every day. If you're actually referring to MacOS then who cares, it's a dead operating system and has been for at least ten years.

Which only reinforces my point that C is redundant.

See Paulo's post. -- Alex Rønne Petersen alex lycus.org http://lycus.org
Jul 28 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/28/12 4:26 AM, Nick Sabalausky wrote:
 God I hope that's not true. Using a VM on a low-power system is just so
 rediculously *wrong* it should be a crime.

Isn't Android standardizing on Java? Andrei
Jul 28 2012
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 28-07-2012 15:42, Andrei Alexandrescu wrote:
 On 7/28/12 4:26 AM, Nick Sabalausky wrote:
 God I hope that's not true. Using a VM on a low-power system is just so
 rediculously *wrong* it should be a crime.

Isn't Android standardizing on Java? Andrei

Yes (see second paragraph of Nick's post). -- Alex Rnne Petersen alex lycus.org http://lycus.org
Jul 28 2012
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/29/12 4:34 AM, Russel Winder wrote:
 Primitive types are now effectively deprecated in Java, and this is
 likely a deprecation which will actually lead to a removal – unlike
 everything else in Java that has been deprecated which is still there.

That's interesting. Do you have references to some related resources? Thanks, Andrei
Jul 29 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-07-29 15:10, Minas Mina wrote:
 The only thing Java is good for is portability. And its standard library
 is very good too.

 However the language as it is, really sucks in my opinion. I mean,
 there's no way to change the value of a primitive type passed to a
 method? Come on.

There are many other languages available on the JVM platform. Scala for example. -- /Jacob Carlborg
Jul 29 2012
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/27/2012 7:38 PM, Jonathan M Davis wrote:
 True, but I'm kind of shocked that anything 16-bit even still exists. _32-bit_
 is on its way out. I thought that 16-bit was dead _years_ ago. I guess that
 some embedded stuff must use it. But really, I wouldn't expect the lack of 16-
 bit support to be much of an impediment - if any at all - and in the long run,
 it'll mean absolutely nothing.

For those who may not realize it, C++ is simply not suitable for 16 bit systems either. It theoretically supports 16 bit code, but in practice, full C++ will never work on them. So, you might ask, why was 16 bit C++ popular on 16 bit MSDOS in the 80's? That was C++ before exception handling and RTTI, both of which were unimplementable on 16 bit machines. (Yes, you could do it, but the result was practically unusable.) C and 16 bits go reasonably well together, but even so, the best programs were written all in asm.
Jul 29 2012
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/28/12 10:13 AM, Philippe Sigaud wrote:
 "bearophile" <bearophileHUGS lycos.com <mailto:bearophileHUGS lycos.com>>
  > 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.

 Do you happen to still have the code, by any chance? I think Phobos
 could use a std.fsm, to automatically generate FSM at compile-time
 (using lots of gotos :) ).

I've always found it difficult to generate FSMs from textual specs (as opposed to regexen or pretty images). Problem is you need to name your states, and in many FSMs intermediate states are not meaningful. Andrei
Jul 28 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
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). 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.
Jul 26 2012
prev sibling next sibling parent reply "F i L" <witte2008 gmail.com> writes:
Stuart wrote:
 Why does D have GOTO? I haven't used GOTO in over a decade, 
 because it's truly evil.

There are some who use it, and I imagine it's in there for their benefit. Thought I agree, I've rarely ever used goto.
 I have a couple of questions though. Why does the VisualD 
 plugin crash Visual Studio if I double-click a .sln file in 
 Windows Explorer? I mean, every single time? I'm using VS2010 
 on Windows 7 64-bit; and the problem only happens with D 
 projects, and only when loading an .sln file by association. If 
 I load VS and use the menu to open the solution, it works fine.

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.
 One thing I really think D ought to have is iterators, like 
 VB.NET and C# have. Trust me, they're really damn useful. Any 
 chance of them being implemented? The implementation of .NET 
 iterators is well-known and fairly straightforward; all we need 
 is compiler support.

Ranges are a very good alternative. However there's also D-Collections (http://www.dsource.org/projects/dcollections/) which supports a "Cursor" type, similar to iterators (to my knowledge). The biggest issue with D's collections IMO, are std.container's lack of useful structures. For instance there's no standard Doubly-Linked-List type. However, I understand that Andrei is currently working on a new allocation system, which should pave the way to a new standard collection lib.
Jul 26 2012
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 27.07.2012 04:05, Stuart wrote:
 On Friday, 27 July 2012 at 01:25:45 UTC, F i L wrote:

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

I tried to reproduce it, but for my solutions it works. I suspect it might have to do with your window layout. You might try to remove the solution options file (.suo) and see if it still crashes. Please create a ticket here: http://www.dsource.org/projects/visuald/newticket
 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?

The intellisense part is rather unfinished. it needs full semantic analysis, and that is almost as complex as a D compiler. I'm not really sure what you mean by "Blows" or "hit-and-miss", though. Rainer
Jul 27 2012
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 27.07.2012 15:20, Stuart wrote:
 On Friday, 27 July 2012 at 12:56:12 UTC, Rainer Schuetze wrote:
 Incidentally, none of that answered my original question, which is
 "why does VisualD crash?"

I tried to reproduce it, but for my solutions it works. I suspect it might have to do with your window layout. You might try to remove the solution options file (.suo) and see if it still crashes. Please create a ticket here: http://www.dsource.org/projects/visuald/newticket

Yes, removing the .suo file fixed the problem. I don't know why. I will create a ticket. Would submitting my .suo file help?

Yes, please do. Even though it is system specific, maybe I can find some information.
 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?

The intellisense part is rather unfinished. it needs full semantic analysis, and that is almost as complex as a D compiler. I'm not really sure what you mean by "Blows" or "hit-and-miss", though.

Well, it doesn't work in a lot of cases. A lot of times I'll press . or ( and get nothing at all.

Do you have semantic analysis enabled in the intellisense options? That is needed for '.' producing sensible results. In contrast '(' uses the compiler generated browse information. I guess that should be consolidated...
Jul 28 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jul 26 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
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).

 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?
Jul 26 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
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.
Jul 26 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
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?
Jul 26 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
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?
Jul 26 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, July 27, 2012 03:58:52 Stuart wrote:
 On Friday, 27 July 2012 at 00:23:54 UTC, Ali =C3=87ehreli wrote:
 Welcome! :)
=20
 GOTO is evil; 'goto' is not! ;) goto makes switch-case

 statements safer in D:

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 dealin= g with a=20 systems language. Particularly when dealing with low level code, gotos = can be=20 very useful. Granted, if code is littered with them, there's no questio= n that=20 there's a problem, but there are definitely cases where using goto actu= ally=20 improves code - especially when efficiency is a major concern. They're = just=20 relatively rare. Other, good, language constructs make them far less ne= cessary=20 than they once were. - Jonathan M Davis
Jul 26 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
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?
Jul 26 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
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?
Jul 26 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jul 26 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, July 27, 2012 04:13:09 Stuart wrote:
 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?

We have library documentation on dlang.org: http://dlang.org/phobos/std_typecons.html#scoped - Jonathan M Davis
Jul 26 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 02:13:19 UTC, Jonathan M Davis wrote:
 It's inherently unsafe. What happens if you returned a 
 reference to foo from someFunc?

Good answer. I didn't think of that.
 scope on local variables is going away for pretty much the same 
 reason that delete is.

Delete is going away too? Damn. Then again, I guess I'm still thinking in C++ terms. I need to stop doing that. I'm having difficulty thinking in terms of D. It looks like C++, it compiles to native code (unlike .NET), therefore I need to manage memory myself... ;) I'll get the hang of it eventually.
Jul 26 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 02:17:22 UTC, Jonathan M Davis wrote:
 
 We have library documentation on dlang.org:

 http://dlang.org/phobos/std_typecons.html#scoped

Wow! That's a lot of information. Better get reading it, then. Thanks.
Jul 26 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 27 Jul 2012 04:09:36 +0200
"Stuart" <stugol gmx.com> wrote:

 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?

Duff's device. Goto certainly should not be used (except for "goto case") in the vast majority of cases. And it is indeed extremely rare to find goto used in D code. Plus having it in existence doesn't really cause problems - only abusing it causes problems and but nobody really abuses goto anymore anyway. But there are some rare controlled cases (like duff's device, or porting old C code that might use it) where some low-level programmers do consider it to be useful (whether right or wrong). So it's there if for whatever reason you happen to need it, otherwise it just stays out of the way and doesn't bother anybody.
Jul 26 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 27 Jul 2012 04:05:48 +0200
"Stuart" <stugol gmx.com> wrote:
 
 Incidentally, none of that answered my original question, which 
 is "why does VisualD crash?"
 

You should probably ask over at wherever VisualD's site is. I don't personally use big IDEs much (I use Programmer's Notepad 2 for my D work) and in fact many of us here (though certainly not all) actually just use relatively plain highlighting text editors and the command line. So it'll probably be better to just ask the VisualD people directly.
Jul 26 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, July 27, 2012 04:27:36 Stuart wrote:
 On Friday, 27 July 2012 at 02:13:19 UTC, Jonathan M Davis wrote:
 It's inherently unsafe. What happens if you returned a
 reference to foo from someFunc?

Good answer. I didn't think of that.
 scope on local variables is going away for pretty much the same
 reason that delete is.

Delete is going away too? Damn. Then again, I guess I'm still thinking in C++ terms. I need to stop doing that. I'm having difficulty thinking in terms of D. It looks like C++, it compiles to native code (unlike .NET), therefore I need to manage memory myself... ;) I'll get the hang of it eventually.

In general, you should just let the GC do its thing. Then when you have portions of your code that need to be optimized, _then_ you worry about managing GC memory or using malloc and free instead or whatever it takes to make it properly efficient. Coding in a way that reduces unnecessary heap allocations is also good, but if you're worrying about when you need to free GC-allocated resources, then you're likely going about things wrong, since that's what the GC is for. - Jonathan M Davis
Jul 26 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 27 July 2012 at 02:41:21 UTC, Nick Sabalausky wrote:
 Plus having it in existence doesn't really cause problems - 
 only abusing it causes problems and but nobody
 really abuses goto anymore anyway.

goto in C and descendants is an entirely different animal than the goto that people would abuse anyway. The fact that it is scoped to functions and must go to explicit labels limits the potential for abuse that made it notorious.
Jul 26 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 27 Jul 2012 03:56:32 +0200
"Stuart" <stugol gmx.com> wrote:

 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).

 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?

D can do that with either fibers or opApply. I've explored all the different approaches in this admittedly not-so-well-written article: https://semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration Note, however, that fibers (while far, *far* faster than threads) are still too heavyweight to be recommended for most generator functions (as I learned after writing that article). So if you want a generator, you should use opApply instead of fibers or my "InputVisitor" trick. I'd recommend using Adam's trick mentioned in the second "Update" at the bottom of the article.
Jul 26 2012
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--047d7b60399c2544e904c5c6e904
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jul 26, 2012 at 7:56 PM, Stuart <stugol gmx.com> wrote:

 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<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<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?

D equivalent: iota(0, int.max, 2).map!(a => /* do something with even numbers */)(); --047d7b60399c2544e904c5c6e904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jul 26, 2012 at 7:56 PM, Stuart <span dir=3D"ltr">&lt;<a href=3D"ma= ilto:stugol gmx.com" target=3D"_blank">stugol gmx.com</a>&gt;</span> wrote:= <br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Friday, 27 July 2012 at 00:10:31 UTC, Brad Anderson wr= ote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> D uses ranges instead of iterators. You can read more about them here: <a h= ref=3D"http://ddili.org/ders/d.en/ranges.html" target=3D"_blank">http://ddi= li.org/ders/d.en/<u></u>ranges.html</a><br> <br> I find ranges to be a vast improvement over iterators personally (I use ite= rators extensively in C++ for my job and lament not having ranges regularly= ).<br> <br> <br> </blockquote></div><div class=3D"im"> On Friday, 27 July 2012 at 00:17:21 UTC, H. S. Teoh wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> D has something far superior: ranges.<br> <br> =A0 =A0 =A0 =A0 <a href=3D"http://www.informit.com/articles/printerfriendly= .aspx?p=3D1407357&amp;rll=3D1" target=3D"_blank">http://www.informit.com/<u=
</u>articles/printerfriendly.aspx?<u></u>p=3D1407357&amp;rll=3D1</a><br>

Even better, they are completely implemented in the library. No<br> unnecessary language bloat just to support them.<br> </blockquote> <br></div> I&#39;m not very well up on ranges. I understand the general [1 ... 6] type= of ranges, but I really don&#39;t see how custom range functions could be = as useful as the Yield support in <a href=3D"http://VB.NET" target=3D"_blan= k">VB.NET</a>. I mean, here&#39;s an example of an iterator in <a href=3D"h= ttp://VB.NET" target=3D"_blank">VB.NET</a>:<br> <br> =A0 =A0Public Function InfiniteSequence(StartValue As Int32, Step As Int32)= As IEnumerable(Of Int32)<br> =A0 =A0 =A0 Do<br> =A0 =A0 =A0 =A0 =A0Yield StartValue<br> =A0 =A0 =A0 =A0 =A0StartValue +=3D Step<br> =A0 =A0 =A0 Loop<br> =A0 =A0End Function<br> <br> Usage:<br> <br> =A0 =A0For Each N in InfiniteSequence(2, 2)<br> =A0 =A0 =A0 ... do something with this sequence of even numbers ...<br> =A0 =A0Next<br> <br> Notice how this function is written like a synchronous loop, yet yields a l= azy-initialised infinite sequence of numbers. Granted, it&#39;s not a parti= cularly useful example, but trust me: Iterators and Yield in .NET is *reall= y* damn useful. I would go so far as to say it was one of the language&#39;= s best features.<br> <br> I may be wrong, but it looks like I&#39;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?<br> </blockquote></div><br><div>D equivalent: iota(0, int.max, 2).map!(a =3D&gt= ; /* do something with even numbers */)();</div> --047d7b60399c2544e904c5c6e904--
Jul 26 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 26 Jul 2012 17:23:53 -0700
Ali =C7ehreli <acehreli yahoo.com> wrote:
  > iterators
=20
 Here is a paper that compares different approaches:
=20
    http://www.informit.com/articles/printerfriendly.aspx?p=3D1407357
=20

As great as Andrei's article is, this makes me think: We need a short article with a simple little example that demonstrates *how* D's ranges really do kick iterators' asses. Any good ideas?
Jul 26 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 26 Jul 2012 21:00:12 -0600
Brad Anderson <eco gnuk.net> wrote:

 On Thu, Jul 26, 2012 at 7:56 PM, Stuart <stugol gmx.com> wrote:
 
 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<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<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?

D equivalent: iota(0, int.max, 2).map!(a => /* do something with even numbers */)();

Or: foreach(i; iota(0, int.max, 2)) { // stuff } Or (not as fast, but more flexible): foreach(i; iota(0, int.max).filter!(a => a%2==0)()) { // stuff } Or: foreach(i; recurrence!(a => a[n-1] + 2)(0)) { // stuff } Etc...
Jul 26 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 26 Jul 2012 23:21:54 -0400
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:

 On Thu, 26 Jul 2012 21:00:12 -0600
 Brad Anderson <eco gnuk.net> wrote:
 
 On Thu, Jul 26, 2012 at 7:56 PM, Stuart <stugol gmx.com> wrote:
 
 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<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<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?

D equivalent: iota(0, int.max, 2).map!(a => /* do something with even numbers */)();

Or: foreach(i; iota(0, int.max, 2)) { // stuff } Or (not as fast, but more flexible): foreach(i; iota(0, int.max).filter!(a => a%2==0)()) { // stuff } Or: foreach(i; recurrence!(a => a[n-1] + 2)(0))

Erm, should be: foreach(i; recurrence!"a[n-1] + 2"(0))
 {
 	// stuff
 }
 
 Etc...
 
 

Jul 26 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 27 Jul 2012 04:55:30 +0200
"Adam D. Ruppe" <destructionator gmail.com> wrote:
 
 The fact that [goto] is scoped to functions

I didn't think that was true in C? It's certainly true in D, anyway.
Jul 26 2012
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2012 4:59 PM, Stuart wrote:
 Why does D have GOTO? I haven't used GOTO in over a decade, because it's truly
 evil.

The road to hell is paved with good intentions, so we felt it necessary to add a touch of eeeevil.
 One thing I really think D ought to have is iterators,

We call them "ranges" in D. :-) I think you'll like them.
Jul 26 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, July 27, 2012 08:36:17 Jacob Carlborg wrote:
 On 2012-07-27 02:25, 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.

"scope" on class declarations as well.

I didn't even know that you could do that, and I have no idea what that would do. - Jonathan M Davis
Jul 26 2012
prev sibling next sibling parent Stefan Scholl <stesch no-spoon.de> writes:
Stuart <stugol gmx.com> wrote:
 Why does D have GOTO? I haven't used GOTO in over a decade, 
 because it's truly evil.

Dogmas are evil.
Jul 27 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 27 Jul 2012 05:24:08 +0200, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:

 foreach(i; recurrence!(a => a[n-1] + 2)(0))

Erm, should be: foreach(i; recurrence!"a[n-1] + 2"(0))

or just foreach(i; recurrence!((a,n) => a[n-1] + 2)(0)) -- Simen
Jul 27 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, July 27, 2012 09:27:55 Simen Kjaeraas wrote:
 On Fri, 27 Jul 2012 05:24:08 +0200, Nick Sabalausky
 
 <SeeWebsiteToContactMe semitwist.com> wrote:
 foreach(i; recurrence!(a => a[n-1] + 2)(0))

Erm, should be: foreach(i; recurrence!"a[n-1] + 2"(0))

or just foreach(i; recurrence!((a,n) => a[n-1] + 2)(0))

Yeah. You can do a lot with infinite and generative ranges. That's one of the reasons that they're so much better than iterators (though it sounds like you can do some interesting things with C# interators that you can't do with most other types of iterators). - Jonathan M Davis
Jul 27 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 27 Jul 2012 06:36:57 +0200, Alex R=C3=B8nne Petersen <alex lycus=
.org>  =

wrote:

 Jumping over initialization isn't as problematic in D because variable=

 are guaranteed to have a default initialization value (if not  =

 initialized to void).

And how is that supposed to work, when you just skipped that piece of co= de?
 It's worse in languages like C where the value of variables would be
 undefined.

It's *better* in languages like C, where the value of the variable would= be undefined anyway, so you'd have to deal with that anyway. I would go as far as to say this is part of the reason this is in the sp= ec: "It is illegal for a GotoStatement to be used to skip initializations."[= 1] [1]: http://dlang.org/statement.html#GotoStatement -- = Simen
Jul 27 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 27 Jul 2012 08:31:36 +0200
Jacob Carlborg <doob me.com> wrote:
 
 Note that iterators in .NET and C++ are a bit different. .NET has 
 language support with the "yield" keyword.
 

I wonder how that works under the hood. Like, if it's somewhat similar to opApply. Or maybe more like an Asm-style "messin' with the call stack's return addresses". I would hope it wouldn't involve fiber context switches, unless they're somehow much faster than D fiber context switches (which would seem weird, being in a VM).
Jul 27 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 27 Jul 2012 09:42:37 +0200, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:

 On Fri, 27 Jul 2012 08:31:36 +0200
 Jacob Carlborg <doob me.com> wrote:
 Note that iterators in .NET and C++ are a bit different. .NET has
 language support with the "yield" keyword.

I wonder how that works under the hood. Like, if it's somewhat similar to opApply. Or maybe more like an Asm-style "messin' with the call stack's return addresses". I would hope it wouldn't involve fiber context switches, unless they're somehow much faster than D fiber context switches (which would seem weird, being in a VM).

The compiler generates a state-machine for you. http://blogs.msdn.com/b/wesdyer/archive/2007/03/23/all-about-iterators.aspx -- Simen
Jul 27 2012
prev sibling next sibling parent "Christof Schardt" <christof schardt.info> writes:
"Stuart" <stugol gmx.com> schrieb im Newsbeitrag 
news:pzhwiumzhktkzdmvlpig forum.dlang.org...
 Why does D have GOTO? I haven't used GOTO in over a decade, because it's 
 truly evil.

"By the way, if you don't like |goto| statements, don't read this. (And don't read any other programs that simulate multistate systems.) \smallskip\rightline{--- Don Knuth, September 1998}" [1] http://sunburn.stanford.edu/~knuth/programs.html#advent
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 02:41:21 UTC, Nick Sabalausky wrote:
 On Fri, 27 Jul 2012 04:09:36 +0200
 "Stuart" <stugol gmx.com> wrote:

 I can't think of ANY situation where goto would be the only 
 viable option.

Duff's device.

According to Wikipedia, Duff's device (about which, until just now, I knew nothing) can be implemented without goto. Then again, this might be due to "features" of C++ that are not present in D. In any case, isn't it the job of the compiler to unroll loops? Why should the coder have to do this himself? Unless of course he's using a thin shitty wrapper over assembly language that claims falsely to be a high-level language - i.e. C.
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 02:48:36 UTC, Jonathan M Davis wrote:
 I'm having difficulty thinking in terms of D. It looks like 
 C++,
 it compiles to native code (unlike .NET), therefore I need to
 manage memory myself... ;)
 
 I'll get the hang of it eventually.

In general, you should just let the GC do its thing.

Yeah, I know. I was just explaining how I find myself thinking in terms of C++ because the syntax (and compilation) is very similar.
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 03:00:25 UTC, Brad Anderson wrote:
 D equivalent: iota(0, int.max, 2).map!(a => /* do something 
 with even numbers */)();

I think you're missing the point. The purpose isn't to generate a sequence of numbers, but to illustrate how the Yield keyword is used in VB.NET. Sure, getting a sequence of numbers may be straightforward, but what about a lazy-populated list of all files on a computer? That can be done using Yield - and more importantly, WRITTEN like a normal synchronous function. Let's see you do that with map.
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 06:36:17 UTC, Jacob Carlborg wrote:
 On 2012-07-27 02:25, Jonathan M Davis wrote:

 scope on local variables is going to be deprecated, because 
 it's unsafe. scope on function parameters and scope statements

"scope" on class declarations as well.

Huh? If you deprecate scoped locals, you have to deprecate scope classes, because the latter means "must be scoped local when used". Yes?
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 07:41:50 UTC, Simen Kjaeraas wrote:
 On Fri, 27 Jul 2012 06:36:57 +0200, Alex Rønne Petersen 
 <alex lycus.org> wrote:

 Jumping over initialization isn't as problematic in D because 
 variables are guaranteed to have a default initialization 
 value (if not initialized to void).

And how is that supposed to work, when you just skipped that piece of code?

A very good question.
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 07:42:51 UTC, Nick Sabalausky wrote:
 On Fri, 27 Jul 2012 08:31:36 +0200
 Jacob Carlborg <doob me.com> wrote:
 
 Note that iterators in .NET and C++ are a bit different. .NET 
 has language support with the "yield" keyword.
 

I wonder how that works under the hood.

It's well-documented. The compiler creates an anonymous class with a state machine. It's really useful.
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 12:56:12 UTC, Rainer Schuetze wrote:
 Incidentally, none of that answered my original question, 
 which is "why does VisualD crash?"

I tried to reproduce it, but for my solutions it works. I suspect it might have to do with your window layout. You might try to remove the solution options file (.suo) and see if it still crashes. Please create a ticket here: http://www.dsource.org/projects/visuald/newticket

Yes, removing the .suo file fixed the problem. I don't know why. I will create a ticket. Would submitting my .suo file help?
 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?

The intellisense part is rather unfinished. it needs full semantic analysis, and that is almost as complex as a D compiler. I'm not really sure what you mean by "Blows" or "hit-and-miss", though.

Well, it doesn't work in a lot of cases. A lot of times I'll press . or ( and get nothing at all.
Jul 27 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 27 July 2012 at 03:26:22 UTC, Nick Sabalausky wrote:
 I didn't think that was true in C? It's certainly true in D, 
 anyway.

It is, C and D have more or less the same goto rules. goto.c: === void a() { goto cool; } void main() { a(); cool: ; } === $ gcc goto.c goto.c: In function a: goto.c:2: error: label cool used but not defined While you can still kinda sorta spaghetti in C, the fact that it is limited to a function makes it much easier to follow. There's only one function to look at, not the whole program. The requirement of a label is important too, since any particular line of code can't be a comes-from point; unless there is a label there, you can be pretty confident that the line before is actually run before.
Jul 27 2012
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 27 Jul 2012 07:22:49 +0000 (UTC)
schrieb Stefan Scholl <stesch no-spoon.de>:

 Stuart <stugol gmx.com> wrote:
 Why does D have GOTO? I haven't used GOTO in over a decade,=20
 because it's truly evil.

Dogmas are evil.

+1 I clicked through a few responses, and this one I liked most. It feels like GOTO was stigmatized during the days when if/for/while appear= ed to replace its omni presence. Back than it was ok to shout and scream ab= out every use, but today it is more likely that people who use goto, know w= hat they are doing. I use it in switch-case for "preprocessing", where there may be 3 cases tha= t all end at case 3:, but case 1 and 2 need something done first. Now you c= an just goto case 3 at the end of 1 & 2. Also when I have a sequence of steps to be done and some steps may jump bac= k a few steps, I prefer labels with good names + goto, over blocks of for/w= hile/if, which distract from the sequential nature of the code. It's funny how I felt a bit offended by "Why does D have GOTO? [=E2=80=A6] = it's truly evil." :D --=20 Marco
Jul 27 2012
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Friday, 27 July 2012 at 01:45:35 UTC, Jonathan M Davis wrote:
 It's a useful construct when used
 properly. It just shouldn't be used when there are better 
 alternatives.

Hmm... do you have a use case besides Duff's device and porting legacy code?
Jul 27 2012
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Friday, 27 July 2012 at 14:03:05 UTC, Marco Leise wrote:
 Also when I have a sequence of steps to be done and some steps 
 may jump back a few steps, I prefer labels with good names + 
 goto, over blocks of for/while/if, which distract from the 
 sequential nature of the code.

Huh, but such code is not sequential, it's spaghetti.
Jul 27 2012
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Fri, 27 Jul 2012 15:09:14 +0100, Kagamin <spam here.lot> wrote:

 On Friday, 27 July 2012 at 14:03:05 UTC, Marco Leise wrote:
 Also when I have a sequence of steps to be done and some steps may jump  
 back a few steps, I prefer labels with good names + goto, over blocks  
 of for/while/if, which distract from the sequential nature of the code.

Huh, but such code is not sequential, it's spaghetti.

Spaghetti goes in many directions, the code above always flows downhill but sometimes jumps/loops back up. As long as the jumps are in one direction and not both, it's typically easy enough to follow. IMO, goto is a tool like any other, in the wrong hands it can make bad code, in the right hands, used sparingly and only when it makes code easier to follow it's the right tool and avoiding it due to dogma is just plain silly. My main use in the past has been to jump to clean up code, which is not always necessary with D as we have finally and scope(exit). If I have the choice between a loop construct which only ever executes once with 'break' to simulate goto vs using goto, I will chose the latter because it's clearer what the intent of the code is, it actually makes the code cleaner and easier to follow. I tend to code in the style of check for error and fail/return/exit vs layered scopes (if inside if inside if ..) because the flatter the code the easier I find it to reason about code paths and logic, goto can help to keep a piece of code flat and make it easier to reason about. I almost always use goto to jump down a function, and almost never up. Loop constructs are with 'continue' are a better match for the latter. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Jul 27 2012
prev sibling next sibling parent "Graham Fawcett" <fawcett uwindsor.ca> writes:
On Friday, 27 July 2012 at 13:10:46 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 03:00:25 UTC, Brad Anderson wrote:
 D equivalent: iota(0, int.max, 2).map!(a => /* do something 
 with even numbers */)();

I think you're missing the point. The purpose isn't to generate a sequence of numbers, but to illustrate how the Yield keyword is used in VB.NET. Sure, getting a sequence of numbers may be straightforward, but what about a lazy-populated list of all files on a computer? That can be done using Yield - and more importantly, WRITTEN like a normal synchronous function. Let's see you do that with map.

That's easy: import std.file, std.stdio, std.algorithm; void main() { static BASE_DIR = "/path/to/base"; static SIZE_CUTOFF = 100; // 'entries' is an InputRange auto entries = dirEntries(BASE_DIR, SpanMode.breadth); // filter the range; map to a range of filenames auto smallFileNames = entries .filter!(e => e.size < SIZE_CUTOFF) .map!(e => e.name); // note, the filesystem hasn't been touched yet; // we have full laziness. foreach(name; smallFileNames) writeln(name); } And check out this example, where you can process the entries in parallel: http://dlang.org/phobos/std_file.html#dirEntries You should spend some time using ranges before drawing conclusions about them. Graham
Jul 27 2012
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
On Jul 27, 2012, at 8:05 AM, Andrei Alexandrescu =
<SeeWebsiteForEmail erdani.org> wrote:

 On 7/27/12 9:10 AM, Stuart wrote:
 On Friday, 27 July 2012 at 03:00:25 UTC, Brad Anderson wrote:
=20
 D equivalent: iota(0, int.max, 2).map!(a =3D> /* do something with =



 numbers */)();

I think you're missing the point. The purpose isn't to generate a sequence of numbers, but to illustrate how the Yield keyword is used =


 VB.NET. Sure, getting a sequence of numbers may be straightforward, =


 what about a lazy-populated list of all files on a computer? That can =


 done using Yield - and more importantly, WRITTEN like a normal
 synchronous function. Let's see you do that with map.

I think it's fair to say yield makes some things easier to do than =

course, ideally you'd have both, but for the time being we don't have = yield. core.thread.Fiber has yield and has been used as the basis for this = style of iterator. See Mikola Lysenko's talk from the D conference a = few years ago.=
Jul 27 2012
parent FeepingCreature <default_357-line yahoo.de> writes:
On 07/27/12 21:22, Stuart wrote:
 On Friday, 27 July 2012 at 19:17:10 UTC, H. S. Teoh wrote:
 Nevertheless, D has gotten to the point where it's powerful enough that most
feature requests can be implemented in a
 library rather than as a language extension.

How could Yield be implemented as a library feature? Something like: return ITERATOR( { ...setup code ... }, { ...loop body code... }) ? I don't see how that would work.

The threading "yield" and the iterator "yield" are actually strongly related. By yielding a coroutine, you can effectively suspend a routine and resume it later. Let me give you an example: int delegate() genEvenNumbers() { // not actual api return startCoroutineIterator!int((void delegate(int) yield) { for (int i = 0; true; i++) if (i % 2 == 0) yield(i); }); } // long form of the above function, so you can see how you gain iterator-style behavior via coroutines int delegate() genEvenNumbers() { int* resultp = new int; void cofun(void delegate(int) yield) { for (int i = 0; true; i++) if (i % 2 == 0) yield(i); } // still not actual api auto coroutine = new Coroutine(1024*1024 /* stack size */); // set the 'main function' of the coroutine coroutine.fun = { // yield, when called, will cause the coroutine to suspend and run() to return cofun((int i) { *resultp = i; coroutine.yield(); }); }; // run the coroutine up to the next yield, then return yielded value return { coroutine.run(); return *resultp; }; } You can fully implement Coroutine as a library, provided you're somewhat confident with x86 assembly and stack frame layouts.
Jul 30 2012
prev sibling next sibling parent reply "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Thursday, 26 July 2012 at 23:59:13 UTC, Stuart wrote:

 How good is the Entice Designer? I'd like to write some GUI 
 apps in D, but I need to know that the designer won't fall over 
 halfway through; and I'll be damned if I'm writing my GUI code 
 by hand. Even MFC programmers have a "dialog designer".

Entice is pretty good, but I can't comment much on its capability as I've only used it to get me some code started for writing a gui. And while it is no where near VS, I don't really like the VS designer so I guess you can take my opinion of GUI designers with an atom of salt. Entice also hasn't gotten a much/any updates for D2 code generation, so it is likely to fall down at some point.
Jul 27 2012
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 28-Jul-12 00:42, Nick Sabalausky wrote:
 On Fri, 27 Jul 2012 17:52:27 +0200
 "Jesse Phillips" <Jessekphillips+D gmail.com> wrote:

 so I guess you can take my opinion of GUI designers with
 an atom of salt.

<annoyingly pedantic>It would have to be a molecule. Try to take an atom of salt and you'll either get a poisonous gas, or something that goes boom in contact with water.</annoyingly pedantic>

Well Na isn't much of boom. K will do much better :)
 Chemistry is really weird...

...though Physics is no less so once you are past the Newton mechanics. -- Dmitry Olshansky
Jul 27 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, July 27, 2012 16:05:07 Kagamin wrote:
 On Friday, 27 July 2012 at 01:45:35 UTC, Jonathan M Davis wrote:
 It's a useful construct when used
 properly. It just shouldn't be used when there are better
 alternatives.

Hmm... do you have a use case besides Duff's device and porting legacy code?

There's quite a bit of code out there which uses it to jump to a common set of error handling code, which can actually make functions cleaner in some cases. Phobos even does this a few places (though not many). Also, as I understand it, there are cases in low level code (where you need every cycle that you can get) that using a goto to get out of a section of code can be more efficient than getting out of it in the ways that you would more typically do. I haven't personally run into that sort of thing though, since I don't generally write code that low level. And just because you or I don't use it much, doesn't mean that people programming in other domains don't need it for use cases that we never run into. goto is just one of those things that a systems language is bound to have. - Jonathan M Davis
Jul 27 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Kagamin:

 Hmm... do you have a use case besides Duff's device and porting 
 legacy code?

To implement certain quick finite state machines, it's a quite important use case for me. At the moment I am even using computed gotos in GCC-C, for similar purposes. Bye, bearophile
Jul 27 2012
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Friday, 27 July 2012 at 13:10:46 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 03:00:25 UTC, Brad Anderson wrote:
 D equivalent: iota(0, int.max, 2).map!(a => /* do something 
 with even numbers */)();

I think you're missing the point. The purpose isn't to generate a sequence of numbers, but to illustrate how the Yield keyword is used in VB.NET. Sure, getting a sequence of numbers may be straightforward, but what about a lazy-populated list of all files on a computer? That can be done using Yield - and more importantly, WRITTEN like a normal synchronous function. Let's see you do that with map.

You wouldn't use map for that, that would be silly. Taking a look at DirIteratorImpl[1] in std.file suggest there is a lot of setup to navigate the filesystem on Windows. How does Yield help with that logic? 1. https://github.com/D-Programming-Language/phobos/blob/master/std/file.d#L2397 Seriously I'll take my composing ranges over iterators any day.
Jul 27 2012
prev sibling next sibling parent "David Piepgrass" <qwertie256 gmail.com> writes:
On Friday, 27 July 2012 at 01:56:33 UTC, Stuart wrote:
 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).

 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.

Yes, I think H. S. Teoh wrote what that without knowing what C#/VB iterators actually are. .NET has a concept of "enumerators" which are basically equivalent to D's "input ranges". Both enumerators and input ranges are easier to use and safer than C++ iterators. Neither enumerators nor input ranges require any language support to use, but both C# and D have syntactic sugar for them in the form of the foreach statement. Both C# and D input ranges can be infinite. C#/VB "iterators", however, are an additional syntactic sugar that transforms a function into a state machine that provides an enumerator (or "enumerable"). These are indeed very useful, and missing from D. Here is an example of an iterator that I updated today: public IEnumerable<IMapOverlay> Overlays() { foreach (var ps in _patterns) { yield return ps.RouteLine; yield return ps.PermShapes; if (ps.Selected) yield return ps.SelShapes; } } It does not work like opApply; the compiler creates a heap object that implements IEnumerable or IEnumerator (depending on the return value that you ask for -- it is actually IEnumerator that works like a forward ranges, but foreach only accepts IEnumerable, which is a factory for IEnumerators) In D you could use opApply to do roughly the same thing, but in that case the caller cannot treat the opApply provider like an ordinary collection (e.g. IIUC, the caller cannot use map or filter on the results).
Jul 27 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 27 Jul 2012 16:05:07 +0200, Kagamin <spam here.lot> wrote:

 Hmm... do you have a use case besides Duff's device and porting legacy  
 code?

I've used it once, when the other option was a pyramid of 15 if statements. Not saying it couldn't be done without, obviously, but it was clearly the better option. -- Simen
Jul 27 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 27 Jul 2012 18:15:45 +0200, Jesse Phillips  
<Jessekphillips+D gmail.com> wrote:

 Seriously I'll take my composing ranges over iterators any day.

Thing is, them C# iterators are a lot more like D input ranges (and sometimes forward ranges) than they are C++ iterators. Given that, they are as composable as D ranges. -- Simen
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 15:09:38 UTC, Graham Fawcett wrote:
 On Friday, 27 July 2012 at 13:10:46 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 03:00:25 UTC, Brad Anderson wrote:
 D equivalent: iota(0, int.max, 2).map!(a => /* do something 
 with even numbers */)();

I think you're missing the point. The purpose isn't to generate a sequence of numbers, but to illustrate how the Yield keyword is used in VB.NET. Sure, getting a sequence of numbers may be straightforward, but what about a lazy-populated list of all files on a computer? That can be done using Yield - and more importantly, WRITTEN like a normal synchronous function. Let's see you do that with map.

That's easy: [...elided code...] auto entries = dirEntries(BASE_DIR, SpanMode.breadth);

Ah, but that depends upon the pre-existence of the dirEntries() function. I think perhaps you're missing the point - which is that "Yield" allows you to WRITE a function synchronously which will then be executed lazily, as an iterator. What you have demonstrated there is USING a lazy function. How would I write, in D, a function that would lazily assemble some data and return it as a lazy collection? I mean, without calling existing lazy functions. Unless ranges (which I admit to knowing very little about) can do this, I respectfully request that Yield be supported in D.
 You should spend some time using ranges before drawing 
 conclusions about them.

Is there a good tutorial on them? I didn't see one on the website.
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 15:27:58 UTC, Alex Rønne Petersen 
wrote:
 On 27-07-2012 14:56, Stuart wrote:

 In any case, isn't it the job of the compiler to unroll loops? 
 Why
 should the coder have to do this himself? Unless of course 
 he's using a
 thin shitty wrapper over assembly language that claims falsely 
 to be a
 high-level language - i.e. C.

It was a high-level language at the time it was created.

Quite possibly. But the definition of "high level" has since changed, and C no longer qualifies. Yet proponents of C/C++ continue to froth at the mouth and claim it's a decent language. Why is D so awesome? Because it's not C.
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 15:42:27 UTC, Sean Kelly wrote:
 On Jul 27, 2012, at 8:05 AM, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 core.thread.Fiber has yield and has been used as the basis for 
 this style of iterator.  See Mikola Lysenko's talk from the D 
 conference a few years ago.

I think perhaps you are confusing two different meanings of yield. I am not talking about threading. The VB.NET "yield" and "iterator" keywords can be used just as well in a single-threaded application. http://mattmc3.blogspot.co.uk/2011/04/vbnet-finally-gets-yield-statement.html
Jul 27 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, July 27, 2012 20:47:32 Stuart wrote:
 On Friday, 27 July 2012 at 15:09:38 UTC, Graham Fawcett wrote:
 You should spend some time using ranges before drawing
 conclusions about them.

Is there a good tutorial on them? I didn't see one on the website.

There's not. There should be. But someone needs to write one. They're u= sed=20 heavily in Phobos and a fair bit is explained in the library docs, but = we=20 really need a general overview and explanation of the concept and how P= hobos=20 uses them. The best thing that we have at the moment is a chapter in a book on D t= hat Ali=20 =C3=87ehreli wrote in Turkish and has been translating to English. It's= freely=20 avaiable online: http://ddili.org/ders/d.en/ranges.html - Jonathan M Davis
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 16:15:46 UTC, Jesse Phillips wrote:
 Taking a look at DirIteratorImpl[1] in std.file suggest there 
 is a lot of setup to navigate the filesystem on Windows. How 
 does Yield help with that logic?

Well, off the top of my head, you could use something like: Public Iterator Function AllFiles(RootDirectory As String) As IEnumerable(Of String) Dim Roots As New Queue(Of String) From {RootDirectory} While Roots.Any Dim Root = Roots.Pop Roots.AddRange(IO.Directory.GetDirectories(Root)) For Each Filename in IO.Directory.GetFiles(Root) Yield Filename Next End While End Function
Jul 27 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, July 27, 2012 20:52:37 Stuart wrote:
 I think perhaps you are confusing two different meanings of
 yield. I am not talking about threading. The VB.NET "yield" and
 "iterator" keywords can be used just as well in a single-threaded
 application.

From what you've been saying, it sounds like yield is probably the equivalent 

somewhat more verbose. In most basic cases though, a function probably already exists in std.algorithm that will let you do what you want to do by only providing a lambda function rather than a new range. And the more complex cases have enough implementation that the boilerplate range type declarations are small in comparison. Maybe we _should_ look at providing a better mechanism for creating range types in-place at some point, but what we have - particularly with std.algorithm - is already quite powerful, and I rarely see the need (if ever) to declare a range in-place. Regardless, with where D is right now, there's no way that such a feature would be added the language itself any time soon. It's probably possible to provide a library solution though, where you just give lambda functions for empty, front, and popFront, which would make creating a basic input range in place quite easy. - Jonathan M Davis
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 16:28:50 UTC, Dmitry Olshansky wrote:
 But this advantage is unimportant since arbitrary deep 
 recursion is a security risk (especially for servers that 
 typically use threads with tiny stacks).

I would like to point out here that the example VB.NET code I just gave for lazy-populating a list of all files on a drive uses NO recursion whatsoever. Recursion isn't just a security risk - it's a performance hit as well.
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 19:03:34 UTC, Jonathan M Davis wrote:
 Regardless, with where D is right now, there's no way that such 
 a feature would be added the language itself any time soon.

What do you mean? Where *is* D at right now? Has development stopped? Is there a massive feature backlog?
Jul 27 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 16:28:50 UTC, Dmitry Olshansky wrote:
 But this advantage is unimportant since arbitrary deep 
 recursion is a security risk (especially for servers that 
 typically use threads with tiny stacks).

I would like to point out here that the example VB.NET code I just gave for lazy-populating a list of all files on a drive uses NO recursion whatsoever. Recursion isn't just a security risk - it's a performance hit as well.

Only in languages without tail call optimizations.
Jul 27 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 27, 2012 at 09:04:06PM +0200, Stuart wrote:
 On Friday, 27 July 2012 at 16:28:50 UTC, Dmitry Olshansky wrote:
But this advantage is unimportant since arbitrary deep recursion is a
security risk (especially for servers that typically use threads with
tiny stacks).

I would like to point out here that the example VB.NET code I just gave for lazy-populating a list of all files on a drive uses NO recursion whatsoever. Recursion isn't just a security risk - it's a performance hit as well.

I'm pretty sure Yield has a performance hit as well, 'cos it amounts to an implicit context-switch between two fibers. Once translated to the machine level, there is no such thing as yielding; you have to save your current state and return control to the caller, then recover your state when you get called again. Of course, from what I understand, C# runs on a VM, correct? If so, this performance hit is probably hidden in the VM overhead, since the VM is already keeping track of states anyway, so the cost of tracking multiple states is absorbed into the VM's overall overhead. So you probably won't _notice_ the cost, but it's definitely there. T -- People walk. Computers run.
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 19:09:27 UTC, Paulo Pinto wrote:
 On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
 Recursion isn't just a security risk - it's a performance hit 
 as well.

Only in languages without tail call optimizations.

Which is pretty much all of them. Scheme does it, and probably HOPE too; but bugger-all you could write a real program in, like .NET or C++. I mean, we're in bloody FORTRAN territory here. What use is that for writing Windows applications? Does D have tail call optimisation?
Jul 27 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 27, 2012 at 09:09:25PM +0200, Stuart wrote:
 On Friday, 27 July 2012 at 19:03:34 UTC, Jonathan M Davis wrote:
Regardless, with where D is right now, there's no way that such a
feature would be added the language itself any time soon.

What do you mean? Where *is* D at right now? Has development stopped? Is there a massive feature backlog?

Development is far from stopped, which is the problem: we're trying to stabilize the language, and adding more language-level features will only delay an already overdue stable language version. Nevertheless, D has gotten to the point where it's powerful enough that most feature requests can be implemented in a library rather than as a language extension. There's been a trend of moving away from core language changes and implementing desired features in libraries (esp. Phobos) instead. T -- That's not a bug; that's a feature!
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 19:12:41 UTC, H. S. Teoh wrote:
 I'm pretty sure Yield has a performance hit as well, 'cos it 
 amounts to an implicit context-switch between two fibers.

Unless I'm sorely mistaken, Yield has bugger-all to do with fibers. I say again: I'm not talking about threading. There is more than one meaning of the word "yield". Go look it up. I provided a link in a previous post.
 Of course, from what I understand, C# runs on a VM, correct? If 
 so, this performance hit is probably hidden in the VM overhead,
 since the VM is already keeping track of states anyway, so the
 cost of tracking multiple states is absorbed into the VM's 
 overall
 overhead. So you probably won't _notice_ the cost, but it's 
 definitely
 there.

I'm fairly sure D could implement the Iterator and Yield keywords from VB.NET without all this "overhead" to which you refer. As I said, go look it up.
Jul 27 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, July 27, 2012 21:09:25 Stuart wrote:
 On Friday, 27 July 2012 at 19:03:34 UTC, Jonathan M Davis wrote:
 Regardless, with where D is right now, there's no way that such
 a feature would be added the language itself any time soon.

What do you mean? Where *is* D at right now? Has development stopped? Is there a massive feature backlog?

We're specifically trying _not_ to add language features right now but rather to stabilize the language and its implementation. We've added a few things since the release of TDPL - mostly to resolve major issues that came up - but with the release of TDPL, the language was supposed to have been effectively frozen. We may add more backwards-compatible features once everything in TDPL has been fully implemented and is reasonably stable, but at this point, new language features need a _really_ good justification in order to be added. - Jonathan M Davis
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 19:17:10 UTC, H. S. Teoh wrote:
 Nevertheless, D has gotten to the point where it's powerful 
 enough that most feature requests can be implemented in a
 library rather than as a language extension.

How could Yield be implemented as a library feature? Something like: return ITERATOR( { ...setup code ... }, { ...loop body code... }) ? I don't see how that would work. Variables declared in the setup would not be accessible from the body. I guess it could be done a bit like this: Enumerable!int ExampleFunction() { ... create some variables ... return ITERATOR!int( { ...do something with variables... ...return something... } ) } That the kind of thing you mean?
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 19:18:11 UTC, Artur Skawina wrote:
 A more or less direct translation of your original example 
 would be:

 [...interesting code elided...]

Hmm. I think I need to learn more about ranges. They look quite powerful. It could, as you suggest, be nothing more than [a] a difference of syntax and [b] my ignorance of ranges. Unfortunately, I understand that information is quite scarce on the subject.
Jul 27 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, July 27, 2012 21:22:47 Stuart wrote:
 On Friday, 27 July 2012 at 19:17:10 UTC, H. S. Teoh wrote:
 Nevertheless, D has gotten to the point where it's powerful
 enough that most feature requests can be implemented in a
 library rather than as a language extension.

How could Yield be implemented as a library feature? Something like: return ITERATOR( { ...setup code ... }, { ...loop body code... }) ? I don't see how that would work. Variables declared in the setup would not be accessible from the body. I guess it could be done a bit like this: Enumerable!int ExampleFunction() { ... create some variables ... return ITERATOR!int( { ...do something with variables... ...return something... } ) } That the kind of thing you mean?

As they're delegates, you could just put any variables you need in both functions in surrounding function. So, something like that could be done, though it would probably be built around the idea that you'd be giving lambdas for empty, front, and popFront rather than an iterator. But regardless, I'm sure that a library solution could be found, and at this point, unless a library solution really just doesn't work or is really ugly and the feature is really needed, it's not going to be added to the language. D is incredibly powerful, and there's been a large push (especially from Andrei) to use that power to solve problems rather than add more to the language to do it. - Jonathan M Davis
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 19:12:41 UTC, H. S. Teoh wrote:
 an implicit context-switch between two fibers

I've just looked up "fiber" and "coroutine". Sounds like a very useful concept. As previously stated, VB.NET iterators implement coroutines WITHOUT fibers; but I can see where fibers would be useful. What is the recommended way to implement coroutines in D? More RANGE stuff?
Jul 27 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 27 Jul 2012 11:05:21 -0400
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 
 I think it's fair to say yield makes some things easier to do than 
 ranges, and ranges makes some other things easier to do than yield.
 Of course, ideally you'd have both, but for the time being we don't
 have yield.
 

We have this, which is essentially the same, just not quite as nice syntax ("mixin(yield("blah"));" instead of "yield blah;") http://forum.dlang.org/thread/jno6o5$qtb$1 digitalmars.com#post-ojeetpvwvzltxwlgphpb:40forum.dlang.org
Jul 27 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 27 Jul 2012 20:52:37 +0200
"Stuart" <stugol gmx.com> wrote:

 On Friday, 27 July 2012 at 15:42:27 UTC, Sean Kelly wrote:
 On Jul 27, 2012, at 8:05 AM, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 core.thread.Fiber has yield and has been used as the basis for 
 this style of iterator.  See Mikola Lysenko's talk from the D 
 conference a few years ago.

I think perhaps you are confusing two different meanings of yield. I am not talking about threading. The VB.NET "yield" and "iterator" keywords can be used just as well in a single-threaded application.

Fibers don't use any threads.
Jul 27 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 27 Jul 2012 20:47:32 +0200
"Stuart" <stugol gmx.com> wrote:
 
 Unless ranges (which I admit to knowing very little about) can do 
 this, I respectfully request that Yield be supported in D.
 

Being able to easily do things lazily is one of the main points of ranges.
Jul 27 2012
prev sibling next sibling parent "Graham Fawcett" <fawcett uwindsor.ca> writes:
On Friday, 27 July 2012 at 18:47:34 UTC, Stuart wrote:
[snip]
 Ah, but that depends upon the pre-existence of the dirEntries() 
 function. I think perhaps you're missing the point - which is 
 that "Yield" allows you to WRITE a function synchronously which 
 will then be executed lazily, as an iterator. What you have 
 demonstrated there is USING a lazy function. How would I write, 
 in D, a function that would lazily assemble some data and 
 return it as a lazy collection? I mean, without calling 
 existing lazy functions.

Short answer: you'd implement an InputRange, just as dirEntries is implemented. When I started learning D, the lack of first-class coroutines ("things that yield") struck me as a real drawback. I had grown very used to them in Python and in Scheme. So I learned how to write ranges. I did not totally fall in love with them. I agree with you that there is a conceptual elegance in writing a coroutine as if it were a regular function, just one that happens to include a "yield" keyword that seems to "remember its place" between calls. I'd like to see language-level support for them in D some day. Having said that, I'm satisfied with ranges. I've seen the fiber and opApply ways of implementing yield, and they are okay. But the fact is, it's usually not that hard to write an input range. Just make a struct that implements these operations: http://dlang.org/phobos/std_range.html#isInputRange Decide what state you need to maintain between calls; determine meaningful definitions for empty, front, and popFront that read and manipulate that state. Write a few of those, and the idiom will become natural to you. It will feel inside-out with respect to C# enumerators. But it's not inherently bad -- certainly not bad enough to dismiss without deeper study, and certainly not bad enough to immediately jump to fibers or an opApply-with-mixin trick before you've at least attempted a range-based solution. There is a load of reusable library code in D that can be brought to bear on ranges. It's well worth a bit of mental rewiring to benefit from that. Best, Graham
Jul 27 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 27 Jul 2012 21:31:08 +0200
"Stuart" <stugol gmx.com> wrote:

 On Friday, 27 July 2012 at 19:12:41 UTC, H. S. Teoh wrote:
 an implicit context-switch between two fibers

I've just looked up "fiber" and "coroutine". Sounds like a very useful concept. As previously stated, VB.NET iterators implement coroutines WITHOUT fibers; but I can see where fibers would be useful. What is the recommended way to implement coroutines in D? More RANGE stuff?

In D, coroutines are implemented by using Fiber: http://dlang.org/phobos/core_thread.html#Fiber
Jul 27 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 27 Jul 2012 21:17:10 +0200
"Stuart" <stugol gmx.com> wrote:

 On Friday, 27 July 2012 at 19:12:41 UTC, H. S. Teoh wrote:
 I'm pretty sure Yield has a performance hit as well, 'cos it 
 amounts to an implicit context-switch between two fibers.


Someone linked to an article which explained that .NET coroutines work, not by using fibers, but by translating the coroutine's source code into an equivalent switch-driven state machine. Pretty cool, actually.
 Unless I'm sorely mistaken, Yield has bugger-all to do with 
 fibers. I say again: I'm not talking about threading.

Fibers aren't threading.
Jul 27 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 27 Jul 2012 17:52:27 +0200
"Jesse Phillips" <Jessekphillips+D gmail.com> wrote:

 so I guess you can take my opinion of GUI designers with 
 an atom of salt.

<annoyingly pedantic>It would have to be a molecule. Try to take an atom of salt and you'll either get a poisonous gas, or something that goes boom in contact with water.</annoyingly pedantic> Chemistry is really weird...
Jul 27 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Nick Sabalausky:

 Chemistry is really weird...

Yep, and that's one of the things it makes is fascinating: http://en.wikipedia.org/wiki/Ionic_bond And of course chemistry runs animal bodies like ours :-) Bye, bearophile
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 20:42:40 UTC, Nick Sabalausky wrote:
 On Fri, 27 Jul 2012 17:52:27 +0200
 "Jesse Phillips" <Jessekphillips+D gmail.com> wrote:

 so I guess you can take my opinion of GUI designers with an 
 atom of salt.

<annoyingly pedantic>It would have to be a molecule. Try to take an atom of salt and you'll either get a poisonous gas, or something that goes boom in contact with water.</annoyingly pedantic>

You know, I do believe he's right.
Jul 27 2012
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Friday, 27 July 2012 at 20:42:40 UTC, Nick Sabalausky wrote:
 On Fri, 27 Jul 2012 17:52:27 +0200
 "Jesse Phillips" <Jessekphillips+D gmail.com> wrote:

 so I guess you can take my opinion of GUI designers with an 
 atom of salt.

<annoyingly pedantic>It would have to be a molecule. Try to take an atom of salt and you'll either get a poisonous gas, or something that goes boom in contact with water.</annoyingly pedantic> Chemistry is really weird...

I realized the whole molecule thing but through laziness it was on purpose. Besides, as you have described here it fits nicely, my opinion could potentially explode with contact to water.
Jul 27 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 27 July 2012 at 19:14:29 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 19:09:27 UTC, Paulo Pinto wrote:
 On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
 Recursion isn't just a security risk - it's a performance hit 
 as well.

Only in languages without tail call optimizations.

Which is pretty much all of them. Scheme does it, and probably HOPE too; but bugger-all you could write a real program in, like .NET or C++. I mean, we're in bloody FORTRAN territory here. What use is that for writing Windows applications? Does D have tail call optimisation?

Well, at least all of these: - Scheme - Haskell - OCaml - F# - Erlang - Clojure - Some C and C++ compilers (gcc, Intel, MSVC in release mode) - Most commercial Lisp compilers Yes D compilers also do tail call optimizations in certain cases, even if not specified in the language spec, picking up an old thread http://www.digitalmars.com/d/archives/digitalmars/D/learn/Tail_call_optimization_33772.html -- Paulo
Jul 27 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, July 28, 2012 04:31:40 Alex R=C3=B8nne Petersen wrote:
 But note, even then, that D only targets 32-bit architectures
 and up, while C can handle 16-bit architectures.

True, but I'm kind of shocked that anything 16-bit even still exists. _= 32-bit_=20 is on its way out. I thought that 16-bit was dead _years_ ago. I guess = that=20 some embedded stuff must use it. But really, I wouldn't expect the lack= of 16- bit support to be much of an impediment - if any at all - and in the lo= ng run,=20 it'll mean absolutely nothing. - Jonathan M Davis
Jul 27 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Saturday, 28 July 2012 at 02:38:47 UTC, Jonathan M Davis wrote:
 On Saturday, July 28, 2012 04:31:40 Alex Rønne Petersen wrote:
 But note, even then, that D only targets 32-bit architectures 
 and up, while C can handle 16-bit architectures.

True, but I'm kind of shocked that anything 16-bit even still exists. _32-bit_ is on its way out. I thought that 16-bit was dead _years_ ago. I guess that some embedded stuff must use it. But really, I wouldn't expect the lack of 16- bit support to be much of an impediment - if any at all - and in the long run, it'll mean absolutely nothing.

The largest majority of computers and programs aren't what you and me use on a computer, it's things that are everywhere and they remain hidden. Your watch, your calculator, smart cards, CD players, devices (Like CD-ROM drives). There are still 8bit chips you can buy, program and use. For the main common computers, yes 32bit is going out of style. http://www.mouser.com/Semiconductors/MCU-MPU-DSP-DSC-SoC-Processors/Microprocessors-MPU/_/N-6hpeh?Keyword=microprocessors&FS=True It's been a while since I looked over this list or catalog.
Jul 27 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 28 Jul 2012 02:42:36 +0400
Dmitry Olshansky <dmitry.olsh gmail.com> wrote:

 On 28-Jul-12 00:42, Nick Sabalausky wrote:
 On Fri, 27 Jul 2012 17:52:27 +0200
 "Jesse Phillips" <Jessekphillips+D gmail.com> wrote:

 so I guess you can take my opinion of GUI designers with
 an atom of salt.

<annoyingly pedantic>It would have to be a molecule. Try to take an atom of salt and you'll either get a poisonous gas, or something that goes boom in contact with water.</annoyingly pedantic>

Well Na isn't much of boom. K will do much better :)
 Chemistry is really weird...

...though Physics is no less so once you are past the Newton mechanics.

That's kind of another weird thing, but just with the terminology: Really, really big: Astro*physics* Medium: Newtonian *physics* Small: *Chemistry* Really, really small: Quantum...*physics*?!? :) (Yea, a gross oversimplification, I'm sure, but still ;) )
Jul 27 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 On Friday, 27 July 2012 at 19:14:29 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 19:09:27 UTC, Paulo Pinto wrote:
 On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
 Recursion isn't just a security risk - it's a performance 
 hit as well.

Only in languages without tail call optimizations.

Which is pretty much all of them. Scheme does it, and probably HOPE too; but bugger-all you could write a real program in, like .NET or C++. I mean, we're in bloody FORTRAN territory here. What use is that for writing Windows applications? Does D have tail call optimisation?

Well, at least all of these: - Scheme - Haskell - OCaml - F# - Erlang - Clojure - Some C and C++ compilers (gcc, Intel, MSVC in release mode) - Most commercial Lisp compilers

So, as I said, nothing you can write a real program in - except possibly for F#. The possibility of "some" C compilers supporting it doesn't mean you can rely on the feature being present.
 Yes D compilers also do tail call optimizations in certain 
 cases, even if not specified in the language spec

If it's not specified in the language spec - and if it's only "in certain cases" - how can you rely on it?
Jul 28 2012
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Saturday, 28 July 2012 at 03:06:53 UTC, Era Scarecrow wrote:
 The largest majority of computers and programs aren't what you 
 and me use on a computer, it's things that are everywhere and 
 they remain hidden. Your watch, your calculator, smart cards, 
 CD players, devices (Like CD-ROM drives). There are still 8bit 
 chips you can buy, program and use. For the main common 
 computers, yes 32bit is going out of style.

 http://www.mouser.com/Semiconductors/MCU-MPU-DSP-DSC-SoC-Processors/Microprocessors-MPU/_/N-6hpeh?Keyword=microprocessors&FS=True

  It's been a while since I looked over this list or catalog.

ARM is staying 32-bit for the foreseeable future, and ARM is just as important as x86 these days. The first ARM64 chips won't even appear for a few years still, and who knows how long it will take for them to take over.
Jul 28 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 22:34:13 UTC, Dmitry Olshansky wrote:
 On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
 I would like to point out here that the example VB.NET code I 
 just
 gave for lazy-populating a list of all files on a drive uses 
 NO
 recursion whatsoever.


It sure thing would. Just list your code to do so. Recursively scan all files on drive does involve stack or recursion.

I already *did* list my code. Check previous posts. And you're wrong - there are no recursive calls. I maintain a queue of pending directories.
Jul 28 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Friday, 27 July 2012 at 22:38:46 UTC, Dmitry Olshansky wrote:
 On 27-Jul-12 22:58, Stuart wrote:
 Well, off the top of my head, you could use something like:

    Public Iterator Function AllFiles(RootDirectory As String) 
 As
 IEnumerable(Of String)
       Dim Roots As New Queue(Of String) From {RootDirectory}
       While Roots.Any
          Dim Root = Roots.Pop
          Roots.AddRange(IO.Directory.GetDirectories(Root))
          For Each Filename in IO.Directory.GetFiles(Root)
             Yield Filename
          Next
       End While
    End Function

Then it's not in anyway better then ranges.

I assume you mean "any way" - "anyway" has a different meaning. And I don't know much about ranges, because there's very little documentation. But as I understand it, for ranges I'd need to write a whole new class. Here, I'm writing a SINGLE FUNCTION in standard imperative style.
 You again maintain stack (or queue, whatever).

There is a difference between recursion (stack) and state variables. To claim that my function is recursive is sheer nonsense. Recursion is costlier than a local queue.
Jul 28 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Saturday, 28 July 2012 at 02:31:42 UTC, Alex Rønne Petersen 
wrote:
 In all fairness, I think C still has its place. The advantage 
 of writing software in C is that when you want to port it to a 
 new platform/architecture, there will almost always be a C 
 compiler available. This isn't the case for D yet - but 
 hopefully will be in the future. But note, even then, that D 
 only targets 32-bit architectures and up, while C can handle 
 16-bit architectures.

Ah. So, in essence, C has a purpose because [a] it supports incredibly obsolete hardware that nobody in their right mind would be using; and [b] nobody's ported D to MacOS (or whatever) yet. Not a particularly good argument, to my mind ;)
Jul 28 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Saturday, 28 July 2012 at 02:38:47 UTC, Jonathan M Davis wrote:
 On Saturday, July 28, 2012 04:31:40 Alex Rønne Petersen wrote:
 But note, even then, that D only targets 32-bit architectures
 and up, while C can handle 16-bit architectures.

True, but I'm kind of shocked that anything 16-bit even still exists. _32-bit_ is on its way out. I thought that 16-bit was dead _years_ ago. I guess that some embedded stuff must use it. But really, I wouldn't expect the lack of 16- bit support to be much of an impediment - if any at all - and in the long run, it'll mean absolutely nothing.

Embedded systems mostly use Java now in any case, as I understand it.
Jul 28 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Saturday, 28 July 2012 at 07:45:20 UTC, Alex Rønne Petersen 
wrote:
 On 28-07-2012 09:36, Stuart wrote:
 On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 - Scheme
 - Haskell
 - OCaml
 - F#
 - Erlang
 - Clojure
 - Some C and C++ compilers (gcc, Intel, MSVC in release mode)
 - Most commercial Lisp compilers

So, as I said, nothing you can write a real program in - except possibly for F#. The possibility of "some" C compilers supporting it doesn't mean you can rely on the feature being present.

Are you serious........?

Uh, yeah? Aside from C (which doesn't always support tail call optimisation), and F#, none of these languages would seem to have any purpose on a desktop computer. I don't know of any way, in this day and age, to write application software (e.g. Notepad) for a 32 or 64-bit Windows 7 machine, in goddamn Haskell. I may be mistaken. As I understand it, languages like Scheme and Cojure exist solely to keep mathematicians happy. If you can't call API functions in it, what's the use of it?
Jul 28 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Saturday, 28 July 2012 at 07:58:23 UTC, Rainer Schuetze wrote:
 On 27.07.2012 15:20, Stuart wrote:
 Yes, removing the .suo file fixed the problem. I don't know 
 why. I will create a ticket. Would submitting my .suo file 
 help?

Yes, please do. Even though it is system specific, maybe I can find some information.

Done.
 Well, it doesn't work in a lot of cases. A lot of times I'll 
 press . or ( and get nothing at all.

Do you have semantic analysis enabled in the intellisense options? That is needed for '.' producing sensible results. In contrast '(' uses the compiler generated browse information. I guess that should be consolidated...

I didn't, but I do now. The status bar now says "blah blah blah\gl.d: parsing" and has done for several minutes. Pressing . after a variable of type WNDCLASS has no effect. Pressing ( has no effect either. Pressing . elsewhere sometimes shows intellisense. It all depends on what is before the . Pressing ( does nothing unless the function I am calling is located within the same source file. This is what I meant by "hit and miss". Also "blows" ;)
Jul 28 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Saturday, 28 July 2012 at 08:05:09 UTC, Daniel Murphy wrote:
 "Stuart" <stugol gmx.com> wrote in message
 Embedded systems mostly use Java now in any case, as I 
 understand
 it.

Your understanding is obviously quite limited.

Quite possibly. I'm not an expert on embedded systems.
Jul 28 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 28 Jul 2012 09:45:19 +0200
Alex R=F8nne Petersen <alex lycus.org> wrote:

 On 28-07-2012 09:36, Stuart wrote:
 On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 - Scheme
 - Haskell
 - OCaml
 - F#
 - Erlang
 - Clojure
 - Some C and C++ compilers (gcc, Intel, MSVC in release mode)
 - Most commercial Lisp compilers

So, as I said, nothing you can write a real program in - except possibly for F#. The possibility of "some" C compilers supporting it doesn't mean you can rely on the feature being present.

Are you serious........? =20

I would tend to agree with him, unless you're being overly literal. Obviously you *can* do real programs in C/C++, hell I've done it (and I am doing it, much to my dismay) - but it's notoriously painful. As for the rest, yea, sure, stuff *has* been written in them, but regardless, most of them still just aren't *realistically* suitable for most software development. It's just like how somebody once write a high-precision Pi calculator in MS Batch. They pulled it off, and it works, but that doesn't mean Batch is realistically suitable as a numeric processing language. Writing real software in, for example, Haskell is like calculating high-precision Pi in Batch. It can be done, but it takes a masochist.
Jul 28 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, July 28, 2012 09:58:58 Stuart wrote:
 On Saturday, 28 July 2012 at 07:45:20 UTC, Alex R=C3=B8nne Petersen
=20
 wrote:
 On 28-07-2012 09:36, Stuart wrote:
 On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 - Scheme
 - Haskell
 - OCaml
 - F#
 - Erlang
 - Clojure
 - Some C and C++ compilers (gcc, Intel, MSVC in release mode)
 - Most commercial Lisp compilers

So, as I said, nothing you can write a real program in - except possibly for F#. The possibility of "some" C compilers supporting it doesn't mean you can rely on the feature being present.

Are you serious........?

Uh, yeah? Aside from C (which doesn't always support tail call optimisation), and F#, none of these languages would seem to have any purpose on a desktop computer. I don't know of any way, in this day and age, to write application software (e.g. Notepad) for a 32 or 64-bit Windows 7 machine, in goddamn Haskell. I may be mistaken.

Oh, you can do it. There's no question of that. For instance, you can u= se=20 wxhaskell to do your GUI. However, how _sane_ it is is another matter=20= entirely. I've done a fair bit of programming in haskell and quite like= the=20 language (it has the best parsing library that I've ever used), but deb= ugging=20 it is a royal pain thanks to the fact that it's a lazy language, and I = don't=20 know how you could sanely do more than small programs with it. People=20= definitely do it though. - Jonathan M Davis
Jul 28 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 28 Jul 2012 09:53:27 +0200
"Stuart" <stugol gmx.com> wrote:

 On Saturday, 28 July 2012 at 02:38:47 UTC, Jonathan M Davis wrote:
 On Saturday, July 28, 2012 04:31:40 Alex R=F8nne Petersen wrote:
 But note, even then, that D only targets 32-bit architectures
 and up, while C can handle 16-bit architectures.

True, but I'm kind of shocked that anything 16-bit even still=20 exists. _32-bit_ is on its way out. I thought that 16-bit was dead _years_ ago.=20 I guess that some embedded stuff must use it. But really, I wouldn't expect=20 the lack of 16- bit support to be much of an impediment - if any at all - and=20 in the long run, it'll mean absolutely nothing.

Embedded systems mostly use Java now in any case, as I understand it.

God I hope that's not true. Using a VM on a low-power system is just so rediculously *wrong* it should be a crime. The only embedded systems I know of that use Java are Android and Symbian (both phones, of course). On Symbian it's optional (or at least it was last I checked, many years ago), and at this point I think it's questional whether Android counts as "embedded system" (more like "handheld supercomputer"). But of course, there's no doubt *MANY* embedded systems I'm completely unaware of...
Jul 28 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 28 Jul 2012 09:52:36 +0200
"Stuart" <stugol gmx.com> wrote:

 On Saturday, 28 July 2012 at 02:31:42 UTC, Alex R=F8nne Petersen=20
 wrote:
 In all fairness, I think C still has its place. The advantage=20
 of writing software in C is that when you want to port it to a=20
 new platform/architecture, there will almost always be a C=20
 compiler available. This isn't the case for D yet - but=20
 hopefully will be in the future. But note, even then, that D=20
 only targets 32-bit architectures and up, while C can handle=20
 16-bit architectures.

Ah. So, in essence, C has a purpose because [a] it supports=20 incredibly obsolete hardware that nobody in their right mind=20 would be using;

That's just plain hyperbole.
Jul 28 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Saturday, 28 July 2012 at 08:53:43 UTC, Dmitry Olshansky wrote:
 On 28-Jul-12 11:49, Stuart wrote:
 But as I understand it, for ranges I'd need to write a whole 
 new class.

struct. Yeah, you need it.
 Here, I'm writing a SINGLE FUNCTION in standard imperative 
 style.

That implicitly constructs Iterator. It's just a sugar. In fact you can do template mixin to generate most of range boilerplate.

I think the basic thrust of my point is: Sugar is good. The compiler converting an imperative function into a state-machine class is helpful. Having to write it yourself every damn time is a pain in the arse. I've been reading about ranges at [http://ddili.org/ders/d.en/ranges.html], and don't understand something. Where it says: struct StudentRange { Student[] students; this(School school) { this.students = school.students; } [...code...] Surely "students" is copied here? Isn't the whole point NOT to copy the array? Perhaps it should say: this.students = school.students[]; ?
Jul 28 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 28 July 2012 at 07:58:59 UTC, Stuart wrote:
 On Saturday, 28 July 2012 at 07:45:20 UTC, Alex Rønne Petersen 
 wrote:
 On 28-07-2012 09:36, Stuart wrote:
 On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 - Scheme
 - Haskell
 - OCaml
 - F#
 - Erlang
 - Clojure
 - Some C and C++ compilers (gcc, Intel, MSVC in release mode)
 - Most commercial Lisp compilers

So, as I said, nothing you can write a real program in - except possibly for F#. The possibility of "some" C compilers supporting it doesn't mean you can rely on the feature being present.

Are you serious........?

Uh, yeah? Aside from C (which doesn't always support tail call optimisation), and F#, none of these languages would seem to have any purpose on a desktop computer. I don't know of any way, in this day and age, to write application software (e.g. Notepad) for a 32 or 64-bit Windows 7 machine, in goddamn Haskell. I may be mistaken.

What about X Window managers (xmonad) ? Or Operating systems (Home)? Tim Sweeney from Valve, seems to have a different opinion from you http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt
 As I understand it, languages like Scheme and Cojure exist 
 solely to keep mathematicians happy. If you can't call API 
 functions in it, what's the use of it?

Soundcloud, LinkedIn, Twitter, Facebook seem to think differently. In Germany there are quite a few Clojure based projects both server side and desktop based. Some people are even crazy enough to sell PS games with Lisp based engines (Crash Bandicoot/GOOL) or Abuse in MS-DOS days. -- Paulo
Jul 28 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 28 July 2012 at 09:05:13 UTC, Alex Rønne Petersen 
wrote:
 On 28-07-2012 09:58, Stuart wrote:
 On Saturday, 28 July 2012 at 07:45:20 UTC, Alex Rønne 
 Petersen wrote:
 On 28-07-2012 09:36, Stuart wrote:
 On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 - Scheme
 - Haskell
 - OCaml
 - F#
 - Erlang
 - Clojure
 - Some C and C++ compilers (gcc, Intel, MSVC in release 
 mode)
 - Most commercial Lisp compilers

So, as I said, nothing you can write a real program in - except possibly for F#. The possibility of "some" C compilers supporting it doesn't mean you can rely on the feature being present.

Are you serious........?

Uh, yeah? Aside from C (which doesn't always support tail call optimisation), and F#, none of these languages would seem to have any purpose on a desktop computer. I don't know of any way, in this day and age, to write application software (e.g. Notepad) for a 32 or 64-bit Windows 7 machine, in goddamn Haskell. I may be mistaken.

Some of the most robust and reliable server systems are written in Erlang. OCaml is basically F# but in native code. It isn't actually much different from using D in terms of capabilities.

I tend to favour F# instead of OCaml due to three things: - Visual Studio integration means I can sneak its use in my PC - As Microsoft language is an easy sell to the boss and clients - It has better multicore support as OCaml, which still suffers from a global lock -- Paulo
Jul 28 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 28 July 2012 at 02:31:42 UTC, Alex Rønne Petersen 
wrote:
 On 27-07-2012 20:50, Stuart wrote:
 On Friday, 27 July 2012 at 15:27:58 UTC, Alex Rønne Petersen 
 wrote:
 On 27-07-2012 14:56, Stuart wrote:

 In any case, isn't it the job of the compiler to unroll 
 loops? Why
 should the coder have to do this himself? Unless of course 
 he's using a
 thin shitty wrapper over assembly language that claims 
 falsely to be a
 high-level language - i.e. C.

It was a high-level language at the time it was created.

Quite possibly. But the definition of "high level" has since changed, and C no longer qualifies. Yet proponents of C/C++ continue to froth at the mouth and claim it's a decent language. Why is D so awesome? Because it's not C.

In all fairness, I think C still has its place. The advantage of writing software in C is that when you want to port it to a new platform/architecture, there will almost always be a C compiler available.

Actually there is always the option of cross-compiling, but it is usually more work than just use the platform tools directly.
Jul 28 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 28 July 2012 at 07:52:37 UTC, Stuart wrote:
 On Saturday, 28 July 2012 at 02:31:42 UTC, Alex Rønne Petersen 
 wrote:
 In all fairness, I think C still has its place. The advantage 
 of writing software in C is that when you want to port it to a 
 new platform/architecture, there will almost always be a C 
 compiler available. This isn't the case for D yet - but 
 hopefully will be in the future. But note, even then, that D 
 only targets 32-bit architectures and up, while C can handle 
 16-bit architectures.

Ah. So, in essence, C has a purpose because [a] it supports incredibly obsolete hardware that nobody in their right mind would be using;

Yep, who would want to use one of the many 8 and 16 bit processors used to make work all the embedded systems in microwaves, fridges, on bord car computers, cameras, watches, calculators, elevators, vcr/dvd systems ... -- Paulo
Jul 28 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Saturday, 28 July 2012 at 11:43:14 UTC, Jacob Carlborg wrote:
 On 2012-07-28 09:52, Stuart wrote:

 Ah. So, in essence, C has a purpose because [a] it supports 
 incredibly
 obsolete hardware that nobody in their right mind would be 
 using; and
 [b] nobody's ported D to MacOS (or whatever) yet.

If you refer to Mac OS X, I use D on it every day. If you're actually referring to MacOS then who cares, it's a dead operating system and has been for at least ten years.

Which only reinforces my point that C is redundant.
Jul 28 2012
prev sibling next sibling parent "Stuart" <stugol gmx.com> writes:
On Saturday, 28 July 2012 at 09:37:47 UTC, Paulo Pinto wrote:
 I tend to favour F# instead of OCaml due to three things

I've never really seen the point of F#. Aside from maths, what is F# good for that a standard imperative language is not? Especially when you consider that all flavours of .NET have native support for LINQ.
Jul 28 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 28 July 2012 at 12:42:47 UTC, Stuart wrote:
 On Saturday, 28 July 2012 at 09:37:47 UTC, Paulo Pinto wrote:
 I tend to favour F# instead of OCaml due to three things

I've never really seen the point of F#. Aside from maths, what is F# good for that a standard imperative language is not? Especially when you consider that all flavours of .NET have native support for LINQ.

Let me see: - Symbolic code manipulation; - Metaprogramming; - Easy parallelization of code thanks to immutable data structures and workflows - Type providers (comming in F# 3.0) to manipulate remote data as language data types - The right way of doing type inference (shared by all ML languages) - Asynchronous programming builtin without having to wait for .NET 4.5 - Algebraic data types Microsoft wouldn't have brought F# into Visual Studio if it wasn't worth it, Microsoft is a business, not a language charity company.
Jul 28 2012
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
--00235452fe247474b604c5e46f94
Content-Type: text/plain; charset=UTF-8

"bearophile" <bearophileHUGS lycos.com>
 Gotos are not so evil. Just use them when they are useful and they can't

at compile-time that use gotos, they are quick. Do you happen to still have the code, by any chance? I think Phobos could use a std.fsm, to automatically generate FSM at compile-time (using lots of gotos :) ). --00235452fe247474b604c5e46f94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p>&quot;bearophile&quot; &lt;<a href=3D"mailto:bearophileHUGS lycos.com">b= earophileHUGS lycos.com</a>&gt; <br> &gt; Gotos are not so evil. Just use them when they are useful and they can= &#39;t be replaced by structured programming. In D I create finite state ma= chines at compile-time that use gotos, they are quick.</p> <p>Do you happen to still have the code, by any chance? I think Phobos coul= d use a std.fsm, to automatically generate FSM at compile-time=C2=A0 (using= lots of gotos :) ).</p> --00235452fe247474b604c5e46f94--
Jul 28 2012
prev sibling next sibling parent "q66" <quaker66 gmail.com> writes:
On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 On Friday, 27 July 2012 at 19:14:29 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 19:09:27 UTC, Paulo Pinto wrote:
 On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
 Recursion isn't just a security risk - it's a performance 
 hit as well.

Only in languages without tail call optimizations.

Which is pretty much all of them. Scheme does it, and probably HOPE too; but bugger-all you could write a real program in, like .NET or C++. I mean, we're in bloody FORTRAN territory here. What use is that for writing Windows applications? Does D have tail call optimisation?

Well, at least all of these: - Scheme - Haskell - OCaml - F# - Erlang - Clojure - Some C and C++ compilers (gcc, Intel, MSVC in release mode) - Most commercial Lisp compilers Yes D compilers also do tail call optimizations in certain cases, even if not specified in the language spec, picking up an old thread http://www.digitalmars.com/d/archives/digitalmars/D/learn/Tail_call_optimization_33772.html -- Paulo

All implementations of Lua also perform TOC and as far as I know some of Python implementations as well.
Jul 28 2012
prev sibling next sibling parent "q66" <quaker66 gmail.com> writes:
 All implementations of Lua also perform TOC and as far as I 
 know some of Python implementations as well.

err TCO :)
Jul 28 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 28 July 2012 at 08:26:45 UTC, Nick Sabalausky wrote:
 On Sat, 28 Jul 2012 09:53:27 +0200
 "Stuart" <stugol gmx.com> wrote:

 On Saturday, 28 July 2012 at 02:38:47 UTC, Jonathan M Davis 
 wrote:
 On Saturday, July 28, 2012 04:31:40 Alex Rønne Petersen 
 wrote:
 But note, even then, that D only targets 32-bit 
 architectures
 and up, while C can handle 16-bit architectures.

True, but I'm kind of shocked that anything 16-bit even still exists. _32-bit_ is on its way out. I thought that 16-bit was dead _years_ ago. I guess that some embedded stuff must use it. But really, I wouldn't expect the lack of 16- bit support to be much of an impediment - if any at all - and in the long run, it'll mean absolutely nothing.

Embedded systems mostly use Java now in any case, as I understand it.

God I hope that's not true. Using a VM on a low-power system is just so rediculously *wrong* it should be a crime.

Java != VM There are quite a few companies selling Java native code compilers for embedded systems. For example, the Perc systems from Aonix, http://www.atego.com/products/aonix-perc/ What I can say it that in telecommunications, many SIM cards are actually running Java Card inside. http://java.sun.com/javacard/overview.jsp I know at least of one mobile operator that uses this in all its SIM cards, and it is a pretty big operator available across Europe. Due to NDA issues I cannot state the name, but should not be hard to guess. Not really commercial product, but you can also get a Java Spot, with the VM almost fully implemented in Java, except for the low level hardware access done via native methods. http://www.sunspotworld.com/ The embedded space is very broad, from the tiny processors which you still have to code in pure Assembly while counting valuable byte space, to some which are big enough to run Java in all flavours, high speed interpreter, JIT or natively. It all a matter of cost vs type of product you want to sell. -- Paulo
Jul 28 2012
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
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.

Do FSMs really need to be spaghetti monsters? I heard, gcc optimizer can tear functions into common pieces and them reassemble the functions back from these pieces, or simply inline them, won't you get the same result?
Jul 28 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 28 July 2012 at 16:07:14 UTC, Andrei Alexandrescu 
wrote:
 On 7/28/12 10:04 AM, Paulo Pinto wrote:
 On Saturday, 28 July 2012 at 12:42:47 UTC, Stuart wrote:
 On Saturday, 28 July 2012 at 09:37:47 UTC, Paulo Pinto wrote:
 I tend to favour F# instead of OCaml due to three things

I've never really seen the point of F#. Aside from maths, what is F# good for that a standard imperative language is not? Especially when you consider that all flavours of .NET have native support for LINQ.

Let me see: - Symbolic code manipulation; - Metaprogramming; - Easy parallelization of code thanks to immutable data structures and workflows - Type providers (comming in F# 3.0) to manipulate remote data as language data types - The right way of doing type inference (shared by all ML languages) - Asynchronous programming builtin without having to wait for ..NET 4.5 - Algebraic data types Microsoft wouldn't have brought F# into Visual Studio if it wasn't worth it, Microsoft is a business, not a language charity company.

It was for Basic :o). Anyhow, indeed, the tools around it make F# pretty cool (just not all that original as a language). Andrei

Sure, as I said it is all about having Microsoft's weight on it.
Jul 28 2012
prev sibling next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
On Saturday, 28 July 2012 at 16:55:32 UTC, Kagamin 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.

Do FSMs really need to be spaghetti monsters? I heard, gcc optimizer can tear functions into common pieces and them reassemble the functions back from these pieces, or simply inline them, won't you get the same result?

State machines encoded with goto tend not to be more spaghetti than their specifications (say in regex or graph picture
Jul 28 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Philippe Sigaud:

 Do you happen to still have the code, by any chance? I think 
 Phobos
 could use a std.fsm

The code is not general enough for Phobos. Kagamin:
 I heard, gcc optimizer can tear functions into common pieces 
 and them reassemble the functions back from these pieces, or 
 simply inline them, won't you get the same result?

Sometimes those FSM are the only part of those small C or D programs where I don't trust the optimizers. But thankfully in C-GCC using a little of __builtin_expect() it's not necessary to generate the assembly directly from the FSM description. Bye, beaophile
Jul 28 2012
prev sibling next sibling parent "David Piepgrass" <qwertie256 gmail.com> writes:
 I'd say this argument on which is "better", yield or ranges, is 
 a problem ill posed.

Yeah, since yielding is just a convenient way to implement an input range, asking which is better is like asking "Which is better, pick-up trucks or vehicles?"
 "yield" adds real, nontrivial value, and is not entirely 
 implementable as a library. Walter and I saw some uses of it in 
 C# at Lang.NEXT that were quite impressive.

 On the other hand yield's charter is limited when compared to 
 that of ranges. Yield goes with the very simple "go through 
 everything once" functionality, which is essentially input 
 ranges - only a tiny part of ranges can do.

 "yield" adds real, nontrivial value, and is not entirely 
 implementable as a library. Walter and I saw some uses of it in 
 C# at Lang.NEXT that were quite impressive.

Agreed. However, I have been looking at D's Fibers and I wonder if an optimized implementation of them could provide the same functionality reasonably well: https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration The only problem is performance (and perhaps memory usage, but there are ways to reduce that). Someone reported that a trivial fiber-based forward range had 26x the overhead of opApply for iteration (70s vs 2.7s for 1 billion iterations). I wonder if the fiber-switching could be optimized? But I looked at core/thread.d and unless I'm missing something, the fiber switch does not appear to do much work: it calls Thread.getThis() twice per switch (= 4 times per iteration), getStackTop() (= rt_stackTop) once, and a naked asm routine with 21 asm instructions. The entire yield() process contains no branches; call() additionally calls setThis() twice and checks if the Fiber threw an exception. What's the easiest way to time something in D? I'm curious if Thread.getThis() (= TlsGetValue()) is the bottleneck. Anyway, stack-switching lets you do not only the same things as C# 2's "yield return" but as far as I can tell, it can also do everything that C# 5's "async/await" can do and more: http://qscribble.blogspot.ca/2012/07/asyncawait-vs-stack-switching.html i.e. stack switching can accomplish tasks that async/await cannot, while I don't know of any cases of the reverse. async is more limited because all functions involved in an async task must be explicitly marked and transformed by the compiler, but stack switching works no matter what code is involved; even C code can be called on an asynchronous fiber task.
Jul 28 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Saturday, 28 July 2012 at 08:05:09 UTC, Daniel Murphy wrote:
 "Stuart" <stugol gmx.com> wrote in message
 news:vjaspnvbihpgvxgqmccr forum.dlang.org...
 Embedded systems mostly use Java now in any case, as I 
 understand it.

Your understanding is obviously quite limited.

I've used the java compiler for GNU's compilers; Doesn't it compile to native code? In which case java in the right compiler/setup is the same as C/C++ (To a degree... with the appropriate runtime)
Jul 28 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 28 Jul 2012 20:32:57 +0200
"David Piepgrass" <qwertie256 gmail.com> wrote:

 What's the easiest way to time something in D?

{ import std.datetime; StopWatch stopWatch; stopWatch.start(); scope(exit) writeln(stopWatch.peek.msecs, "ms"); // Do stuff to be timed } Or use my verboseSection wrapper: https://bitbucket.org/Abscissa/semitwistdtools/src/8123e04b593c/src/semitwist/util/mixins.d#cl-644 bool verbose = true; ... { mixin(verboseSection!"Making the fizzbar"); makeFizzbar(); } Output: Making the fizzbar...732ms
Jul 28 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 28 Jul 2012 16:33:02 +0200
"Paulo Pinto" <pjmlp progtools.org> wrote:

 On Saturday, 28 July 2012 at 08:26:45 UTC, Nick Sabalausky wrote:
 God I hope that's not true. Using a VM on a low-power system is 
 just so
 rediculously *wrong* it should be a crime.

Java != VM

Yea, people keep telling me that and I still keep forgetting :P "Java==VM" has been ingrained pretty deeply into my brain for about 10 years. Hard to change that :) Still, unless there's something different about these offerings, Java (the langauge) has no low-level ability whatsoever, no manual memory management and strongly encourages over-use of objects and heap allocation. Even natively-compiled, that doesn't sound like my idea of a good embedded language. But I dunno, I guess maybe if they're using it in the sort of way that game devs use Lua...(Not that I'm a fan of Lua - far too dynamic for my tastes.)
Jul 28 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Sunday, 29 July 2012 at 02:40:44 UTC, Nick Sabalausky wrote:

 Still, unless there's something different about these 
 offerings, Java (the langauge) has no low-level ability 
 whatsoever, no manual memory management and strongly encourages 
 over-use of objects and heap allocation. Even 
 natively-compiled, that doesn't sound like my idea of a good 
 embedded language. But I dunno, I guess maybe if they're using 
 it in the sort of way that game devs use Lua...(Not that I'm a 
 fan of Lua - far too dynamic for my tastes.)

It does do low-level bit manipulation for built-in types, however I think that's it's limit.
Jul 28 2012
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 2012-07-29 at 04:59 +0200, Era Scarecrow wrote:
[=E2=80=A6]
   It does do low-level bit manipulation for built-in types,=20
 however I think that's it's limit.

There are no unsigned types which leads to extremely ugly bit manipulation codes. Primitive types are now effectively deprecated in Java, and this is likely a deprecation which will actually lead to a removal =E2=80=93 unlike everything else in Java that has been deprecated which is still there. Sun did one time actually remove something from a Java release but there was such an outcry that it got put back in. Sadly it should never have been taken out in the first place. Unlike all the stuff that has been deprecated for >10 years which should have gone long ago. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jul 29 2012
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 2012-07-28 at 22:40 -0400, Nick Sabalausky wrote:
[=E2=80=A6]
 allocation. Even natively-compiled, that doesn't sound like my idea of a
 good embedded language. But I dunno, I guess maybe if they're
 using it in the sort of way that game devs use Lua...(Not that I'm a fan
 of Lua - far too dynamic for my tastes.)

The benefit of using Java in an embedded context is exactly to avoid native code. The use of a language that has no access to physical memory makes operating system level security management significantly easier. For example on smart cards =E2=80=93 which has to be one of the most constr= ained multi-application platforms out there =E2=80=93 the lengths processor manufacturers have to go to support management of native code applications is awful compared to those who support only Java Card. Yes I know Java Card is not Java in any meaningful way, shape or form, but it is an bytecode virtual machine based system. The use of dynamic languages in systems such as games, post-production, image manipulation has many similarities in terms of security management, but is there for a wholly different purpose: the C and/or C ++ code does all the real computational work. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jul 29 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 29 July 2012 at 08:34:33 UTC, Russel Winder wrote:
 On Sun, 2012-07-29 at 04:59 +0200, Era Scarecrow wrote:
 […]
   It does do low-level bit manipulation for built-in types, 
 however I think that's it's limit.

There are no unsigned types which leads to extremely ugly bit manipulation codes. Primitive types are now effectively deprecated in Java, and this is likely a deprecation which will actually lead to a removal – unlike everything else in Java that has been deprecated which is still there. Sun did one time actually remove something from a Java release but there was such an outcry that it got put back in. Sadly it should never have been taken out in the first place. Unlike all the stuff that has been deprecated for >10 years which should have gone long ago.

I like Java, but currently have a few issues with the some of the design decisions after Java 5, namely the overuse of annotations instead of adding new keywords. Examples are Overload, Checked, NotNull, Null, or worse the possible Value annotation. I mean, use Value to specify a class with value semantics, really?! Is it that complicated to add struct as keyword? Nowadays I find myself having more fun with C#, a language I used to criticise as being a cheap Java clone back in 2001. How things change. -- Paulo
Jul 29 2012
prev sibling next sibling parent "Minas Mina" <minas_mina1990 hotmail.co.uk> writes:
The only thing Java is good for is portability. And its standard 
library is very good too.

However the language as it is, really sucks in my opinion. I 
mean, there's no way to change the value of a primitive type 
passed to a method? Come on.
Jul 29 2012
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 2012-07-29 at 09:31 -0400, Andrei Alexandrescu wrote:
 On 7/29/12 4:34 AM, Russel Winder wrote:
 Primitive types are now effectively deprecated in Java, and this is
 likely a deprecation which will actually lead to a removal =E2=80=93 un=


 everything else in Java that has been deprecated which is still there.

That's interesting. Do you have references to some related resources? =20 Thanks,

It's on the Java road map for Java 10. I can't immediately find the actual road map, but you will find lots of people blogging about the fact which has been "announced" at most of the main Java conferences. e.g. http://java.dzone.com/articles/oracle-discusses-features-java --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jul 29 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 29 Jul 2012 13:14:06 +0200
"Paulo Pinto" <pjmlp progtools.org> wrote:
 
 Nowadays I find myself having more fun with C#, a language I used 
 to criticise as being a cheap Java clone back in 2001. How things 
 change.
 

Ever since I first tried it out, many years ago, I've been convinced that C# is "Java done right". Or at least "Java done much better". Still think so. It used to actually be tied with D as my favorite language, but eventually I grew more and more tired of the limitations C# does still have, while I grew to like D more and more.
Jul 29 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 29 July 2012 at 19:23:38 UTC, Jacob Carlborg wrote:
 On 2012-07-29 15:10, Minas Mina wrote:
 The only thing Java is good for is portability. And its 
 standard library
 is very good too.

 However the language as it is, really sucks in my opinion. I 
 mean,
 there's no way to change the value of a primitive type passed 
 to a
 method? Come on.

There are many other languages available on the JVM platform. Scala for example.

The problem is that in the enterprise world with expendable programmers, is very hard to do JVM based projects with anything other than Java. I was very happy when on a project for a new internal proprietary JSF based framework, we were allowed to have Groovy as part of the framework's supported languages. That only happened because the said company was replacing the Perl scripts by Groovy scripts in their deployment infrastructure. -- Paulo
Jul 29 2012
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 2012-07-29 at 21:35 +0200, Paulo Pinto wrote:
[=E2=80=A6]
 The problem is that in the enterprise world with expendable=20
 programmers, is very hard to do JVM based projects with anything=20
 other than Java.

My experience from various training courses I have given is that in the large corporate Web applications world, the average programmer knows Java, just enough Java, and isn't that interested in anything else. Gross oversimplification but a good indicator. However within the financial sector, some of the large players are ditching Java and unitary systems in favour of a small Scala core and Python using what is effectively an SOA architecture. In all these organizations there are large bodies of C++ code hence a move away from Java and C# to Python. In other organizations Java remains the core but Groovy, JRuby and Clojure are admitted, which sounds like your experience=E2=80=A6
 I was very happy when on a project for a new internal proprietary=20
 JSF based framework, we were allowed to have Groovy as part of=20
 the framework's supported languages.
=20
 That only happened because the said company was replacing the=20
 Perl scripts by Groovy scripts in their deployment infrastructure.

Perl is a fine language in many ways and not so fine in others. It seems though that it is increasingly seen as legacy in the way COBOL is.=20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jul 29 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 30 July 2012 at 06:04:31 UTC, Russel Winder wrote:
 On Sun, 2012-07-29 at 21:35 +0200, Paulo Pinto wrote:
 […]
 The problem is that in the enterprise world with expendable 
 programmers, is very hard to do JVM based projects with 
 anything other than Java.

My experience from various training courses I have given is that in the large corporate Web applications world, the average programmer knows Java, just enough Java, and isn't that interested in anything else. Gross oversimplification but a good indicator.

That is actually the case.
Jul 30 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Monday, 30 July 2012 at 07:26:51 UTC, Paulo Pinto wrote:
 On Monday, 30 July 2012 at 06:04:31 UTC, Russel Winder wrote:
 On Sun, 2012-07-29 at 21:35 +0200, Paulo Pinto wrote:
 The problem is that in the enterprise world with expendable 
 programmers, is very hard to do JVM based projects with 
 anything other than Java.

My experience from various training courses I have given is that in the large corporate Web applications world, the average programmer knows Java, just enough Java, and isn't that interested in anything else. Gross oversimplification but a good indicator.

That is actually the case.

The only thing I walked away with after I learned java as part of a programming course, was how polymorphism and interfaces worked in OO programming. I just really wish they would change their courses for 'this is inheritance with animals!' which although logically makes sense (in a dictionary wikipedia way) but structurally and programming-wise doesn't. Describing it as a building block for a game (like item) would have made much more sense.
Jul 30 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 30 July 2012 at 07:57:47 UTC, Era Scarecrow wrote:
 On Monday, 30 July 2012 at 07:26:51 UTC, Paulo Pinto wrote:
 On Monday, 30 July 2012 at 06:04:31 UTC, Russel Winder wrote:
 On Sun, 2012-07-29 at 21:35 +0200, Paulo Pinto wrote:
 The problem is that in the enterprise world with expendable 
 programmers, is very hard to do JVM based projects with 
 anything other than Java.

My experience from various training courses I have given is that in the large corporate Web applications world, the average programmer knows Java, just enough Java, and isn't that interested in anything else. Gross oversimplification but a good indicator.

That is actually the case.

The only thing I walked away with after I learned java as part of a programming course, was how polymorphism and interfaces worked in OO programming. I just really wish they would change their courses for 'this is inheritance with animals!' which although logically makes sense (in a dictionary wikipedia way) but structurally and programming-wise doesn't. Describing it as a building block for a game (like item) would have made much more sense.

It always depends how lucky you get with who teaches you. I learned OO with Turbo Pascal 6.0, as I prepared a class about OO in high school. Afterwards it was time to learn with OO the C++ way. Before Java I was exposed to OO in Smalltalk, CLOS, Eiffel, Modula-3, Oberon, Python. Not only the languages, but OO abstract design in the form of Boochs and UML methods. So when I came to lean Java, many things felt natural, and I was not contaminated like many, with the idea that OOP == Java. -- Paulo
Jul 30 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 29 July 2012 at 22:22:33 UTC, Walter Bright wrote:
 On 7/27/2012 7:38 PM, Jonathan M Davis wrote:
 True, but I'm kind of shocked that anything 16-bit even still 
 exists. _32-bit_
 is on its way out. I thought that 16-bit was dead _years_ ago. 
 I guess that
 some embedded stuff must use it. But really, I wouldn't expect 
 the lack of 16-
 bit support to be much of an impediment - if any at all - and 
 in the long run,
 it'll mean absolutely nothing.

For those who may not realize it, C++ is simply not suitable for 16 bit systems either. It theoretically supports 16 bit code, but in practice, full C++ will never work on them. So, you might ask, why was 16 bit C++ popular on 16 bit MSDOS in the 80's? That was C++ before exception handling and RTTI, both of which were unimplementable on 16 bit machines. (Yes, you could do it, but the result was practically unusable.)

I remember using both features with Borland compilers. But then I was around 16 years old and was not doing anything serious with C++, besides getting to know the language. On those days, Turbo Pascal was my number one choice for serious software.
 C and 16 bits go reasonably well together, but even so, the 
 best programs were written all in asm.

Jul 30 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, July 30, 2012 11:23:06 Christophe Travert wrote:
 Jonathan M Davis , dans le message (digitalmars.D:173382), a écrit :
 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.

I don't mind scope going away, since it can be replaced with a library solution. But scope is not more dangerous than a static array, or simple function variables. Slice them, or take their reference, and you're up for troubles. Do you think they should be removed as core features of the langage?

I don't think that you _can_ implement them in a library. I _do_ think that implicit slicing of static arrays should go away, since it's just begging for bugs. But there's pretty much no way that that's going to change at this point. - Jonathan M Davis
Jul 30 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 30 Jul 2012 07:04:21 +0100
Russel Winder <russel winder.org.uk> wrote:
 My experience from various training courses I have given is that in
 the large corporate Web applications world, the average programmer
 knows Java, just enough Java, and isn't that interested in anything
 else. Gross oversimplification but a good indicator.

Ugh, such "programmers" don't deserve a paycheck. It's like hiring someone who never learned arithmetic as an accountant. Makes no fucking sense at all - they just simply *can't* do their fucking trade, period. The "programmer" and the hiring manager should both be fired and pointed to nearest (possibly hiring) fast food joint. (Incarceration for "impersonating a programmer" would perhaps be more appropriate ;) )
Jul 30 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 30 July 2012 at 19:31:51 UTC, Nick Sabalausky wrote:
 On Mon, 30 Jul 2012 07:04:21 +0100
 Russel Winder <russel winder.org.uk> wrote:
 My experience from various training courses I have given is 
 that in
 the large corporate Web applications world, the average 
 programmer
 knows Java, just enough Java, and isn't that interested in 
 anything
 else. Gross oversimplification but a good indicator.

Ugh, such "programmers" don't deserve a paycheck. It's like hiring someone who never learned arithmetic as an accountant. Makes no fucking sense at all - they just simply *can't* do their fucking trade, period. The "programmer" and the hiring manager should both be fired and pointed to nearest (possibly hiring) fast food joint. (Incarceration for "impersonating a programmer" would perhaps be more appropriate ;) )

Sadly this is how many well known consulting companies with a big client portfolio of Fortune 500 companies work. I happen to work in one of them, you would be amazed what managers and clients look for as developers. As a guy I know says, pay for a FIAT while expecting to get a Ferrari in the end. -- Paulo
Jul 30 2012
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 30 Jul 2012 22:22:22 +0200
"Paulo Pinto" <pjmlp progtools.org> wrote:

 On Monday, 30 July 2012 at 19:31:51 UTC, Nick Sabalausky wrote:
 On Mon, 30 Jul 2012 07:04:21 +0100
 Russel Winder <russel winder.org.uk> wrote:
 My experience from various training courses I have given is 
 that in
 the large corporate Web applications world, the average 
 programmer
 knows Java, just enough Java, and isn't that interested in 
 anything
 else. Gross oversimplification but a good indicator.

Ugh, such "programmers" don't deserve a paycheck. It's like hiring someone who never learned arithmetic as an accountant. Makes no fucking sense at all - they just simply *can't* do their fucking trade, period. The "programmer" and the hiring manager should both be fired and pointed to nearest (possibly hiring) fast food joint. (Incarceration for "impersonating a programmer" would perhaps be more appropriate ;) )

Sadly this is how many well known consulting companies with a big client portfolio of Fortune 500 companies work.

It's no surprise then as to why, outside of management circles, consulting companies have gained a reputation for not knowing what they're doing.
Jul 30 2012