Linked by RandomGuy on Wed 10th Jun 2009 20:00 UTC
General Development 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.
Permalink for comment 367828
To read all comments associated with this story, please click here.
RE[4]: Blank Stare
by RandomGuy on Wed 10th Jun 2009 23:57 UTC in reply to "RE[3]: Blank Stare"
RandomGuy
Member since:
2006-07-30

That way you could have evolved your idea before presenting it to the world- without the authoritative context implied by an article.

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?

Reply Parent Score: 2