Comments on: The fallacy of high-level languages http://netsplit.com/2009/03/26/the-fallacy-of-high-level-languages/ Fri, 18 May 2012 22:45:15 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Tom Wright http://netsplit.com/2009/03/26/the-fallacy-of-high-level-languages/#comment-2048 Tom Wright Sat, 15 May 2010 21:29:36 +0000 http://www.netsplit.com/?p=200#comment-2048 I'm sorry but programming languages aside, Banshee is dazzlingly better in its interface, and generally ease of use. I’m sorry but programming languages aside, Banshee is dazzlingly better in its interface, and generally ease of use.

]]> By: Glyph Lefkowitz http://netsplit.com/2009/03/26/the-fallacy-of-high-level-languages/#comment-2047 Glyph Lefkowitz Mon, 03 May 2010 01:14:07 +0000 http://www.netsplit.com/?p=200#comment-2047 As anyone who recognizes my name will know, I have an obvious bias here, but perhaps we can cut through some of the posturing here and offer up some metrics. The only one I have is pretty old (2003) and not particularly scientific, since the feature-sets of these three bits of software aren't exactly the same, but consider this: http://www.usenix.org/events/usenix03/tech/freenix03/full_papers/lefkowitz/lefkowitz_html/index.html#sec:conch While there aren't a lot of numbers there (in particular, "development time" is conspicuously missing, but since none of these projects are ever truly finished it's somewhat difficult to pick a line in the sand for that), they do follow the general curve that the "higher level" the language is, the less code and the fewer developers you need to get roughly the same amount of work done. What are the metrics like on the community size and development time for other largely functionally-similar projects: for example, the ones mentioned in the article: Banshee vs. Rhythmbox? Git, Bazaar, and Mercurial? It's important to remember that even if the end results are largely similar (and I don't entirely agree that they are; see arguments above about security and reliability), it *does* matter if one tool lets you achieve that result with proportionally less effort. As anyone who recognizes my name will know, I have an obvious bias here, but perhaps we can cut through some of the posturing here and offer up some metrics.

The only one I have is pretty old (2003) and not particularly scientific, since the feature-sets of these three bits of software aren’t exactly the same, but consider this:

http://www.usenix.org/events/usenix03/tech/freenix03/full_papers/lefkowitz/lefkowitz_html/index.html#sec:conch

While there aren’t a lot of numbers there (in particular, “development time” is conspicuously missing, but since none of these projects are ever truly finished it’s somewhat difficult to pick a line in the sand for that), they do follow the general curve that the “higher level” the language is, the less code and the fewer developers you need to get roughly the same amount of work done.

What are the metrics like on the community size and development time for other largely functionally-similar projects: for example, the ones mentioned in the article: Banshee vs. Rhythmbox? Git, Bazaar, and Mercurial? It’s important to remember that even if the end results are largely similar (and I don’t entirely agree that they are; see arguments above about security and reliability), it *does* matter if one tool lets you achieve that result with proportionally less effort.

]]> By: Jason Carr http://netsplit.com/2009/03/26/the-fallacy-of-high-level-languages/#comment-2046 Jason Carr Fri, 30 Apr 2010 23:55:01 +0000 http://www.netsplit.com/?p=200#comment-2046 Niklas, I don't know the exact legalities behind the C# language, but I do know that everyone is free to use the language on Microsoft platforms or off (see Mono for Linux and Mac). Microsoft's compilers are free, and there are free versions of Visual Studio too, if you're interested. I know that Microsoft had a lot to do with C#'s creation, but I'm not sure that they actually own the language (though they may). Regardless, C# basically ripped off Java in every way, shape, and form. C# took Java and tweaked it heavily for Windows event driven development. I believe C# has become a much better language than Java, but Java still allows for much, much faster development than C. Niklas, I don’t know the exact legalities behind the C# language, but I do know that everyone is free to use the language on Microsoft platforms or off (see Mono for Linux and Mac). Microsoft’s compilers are free, and there are free versions of Visual Studio too, if you’re interested. I know that Microsoft had a lot to do with C#’s creation, but I’m not sure that they actually own the language (though they may).

Regardless, C# basically ripped off Java in every way, shape, and form. C# took Java and tweaked it heavily for Windows event driven development. I believe C# has become a much better language than Java, but Java still allows for much, much faster development than C.

]]> By: Costin http://netsplit.com/2009/03/26/the-fallacy-of-high-level-languages/#comment-2045 Costin Fri, 30 Apr 2010 22:10:42 +0000 http://www.netsplit.com/?p=200#comment-2045 Spot on (the author is). Spot on (the author is).

]]> By: lopgok http://netsplit.com/2009/03/26/the-fallacy-of-high-level-languages/#comment-2044 lopgok Fri, 30 Apr 2010 20:39:55 +0000 http://www.netsplit.com/?p=200#comment-2044 I have written C professionally for over 25 years. A few years ago, I rewrote about 30k lines of C code that I wrote in Python. I found a problem in my unit testing. I was sure it was something that I had done wrong in Python. It turns out that the bug wasn't in my Python code, but in my C code. I was processing characters in a string. I didn't properly process the last character in the string. In Python I did, and so the results of my unit tests differed. If speed is the issue, C is always faster. If time to develop the code is an issue, or time to maintain, or security issues is a concern, I think Python is better overall. I just looked at some bug reports in different linux distributiuons at lwn.net. About half of them related to buffer overflows or heap overflows. This is for deployed, tested, somewhat mature code. I haven't seen these kind of bug reports for code written in languages that have memory management, such as Python or Java. I have written C professionally for over 25 years. A few years ago, I rewrote about 30k lines of C code that I wrote in Python. I found a problem in my unit testing. I was sure it was something that I had done wrong in Python. It turns out that the bug wasn’t in my Python code, but in my C code. I was processing characters in a string. I didn’t properly process the last character in the string. In Python I did, and so the results of my unit tests differed.

