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

On Sun, 02 Jan 2011 01:46:46 -0500
bearophile <bearophileHUGS@lycos.com> wrote:

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

That's a Very Good Thing: imo, the programming community desperately needs Bearophile's (instead of each designer not even beeing aware of alternatives and/or believing in one only way and/or wearing blinders).

Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com

On Sunday, 2 January 2011 at 06:46:46 UTC, 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

There is no need though. I'm already aware of D. And copied nothing from it; features like CTFE or UCS have been in Nimrod's design before D got them. Please consider that most of Nimrod's design is from 2004, but development is slow enough that other people got the same ideas. Nimrod is still different from D, and includes many features that D does not have (distinct types, AST macros, sum types, iterators, realtime GC) as well as lacks some "anti-features" (like unchecked unions or undetectable integer overflows).

 Like the design, syntax is way better than D

 But half of what makes a language are the compilers/debuggers/tool

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.

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

On 5/24/2012 12:58 PM, Araq wrote:
> There is no need though. I'm already aware of D. And copied nothing from it;
> features like CTFE or UCS have been in Nimrod's design before D got them. Please
> consider that most of Nimrod's design is from 2004, but development is slow
> enough that other people got the same ideas. Nimrod is still different from D,
> and includes many features that D does not have (distinct types, AST macros, sum
> types, iterators, realtime GC) as well as lacks some "anti-features" (like
> unchecked unions or undetectable integer overflows).

Nice to see you here! Welcome!

Araq wrote:
> On Sunday, 2 January 2011 at 06:46:46 UTC, 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
> 
> There is no need though. I'm already aware of D. And copied nothing from it; features like CTFE or UCS have been in Nimrod's design before D got them. Please consider that most of Nimrod's design is from 2004, but development is slow enough that other people got the same ideas. Nimrod is still different from D, and includes many features that D does not have (distinct types, AST macros, sum types, iterators, realtime GC) as well as lacks some "anti-features" (like unchecked unions or undetectable integer overflows).
> 
	One D feature I'm really missing in Nimrod is the
scope(exit/success/failure) statement. Other than that, I tend to
prefer Nimrod (easier syntax, better choice of names...)

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

On 2012-05-25 01:21, Araq 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. ;-)
> 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.

I don't know about Nimrod but in Ruby and I assume in other languages like JavaScript, PHP and similar, the order of declarations only matters at top level. Example in Ruby:

def foo (args)
  bar(args)
end

foo(3)

def bar (args)
  p args
end

Results in:

NoMethodError: undefined method ‘bar’ for main:Object

But if I wrap everything in a class the order doesn't matter:

class Bar
  def foo (args)
    bar(args)
  end

  def initialize
    foo(3)
  end

  def bar (args)
    p args
  end
end

Bar.new

Prints '3' as excepted.

-- 
/Jacob Carlborg

On Fri, 2012-05-25 at 10:43 +0200, Jacob Carlborg wrote: [...]
> I don't know about Nimrod but in Ruby and I assume in other languages like JavaScript, PHP and similar, the order of declarations only matters at top level. Example in Ruby:

Surely with dynamic languages like Python, Ruby, Groovy etc. declaration order is irrelevant, it is execution order that matters.  Your example holds but only by following what execution happens not what the compiler does.

[...]
> Prints '3' as excepted.

No exception there ;-)

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 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