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.
Thread beginning with comment 367797
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Blank Stare
by RandomGuy on Wed 10th Jun 2009 21:47 UTC in reply to "RE: Blank Stare"
RandomGuy
Member since:
2006-07-30

He is attempting to apply methodology/terminology for describing algorithms to programming languages. While that is an interesting abstract idea, it needs to be better defined and he does not take it anywhere meaningful.

I'm relieved. Somebody understood my idea and finds it interesting ;)
Could you take it anywhere meaningful on one page?

Honestly, this is not meant as a "Oh, so Mr computer scientist knows better, well then show me, Mr computer scientist" kind of reply. I would love to see people evolve this idea. That's why I wrote this article.

Reply Parent Score: 3

RE[3]: Blank Stare
by voidlogic on Wed 10th Jun 2009 22:40 in reply to "RE[2]: Blank Stare"
voidlogic Member since:
2005-09-03

First off sorry for being an elitist bastard. Your presentation of such idea probably would have better received in a forum somewhere. That way you could have evolved your idea before presenting it to the world- without the authoritative context implied by an article.

I think your insight, that there are analytical methods for evaluating programming languages, is a valid and true point. The problem is that big-O notation is not very suitable, let me try to explain why.

Specificity, since big-O notation evaluates algorithms, not languages, it is language independent. If you are trying to apply the underlying principle of big-O notation very generically: In your axis on the big-O graphs you present, although unlabelled, have cost on the y-axis and problem size on the x-axis. What you should have done was replaced cost and problem size with the properties of languages that interest you. I think you will find however that one line graph cannot define a language as the result depends on a program examined.

One approach often done (see the link in my last post) is creating a scatter plot where the data points are programs written in a lang. and looking at trends.

Now, I understand your point is that features of a language that make it suitable for a small project (your example was a dynamic type system) may actually make is less ideal for a large project. But big-O notation can not really be applied to this problem in a tractable way.

If you are interested in this subject there are hundreds of papers in the IEEE journals of software engineering and ACM journals, they would be a very good place to start and propose many metrics you may find insightful. Definitely check out my original link.

Reply Parent Score: 2

RE[4]: Blank Stare
by RandomGuy on Wed 10th Jun 2009 23:57 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

RE[3]: Blank Stare
by rhyder on Fri 12th Jun 2009 07:05 in reply to "RE[2]: Blank Stare"
rhyder Member since:
2005-09-28

Thanks for writing the article, but I agree with others that your approach tends to obfuscate your ideas. The central idea, that it's possible to make a systematic appraisal of the applicability and efficiency of different languages for different types of problem, is interesting. I wonder if you needed to get into the technicalities of Big O, although I confess, I don't fully understand it. A graph showing that the complexity of different code increases for a given language when implementing different algorithm types might have sufficed as an explanation.

A lot will depend on where you intend to take your future articles and on your intended audience. Will this be an explanation of your idea for the general reader or will it be a treatise that specifies a precise algebraic method of programming language analysis?

Although I'm intrigued by what you're proposing, I have to agree with the other commenter when I say that, stylistically, the current article is neither fish nor foul in its approach. Good luck and I'll look out for your future attempts.

Reply Parent Score: 2