Brilliant blog post. It's a pity though that the "Good things about Nimrod" section only takes up 40% of my screen whereas the "Bad things about Nimrod" takes up almost 100% (perhaps thats a silly metric though). But I respect your opinion and your truth, I certainly hope that you still believe in Nimrod despite those "bad things" you mention, the fact that you have been missing from IRC for so long worried me although I guess it was just slowing down your progress so you left to be more productive. Please remember that while it's good to be honest, we do want to attract more users so you may want to tone down on the negativity just a wee bit.
As for more concrete problems that i've had: I found the SLOC table a bit confusing. I think you should s/python/nimrod/. Maybe add an asterisk which talks about that sloc count aoftware not supporting Nimrod. Most people won't bother to read the points beneath the table.
As for good things: very informative and loving the humour. Your blog is fast becoming my favourite and its awesome that you're still using ipsum genera. Wish I had the determination to write as many blog posts as you.
Anyway, keep up the good work.
Thanks for your comment. I have changed the table to avoid confusing, certainly nobody is going to read all that.
I actually was lenient about Nimrod. Whenever stuff started to go wrong or it was obviously a bug I would stop the clock or delete the time already spent so that it would not worsen the metrics. From memory it took about 15-20h away from the project. That's notable, because it is nearly a third of the total time I spent for the OSX client. Not good. Still, sort of acceptable to not report that because I could also have used the last stable release and avoid myself the trouble (though some stuff may not compile). Ok, so that's my fault for using the latest git version. Maybe I should stick in the future to 0.9.2 where all is rainbows and unicorns.
But I don't want to take part in any sugar coating. If I was lured into Nimrod with such a blog post but with the bad things removed, or maybe made more palatable, to later find out myself that there are issues which won't go away just because I want them to, I would feel cheated on. Does Nimrod need more eyeballs so desperately that even risking this is acceptable? Maybe.
The part from the webpage where it says (in bold letters no less) that Nimrod generates Objective C for easier interfacing is especially irritating to me. Renaming .c files to .m and calling a different compiler doesn't actually ease that much interfacing, and hopefully Objective-C and C++ coders know that they can add C code to their projects. Or to put it the other way round, let's say that Nimrod grows a javascript backend. Would it be ok then to say "Nimrod generates CoffeeScript and Dart code for easier interfacing"? After all, they all use javascript…
I have no use for IRC and I'm of no use to IRC. I'll keep doing stuff on my own from the distance. Hopefully for 1.0 release I'll be able to make true the sentence about Objective C interfacing. And don't worry about blogging. At some point you will be grumpy enough that it will all flow out with ease. You could start a post about how hard it is to please other programmers and growing a community, harder than herding cats.
The part from the webpage where it says (in bold letters no less) that Nimrod generates Objective C for easier interfacing is especially irritating to me. Renaming .c files to .m and calling a different compiler doesn't actually ease that much interfacing,
We have also an importobjc pragma, but you know that... The other issue that you mention about subtyping to id can be done with a converter quite easily.
The problem that you can't run Nimrod code in a background thread is indeed a serious limitation and I keep thinking about how to solve it. But it is a very hard problem.
Improving the support for C++ interfacing is on my relatively short-term to-do list. This includes using C++ templates, types with constructors and even more crazy stuff like inheriting types with virtual functions and overriding them in Nimrod. Since I'll be touching the same places in the compiler, it won't be hard to improve the Objective-C support as well.
What did you learn from your experiments with the Objective-C-Bridge and why did you close this issue? https://github.com/Araq/Nimrod/issues/265
I've learned that there are two directions for the binding, and one is flawed. When it comes to making objective-c code available in Nimrod I started by writing a macro which would transform a Nimrod proc definition into the appropriate objective-c binding. As Araq mentions, you need to generate converters for each step of class hierarchies, which would tend to a maximum of N * M converter procs generated at runtime during each compilation where N is the level of the class hierarchy to reach the base objective-c method, and M the number of different leaf classes.
Since different classes may be in different files (you could write the binding for NSObject in one file, and the binding for NSString in another) a method to maintain state inside these macros would be needed so that classes importing their parents would generate the required converters. That didn't work, I thought then that the macro could generate on top of the procs for the current class level a different macro which passed the name of any subclass would regenerate these for the subclass.
At this point you realise it is all madness, and since you are essentially brute forcing a class hierarchy generated at runtime, it would be better to look into writing a clang scanner which could generate these procs once, so you wouldn't have to pay the macro cost every time you compile. Therefore I won't be looking more into doing these kind of bindings with macros.
The other way of the binding would mean taking a Nimrod type and exposing it as an Objective-C class. This is possible by either creating a proxy class object which would wrap the C methods, or by modifying the Nimrod C structure to contain an isa field for toll-free bridging and figuring out what is necessary to make the C structure work like an Objective-C class. Progress halted when I could not reliably control Nimrod memory.
I am deferring any more work on this until I look at java bindings for android. In any case objective-c seems like a subset of the features you plan to implement for c++ support.
A fascinating blog post I've just read. Hope Araq will coin a solution to the multithreading problem you mention.
While I share the same frustration as Gradha regarding instabilities and feature bugs, Nimrod is a very nice piece of software and full of inspiring ideas. I think the problems are of the complicated and feature-rich nature of the language that just demand more manpower to solve. Current version already seems very complex and all-encompassing to me.
I lean towards a more confined languages to solve a part of a problem, like using C for low-level stuff and something of higher level to do only high-level stuff and a bridge between them. Otherwise we finish using a subset of features, a dialect, like in the world of c++ where some projects adopt only "C with classes" part and the others "some boost library and classes"...