On Tuesday, 14 April 2015 at 06:31:08 UTC, Jadbox wrote:
>> btw : I think D should get rid off un-bracketed if statement, program king is not about sparing the number of lines...but that’s again a matter of taste.
>
> I'm that guy on the other side of the fence. I view unbracked IFs as an essential part of concise code readability. Brackets are the symbolization of a block of logic, meaning multiple steps of logic. Being forced to express "this is a block of code" for just a single statement after an IF seems bloaty and hurts scanning through code. I also feel reducing line numbers is something to strive for as long as no readability is sacrifices.

I think Apple would disagree (CVE-ID CVE-2014-1266).

On Tuesday, 14 April 2015 at 10:48:48 UTC, Messenger wrote:
> To be fair, a vocal minority says the same of D. Accusations of linkbombing are commonplace, as is the notion that the D forums are "nice except for the constant go-bashing", claims that there is an organized secret cabal (naturally led by AA and WB) directing people over IRC to upvote everything D regardless of content, etc. Once the seed of doubt is there suddenly everyone saying anything positive about D is probably/maybe/possibly just part of the mob.

The problem with Nim is different. They'll go into the comments section of a completely unrelated post, write something favorable about Nim, then they'll all upvote it so it stays there. That signals to me that they know they can't generate interest based on the merits of the language.

On Tue, 2015-04-14 at 12:47 +0000, bachmeier via Digitalmars-d wrote:
> On Tuesday, 14 April 2015 at 10:48:48 UTC, Messenger wrote:
> > To be fair, a vocal minority says the same of D. Accusations of linkbombing are commonplace, as is the notion that the D forums are "nice except for the constant go-bashing", claims that there is an organized secret cabal (naturally led by AA and WB) directing people over IRC to upvote everything D regardless of content, etc. Once the seed of doubt is there suddenly everyone saying anything positive about D is probably/maybe/possibly just part of the mob.
> 
> The problem with Nim is different. They'll go into the comments section of a completely unrelated post, write something favorable about Nim, then they'll all upvote it so it stays there. That signals to me that they know they can't generate interest based on the merits of the language.

That is a very strong claim about ethically bad behaviour, I hope you have evidence to substantiate it.

Even if true, that sort of behaviour is just "gaming the system", I am sure it happens in Java, C, C++, etc. circles, it is all part of guerilla marketing undertaken by anyone with anything to market.

I like the Nim concept and approach, but there is an annoying attitude towards certain types of obvious bug. My current bugbear (!) is that the installer will not install, due to what seems like a blindingly obvious problem, but they will not fix the issue because "just use it in place". Grr…

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

Russel Winder:

> it is all part of
> guerilla marketing undertaken by anyone with anything to market.

It's still not a correct behavour, regardless how many do it.

Bye,
bearophile

