July 28, 2012
"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 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.

Your understanding is obviously quite limited.


July 28, 2012
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" ;)
July 28, 2012
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.
July 28, 2012
On Sat, 28 Jul 2012 09:45:19 +0200
Alex Rønne 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.

July 28, 2012
On Saturday, July 28, 2012 09:58: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.

Oh, you can do it. There's no question of that. For instance, you can use wxhaskell to do your GUI. However, how _sane_ it is is another matter entirely. I've done a fair bit of programming in haskell and quite like the language (it has the best parsing library that I've ever used), but debugging it is a royal pain thanks to the fact that it's a lazy language, and I don't know how you could sanely do more than small programs with it. People definitely do it though.

- Jonathan M Davis
July 28, 2012
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.

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

July 28, 2012
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ø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;

That's just plain hyperbole.

July 28, 2012
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
July 28, 2012
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[];

?
July 28, 2012
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