July 28, 2012
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.
>
It would be good to redo opApply so that it does something like this. In 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[];
>
> ?
Okay. You also need to learn how D arrays or rather slices work :)
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
July 28, 2012
On 28-07-2012 10:16, Nick Sabalausky wrote:
> 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.
>

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 Rønne Petersen
alex@lycus.org
http://lycus.org
July 28, 2012
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



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

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

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