On Wednesday, 25 September 2019 at 10:37:07 UTC, JN wrote:
> Don't like GC? Don't worry, you can use refcounting and manual
>
But I like ARC .
Using ARC instead of GC .

On Wednesday, 25 September 2019 at 10:01:40 UTC, Rel wrote:
> https://nim-lang.org/blog/2019/09/23/version-100-released.html
>
> Well, finally Nim team released 1.0. Now future releases shouldn't break people's code and this fact should increase language adoption. Still few things seems to be unfinished (like their NewRuntime thing), but I'd like to congratulate Nim's team with this big release. What do you think about it?

I recently tried Nim. The first good impression was quickly replaced by disappointment.

No nested types, constants and functions. Poor generics and templates (but macros are great). Primitive modules system. Unclear error messages.

But. Nim's GC (including boehm) is much faster then D's one. And Nim compiler creates very compact binaries.

On Saturday, 5 October 2019 at 08:01:15 UTC, Jack Applegame wrote:

>
> I recently tried Nim. The first good impression was quickly replaced by disappointment.
>
> No nested types, constants and functions. Poor generics and templates (but macros are great). Primitive modules system. Unclear error messages.
>
> But. Nim's GC (including boehm) is much faster then D's one. And Nim compiler creates very compact binaries.

I suppose Nim is not trying to have all features one can possibly look for in a programming language, rather it's designed as a "native Python" and that'd be great from my point of view. If researchers used Nim to write code that they usually write in Python, it'd speed up the development of real world programs (especially for programs where performance is of the essence).

There is a trend (started by Google?) to keep PLs simple so that a) non-programmers can write code too and b) the code is more robust. Go is one example and now definitely Dart, i.e. there's only so much you can do / choose from. C++ is out of the question and D is somewhere between C++ and Python, fast modelling but way too many features for people who are not really into programing.

On Monday, 7 October 2019 at 10:38:49 UTC, Chris wrote:
> there's only so much you can do / choose from. C++ is out of the question and D is somewhere between C++ and Python, fast modelling but way too many features for people who are not really into programing.

I don't think features necessarily is a problem. Python has an incredible amount of features and is rather complex if you want to master it all, but you usually don't have to deal with it if you just want to solve a problem. So what is important is to have a smooth curve of incremental learning and keep the features out of the application level programming interface.

C++ is at the other end of the spectrum, not because of features, but because you cannot make good use of it (outside the C-subset) without being proficient.

So when newbies complain about not understanding the documentation for the standard library of a language, then that could be a sign of not supporting the incremental learning process as well as desired.

Sort of.

On Monday, 7 October 2019 at 14:20:10 UTC, Ola Fosheim Grøstad wrote:
>
> I don't think features necessarily is a problem. Python has an incredible amount of features and is rather complex if you want to master it all, but you usually don't have to deal with it if you just want to solve a problem. So what is important is to have a smooth curve of incremental learning and keep the features out of the application level programming interface.
>
> C++ is at the other end of the spectrum, not because of features, but because you cannot make good use of it (outside the C-subset) without being proficient.
>
> So when newbies complain about not understanding the documentation for the standard library of a language, then that could be a sign of not supporting the incremental learning process as well as desired.
>
> Sort of.

Yes. However, D is a bit like C++ in the sense that you have to be proficient or else it's very hard to make sense of it. Templates, ranges and lambdas are everywhere.

On Monday, 7 October 2019 at 14:38:01 UTC, Chris wrote:
> Yes. However, D is a bit like C++ in the sense that you have to be proficient or else it's very hard to make sense of it. Templates, ranges and lambdas are everywhere.

Yes, it becomes problematic when you need that kind of knowledge to use the std lib API.

The questions newbies ask also suggests that having two different types of pointers increases the learning curve. How arrays reallocate when expanded is another surprise for newbies... and so on.

By keeping track of what newbies ask about, one could probably learn a lot, but it has always been the case that seasoned D-programmers tend to have more influence over the direction than newbies. Which probably is why the language keeps heading in that direction...

On Mon, 2019-10-07 at 10:38 +0000, Chris via Digitalmars-d wrote: […]
> There is a trend (started by Google?) to keep PLs simple so that a) non-programmers can write code too and b) the code is more robust. Go is one example and now definitely Dart, i.e. there's only so much you can do / choose from. C++ is out of the question and D is somewhere between C++ and Python, fast modelling but way too many features for people who are not really into programing.

I believe the publicly released rationale for Go:

– A modern update on C: remove the obvious cruft of C, add object-based and
GC.
– A language very fast to parse and code generate.
– Include modern approach to parallelism and concurrency in the language:
processes and channels on a thread pool.
– Include a modern approach to code reuse – it is not totally clear Go has yet
achieved this.
– A language in which Google interns cannot make big errors.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Fri, 2019-10-04 at 13:05 +0000, Ola Fosheim Grøstad via Digitalmars-d
wrote:
[…]
> 
> Right, and the JS APIs are much better too.  I sometimes wonder why jquery is still around? Established habits don't change easily...
[…]

Isn't jQuery still being used because everyone with jQuery based systems refuses to update them because they work?

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Monday, 7 October 2019 at 16:58:17 UTC, Russel Winder wrote:
> On Fri, 2019-10-04 at 13:05 +0000, Ola Fosheim Grøstad via Digitalmars-d
> wrote:
> […]
>> 
>> Right, and the JS APIs are much better too.  I sometimes wonder why jquery is still around? Established habits don't change easily...
> […]
>
> Isn't jQuery still being used because everyone with jQuery based systems refuses to update them because they work?

I don't know...

https://meta.stackoverflow.com/questions/383170/how-do-i-ask-a-question-and-exclude-jquery-answers-to-strict-javascript-question

*sigh*

One Achilles heel of Nim is that it compiles via C or C++. This means in a debugging environment you will be watching the environment of the intermediate language. There workarounds for this described here.

https://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html#using-gdb-lldb

However, this doesn't solve everything. Also all the variable are intermixed with generated symbols, probably with some ugly hash added to it. Languages that directly compiles to the target like D will give a better debugging environment.

There is a attempt make Nim compile via LLVM instead.

https://github.com/arnetheduck/nlvm

not sure if it is in any productive state yet. Also Nim seems to allow C to intermix and all sorts of built in C features that will not work when going via LLVM. Trying to merge Nim with C features is a bad decision in my opinion.