If speed is the issue, C is always faster. If time to develop the code is an issue, or time to maintain, or security issues is a concern, I think Python is better overall.

I just looked at some bug reports in different linux distributiuons at lwn.net. About half of them related to buffer overflows or heap overflows. This is for deployed, tested, somewhat mature code.

I haven’t seen these kind of bug reports for code written in languages that have memory management, such as Python or Java.

]]> By: Niklas Cholmkvist http://netsplit.com/2009/03/26/the-fallacy-of-high-level-languages/#comment-2043 Niklas Cholmkvist Fri, 30 Oct 2009 12:24:28 +0000 http://www.netsplit.com/?p=200#comment-2043 But isn't the C# language owned by Microsoft? But isn’t the C# language owned by Microsoft?

]]> By: Jason Carr http://netsplit.com/2009/03/26/the-fallacy-of-high-level-languages/#comment-2042 Jason Carr Mon, 21 Sep 2009 18:06:30 +0000 http://www.netsplit.com/?p=200#comment-2042 This is certainly interesting, though I have to disagree. With any programming language comes a learning curve, and I'm not convinced that the learning curve is any greater for a language like C# than C (in fact, I would argue in the opposite direction). The closer we come to representing common spoken language and real life within our programming languages, the easier and faster programming will be. Clearly, C is a lot farther away from this than many modern programming languages. To say that it is just as quick or quicker to develop in C as it is to develop in C# is to throw away much of the progress that has been made in recent years. It is painfully obvious that developing a straightforward Windows (or any other GUI-based) application is much, much quicker using a modern, truly object-oriented programming language than using C, for many reasons. Some of them include fewer lines of code, better representations of real world objects, easier to read code, better designer tools (IDE GUI tools), and event-based development. C was not designed for these approaches. Straight up it is quite odd and misplaced to argue that C is just as fast or faster for development than modern languages. We all struggle with finding our comfortable favorite languages and approaches and sticking to them, but in this industry we do not have the luxury of sitting back and relaxing where we are at. I'm afraid that's what you're encouraging and fighting for here. It seems pretty silly to me. This is certainly interesting, though I have to disagree. With any programming language comes a learning curve, and I’m not convinced that the learning curve is any greater for a language like C# than C (in fact, I would argue in the opposite direction). The closer we come to representing common spoken language and real life within our programming languages, the easier and faster programming will be. Clearly, C is a lot farther away from this than many modern programming languages.

To say that it is just as quick or quicker to develop in C as it is to develop in C# is to throw away much of the progress that has been made in recent years. It is painfully obvious that developing a straightforward Windows (or any other GUI-based) application is much, much quicker using a modern, truly object-oriented programming language than using C, for many reasons. Some of them include fewer lines of code, better representations of real world objects, easier to read code, better designer tools (IDE GUI tools), and event-based development. C was not designed for these approaches.

Straight up it is quite odd and misplaced to argue that C is just as fast or faster for development than modern languages. We all struggle with finding our comfortable favorite languages and approaches and sticking to them, but in this industry we do not have the luxury of sitting back and relaxing where we are at. I’m afraid that’s what you’re encouraging and fighting for here. It seems pretty silly to me.

]]> By: Mughal http://netsplit.com/2009/03/26/the-fallacy-of-high-level-languages/#comment-2041 Mughal Sat, 20 Jun 2009 07:00:40 +0000 http://www.netsplit.com/?p=200#comment-2041 As for as the programmer is concern, language is only the tool, it depends how we utilize it. so in this regard assembly is the best giving us the full capability to handle pc's power. As for as the programmer is concern, language is only the tool, it depends how we utilize it. so in this regard assembly is the best giving us the full capability to handle pc’s power.

]]> By: xteraco http://netsplit.com/2009/03/26/the-fallacy-of-high-level-languages/#comment-2040 xteraco Sun, 19 Apr 2009 11:46:38 +0000 http://www.netsplit.com/?p=200#comment-2040 I haven't read the comments, but I agree with this post. It seems that new fads are driving people to forget how powerful our old languages are. School teaches industry standard languages. CEO's decide the industry standard language, CEO's decide what language their coders use. CEO's have no business making this type of decision. Now because n00bs all learn Java as their first language (in schools), and learn that it is "right", they will accept nothing else. I need to start a blog, maybe I can meet more people like the original poster! =D I haven’t read the comments, but I agree with this post. It seems that new fads are driving people to forget how powerful our old languages are. School teaches industry standard languages. CEO’s decide the industry standard language, CEO’s decide what language their coders use. CEO’s have no business making this type of decision. Now because n00bs all learn Java as their first language (in schools), and learn that it is “right”, they will accept nothing else.

I need to start a blog, maybe I can meet more people like the original poster! =D

]]> By: JanC http://netsplit.com/2009/03/26/the-fallacy-of-high-level-languages/#comment-2039 JanC Sun, 12 Apr 2009 05:06:35 +0000 http://www.netsplit.com/?p=200#comment-2039 Actually, using pointers is much easier to understand in assembler than it is in C, so you're right that higher level languages are the wrong way to develop software... ;-) PS: of course that's because the C syntax for using pointers is probably the worst and most inconsistent of any language in common use... Actually, using pointers is much easier to understand in assembler than it is in C, so you’re right that higher level languages are the wrong way to develop software… ;-)

PS: of course that’s because the C syntax for using pointers is probably the worst and most inconsistent of any language in common use…

]]>