On Monday, 13 April 2015 at 17:28:14 UTC, Timothee Cour wrote:
> I think people interested in D should take a closer look at nim and judge
> for yourself ; http://nim-lang.org/tut1.html is a good starting point (docs
> in general are very well written).
>
> I went through their tutorials and here are some first impressions:
>
> * nim is already bootstrapped (self-compiles)
> * feature set is very rich, many features (semantic and syntax) not found
> in D or improving the ones in D, eg hygenic macros,
> * many key features of D (static if, type inference, CTFE, UFCS, lambda,
> template constraints).
> * The syntax seems more orthogonal with fewer bultin constructs and many
> generated by library, eg: 'a>b is a hygyenic macro that generates 'b<a';
> associative arrays (tables) are in library
> * documentation in code uses markdown (less noisy than D's)
>  * named parameter arguments
> * tooling (nimble package manager ~dub, nimfix ~= gofix; nimgrep ~=
> dscanner);
> * etc...
>
> less good or tradeoffs:
>
> * C backend instead of (LLVM,gcc or dmd's; but they're working on it
> * uses yield-based ranges instead of D-based ranges (maybe simpler to write
> but less efficient?)
> * forward declarations needed (docs says this may change)
> * thread-local GC (no stop the world)
> * RAII still experimental it seems
> * mutually importing modules seem possible; but doc says: Modules that
> depend on each other are possible, but strongly discouraged; it's very
> common in D
> * mutually recursive types. In Nim these types can only be declared within
> a single type section. (Anything else would require arbitrary symbol
> lookahead which slows down compilation.)
>
> not sure whether language has those; need to look more in the docs:
> * delegates
> * template variadic (but has varargs[T])
> * not sure whether we can have template parameters which are other than a
> type
>
> It would be nice to have a wiki page to describe this further feature by
> feature. Many ideas would be great to incorporate in D too btw.
>
> On Fri, Apr 10, 2015 at 2:26 PM, bachmeier via Digitalmars-d <
> digitalmars-d@puremagic.com> wrote:
>
>> On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote:
>>
>>> The only things I've read about nim have been on the D forums - it seems
>>> the wikipedia article is even being considered for deletion due to not
>>> being noteworthy. So I think you might have trouble finding any comparisons.
>>>
>>
>> Read the comments sections on other languages on Reddit programming and
>> you'll see their spam all over the place.
>>
>> I've never used Nim (and don't plan to because I've been turned off by
>> their constant spamming of comment threads on Reddit) but the numerous
>> comments I've seen repeatedly indicate that Nim is not yet ready for real
>> use.

I have to say, Nim sounds very interesting and promising. I don't know how easy it is to integrate C/C++ code, but they have a foreign function interface:

http://nim-lang.org/manual.html#foreign-function-interface

On Mon, Apr 20, 2015 at 2:21 AM, Russel Winder via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> I like the Nim concept and approach, but there is an annoying attitude towards certain types of obvious bug. My current bugbear (!) is that the installer will not install, due to what seems like a blindingly obvious problem, but they will not fix the issue because "just use it in place". Grr…

Nim includes an install.sh script.  It worked for me.

According to the Nim docs ( http://nim-lang.org/download.html ) "There are other ways to install Nim (like using the install.sh script), but these tend to cause more problems."  I am not sure what these unspecified problems are.  I used Nim only briefly, so perhaps there problems are lurking and I just did not encounter them.

-Parke

On Mon, 2015-04-20 at 13:05 -0700, Parke via Digitalmars-d wrote:
> 
[…]
> Nim includes an install.sh script.  It worked for me.

install.sh calls koch, both of these are created by running build.sh.

Running koch builds the executable for installation which requires extra compilations one critical part of which does not happen. So the built system is fine but the installable version will not build.

> According to the Nim docs ( http://nim-lang.org/download.html ) "There are other ways to install Nim (like using the install.sh script), but these tend to cause more problems."  I am not sure what these unspecified problems are.  I used Nim only briefly, so perhaps there problems are lurking and I just did not encounter them.

The Nim developers seem disinterested in fixing things for early adopters, which is sad.
-- 
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

On Tuesday, 21 April 2015 at 08:29:11 UTC, Russel Winder wrote:
> On Mon, 2015-04-20 at 13:05 -0700, Parke via Digitalmars-d wrote:
>> 
> […]
>> Nim includes an install.sh script.  It worked for me.
>
> install.sh calls koch, both of these are created by running build.sh.
>
> Running koch builds the executable for installation which requires extra
> compilations one critical part of which does not happen. So the built
> system is fine but the installable version will not build.
>
>> According to the Nim docs ( http://nim-lang.org/download.html ) "There
>> are other ways to install Nim (like using the install.sh script), but
>> these tend to cause more problems."  I am not sure what these
>> unspecified problems are.  I used Nim only briefly, so perhaps there
>> problems are lurking and I just did not encounter them.
>
> The Nim developers seem disinterested in fixing things for early adopters,
> which is sad.

Neither is it a good strategy. How are they supposed to build up a user base (and get input), if they don't care for potential users, especially now that they are going on about how great the language is.

> On Mon, 2015-04-20 at 13:05 -0700, Parke via Digitalmars-d wrote:
>> Nim includes an install.sh script.  It worked for me.

On Tue, Apr 21, 2015 at 1:28 AM, Russel Winder via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> install.sh calls koch, both of these are created by running build.sh.
>
> Running koch builds the executable for installation which requires extra compilations one critical part of which does not happen. So the built system is fine but the installable version will not build.

How should I modify the following script to encounter the problems of which you speak?

----

unzip -q nim-0.10.2.zip

cd nim-0.10.2
sh build.sh > /dev/null
sh install.sh ../install_dir

cd ../install_dir
echo 'echo "Hello, Nim world!"' > hello.nim
nim/bin/nim c hello.nim
echo
./hello

----

When I run the script on my Ubuntu system, I get the following:

$ sh -x nim_test.sh
+ unzip -q nim-0.10.2.zip
+ cd nim-0.10.2
+ sh build.sh
+ sh install.sh ../install_dir
Nim build detected
copying files...
installation successful
+ cd ../install_dir
+ echo echo "Hello, Nim world!"
+ nim/bin/nim c hello.nim
config/nim.cfg(45, 2) Hint: added path: '/home/bake/.babel/pkgs/' [Path]
config/nim.cfg(46, 2) Hint: added path: '/home/bake/.nimble/pkgs/' [Path]
Hint: used config file
'/usr/local/bake/tmp/install_dir/nim/config/nim.cfg' [Conf]
Hint: system [Processing]
Hint: hello [Processing]
CC: hello
CC: system
[Linking]
Hint: operation successful (8753 lines compiled; 1.230 sec total;
14.148MB) [SuccessX]
+ echo

+ ./hello
Hello, Nim world!

On Mon, Apr 13, 2015 at 10:28 AM, Timothee Cour <thelastmammoth@gmail.com> wrote:

> I think people interested in D should take a closer look at nim and judge for yourself ; http://nim-lang.org/tut1.html is a good starting point (docs in general are very well written).
>
> I went through their tutorials and here are some first impressions:
>
> * nim is already bootstrapped (self-compiles)
> * feature set is very rich, many features (semantic and syntax) not found
> in D or improving the ones in D, eg hygenic macros,
> * many key features of D (static if, type inference, CTFE, UFCS, lambda,
> template constraints).
> * The syntax seems more orthogonal with fewer bultin constructs and many
> generated by library, eg: 'a>b is a hygyenic macro that generates 'b<a';
> associative arrays (tables) are in library
> * documentation in code uses markdown (less noisy than D's)
>  * named parameter arguments
> * tooling (nimble package manager ~dub, nimfix ~= gofix; nimgrep ~=
> dscanner);
> * etc...
>
> less good or tradeoffs:
>
> * C backend instead of (LLVM,gcc or dmd's; but they're working on it * uses yield-based ranges instead of D-based ranges (maybe simpler to write but less efficient?)
>

Other issues with that: this provides a less flexibility (eg infinite ranges, bidirectional ranges etc)


> * forward declarations needed (docs says this may change)
> * thread-local GC (no stop the world)
> * RAII still experimental it seems
> * mutually importing modules seem possible; but doc says: Modules that
> depend on each other are possible, but strongly discouraged; it's very
> common in D
> * mutually recursive types. In Nim these types can only be declared within
> a single type section. (Anything else would require arbitrary symbol
> lookahead which slows down compilation.)
>
> not sure whether language has those; need to look more in the docs: * delegates
>

Actually they do have delegates (just not mentioned in the tutorial)


> * template variadic (but has varargs[T])
> * not sure whether we can have template parameters which are other than a
> type
>

> It would be nice to have a wiki page to describe this further feature by feature. Many ideas would be great to incorporate in D too btw.
>
> On Fri, Apr 10, 2015 at 2:26 PM, bachmeier via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote:
>>
>>> The only things I've read about nim have been on the D forums - it seems the wikipedia article is even being considered for deletion due to not being noteworthy. So I think you might have trouble finding any comparisons.
>>>
>>
>> Read the comments sections on other languages on Reddit programming and you'll see their spam all over the place.
>>
>> I've never used Nim (and don't plan to because I've been turned off by their constant spamming of comment threads on Reddit) but the numerous comments I've seen repeatedly indicate that Nim is not yet ready for real use.
>>
>
>

I would like to refocus this thread on feature set and how it compares to D, not on flame wars about brackets or language marketing issues.