
This series is aimed at programming language aficionados. There's a lot of very abstract writing about programming languages and a lot of simple minded "language X sux!" style blog posts by people who know next to nothing about programming. What I feel is sorely missing is a kind of article that deliberately sacrifices the last 10% of precision that make the theoretical articles dry and long winded but still makes a point and discusses the various trade offs involved. This series is meant to fill that void and hopefully start a lot of discussions that are more enlightening than the articles themselves. I will point out some parallels in different parts of computing that I haven't seen mentioned as well as analyze some well known rules of thumb and link to interesting blogs and articles.
Member since:
2006-07-30
I didn't mean to imply an authoritative context:
"This series is meant to fill that void and hopefully start a lot of discussions that are more enlightening than the articles themselves."
Maybe that was too subtle.
Also I wasn't really trying to compare resource usage/verbosity of programming languages. I was comparing the effort required to solve a set of problems of varying sizes in a fixed programming language to the hardware requirements of a fixed algorithm operating on a set of inputs of varying sizes.
Still your link is interesting and I urge everybody to read it even though it can obviously only measure programming language _implementations_, not the languages themselves. So the maturity of the specific implementation tends to be an important factor.
You're obviously right in that you cannot literally apply big O notation to programming languages. You could define a set of reference problems. Where it really falls apart is Turing completeness:
You can implement Ruby in Java and vice versa in a finite amount of code so they cannot really scale differently. What this means is discussed in the next article.
I think this kind of writing cannot be published as a paper. I want readers to develop a better intuition about programming languages and to better understand where some rules of thumb come from. You cannot write a paper along the lines of "X is sorta like Y". You need to find a very small, very limited topic and really beat it to death, write about it till the last corner case and the last bit of ambiguity are removed.
That's no fun.
I was waiting for somebody more knowledgeable than me to write an article. Nothing happened. So I sat down and wrote the kind of article that _I_ enjoy. If the vast majority of OSNews users are just annoyed by this I basically have two options:
-publish somewhere else
-change the style of the articles
The latter is problematic because you cannot write a good article if you hate what you're writing. I can make longer or shorter paragraphs or cut back on my use of f words. What I cannot do is completely change the topic and line of reasoning. If people hate informal articles there's nothing I can do to help them.
But maybe they're just a vocal minority - I don't know. This may sound like "Waaah, if you don't like me I'll take my ball and play somewhere else!". That's not how I feel about this. I enjoy what I'm doing and if just a single person likes my articles it was totally worth it.
Did I misunderstand your advice?
Were you thinking of a specific forum?