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 367809
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Blank Stare
by voidlogic on Wed 10th Jun 2009 22:40 UTC 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[5]: Blank Stare
by voidlogic on Thu 11th Jun 2009 01:04 in reply to "RE[4]: Blank Stare"
voidlogic Member since:
2005-09-03

Just a few thoughts:

"...Maybe that was too subtle."

Unfortunately, any article read outside a close group of friends is inherently going to be viewed as attempting to be authoritative.

"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...."

Verbosity is somewhat correlated with effort. Not entirely, as I can take the same amount of time to write a 100 line Haskell program as a 800 line java program that do the same thing. Perhaps exploring the best way to quantify effort would be a good start. Although this is of course hard because humans and their varying skill levels are involved.

"it can obviously only measure programming language _implementations_, not the languages themselves."

I agree, perhaps this merits a discussion off whether it is possible at all. I would find in unsurprising if measuring implementations was all that is possible. There are of course many other ways to compare languages, such as their position in the Chomsky hierarchy and family (procedural, functional, logic, etc).

"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.."

If you are examining a set of example implementation of an algorithm, it may be valuable as a metric to understand the "effort" of the average programmer using this language, even if it says nothing about the theoretical construct itself. I would also like to point out your use of the "Turing completeness" is incorrect, you may want to look into the term in more detail.

My advise concerning presenting idea such as you are would be a to read many of the informal proposals by Edgar Dijkstra. Also, don't be afraid to take another page if that is the cost of being more precise. The difference between philosophy and theoretical computer science is mathematical formalism, people like it.

"Were you thinking of a specific forum? "

Check out the IRC channels on frenode, use groups and google groups. I didn't have a specific one in mind.

If you would like I would be willing to critique your future articles and at least tell you what I would guess people would not like.

Take care.

Reply Parent Score: 2