Teabaggers don't care about lower taxes any more than anyone else does. While Bush/Cheney and their Republican Congress were busy running up $TRILLIONS in debt and destroying the economy that could pay it off, Teabaggers were busy voting for them.
Teabaggers care about threats to create fear to force political change. That is the definition of terrorist. It's also the definition of teabaggers.
Shell pipes can be tree structured using tee . I used MS PowerShell through all of 2010 to script MSSQLServer, and I really loved it. It was like they stole the best features from Perl, Java and shellscript, made it object oriented and opened the whole.Net (and installed apps) API with it. I haven't kept up with Perl or Javascript in years, but if either of those languages could adopt the object pipelines and OS registry of all installed classes for an interpreted language that worked like PowerShell, I'd be pretty happy.
Though ultimately what I really want apart from these tools is a language that can flip back and forth between a dataflow graph and lexical structures, editing either. I loved ProGraph on the Mac, but it got wiped out when it targeted Windows instead of the Web in 1995. Shell pipes and Lisp sublists are hints at such a beast. What I'd want would be a lexical/graph editor of object dataflows, with the objects and their data connections stored in RDBMS and executed in a Java app server. Bytecode should be renderable into graphs or any of the languages that compile to bytecode these days, including Perl, Python, Java, Ruby, and I believe CIL C# etc. I'd love to code functions in whichever language was more apt to the function, and hook up their calling interfaces with explicit call graphs. I'm tired of embedding SQL strings in Java code wrappers; I want to just call SQL returning recordsets directly like RecordSet results = SELECT * FROM news WHERE topic IN (prefs.getSubscriptions()) AND dateline=TODAY();
The new Intel Atom/FPGA and Xilinx ARM/FPGA chips might be the platform where this actually works. Running a JVM on one ARM9 core and the C/asm Linux OS on the other core, interconnecting buses and RAM through gates circuits, might expose all these various interfaces in an open scope where all the programming approaches could be mixed, processed by whichever HW/SW is given access, even within a single process. The open SW makes porting code across boundaries possible and even likely.
In 1982 I was happy to get for my 48KB RAM Atari 400 Deep Blue C, which was a lot more than just the Atari Assembler/Editor cartridge, even if not fully C. It was certainly a lot more than call -151 on an Apple ][+. And though it was not quite as powerful as fig-forth, it was certainly a lot more useful in the long run. And the "punctuated spectrum" from machine code to keyed-in assembler to assembler/editor to C compiler was the basic training for computing that I continue to tap today, heading towards a half-century later.
What I really want is to store all my source code in a relational database. Maybe one line of source text in a column, with revision data in other columns. Maybe even store the lines as sequences of tokens, with formatting in another table. Then generating source files for editing and compiling. I don't like text blobs that only a compiler can give me metadata on, and in which formatting (including line terminators like semicolons, but also braces/whitespace) and even variable/method/class names are changeable on demand. And relatable for stats, etc. A MySQL or Postgres module that is a compiler, even just to render the tokens and resolve references into key references, would be cool. And generate text that SVN and other lexical source management tools consume to deliver their features.
Then we wouldn't have to deal with style questions about braces and other cosmetics that matter to humans but not machines. And work with our code relationally, like we do so much else.
This is not pissing in the wind. I did not say it's simply "less correct". I said it's semantically less correct, because it is. Because the human semantics of a language that's higher level than assembly are important semantics, and valuable in human terms. As a human, one with expertise in semantics beyond even just computer languages, I am quite qualified to judge the semantic correctness of languages.
Just because you're not qualified to relate human semantics to programming languages, or even to post as anything but AC, doesn't give you any standing to tell me to quit doing anything.
I said "semantically", not "syntactically". Programming languages are an interface between humans and machines (and between humans and humans), not just between machines. Semantics include meanings beyond the strict syntax, including implications that machines do not process.
In English, "increment p" is rendered in C "++p". In English, "p++" means "p, then increment it". That's why "++p" is semantically more correct.
I'm always curious about these observed supernova events. How long do they last in a well-defined event? Even if not visible to the unassisted human eye at cloudless night, how long by optical telescope? How long can the more subtle beginnings and endings be seen with radar telescope and our more advanced instruments?
Milliseconds? Minutes? Hours? Days? Months? Lifetimes? Planetary lifetimes? Depends on the supernova?
A newline at the end of a long line is indistinguishable from a wordwrapped long line. There are lots of long lines that wordwrap in complex code. Especially with long variable names, which are also a better practice than K&R's single character vars (that have been far too influential for comfort).
As for braces vs parenthesis, I agree. I'd prefer that all ()s, []s, and {}s were interchangeable (but required to match in open/close), just as in English and algebra. But {}s for blocks are no big deal. Nor is the semicolon, which explicitly ends a statement. Whitespace is ambiguous.
Any language that can read and write values in the HW - CPU, buses, chipset and RAM - can be used write an OS. Or any language that can do so after being compiled (which largely depends on the compiler).
But whether any old language is good for writing an OS is another story. If the language has few people with OS-caliber skills to read or write it, probably not. If the language is inflexible in its style, or low performance in its execution (eg. few result bits per op), probably not.
Java for example seems like a good OS language - especially for a distributed/virtual machine, as that's its native target HW - despite its abstraction away from bits and memory. Javascript does not, since it's not very expressive in manipulating bits, and its programming community relies on high level objects like the DOM and browser app for most techniques.
This project would interest me (a little) if the assembly that the C# is compiled to were run on silicon that executed CIL as machine instructions. Even if the CIL implementation were microcode that invoked x86 instructions, or a Transmeta-type on the fly conversion to native instructions.
. would have been just fine, both for humans and compilers to read. Indeed, no space between the line's statement and its terminating semicolon is harder for humans and compilers.
I dunno, after a year or so I had the multilevel meaning of int *foo, and liked seeing a list of ints, even if some were dereferences.
I think using "->" in "struct->elem" was their biggest mistake, because it's not a single character. ++, +=, || and their like aren't so bad, because they're akin to functions, which can have arbitrary character length names.
Yet ItA has been read directly by so few, and its principles rigorously worked by so few, relative to K&R that K&R is clearly more influential. A step further would say that Principia Mathematica is the most influential programming book.
I know better than K&R (did). Of course, I have the benefit of over 30 years programming after their book was published, starting only a year prior; they had only a decade or less experience when they published, among a vastly smaller society of peers to argue with.
I won't like any language that requires a text editor more complex than notepad to generate readable code. Certainly not one that requires a post-processing indenter.
In fact I wish C used only ()s, not []s or {}s. And that every () indicated a function call, including to implicit list processors.
Yet somehow I hate Lisp as unreadable. I'd probably be happier if C used only ()s, but allowed (matched) []s or {}s interchangeably. Just as we do in English parenthesizing and consequently in algebra.
The result is the same in either style. But the reason the ++var style is better sylistically is that it implies only "increment var", and not the other moot effects the other poster mentioned.
And as a parting shot, damn I hate seeing opening curly braces alone on an otherwise blank line! It's just ugly! Good code should be pretty.
So an open brace at the end of a line, that doesn't align in a column with its closing brace, is pretty? The column-aligned braces are prettier, and easier to match by eye. And harder to miss at the right end of a line that's beyond the margin of the viewport. Or which wraps to the next line, of course usually as the 81st (or 133rd, etc) character. Which satisfies "pretty" in my eyes, but is not reliably persistent across viewport instances.
There's no reason the PDP-11 C compiler couldn't have seen *++p and compiled it to the instructions INC p and *p (or whatever the actual opcodes are). The C language itself should have both, but when the programmer is saying only "increment p", ++p is semantically more correct than is p++.
The problem with my preference in C++ is that nobody would have taken seriously a language called "++C";).
What you just said about C is not true. There is no implication that any two successive statements are related at all, except that their variables are in the same containing scope (except any overrides in any {} block in one statement).
Does int a = 5.; or int a = 5.b; mean something syntactically valid? Or 5.b = 5.6 ?
int a = 5.2. isn't bad at all, as we experience in English all the time. Though I do type to humans including trailing whitespace after code symbols before punctuation, as the symbol name is defined by "between whitespace" in most languages (except Mac, and then Windows, filenames).
So int a = 5 . int a = 5.2 .
What's so hard about that? It looks like the language we've been writing for years before we ever wrote it to a computer.
CRs are indistinguishable from other whitespace. Which is why I like statements to have a visible character ending them. Which also lets me include multiple statements in a single line when that composition is meaningful, like for(i=lowNum, j=hiNum; ij; ++i, ++j) { foo(i, j); } . If anything C (and derivatives like Java and Perl) should end a "{}" block with a ";" , and leave a "{}" block without a semicolon as an expression rather than a statement.
No, I blame the language for requiring people to do something as tedious as "indent properly". The indenting character is indistinguishable from the non-characters after the indent. The compiler should permit extra whitespace and clean it up. Not doing that is a trap.
The language is a tool for human convenience. Not some extra set of skills that don't solve the problem, but instead just create more problem for the programmer to solve.
Slashdot Mirror
Teabaggers don't care about lower taxes any more than anyone else does. While Bush/Cheney and their Republican Congress were busy running up $TRILLIONS in debt and destroying the economy that could pay it off, Teabaggers were busy voting for them.
Teabaggers care about threats to create fear to force political change. That is the definition of terrorist. It's also the definition of teabaggers.
No imagination necessary to know that you're nothing but a puny troll. You have time for that spittle? Loser.
Shell pipes can be tree structured using tee . I used MS PowerShell through all of 2010 to script MSSQLServer, and I really loved it. It was like they stole the best features from Perl, Java and shellscript, made it object oriented and opened the whole .Net (and installed apps) API with it. I haven't kept up with Perl or Javascript in years, but if either of those languages could adopt the object pipelines and OS registry of all installed classes for an interpreted language that worked like PowerShell, I'd be pretty happy.
Though ultimately what I really want apart from these tools is a language that can flip back and forth between a dataflow graph and lexical structures, editing either. I loved ProGraph on the Mac, but it got wiped out when it targeted Windows instead of the Web in 1995. Shell pipes and Lisp sublists are hints at such a beast. What I'd want would be a lexical/graph editor of object dataflows, with the objects and their data connections stored in RDBMS and executed in a Java app server. Bytecode should be renderable into graphs or any of the languages that compile to bytecode these days, including Perl, Python, Java, Ruby, and I believe CIL C# etc. I'd love to code functions in whichever language was more apt to the function, and hook up their calling interfaces with explicit call graphs. I'm tired of embedding SQL strings in Java code wrappers; I want to just call SQL returning recordsets directly like RecordSet results = SELECT * FROM news WHERE topic IN (prefs.getSubscriptions()) AND dateline=TODAY();
The new Intel Atom/FPGA and Xilinx ARM/FPGA chips might be the platform where this actually works. Running a JVM on one ARM9 core and the C/asm Linux OS on the other core, interconnecting buses and RAM through gates circuits, might expose all these various interfaces in an open scope where all the programming approaches could be mixed, processed by whichever HW/SW is given access, even within a single process. The open SW makes porting code across boundaries possible and even likely.
After all, a man can dream.
In 1982 I was happy to get for my 48KB RAM Atari 400 Deep Blue C, which was a lot more than just the Atari Assembler/Editor cartridge, even if not fully C. It was certainly a lot more than call -151 on an Apple ][+. And though it was not quite as powerful as fig-forth, it was certainly a lot more useful in the long run. And the "punctuated spectrum" from machine code to keyed-in assembler to assembler/editor to C compiler was the basic training for computing that I continue to tap today, heading towards a half-century later.
I increasingly use named blocks in Java.
What I really want is to store all my source code in a relational database. Maybe one line of source text in a column, with revision data in other columns. Maybe even store the lines as sequences of tokens, with formatting in another table. Then generating source files for editing and compiling. I don't like text blobs that only a compiler can give me metadata on, and in which formatting (including line terminators like semicolons, but also braces/whitespace) and even variable/method/class names are changeable on demand. And relatable for stats, etc. A MySQL or Postgres module that is a compiler, even just to render the tokens and resolve references into key references, would be cool. And generate text that SVN and other lexical source management tools consume to deliver their features.
Then we wouldn't have to deal with style questions about braces and other cosmetics that matter to humans but not machines. And work with our code relationally, like we do so much else.
This is not pissing in the wind. I did not say it's simply "less correct". I said it's semantically less correct, because it is. Because the human semantics of a language that's higher level than assembly are important semantics, and valuable in human terms. As a human, one with expertise in semantics beyond even just computer languages, I am quite qualified to judge the semantic correctness of languages.
Just because you're not qualified to relate human semantics to programming languages, or even to post as anything but AC, doesn't give you any standing to tell me to quit doing anything.
Goodbye.
I said "semantically", not "syntactically". Programming languages are an interface between humans and machines (and between humans and humans), not just between machines. Semantics include meanings beyond the strict syntax, including implications that machines do not process.
In English, "increment p" is rendered in C "++p". In English, "p++" means "p, then increment it". That's why "++p" is semantically more correct.
I'm always curious about these observed supernova events. How long do they last in a well-defined event? Even if not visible to the unassisted human eye at cloudless night, how long by optical telescope? How long can the more subtle beginnings and endings be seen with radar telescope and our more advanced instruments?
Milliseconds? Minutes? Hours? Days? Months? Lifetimes? Planetary lifetimes? Depends on the supernova?
A newline at the end of a long line is indistinguishable from a wordwrapped long line. There are lots of long lines that wordwrap in complex code. Especially with long variable names, which are also a better practice than K&R's single character vars (that have been far too influential for comfort).
As for braces vs parenthesis, I agree. I'd prefer that all ()s, []s, and {}s were interchangeable (but required to match in open/close), just as in English and algebra. But {}s for blocks are no big deal. Nor is the semicolon, which explicitly ends a statement. Whitespace is ambiguous.
Any language that can read and write values in the HW - CPU, buses, chipset and RAM - can be used write an OS. Or any language that can do so after being compiled (which largely depends on the compiler).
But whether any old language is good for writing an OS is another story. If the language has few people with OS-caliber skills to read or write it, probably not. If the language is inflexible in its style, or low performance in its execution (eg. few result bits per op), probably not.
Java for example seems like a good OS language - especially for a distributed/virtual machine, as that's its native target HW - despite its abstraction away from bits and memory. Javascript does not, since it's not very expressive in manipulating bits, and its programming community relies on high level objects like the DOM and browser app for most techniques.
This project would interest me (a little) if the assembly that the C# is compiled to were run on silicon that executed CIL as machine instructions. Even if the CIL implementation were microcode that invoked x86 instructions, or a Transmeta-type on the fly conversion to native instructions.
. would have been just fine, both for humans and compilers to read. Indeed, no space between the line's statement and its terminating semicolon is harder for humans and compilers.
I dunno, after a year or so I had the multilevel meaning of int *foo, and liked seeing a list of ints, even if some were dereferences.
I think using "->" in "struct->elem" was their biggest mistake, because it's not a single character. ++, +=, || and their like aren't so bad, because they're akin to functions, which can have arbitrary character length names.
In a (my) mistaken way.
Yet ItA has been read directly by so few, and its principles rigorously worked by so few, relative to K&R that K&R is clearly more influential. A step further would say that Principia Mathematica is the most influential programming book.
That's what compilers are for. Otherwise C is just a macro-assembler.
No, because I code:
int SoWhat(int about) /* So that's what this is about.
{
int that = about(this);
return(that); /* SoWhat(int) */
}
Many other people have to read my code. I sometimes have to read my code years later. The open brace is the perfect place to document that scope.
I know better than K&R (did). Of course, I have the benefit of over 30 years programming after their book was published, starting only a year prior; they had only a decade or less experience when they published, among a vastly smaller society of peers to argue with.
I won't like any language that requires a text editor more complex than notepad to generate readable code. Certainly not one that requires a post-processing indenter.
That is also correct.
In fact I wish C used only ()s, not []s or {}s. And that every () indicated a function call, including to implicit list processors.
Yet somehow I hate Lisp as unreadable. I'd probably be happier if C used only ()s, but allowed (matched) []s or {}s interchangeably. Just as we do in English parenthesizing and consequently in algebra.
The result is the same in either style. But the reason the ++var style is better sylistically is that it implies only "increment var", and not the other moot effects the other poster mentioned.
So an open brace at the end of a line, that doesn't align in a column with its closing brace, is pretty? The column-aligned braces are prettier, and easier to match by eye. And harder to miss at the right end of a line that's beyond the margin of the viewport. Or which wraps to the next line, of course usually as the 81st (or 133rd, etc) character. Which satisfies "pretty" in my eyes, but is not reliably persistent across viewport instances.
There's no reason the PDP-11 C compiler couldn't have seen *++p and compiled it to the instructions INC p and *p (or whatever the actual opcodes are). The C language itself should have both, but when the programmer is saying only "increment p", ++p is semantically more correct than is p++.
The problem with my preference in C++ is that nobody would have taken seriously a language called "++C" ;).
What you just said about C is not true. There is no implication that any two successive statements are related at all, except that their variables are in the same containing scope (except any overrides in any {} block in one statement).
What does
int a = 5..
mean?
Does
int a = 5.;
or
int a = 5.b;
mean something syntactically valid?
Or
5.b = 5.6
?
int a = 5.2.
isn't bad at all, as we experience in English all the time. Though I do type to humans including trailing whitespace after code symbols before punctuation, as the symbol name is defined by "between whitespace" in most languages (except Mac, and then Windows, filenames).
So
int a = 5 .
int a = 5.2 .
What's so hard about that? It looks like the language we've been writing for years before we ever wrote it to a computer.
CRs are indistinguishable from other whitespace. Which is why I like statements to have a visible character ending them. Which also lets me include multiple statements in a single line when that composition is meaningful, like for(i=lowNum, j=hiNum; ij; ++i, ++j) { foo(i, j); } . If anything C (and derivatives like Java and Perl) should end a "{}" block with a ";" , and leave a "{}" block without a semicolon as an expression rather than a statement.
No, I blame the language for requiring people to do something as tedious as "indent properly". The indenting character is indistinguishable from the non-characters after the indent. The compiler should permit extra whitespace and clean it up. Not doing that is a trap.
The language is a tool for human convenience. Not some extra set of skills that don't solve the problem, but instead just create more problem for the programmer to solve.