If you have some history with languages with ALGOL roots, perhaps. It might also depend upon what one considers readable to mean.
for x in range(n):
pass
It might be reasonable to expect that someone would understand that this iterates over an integral range of numbers (although from what starting point they might not know), but would it at all be obvious to them that it eagerly constructs a list of length n?
def f(fn, n, xs = []):
for i in range(n):
xs.append(fn(i))
return xs
We might say that some random person that doesn't know Python might be able to determine that this defines a function that takes three arguments, one of which looks like it's a function, another that appears to be a numeric value used for creating an upper bound for iteration, and another that is meant to support some method named append. We might then say that they would be able to figure out that xs here has a default value (and as such is an optional parameter), and perhaps we'll cede that they have determined that the default value for the parameter is some empty array/list constructor. We'll then say that they can determine that this function iterates over a sequence of integers bounded by n, and appends to an optionally provided list the results of the application of the function fn to each integer within the sequence, and then returns the list as a result.
def id(x):
return x
a = [] b = f(id, 15, a) c = f(id, 2) d = f(id, 6, b) e = f(id, 5)
Is the value of e going to be obvious to our hypothetical reader? That is, do we take for granted the clarity of the one-time evaluation of the default value for the xs parameter?
a = [(x,y) for x in range(n) for y in range(n)]
b = [x for x in range(n) if not x == 5 for y in range(n) if not y == x]
Hmm. Is this going to be clear?
I'm not certain that I really have much of a point, except that any reasonably high-level language probably appears simple, trivial, and readable by the people that already know and use it. If one has a certain background, or one has a sufficiently-defined meaning for what it means to be able to easily read code then meeting that criteria is perhaps harder or more difficult.
I'm sure Smalltalk programmers would consider their language to be more easily understandable by a novice than Python, and I've seen plenty of posters on Usenet that believe that Ruby is more elegant blah blah than Python. You get the idea, I imagine.
There's a mindset in corporate/professional comp sci I like to call "fat book syndrome".
Please do not confuse O'Reilly books or Sun's Java books for Computer Science. At the best they're informative documentation of software systems, and at the worst they're little more than introductory tutorials for software systems.
Perhaps you can be less vague so that I can understand what you're claiming.
I want to believe very badly that you're not suggesting that you don't have an editor capable of visually matching parentheses and that you are not implying that there is any common interpreter for which it is the case that it is unable to properly handle nested parentheses of arbitrary depth.
Execution of code can be accomplished by a variety of means ranging from direct interpretation of a form representing a program to invocation of compiled code produced by a compiler.
Evaluation is the process by which a program is executed in Common Lisp. The mechanism of evaluation is manifested both implicitly through the effect of the Lisp read-eval-print loop, and explicitly through the presence of the functions eval, compile, compile-file, and load. Any of these facilities might share the same execution strategy, or each might use a different one.
The behavior of a conforming program processed by eval and by compile-file might differ; see Section 3.2.2.3 (Semantic Constraints).
Evaluation can be understood in terms of a model in which an interpreter recursively traverses a form performing each step of the computation as it goes. This model, which describes the semantics of Common Lisp programs, is described in Section 3.1.2 (The Evaluation Model).
evaluation n. a model whereby forms are executed, returning zero or more values. Such execution might be implemented directly in one step by an interpreter or in two steps by first compiling the form and then executing the compiled code; this choice is dependent both on context and the nature of the implementation, but in any case is not in general detectable by any program. The evaluation model is designed in such a way that a conforming implementation might legitimately have only a compiler and no interpreter, or vice versa. See Section 3.1.2 (The Evaluation Model).
3.2.2.2 Minimal Compilation
Minimal compilation is defined as follows:
All compiler macro calls appearing in the source code being compiled are expanded, if at all, at compile time; they will not be expanded at run time.
All macro and symbol macro calls appearing in the source code being compiled are expanded at compile time in such a way that they will not be expanded again at run time. macrolet and symbol-macrolet are effectively replaced by forms corresponding to their bodies in which calls to macros are replaced by their expansions.
The first argument in a load-time-value form in source code processed by compile is evaluated at compile time; in source code processed by compile-file, the compiler arranges for it to be evaluated at load time. In either case, the result of the evaluation is remembered and used later as the value of the load-time-value form at execution time.
Ah, you almost had me before I looked at your comment history.
I got as far as: Except that he did not learn the language because of some disdain for the tools with which he had been conducting himself; he learned the language as a requirement imposed upon him by his environment.
I was going to include some sardonic comment about your reading-comprehension but then I decided to see if you were a regular troll or just an idiot.
You can freely consider it a bite, since I've decided to reply anyway. Have fun.
Yahoo Store was rewritten with Perl and C++, and according to Paul Graham, the rewrite included the construction of a lisp interpreter for preserving templating. Paul was also not the exclusive author of Viaweb's product, but that's really just nitpicking.
IIRC that link you provided includes Paul's commentary about the subsequent rewrite of Yahoo Store, but if not, it's on his website somewhere.
I know a lot of people that have graduated with degrees in CS that cannot write software well; not surprising since computer science has only a little to do with actually writing software, and the undergraduate computer science curriculum is not very rigorous anyway. Grad students on average will have a much stronger basis in computer science, but there's no correlation between that and good software construction.
It's quite likely that, like most disciplines, that the there are relatively few that are especially talented at writing software, but that is largely irrelevant. That fewer people are especially talented does not mean that Random Slashdot User is a member of that group, regardless of their salary, nor that their job is especially demanding.
First time? No, you really don't know what you're talking about. The Wolf3D, Doom, Quake, and Quake 2 sources all fail to utilize algorithms and datastructures that are several decades old. Some of these are unimportant because the most-obvious performance area of interest is framerate, not loading, network performance, or what have you.
You're also a bit deluded about your history of 3D games; there were 3D games in the early '80s, and the mathematics for 3D rendering techniques has been in development since the '60s. The PC was not suitable for realtime 3D rendering, which is why Wolf3D and Doom used ray-casting. A technique that owes much to Cohen, Sutherland, Bresenham, and others. id was certainly instrumental in spearheading the PC 3D FPS craze, but it's all built upon a foundation of many people whose work neither id nor John Carmack is responsible for. All of those 3D games you see are not descendents of ideas that sprang from John Carmack's head, and he's not responsible for their existence.
What you don't seem to comprehend is that it's the "mass appeal" that matters, code quality means jack shit.
What you don't seem to comprehend is that code quality is orthogonal to its acceptance; even though I said it.
The value of code quality would certainly matter depending upon the domain.
The part that matters is the end result. Carmack DELIVERS the end result.
id has produced a few game engines; that is their result. That result is orthogonal to the quality of their software, and whether or not given some definition of "good programmer" or "bad programmer" the author(s) of that software are thus "good programmers."
His code may not be the prettiest (not sure, haven't looked at it),
You wouldn't understand it anyway; your capacity to reason is insufficient.
Do you have enough cash in the bank to fund an X-Prize team?
Yes.
Carmack does. So if you don't, I'd say you just might be focusing on pretty source code at the expense of a funtional (sic) executable.
Wealth acquisition is orthogonal to software popularity and software quality. Any member of the IE team has produced work that is more popular than all of id's games and the games of licensees combined and there's no reason to suspect that any of them are as wealthy as John Carmack.
There's an enormous difference between a "good" programmer and a "bad" programmer, especially in the gaming and graphics industries. A "bad" programmer does this: He programs just what he has to do. He doesn't critically analyze his programs. He has no sence of programming style, and follows the General bad programming rules A "good" programmer strives to innovate. Not only does he have good style, optimises his work, comments his work (basically the opposite of the advice given in the link above), but he also thinks about new ways to do something. [...] That's what makes him a good programmer.
The software written by id is inconsistent with his description of a "good programmer" and contains elements from the work of a "bad programmer."
Further, I would expect any software that is truely (sic) innovative to appear sloppy when judged after the fact.
That does not follow.
Carmack was building something new, not designing something perfect to satisfy the technology elite.
Much of what id produces is not new at all; it's just revisionary.
Since you claim to have so much knowledge of the relative quality of the code, perhaps you could explain how something you judge to be so deficient could have such an impact on game design.
There is no necessary relation between code quality and mass appeal. id develops game engines for companies to produce derivative pieces of artwork, targeted for a market consisting of people that are willing to accept arbitrarily-poor software.
The number of people that actually have to develop with the engine even after considering licensees could easily fit within a room of unspectacular capacity. The number of patch releases offered is typically only a handful, and the redress for the customer is to not buy further games from them.
Games are just casual entertainment. They don't need to be engineered to be successful. That they're successful does not mean that they are written well.
No. For one, the software released by id for which there is source code available is not an example of good programming, either in the small or the large.
If you have ever looked at the code that is released by id, which I am certain that you have not, you would immediately recognize a lot of deficiencies: a lot of things will be hard-coded, there is no coherent polymorphism and dynamic dispatch will be spread out over several source files, error conditions are not properly handled (many of which can result in crashes), no effort is made for permitting localization, suboptimal and sometimes downright horribly inefficient algorithms and datastructures are used for anything not directly related to rendering, the potential efficiency of the network is poorly utilized, there is no or poor effort to make effective use of system resources for caching, the quality of code documentation is inconsistent, the code itself makes much use of variable name abuse from the very link you provide, and then there are other design deficiencies present in their engines that are unrelated to the quality of the code itself.
These engines are small, and id really isn't a company in the business of writing software; it is in the business of writing game engines for a relatively small industry of developers in the business of writing FPS titles. The code they have released thus far has nothing in common with "software engineering" and no one should point to it as an example of how to write software. However, that is orthogonal to whether or not John Carmack has provided useful contributions to his industry, which he has, though you've exaggerated them slightly.
Is this the inquisition? I merely expressed an opinion, which you are free to disagree with.
You made a claim that your work involves more expertise; I'm asking you to prove it. If you have any sort of intellectual honesty, you will either be fully prepared to back your assertions with evidence, or if you prefer that they be unsubstantiated, refrain from making them.
You can decline, and I will of course have no reason to believe your claims. You haven't given anyone any compelling reason to believe what you say, or even take you seriously. If that's ok with you, then so be it. It's perfectly alright with me.
I think it might be that the popularity of spending 12 hours a day in front of a computer did not occur until the '90s, that is responsible for the surprising disconnect that your average Slashdot user has between their perception of their own mental capacity due to their interests and the actual reality of the talent typically demonstrated by someone in their particular business-field by a code monkey. They fail to differentiate between the field having at one time fewer members due to relative obscurity, and the prerequisite of some superlative intellect. You can certainly find many brilliant mathematicians involved in computer science, but your typical Slashdot user is more of a DB tradesman than anything else.
Are you, or have you ever been a plumber? Perhaps a mechanic?
Do you care for public appraisal of your expertise? You know, so as to demonstrate that you're not just like the other 60,000 Slashdot users that think their own particular, boring work is in the top 1%.
There is however more than one XHTML specification, and thus I cannot reference the XHTML specification, and must instead reference an XHTML specification, or the specification for some version of the standard. I think you'll find that the ambiguity of your suggestion was regretfully not resolvable a priori. That Slashdot does not make use of any version of XHTML only further necessitates the presence of clarity in making such requests, when it does not follow that any such standard would prove relevant for issues regarding the posting of comments on Slashdot.
I am also uncertain how one can place a 50-line script on a single line, unless I am to assume that you mean that extraneous line terminators have been removed been removed from a previously 50-line script, in order to construct a new one-line script sans the aforementioned extraneous line terminators. In either case I am not certain that my earlier post could sanely be argued to be the equivalent of such a one-line script, for it consumes muliple lines and does not (at least to my knowledge) contain anything resembling a script.
I also take exception to your insinuation that computers ignore whitespace. Not being cognizant, computers are quite incapable of refusing to respect any aspect of human language. If, however, we keep your premise that "only computers ignore whitespace," infer from your ability to compose dialogue on Slashdot that you are not a computer, and that therefore you do not ignore whitespace, I am left with the sensation that the argument while sound would be untrue.
As an aside, I am uncertain why you continue to use "sic" (which I read to mean Spelling Is Correct), as your usage seems to be unusual at best.
Why would I look at one of the XHTML specifications (you have neglected to indicate which version, unfortunately) for composing a post on Slashdot? That would be rather out of place, don't you think?
I'm not certain why you desire me to encapsulate my post within a paragraph tag, but I suppose I can aid you this time.
I would like to personally peruse some of your finest examples of C++ code that you have personally written. This is to ascertain whether the implicit claim of authority from 20 years of development really has any merit.
Also, unrelated to my request, it is unfortunately the case that no platform automatically ensures that all frameworks (third-party or otherwise) are constructed with homogeneous datatypes and are free of any disjoint types that are logically congruent for some given resolution of comparison but otherwise functionally different in implementation. This though is a really an example of an issue that can appear in the form of concerns regarding the "safety" of various datatypes (proper checking of preconditions, postconditions, and invariants; proper handling and propagation of exceptions; proper specification and utilization of static type constraints; consistent guarantees of reentrancy; correctness specification that is in sync with implementation), but also matters of efficiency (consistent use of the correct datatypes for the implementation of tasks; consistent use of caching infrastructure; efficient utilization of disk, network, memory, and cache resources through reuse; efficient use of available processing and heap resources through proper specialization and avoidance of unnecessary boxing, and efficient checking of contracts), matters of maintainability (being able to decide where it is necessary to make modifications for behavior to manifest uniformly throughout the system, consistent usage and storage of logging information, being able to easily integrate new frameworks into the code base), and really a lot of other things that are beyond the scope of my interest to mention. This problem has nothing inherently to do with the development platform as such, though various languages and frameworks certainly make certain issues of correctness, efficiency, and maintainability easier to manifest, the underlying problem is still much more intrinsic to the construction of software frameworks in a heterogeneous world. You can, to some varying but limited degrees of extent, deal with issues of correctness and maintainability using the adapter pattern, but this costs both time and efficiency. Back to my point, though, Java does not solve this problem. That some C++ library may not make use of an optionally or mandatory boundary-checked collection is not terribly much different than some Java library not making consistent use of (and potentially not correctly using at all) exceptions, not even having compile-time correctness guarantees of type-safety for a collection, providing poorly-specified and unchecked preconditions, not using the correct datatype(s) for given tasks, or following consistent logging.
Since when does humility have anything to do with capability? Whether or not you are exceptionally productive is orthogonal to whether or not you are exceptionally annoying.
Nothing stated in that article, the jargon file, or in anything written by Eric Raymond or Paul Graham is going to make any sort of causal link between the two extant.
Your position is at least equally as absurd as my suggesting that you are incapable of engaging in cognizant intercourse, because your pretentious proclamation of the unsubstantiated is annoying.
The measure of what, precisely? We need to decide what we're measuring before we can hope to postulate precisely how we can measure it. From your tangent about the Velvet Underground, for some reason, I don't imagine what you have in mind has anything to do with people that have insights on or develop useful software.
If you want to define "hacker" to include ostracized net.kooks, then we could probably define a way to measure that such that Eric Raymond certainly is a "great hacker." That would be a nebulous departure from people that produce the majority of the work in a software development team. I suppose given the content of Paul Graham's article, though, that that would not be out of place, though.
Let's just agree to a few ground rules: merely because one of us agrees with the assertions of another person, in the absence of details, evidence, and probably logic, neither of us will assert that individual gets unspecified things correct. We will instead say that we agree with some subset of their positions, and if we're feeling especially interested in being cogent, we'll specify which and why.
Oh, and lest I forget there's also the matter of F# which provides a subset of the Objective Caml language with interoperability with.NET. There's also OCamlIL which aims at being a more faithful implementation of Objective Caml for the CLR.
I'm uncertain what you mean when you suggest that "the current state of O'Caml is that interfacing to these kinds of 3rd party libraries (using standard DLL or share library interfaces) is almost unworkable."
Are you referring to the ability to construct bindings for shared libraries written in C? Are you referring to being able to generate bindings to shared libraries written in C? Are you referring to being able to write short annotations for introducing symbols from shared libraries written in C in OCaml code?
I suppose one of the problems with being vague is that people have no idea what you're asking.
You can write bindings to C libraries by hand using the FFI, like you can with Python, Perl, or Java.
There are ways of generating wrapper code for interfacing to shared libraries, like CamlIDL and SWIG. You could also generate interfaces for use with the Dl module.
The Caml Humps site is a good place to start looking for some of the presently available libraries.
I think a far more annoying aspect of Objective Caml is that it is not currently possible to have natively-compiled dynamic shared libraries written in Objective Caml; all programs will be statically linked to Objective Caml libraries. You can load dynamic bytecode, but that's really just not the same. There once was a program for wrapping Objective Caml code into a DLL but I don't think it has been kept up to date, it's a dirty approach, and as far as I recall it only worked on Windows. There's the SCaml effort, but it seems to be falling behind, is incomplete, and only works on a few platforms.
Lots of languages offer sizeable and internally consistent frameworks. Eiffel, for example, has a robust standard library. So do Smalltalk implementations.
Interfaces provide statically-typed polymorphism over orthogonal type hierarchies. These are useful, but I'm not certain how their presence "pushes" anyone to define component boundaries in terms of interfaces. This doesn't seem to happen in practice.
Many languages don't have separate interface and implementation files, however their presence isn't even necessarily a bad thing anyway.
Many languages had equivalents or supersets of Javadoc even before Java existed. Regardless, that's a tool matter. Some environments provide means of attaching documentation to actual code, which would at least make that a language feature for them, but Javadoc does not work this way so it's not really a language feature.
Smalltalk environments have had refactoring for a long time now. They've also been more sophisticated than IDEA or Eclipse for many years.
Slashdot Mirror
I'm not certain that I really have much of a point, except that any reasonably high-level language probably appears simple, trivial, and readable by the people that already know and use it. If one has a certain background, or one has a sufficiently-defined meaning for what it means to be able to easily read code then meeting that criteria is perhaps harder or more difficult.
I'm sure Smalltalk programmers would consider their language to be more easily understandable by a novice than Python, and I've seen plenty of posters on Usenet that believe that Ruby is more elegant blah blah than Python. You get the idea, I imagine.
There's a mindset in corporate/professional comp sci I like to call "fat book syndrome".
Please do not confuse O'Reilly books or Sun's Java books for Computer Science. At the best they're informative documentation of software systems, and at the worst they're little more than introductory tutorials for software systems.
Perhaps you can be less vague so that I can understand what you're claiming.
I want to believe very badly that you're not suggesting that you don't have an editor capable of visually matching parentheses and that you are not implying that there is any common interpreter for which it is the case that it is unable to properly handle nested parentheses of arbitrary depth.
Ah, you almost had me before I looked at your comment history.
I got as far as:
Except that he did not learn the language because of some disdain for the tools with which he had been conducting himself; he learned the language as a requirement imposed upon him by his environment.
I was going to include some sardonic comment about your reading-comprehension but then I decided to see if you were a regular troll or just an idiot.
You can freely consider it a bite, since I've decided to reply anyway. Have fun.
I don't recall seeing any of Dianora's contributions being written in brainfuck.
Yahoo Store was rewritten with Perl and C++, and according to Paul Graham, the rewrite included the construction of a lisp interpreter for preserving templating. Paul was also not the exclusive author of Viaweb's product, but that's really just nitpicking.
IIRC that link you provided includes Paul's commentary about the subsequent rewrite of Yahoo Store, but if not, it's on his website somewhere.
Not even close.
I know a lot of people that have graduated with degrees in CS that cannot write software well; not surprising since computer science has only a little to do with actually writing software, and the undergraduate computer science curriculum is not very rigorous anyway. Grad students on average will have a much stronger basis in computer science, but there's no correlation between that and good software construction.
It's quite likely that, like most disciplines, that the there are relatively few that are especially talented at writing software, but that is largely irrelevant. That fewer people are especially talented does not mean that Random Slashdot User is a member of that group, regardless of their salary, nor that their job is especially demanding.
First time? No, you really don't know what you're talking about. The Wolf3D, Doom, Quake, and Quake 2 sources all fail to utilize algorithms and datastructures that are several decades old. Some of these are unimportant because the most-obvious performance area of interest is framerate, not loading, network performance, or what have you.
You're also a bit deluded about your history of 3D games; there were 3D games in the early '80s, and the mathematics for 3D rendering techniques has been in development since the '60s. The PC was not suitable for realtime 3D rendering, which is why Wolf3D and Doom used ray-casting. A technique that owes much to Cohen, Sutherland, Bresenham, and others. id was certainly instrumental in spearheading the PC 3D FPS craze, but it's all built upon a foundation of many people whose work neither id nor John Carmack is responsible for. All of those 3D games you see are not descendents of ideas that sprang from John Carmack's head, and he's not responsible for their existence.
Is John Hughes a good programmer?
What you don't seem to comprehend is that it's the "mass appeal" that matters, code quality means jack shit.
What you don't seem to comprehend is that code quality is orthogonal to its acceptance; even though I said it.
The value of code quality would certainly matter depending upon the domain.
The part that matters is the end result. Carmack DELIVERS the end result.
id has produced a few game engines; that is their result. That result is orthogonal to the quality of their software, and whether or not given some definition of "good programmer" or "bad programmer" the author(s) of that software are thus "good programmers."
His code may not be the prettiest (not sure, haven't looked at it),
You wouldn't understand it anyway; your capacity to reason is insufficient.
Do you have enough cash in the bank to fund an X-Prize team?
Yes.
Carmack does. So if you don't, I'd say you just might be focusing on pretty source code at the expense of a funtional (sic) executable.
Wealth acquisition is orthogonal to software popularity and software quality. Any member of the IE team has produced work that is more popular than all of id's games and the games of licensees combined and there's no reason to suspect that any of them are as wealthy as John Carmack.
To make a long story short, Shut The Fuck Up.
How about 'no?'
There's an enormous difference between a "good" programmer and a "bad" programmer, especially in the gaming and graphics industries.
A "bad" programmer does this: He programs just what he has to do. He doesn't critically analyze his programs. He has no sence of programming style, and follows the General bad programming rules
A "good" programmer strives to innovate. Not only does he have good style, optimises his work, comments his work (basically the opposite of the advice given in the link above), but he also thinks about new ways to do something.
[...]
That's what makes him a good programmer.
The software written by id is inconsistent with his description of a "good programmer" and contains elements from the work of a "bad programmer."
Further, I would expect any software that is truely (sic) innovative to appear sloppy when judged after the fact.
That does not follow.
Carmack was building something new, not designing something perfect to satisfy the technology elite.
Much of what id produces is not new at all; it's just revisionary.
Since you claim to have so much knowledge of the relative quality of the code, perhaps you could explain how something you judge to be so deficient could have such an impact on game design.
There is no necessary relation between code quality and mass appeal. id develops game engines for companies to produce derivative pieces of artwork, targeted for a market consisting of people that are willing to accept arbitrarily-poor software.
The number of people that actually have to develop with the engine even after considering licensees could easily fit within a room of unspectacular capacity. The number of patch releases offered is typically only a handful, and the redress for the customer is to not buy further games from them.
Games are just casual entertainment. They don't need to be engineered to be successful. That they're successful does not mean that they are written well.
No. For one, the software released by id for which there is source code available is not an example of good programming, either in the small or the large.
If you have ever looked at the code that is released by id, which I am certain that you have not, you would immediately recognize a lot of deficiencies: a lot of things will be hard-coded, there is no coherent polymorphism and dynamic dispatch will be spread out over several source files, error conditions are not properly handled (many of which can result in crashes), no effort is made for permitting localization, suboptimal and sometimes downright horribly inefficient algorithms and datastructures are used for anything not directly related to rendering, the potential efficiency of the network is poorly utilized, there is no or poor effort to make effective use of system resources for caching, the quality of code documentation is inconsistent, the code itself makes much use of variable name abuse from the very link you provide, and then there are other design deficiencies present in their engines that are unrelated to the quality of the code itself.
These engines are small, and id really isn't a company in the business of writing software; it is in the business of writing game engines for a relatively small industry of developers in the business of writing FPS titles. The code they have released thus far has nothing in common with "software engineering" and no one should point to it as an example of how to write software. However, that is orthogonal to whether or not John Carmack has provided useful contributions to his industry, which he has, though you've exaggerated them slightly.
Is this the inquisition? I merely expressed an opinion, which you are free to disagree with.
You made a claim that your work involves more expertise; I'm asking you to prove it. If you have any sort of intellectual honesty, you will either be fully prepared to back your assertions with evidence, or if you prefer that they be unsubstantiated, refrain from making them.
You can decline, and I will of course have no reason to believe your claims. You haven't given anyone any compelling reason to believe what you say, or even take you seriously. If that's ok with you, then so be it. It's perfectly alright with me.
I think it might be that the popularity of spending 12 hours a day in front of a computer did not occur until the '90s, that is responsible for the surprising disconnect that your average Slashdot user has between their perception of their own mental capacity due to their interests and the actual reality of the talent typically demonstrated by someone in their particular business-field by a code monkey. They fail to differentiate between the field having at one time fewer members due to relative obscurity, and the prerequisite of some superlative intellect. You can certainly find many brilliant mathematicians involved in computer science, but your typical Slashdot user is more of a DB tradesman than anything else.
Are you, or have you ever been a plumber? Perhaps a mechanic?
Do you care for public appraisal of your expertise? You know, so as to demonstrate that you're not just like the other 60,000 Slashdot users that think their own particular, boring work is in the top 1%.
There is however more than one XHTML specification, and thus I cannot reference the XHTML specification, and must instead reference an XHTML specification, or the specification for some version of the standard. I think you'll find that the ambiguity of your suggestion was regretfully not resolvable a priori. That Slashdot does not make use of any version of XHTML only further necessitates the presence of clarity in making such requests, when it does not follow that any such standard would prove relevant for issues regarding the posting of comments on Slashdot.
I am also uncertain how one can place a 50-line script on a single line, unless I am to assume that you mean that extraneous line terminators have been removed been removed from a previously 50-line script, in order to construct a new one-line script sans the aforementioned extraneous line terminators. In either case I am not certain that my earlier post could sanely be argued to be the equivalent of such a one-line script, for it consumes muliple lines and does not (at least to my knowledge) contain anything resembling a script.
I also take exception to your insinuation that computers ignore whitespace. Not being cognizant, computers are quite incapable of refusing to respect any aspect of human language. If, however, we keep your premise that "only computers ignore whitespace," infer from your ability to compose dialogue on Slashdot that you are not a computer, and that therefore you do not ignore whitespace, I am left with the sensation that the argument while sound would be untrue.
As an aside, I am uncertain why you continue to use "sic" (which I read to mean Spelling Is Correct), as your usage seems to be unusual at best.
I'm not certain why you desire me to encapsulate my post within a paragraph tag, but I suppose I can aid you this time.
I would like to personally peruse some of your finest examples of C++ code that you have personally written. This is to ascertain whether the implicit claim of authority from 20 years of development really has any merit.
Also, unrelated to my request, it is unfortunately the case that no platform automatically ensures that all frameworks (third-party or otherwise) are constructed with homogeneous datatypes and are free of any disjoint types that are logically congruent for some given resolution of comparison but otherwise functionally different in implementation.
This though is a really an example of an issue that can appear in the form of concerns regarding the "safety" of various datatypes (proper checking of preconditions, postconditions, and invariants; proper handling and propagation of exceptions; proper specification and utilization of static type constraints; consistent guarantees of reentrancy; correctness specification that is in sync with implementation), but also matters of efficiency (consistent use of the correct datatypes for the implementation of tasks; consistent use of caching infrastructure; efficient utilization of disk, network, memory, and cache resources through reuse; efficient use of available processing and heap resources through proper specialization and avoidance of unnecessary boxing, and efficient checking of contracts), matters of maintainability (being able to decide where it is necessary to make modifications for behavior to manifest uniformly throughout the system, consistent usage and storage of logging information, being able to easily integrate new frameworks into the code base), and really a lot of other things that are beyond the scope of my interest to mention.
This problem has nothing inherently to do with the development platform as such, though various languages and frameworks certainly make certain issues of correctness, efficiency, and maintainability easier to manifest, the underlying problem is still much more intrinsic to the construction of software frameworks in a heterogeneous world.
You can, to some varying but limited degrees of extent, deal with issues of correctness and maintainability using the adapter pattern, but this costs both time and efficiency.
Back to my point, though, Java does not solve this problem. That some C++ library may not make use of an optionally or mandatory boundary-checked collection is not terribly much different than some Java library not making consistent use of (and potentially not correctly using at all) exceptions, not even having compile-time correctness guarantees of type-safety for a collection, providing poorly-specified and unchecked preconditions, not using the correct datatype(s) for given tasks, or following consistent logging.
Since when does humility have anything to do with capability? Whether or not you are exceptionally productive is orthogonal to whether or not you are exceptionally annoying.
Nothing stated in that article, the jargon file, or in anything written by Eric Raymond or Paul Graham is going to make any sort of causal link between the two extant.
Your position is at least equally as absurd as my suggesting that you are incapable of engaging in cognizant intercourse, because your pretentious proclamation of the unsubstantiated is annoying.
The measure of what, precisely? We need to decide what we're measuring before we can hope to postulate precisely how we can measure it. From your tangent about the Velvet Underground, for some reason, I don't imagine what you have in mind has anything to do with people that have insights on or develop useful software.
If you want to define "hacker" to include ostracized net.kooks, then we could probably define a way to measure that such that Eric Raymond certainly is a "great hacker." That would be a nebulous departure from people that produce the majority of the work in a software development team. I suppose given the content of Paul Graham's article, though, that that would not be out of place, though.
Let's just agree to a few ground rules: merely because one of us agrees with the assertions of another person, in the absence of details, evidence, and probably logic, neither of us will assert that individual gets unspecified things correct. We will instead say that we agree with some subset of their positions, and if we're feeling especially interested in being cogent, we'll specify which and why.
Oh, and lest I forget there's also the matter of F# which provides a subset of the Objective Caml language with interoperability with .NET. There's also OCamlIL which aims at being a more faithful implementation of Objective Caml for the CLR.
I'm uncertain what you mean when you suggest that "the current state of O'Caml is that interfacing to these kinds of 3rd party libraries (using standard DLL or share library interfaces) is almost unworkable."
Are you referring to the ability to construct bindings for shared libraries written in C? Are you referring to being able to generate bindings to shared libraries written in C? Are you referring to being able to write short annotations for introducing symbols from shared libraries written in C in OCaml code?
I suppose one of the problems with being vague is that people have no idea what you're asking.
You can write bindings to C libraries by hand using the FFI, like you can with Python, Perl, or Java.
There are ways of generating wrapper code for interfacing to shared libraries, like CamlIDL and SWIG. You could also generate interfaces for use with the Dl module.
The Caml Humps site is a good place to start looking for some of the presently available libraries.
I think a far more annoying aspect of Objective Caml is that it is not currently possible to have natively-compiled dynamic shared libraries written in Objective Caml; all programs will be statically linked to Objective Caml libraries. You can load dynamic bytecode, but that's really just not the same.
There once was a program for wrapping Objective Caml code into a DLL but I don't think it has been kept up to date, it's a dirty approach, and as far as I recall it only worked on Windows.
There's the SCaml effort, but it seems to be falling behind, is incomplete, and only works on a few platforms.
Lots of languages offer sizeable and internally consistent frameworks. Eiffel, for example, has a robust standard library. So do Smalltalk implementations.
Interfaces provide statically-typed polymorphism over orthogonal type hierarchies. These are useful, but I'm not certain how their presence "pushes" anyone to define component boundaries in terms of interfaces. This doesn't seem to happen in practice.
Many languages don't have separate interface and implementation files, however their presence isn't even necessarily a bad thing anyway.
Many languages had equivalents or supersets of Javadoc even before Java existed. Regardless, that's a tool matter. Some environments provide means of attaching documentation to actual code, which would at least make that a language feature for them, but Javadoc does not work this way so it's not really a language feature.
Smalltalk environments have had refactoring for a long time now. They've also been more sophisticated than IDEA or Eclipse for many years.