Andrei:
>
> My fantasy: bearophile goes to the Nimrod forum and says
> "Hey, how about
> this D language, seems interesting..." :o)

"dom96" <morfeusz8@gmail.com>:
> 
> BTW http://nimrod-code.org/ is the new Nimrod website, the one you linked to is long outdated.

It looks like "ventor3000" mentioned D there just yesterday on those forums. Here is an excerpt:

"[...] i'm in the CAD/CAM industry. [...] The last few years many programming languages have popped up like mushroms, and I have investigated virtually every one of them. Not many matches what I want, which includes:

* Fast compilation times
* Good performance
* Garbage collected
* Sourcecode without cluttered syntax
* Standalone executables
* Object oriented (I just cant stand functional languages)

The D language from digital mars is close to thoose specifications. The problem with D is that it overcomplicates things since it tries to do everything c++ does. I really like D but i think its totally overkill for real world applications. And I say this of long experience: Keep it simple. [...]"

The complete thread: http://forum.nimrod-code.org/t/15

-- 
Marco

On 2012-05-25 14:04, dom96 wrote:

> You will, you can compile an empty .nim file and you still get an
> executable.
>
> BTW http://nimrod-code.org/ is the new Nimrod website, the one you
> linked to is long outdated.

Ah, thanks. I though that the address didn't look quite right.

-- 
/Jacob Carlborg

On 05/24/2012 07:21 PM, Araq wrote:
> On Thursday, 24 May 2012 at 22:56:52 UTC, Kevin Cox wrote:
>> On May 24, 2012 6:53 PM, "Froglegs" <lugtug@yahoo.com> wrote:
>>>
>>> Like the design, syntax is way better than D
>>>
>>> But half of what makes a language are the compilers/debuggers/tool
>>
>> I like many ideas of the language but there are some show-stoppers for
>> me.
>> For example the fact that you have to define things in order. I shouldn't
>> have to deal with that in this day and age.
>
> Nimrod is full of constructs that have inlining semantics and as such
> declaration order matters quite a bit. The D compiler has/had bugs with
> this feature for a reason. ;-)

OK, now I'm curious.  Why?

> I'm considering to weaken the requirement but I don't mind this feature:
> Having the order reflect the call graph has its advantages too. Many
> consider the resulting order *backwards*, but at least there is *an* order.
>

Wouldn't it be good enough to define the order arbitrarily when building your symbol table?  What kind of information is this allowing the programmer to convey to the compiler?

I'm already skeptical because I have no intuition for how this allows me to better optimize my code ;)

Btw, I've looked at Nimrod a while ago (year+) and found it very elegant.  I love good metaprogramming.  I think my only complaints were the bus-factor and the apparent lack of array slices (the kind that doesn't cause copying).  Still, very promising.

On 5/26/12, Marco Leise <Marco.Leise@gmx.de> wrote:
> It looks like "ventor3000" mentioned D there just yesterday on those forums.
> Here is an excerpt:
> "I really like D but i think its totally overkill for
> real world applications. And I say this of long experience: Keep it simple.
> [...]"

You can always keep the D code simple, it's totally up to the programmer. I really don't understand what is "overkill" about D, nobody is forced to use every single feature in the language. And on the plus side, as you write more D code you come to realize its various features come in really handy.

On 2011-01-02 07:46, bearophile wrote:
> Andrei:
>
>> My fantasy: bearophile goes to the Nimrod forum and says "Hey, how about
>> this D language, seems interesting..." :o)
>
> That fantasy of yours means that I am interested in using my time to explain to Nimrod developers what's good in D, what may be modified or improved, to steal some of the good ideas of the D language for the development and spreading of Nimrod :-)
>
> Bye,
> bearophile

I had a look at the Nimrod language, the template and macro features look really cool. I would love to have those in D.

-- 
/Jacob Carlborg

On Saturday, 26 May 2012 at 16:01:25 UTC, Jacob Carlborg wrote:
> I had a look at the Nimrod language, the template and macro features look really cool. I would love to have those in D.

I would be great to see such a mechanism employed to increase the power-to-weight ratio of the D language (e.g. relegate a construct like "scope" to the standard library).

Chad J wrote:
> I think my only complaints were the bus-factor and the apparent lack of array slices (the kind that doesn't cause copying).  Still, very promising.

It actually does have slices as a construct in the system lib (included by default).

http://force7.de/nimrod/system.html#139
http://force7.de/nimrod/system.html#606

but I'm not sure how they stack up against D's in practice.

On Saturday, 26 May 2012 at 17:59:46 UTC, F i L wrote:
> Chad J wrote:
>> I think my only complaints were the bus-factor and the apparent lack of array slices (the kind that doesn't cause copying).  Still, very promising.
>
> It actually does have slices as a construct in the system lib (included by default).
>
> http://force7.de/nimrod/system.html#139
> http://force7.de/nimrod/system.html#606
>
> but I'm not sure how they stack up against D's in practice.

Nimrod's builtin slices copy. It's possible to implement more D-like slices in Nimrod, but a bit tricky. However, if you don't copy slicing a large string (or array) keeps the whole string in memory so it's questionable whether it's a good idea.

D implements slices as (ptr, length) pairs which causes issues for a GC as that invites lots of interior pointers and GCs tend to have problems with those, causing at least some overhead in the GC/memory system.

On Saturday, 26 May 2012 at 11:49:47 UTC, Chad J wrote:
> On 05/24/2012 07:21 PM, Araq wrote:
>> On Thursday, 24 May 2012 at 22:56:52 UTC, Kevin Cox wrote:
>>> On May 24, 2012 6:53 PM, "Froglegs" <lugtug@yahoo.com> wrote:
>>>
>> Nimrod is full of constructs that have inlining semantics and as such
>> declaration order matters quite a bit. The D compiler has/had bugs with
>> this feature for a reason. ;-)
>
> OK, now I'm curious.  Why?
>

Because it's hard to implement? ;-)


  t() # the compiler needs to *expand* t here; parsing t's
  # header and put it into the symbol table is not enough

  template t() = ...


And Nimrod supports symbol table inspection:

  when not defined(p):
    proc p = echo "a"
  else:
    proc p = echo "b"
  p() # what should that do?

These things can be solved, but it's lots of work and I have no idea how the result would affect compile times (probably negligible).


>> I'm considering to weaken the requirement but I don't mind this feature:
>> Having the order reflect the call graph has its advantages too. Many
>> consider the resulting order *backwards*, but at least there is *an* order.
>>
>
> Wouldn't it be good enough to define the order arbitrarily when building your symbol table?  What kind of information is this allowing the programmer to convey to the compiler?
>

I was talking about readability here. You can read an ordinary (smallish) Nimrod program from *bottom to top*. (And a forward declaration often screams "warning: mutually recursive procs ahead").
Granted, from *top to bottom* would be nicer, but I have never seen that happen in practice in C# (which allows for arbitrary order); but admittedly that's a very weak point.

> I'm already skeptical because I have no intuition for how this allows me to better optimize my code ;)

> Btw, I've looked at Nimrod a while ago (year+) and found it very elegant.  I love good metaprogramming.  I think my only complaints were the bus-factor and the apparent lack of array slices (the kind that doesn't cause copying).  Still, very promising.

See my other answer about the slicing. The bus factor got better as there are now 3 core developers. :-)

> Nimrod's builtin slices copy. It's possible to implement more D-like slices in Nimrod, but a bit tricky. However, if you don't copy slicing a large string (or array) keeps the whole string in memory so it's questionable whether it's a good idea.

In that case you can still explicitly copy a slice in D.