Prev: Pathfinding algorithm bugged?
Next: Counting lines of code produced as a metric of programmer quality
From: Maciej Sobczak on 24 Mar 2010 04:31 On 24 Mar, 07:33, "Martin Krischik" <krisc...(a)users.sourceforge.net> wrote: > > Are they supposed to make products for those platforms that they > > consider inferior? Why? > > Self fulfilling prophecy? > > Consider something inferior and then rigged the test condition to prove > the point? That's one possibility. The other is: make a test (however naive), find the best platform (according to the test) and make products that target it. That would be actually rational. We can speculate, but objectively we don't know which is the case here and the innocent-until-proved-guilty rule of the modern society should prevent us from making unfounded accusations. I play the devil's advocate role here, but really I see no reasons to make a noise about this paper. Especially if Ada is not even being mentioned. From the Ada point of view this paper is neither right nor wrong. Heck - it is actually off-topic here. :-) -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4
From: Warren on 24 Mar 2010 11:07 Patrick Scheible expounded in news:w9z39zqlr2s.fsf(a)zipcon.net: > Warren <ve3wwg(a)gmail.com> writes: > >> balson expounded in news:4BA8BA91.4050905(a)cherrystonesoftware.com: >> >> > Andrea Taverna wrote: >> >> Hi folks! >> > [snip] >> >> In the past I used C, but now I have decided to change language. >> >> I'm looking for a "better" one. >> >> >> >> Here follow the features it should have, ranked approximately by >> >> relevance: >> >> >> >> 0) open-source support and an alive community >> >> 1) directly compiled to efficient code >> >> 2) statically typed and object-oriented, better if multi-paradigm >> >> 3) general-purpose libraries (possibly standardized, either by >> >> standard or de facto), including containers and some math >> >> abstractions. 4) garbage collected. As an alternative, provide >> >> memory management policies via libraries (e.g. memory pools and >> >> such) 5) optional run-time checks and some kind of control over >> >> compilation and low-level issues >> >> 6) "relatively simple and consistent" >> > >> > Where's performance on this list? >> >> Performance is mentioned in "1) directly compiled to efficient >> code". >> >> > IOW, stay away from the likes of Java, C#, Pascal. Unless you >> > have a >> > very specific reason for going in that direction. Your performance >> > will suffer. >> > Jim >> >> I don't think many people would be surprised by these results. >> After all Java, C# and Pascal (variants) are still largely >> interpreted languages, even if they use some sort of compiled >> intermediate code. > > Pascal is not an interpreted language. One of Pascal's selling points > was that it was one of the first languages that could be parsed by a > simple recursive descent parser without backtracking. > > -- Patrick P-code implementations were. Warren
From: Warren on 24 Mar 2010 11:15 Jim Balson expounded in news:4BA8FD54.8020200(a)cherrystonesoftware.com: > J-P. Rosen wrote: >> balson a écrit : >>> IOW, stay away from the likes of Java, C#, Pascal. Unless you >>> have a >>> very specific reason for going in that direction. Your performance >>> will suffer. >>> >> I don't see why you put Pascal in the same basket. Pascal is not part >> of the benchmark, therefore there is no evidence for what you say, >> and Pascal does not require an interpreter or semi-interpreter. > > I included Pascal because once you get up into languages that do > bounds checking, performance will degrade. ... Leave out bounds checking, and quality will degrade. Warren
From: Patrick Scheible on 24 Mar 2010 17:11 Warren <ve3wwg(a)gmail.com> writes: > Patrick Scheible expounded in news:w9z39zqlr2s.fsf(a)zipcon.net: > > > Warren <ve3wwg(a)gmail.com> writes: > > > >> balson expounded in news:4BA8BA91.4050905(a)cherrystonesoftware.com: > >> > >> > Andrea Taverna wrote: > >> >> Hi folks! > >> > [snip] > >> >> In the past I used C, but now I have decided to change language. > >> >> I'm looking for a "better" one. > >> >> > >> >> Here follow the features it should have, ranked approximately by > >> >> relevance: > >> >> > >> >> 0) open-source support and an alive community > >> >> 1) directly compiled to efficient code > >> >> 2) statically typed and object-oriented, better if multi-paradigm > >> >> 3) general-purpose libraries (possibly standardized, either by > >> >> standard or de facto), including containers and some math > >> >> abstractions. 4) garbage collected. As an alternative, provide > >> >> memory management policies via libraries (e.g. memory pools and > >> >> such) 5) optional run-time checks and some kind of control over > >> >> compilation and low-level issues > >> >> 6) "relatively simple and consistent" > >> > > >> > Where's performance on this list? > >> > >> Performance is mentioned in "1) directly compiled to efficient > >> code". > >> > >> > IOW, stay away from the likes of Java, C#, Pascal. Unless you > >> > have a > >> > very specific reason for going in that direction. Your performance > >> > will suffer. > >> > Jim > >> > >> I don't think many people would be surprised by these results. > >> After all Java, C# and Pascal (variants) are still largely > >> interpreted languages, even if they use some sort of compiled > >> intermediate code. > > > > Pascal is not an interpreted language. One of Pascal's selling points > > was that it was one of the first languages that could be parsed by a > > simple recursive descent parser without backtracking. > > > > -- Patrick > > P-code implementations were. True. But P-code was for student use, not production, especially not production in an application where execution time was critical. -- Patrick
From: Pascal J. Bourguignon on 24 Mar 2010 17:27
Patrick Scheible <kkt(a)zipcon.net> writes: > Warren <ve3wwg(a)gmail.com> writes: > >> Patrick Scheible expounded in news:w9z39zqlr2s.fsf(a)zipcon.net: >> >> > Warren <ve3wwg(a)gmail.com> writes: >> > >> >> balson expounded in news:4BA8BA91.4050905(a)cherrystonesoftware.com: >> >> >> >> > Andrea Taverna wrote: >> >> >> Hi folks! >> >> > [snip] >> >> >> In the past I used C, but now I have decided to change language. >> >> >> I'm looking for a "better" one. >> >> >> >> >> >> Here follow the features it should have, ranked approximately by >> >> >> relevance: >> >> >> >> >> >> 0) open-source support and an alive community >> >> >> 1) directly compiled to efficient code >> >> >> 2) statically typed and object-oriented, better if multi-paradigm >> >> >> 3) general-purpose libraries (possibly standardized, either by >> >> >> standard or de facto), including containers and some math >> >> >> abstractions. 4) garbage collected. As an alternative, provide >> >> >> memory management policies via libraries (e.g. memory pools and >> >> >> such) 5) optional run-time checks and some kind of control over >> >> >> compilation and low-level issues >> >> >> 6) "relatively simple and consistent" >> >> > >> >> > Where's performance on this list? >> >> >> >> Performance is mentioned in "1) directly compiled to efficient >> >> code". >> >> >> >> > IOW, stay away from the likes of Java, C#, Pascal. Unless you >> >> > have a >> >> > very specific reason for going in that direction. Your performance >> >> > will suffer. >> >> > Jim >> >> >> >> I don't think many people would be surprised by these results. >> >> After all Java, C# and Pascal (variants) are still largely >> >> interpreted languages, even if they use some sort of compiled >> >> intermediate code. This is wrong. The most common implementations of these languages are all compilers. The fact that the compiled code is later executed by a hardware processor or a software processor (a "virtual machine") is irrelevant to the workings of the implementation of the language. >> > Pascal is not an interpreted language. One of Pascal's selling points >> > was that it was one of the first languages that could be parsed by a >> > simple recursive descent parser without backtracking. >> > >> > -- Patrick >> >> P-code implementations were. > > True. But P-code was for student use, not production, especially not > production in an application where execution time was critical. This is wrong. P-code was designed, and used, exactly like the JVM is today. There even were developed processors that executed directly P-code, natively, like we have JVM implemented in hardware too. -- __Pascal Bourguignon__ |