I just saw on the Manning web site that the book has been delayed again until May this time. It's like we are asymptotically approaching the publication date. 2017-04-17 13:55:34

Indeed, apologies about the delays.

Myself and the copy editor have only just recently finished going through each chapter and making corrections. I'm hoping that it won't be too far into May before it's published.

2017-04-17 15:35:18

Poor community. Stop wasting everyone's time, dom96 and Araq. I was a Nim user long ago, but I don't want to even look at it anymore. Here is the fact that senior Nim developers might never understand in their lifetime:

A fully static and compiled language environment is not better in any sense (including speed in development time, execution speed, security, stability, etc) than a fully dynamic and interpreted (without JIT or any other compilation process) language environment. Plus, there are many things that are not possible in static and compiled languages to express, but are possible and easily express-able in dynamic and interpreter languages. I intend to write an article about these issues if can.

Chapter 1 in Nim in Action is (intentionally) totally false (for the sake of money and catching people to the web).

Nim in Action basically makes compilers, infix/indentation-based syntax, static typing, and other Nim-contained concepts superior over the opponent, but dom96 doesn't tell readers about the disadvantages of the above concepts, such as collaboration-difficulty of indentation-based syntax and long compilation time for most modification (in serious and big programs, not in small practices, but in real-world).

And why doesn't Nim in Action mention the unfriendly debugging experience of compiled programming environment (or specifically Nim, which we can barely debug issues)? Interpreted environments, on the other hand, are much friendlier when it comes to debugging and tracing.

Programming is not (and never was) just about "writing" programs and execution speed.

2017-04-18 19:04:48

@Fungi I would have to disagree.

"A fully static and compiled language environment is not better in any sense"

Ever heard of a language called C (and C++)? Any idea why companies still use them? Why wasn't the latest AAA video game written in Python or Javascript?

Do you know why DropBox started developing Pyston, a python JIT?

mGBA, a popular Game Boy Advanced emulator decided to move the project from JavaScript to C, any idea why?

Because some people care about execution speed.

Have you tried running python, Javascript etc. on the Game Boy Advanced, Commodore 64, Arduino, or resource deprived embedded chip?

Ever heard of a project called Cython? I wonder why somebody would create that if the "compiled language environment is not better in any sense"?


I would agree that programming is not just about "writing" programs and execution speed.

I'm not sure where you got that information though.

Go away troll.

EDIT:

To add to your section about Nim In Action, I haven't read the book, so I may be wrong but...

"...but dom96 doesn't tell readers about the disadvantages of the above concepts."

Usually when you write a book about a programming language, you don't write about the pros/cons of the syntax.

The point of the book is for the reader to learn Nim, not to debate the merits of the language's features or flaws.

"And why doesn't Nim in Action mention the unfriendly debugging experience of compiled programming environment (or specifically Nim, which we can barely debug issues)?"

Perhaps a section about debugging Nim might be helpful.

2017-04-18 20:02:40
@Fungi, it's nice that you found out that Nim is not the language for you, but you should understand that everybody's point of view is always a very limited view on the world. Nobody knows everything. What I want to say is, just because you don't see the advantages of compiled programming languages in your domain of expertise, it doesn't mean that this will apply to other people as well. But you are right that the debugging experience in Nim is Bad. 2017-04-18 20:36:19
I'm still really excited about the book! The chapters I've read through the EAP have been very good (and helped with parallelizing a numerical program that I've been working on). 2017-04-18 23:56:17

@Fungi I can understand your disappointment about the lack of an interpreter in Nim, as one was planned originally. I don't know if it still in the works, but it probably has to wait until verson 1.0 is out before it can be worked on.

At least if the main Nim team don't have the time or resources there will be a set version that other interested parties can work on. My advice is to be patient and try to support or contribute to it if you can.

2017-04-19 00:30:53

I don't want to even look at it anymore.

Yet here you are trolling, and showing the world what an awful human being you are.

I can understand your disappointment about the lack of an interpreter in Nim, as one was planned originally.

The compiler contains an interpreter. That's how compile-time expression evaluation is done.

2017-04-19 08:21:54

[sigh] replying non-technical people sucks. @hcorion, @jibal, listen, you are ignorant + arrogant, which makes you the worst people.

compilers impose restirctions, you are forced to use macros, which are just kludge, but in a pure interpreted language (PicoLisp for example) you can simply use functions, which you can debug, apply, etc in opposite to macros. Such as this Common Lisp do macro, written as function in PicoLisp (a pure interpreted and dynamic language):

(de do "Args"
(bind (mapcar car (car "Args"))
(for "A" (car "Args")
(set (car "A") (eval (cadr "A"))) )
(until (eval (caadr "Args"))
(run (cddr "Args"))
(for "A" (car "Args")
(and (cddr "A") (set (car "A") (run @))) ) )

(run (cdadr "Args")) ) )

Note that there are almost no penalties of using eval in PicoLisp.

And nothing stops you to write optimized and efficient code in interpreter environments. And one more thing, the above example obviously uses S-expression or lets say Lisp-like syntax, it has certain advantages, such as ease of parsing it, and together with S-expressions and interpretation, equalivance of code and data is formal and realistic in PicoLisp, check the web resources for reasos...

This one is a very, very wise and beautiful quote, from author of Ruby, Yukihiro Matsumoto,

"Often people, especially computer engineers, focus on the machines. They think, "By doing this, the machine will run fast. By doing this, the machine will run more effectively. By doing this, the machine will something something something." They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves."

I was brainwashed just like you, I thought Nim in Action is right about how bad are dynamism and interpreters, but thank God I realised the truth when I looked around and see all those people use bash, dynamic mecahnism, etc in eveything and I started to know the reality of the concepts.

Compilers simply discards many things just for the sake of execution speed, but those "many things" are what makes programmer's life easier and "truely" reduce development time. Many (if not all) major game engines use and contain JS, Python-like languages (such as Boo in Unity).

The real execution speed concept is well- and carefully-designed algorithm, relying on compiler optimization is for stupid programmers.

2017-04-19 10:58:44

@Fungi: It seems to me you don't want to discuss things but you want to insult people.

My suggestion: Open a forum where people like you could insult each other. Perhaps you will be happier then.

Hope they will ban you here.

2017-04-19 11:06:15
<<<••123••>>>