View mode: basic / threaded / horizontal-split · Log in · Help
July 28, 2012
Re: Impressed
"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
Re: Impressed
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
Re: Impressed
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
Re: Impressed
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
Re: Impressed
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
Re: Impressed
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
Re: Impressed
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
Re: Impressed
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
Re: Impressed
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
Re: Impressed
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
9 10 11 12 13 14 15 16 17
Top | Discussion index | About this forum | D home