I don't think the "static" advantage is all that big an advantage when you consider a large program. Remember the semantics of static are different from the semantics of auto, and depending on some code generation issues, of extern.
One of the really depressing things about having been in the business for nigh on to 40 years now is that, along with the occasional new dumb idea, all the old dumb ideas keep coming back. Among those dumb ideas that keep coming back are "visual programming" --- using graphics instead of programming languages; complicated schematic graphics for software --- UML in its utter complex form; and, sure enough, using the preprocessor to mess with C-like languages.
Every time this is tried --- and God knows it's been tried a lot --- you run into some severe problems:
The scoping rules of C-like languages give semantics to file inclusion. If you #include chunks of code, you are defeating the language's (limited) ability to protect you from name space clashes, mis-named variables, and so on.
While it might be that you gain something from only needing to start the compiler once, parsing and compilation are inherently a bit harder than O(n) where n is the number of source characters or tokens. A normal environment with make(1) will generally need to process fewer tokens than compiling everything all the time; the time required for a big file will inevitably dominate the startup time eventually.
If you've got control of the compiler for this peculiar language, why not explore making the startup time shorter, say, eg., by using shared libraries, DLLs, or by setting the sticky bit?
From sad experience, I can tell you that using the #include scheme will introduce weird-ass order dependencies into the code (ie., what order do you include files in?) that are very very difficult to debug.
Most tools for C-based languages expect you to do the sources in a normal fashion. You confound the tools' expectations' at your peril.
Similarly, most debuggers exploit, or attempt to exploit, scoping rules that you will break through this approach.
When you write lots of smaller modules, each one can be create a single, small TEXT and DATA section, or a collection of small code sections. This makes the job of memory mapping in virtual memory systems much easier. Do it all as one big thing, and you're liable to get one big TEXT section.
Optimization is comnbinatorially fairly hard, quadratic or worse, and global optimizations tend to be managed within section bounardies. One-big-module designs may either make the optimization phase very lengthy, or defeat optimization entirely when table space etc. runs out.
You piss off every experienced C programmer who ever has to deal with the code in the future, especially old farts like me who've seen this trick 20 years ago.
Look, folks, you're mainly bitching about poor documentation or poor file system organization, with some change left over for not liking the setuid/gid thing which seems like a hack now, but was way cool back in the day.
Back many years ago I was proposing something called NERU "a New Enviornment Rationalizing UNIX". Here were some things that I was really interested in doing then:
- uniform addressing schemes that make memory and the file system look more homogeneous.
- typed entities replacing files what carried along their pointers to their own operations. Think of it as an "object oriented file system".
- shell or scripting mechanisms with type casts; say, transforming/etc/passwd to a gdb database indexed on username might be something like cat/etc/passwd |(gdb) application.
- uniform versioning based on copy-on-write: any time you touch a named entity, it automatically has a current version and an old one.
That was 20 years ago (and some of the ideas weren't all that new then the uniform homogeneous model for storage was part of IBM System/38 and is now part of AS/400.)
If you really want to "fix" UNIX, you need something more than fiddling with the file hierarchy organization.
It's clearly time for my periodic "you young pups don't know your history" posts.
1. Reiserfs etc are the results of 30 years of research that, well, hadn't happened 30 years ago. the i-node/u-node business was the best there was. Then. 2. Multics had general, configurable, role-based, magic ACLs; UNIX lost them on purpose becuse it wasn't well suited to a big games system and word-processor, which is what UNIX was meant for originally. 3. When I was a kid we hardly HAD processes, much less IPC. Having named pipes was a helluvan innovation. 4. That's not the operating system, that's book-keeping. 5./bin/sh WAS the coolest scripting language ever. They've gotten better. text files with field seperators (that all passwd(5) is, after all) were the uniform data representation.
If you were to go back to System 3 UNIX, you'd have most everything you're asking for here. It wouldn't be as powerful, but it'd be uniform.
Well, I'm certainly an "educated analyst" going back to the days when "GOTO considered harmful" was the cutting edge and from the question I infer with near-100 percent certainty that you're not one. You may be educated, but you've certainly never had to perform an actual meet people in their offices and ask questions analysis task.
You don't develop preconditions, use CASE tools, or define formal workflows in those sessions; you do that after days or weeks of asking questios, accumulating data, and making vague sketches on whiteboards. Before you can do a brilliant analysis, you've got to know something to be brilliant about.
Now, having disposed of that, I'd say that you may not be running into a computer tools problem as much as you're running into an intellectual tools problem. Personally, I find the linear notes on a page model to be badly bandwidth-limited; for that kind of analysis, I like to use a big drawing pad (like this one, except Office Max sells one with half-inch quadrille I like better, but it's not on their web site for some reason) and many colors of pen and highlighter.
Label each page on a consistent edge with date and time in a consistent format; AFTER the session is done, write some keywords on an orthogonal edge of the paper to remind yourself what the session told you.
If you want th really good CS jobs, you'll get them best by going to a presigious grad school for (at least) a masters.
It's a little chauvinistic of me, since I went there, but I'd say get two-three years of experience and then get into UNC-Chapel Hill. But there are other good schools -- CMU, MIT.
Good point, although those really are things we don't know we don't know. Still, as several people have apparently said: "It ain't what we don't know that hurts us, it's what we know that ain't so".
One of my professors in grad school called it "reading like it was a comic book". Don't try to read the whole thing. In technical papers, read the title, the abstract, and the conclusions. Only read the stuff in the middle if you're really interested.
In technical books, don't try to read the whole thing like a novel. Skin it once, twice, even three times. You'll get a "picture" of the overall "shape" of the topic.
Go back and read the introductory material. Do you understand all of it? If so,. you're on the right track. Most of the time, a book is built around introducing some new material and then ringing the changes on it.
But yeah, that's the tricky part. You need to both keep it simple and have what you need to do everything you want to do.
Of course, that's also why you need to ask "what do you want to do with the language?"
As far as formality goes, the problem -- and I speak as a confirmed and evangelical formal methodist -- with attempting to determine what you should include with a formal method is that formal methods can easily tell you if what you got is what you wanted, but they can't tell you want to want in the first place.
You don't really say what sort of problems you're talking about or why you want to build the language.
If you just want to build a language that will teach you about programming languages, look at old fashioned Pascalnot Delphi or Kylix or even Turbo Pascal, but good old-fashioned Jensen and Wirth 1974 Pascal.
If you want to design a programming language, the best advice is to write some code in the proposed language. Remember Tony Hoare's rule, and keep it simple. Most programming languages, from Perl to Python to Java 5, suffer from being accumulations of features.
Have a look at Ruby, Modula-n, Oberon, and so forth.
If you're looking to learn lots about programming in general, think about things you want to do, and construct a lanaguage that does them. Icon is a nice example. Look at SNOBOL, if only because you'll appreciate the "five miles through the snow" stories we old farts tell.
Limited scope of recounts: because the Democrats only pursued recounts in counties that they thought they had political control of (and remember, after the zillions of post facto recounts, Bush always won under any interpretation that would have passed the equal-protection test.)
"Deliberate" use of flawed felon-purge list: required by statute, and applied -- wait for it -- by the County Election Commission, because they're the ones who make those decisions.
I've never heard the third one: got a citation? Prefereably from something a little more reputable than Mother Jones?
I can sympathize, having been round for the beginning of Libertarian Party, but what we've got is surprisingly effective along those lines. You can, after all, vote; that puts you one up on about half the population of the world. You can choose not to vote, if you prefer not to; that puts you one up on places as varied as Cuba and Australia.
You can in general be confident that your local representatives will actually be from somewhere near you, which I see as an advantage over the UK and occasional aberrations like New York State.
You're guaranteed that your vote has as much impact as anyone in your state, and that it has extra leverage in some situations (in the House if you're in a populous state, in the Senate and the Electoral College if your from one of the flyover states like me.)
And, if you don't like the way the votes are being counted in your county, you've only got a relatively few thousand votes in general to change it, or you can move fairly conveniently to someplace else, which you couldn't do if we had national uniform standards.
Is it perfect? No, but I'm increasingly surprised not by how bad it is, but rather by how good it is.
Slashdot Mirror
I don't think the "static" advantage is all that big an advantage when you consider a large program. Remember the semantics of static are different from the semantics of auto, and depending on some code generation issues, of extern.
Someone should mod this either "funny" or "dumb".
(In real compiled languages, the comments are stripped out in lexing or earlier. In C, they're stripped by the preprocessor.)
One of the really depressing things about having been in the business for nigh on to 40 years now is that, along with the occasional new dumb idea, all the old dumb ideas keep coming back. Among those dumb ideas that keep coming back are "visual programming" --- using graphics instead of programming languages; complicated schematic graphics for software --- UML in its utter complex form; and, sure enough, using the preprocessor to mess with C-like languages.
Every time this is tried --- and God knows it's been tried a lot --- you run into some severe problems:
If you've got control of the compiler for this peculiar language, why not explore making the startup time shorter, say, eg., by using shared libraries, DLLs, or by setting the sticky bit?
Liza Minelli looks a good bit like Judy Garland, but Liza's a gimpy old woman and Judy Garland is dead.
It does look a good bit like an ME-163, although the 163 was ground launched.
With Isp in the neighborhood of 200, though (see the "hot engine"), an air launched 163 would have been quite similar to SS1.
Look, folks, you're mainly bitching about poor documentation or poor file system organization, with some change left over for not liking the setuid/gid thing which seems like a hack now, but was way cool back in the day.
/etc/passwd to a gdb database indexed on username might be something like /etc/passwd |(gdb) application.
Back many years ago I was proposing something called NERU "a New Enviornment Rationalizing UNIX". Here were some things that I was really interested in doing then:
- uniform addressing schemes that make memory and the file system look more homogeneous.
- typed entities replacing files what carried along their pointers to their own operations. Think of it as an "object oriented file system".
- shell or scripting mechanisms with type casts; say, transforming
cat
- uniform versioning based on copy-on-write: any time you touch a named entity, it automatically has a current version and an old one.
That was 20 years ago (and some of the ideas weren't all that new then the uniform homogeneous model for storage was part of IBM System/38 and is now part of AS/400.)
If you really want to "fix" UNIX, you need something more than fiddling with the file hierarchy organization.
It's clearly time for my periodic "you young pups don't know your history" posts.
/bin/sh WAS the coolest scripting language ever. They've gotten better. text files with field seperators (that all passwd(5) is, after all) were the uniform data representation.
1. Reiserfs etc are the results of 30 years of research that, well, hadn't happened 30 years ago. the i-node/u-node business was the best there was. Then.
2. Multics had general, configurable, role-based, magic ACLs; UNIX lost them on purpose becuse it wasn't well suited to a big games system and word-processor, which is what UNIX was meant for originally.
3. When I was a kid we hardly HAD processes, much less IPC. Having named pipes was a helluvan innovation.
4. That's not the operating system, that's book-keeping.
5.
If you were to go back to System 3 UNIX, you'd have most everything you're asking for here. It wouldn't be as powerful, but it'd be uniform.
Fresh spinach, feta cheese, onions.
Slashdot needs a recipes section.
Well, I like spinach sauteed quickly with good olive oil and lots of garlic, but certainly not the usual greeen pudding that's made of it.
No, raw turnips are actually very good, sort of like mild radishes. Cut them in sticks like carrot sticks and serve them chilled.
Actually, once I'd had raw turnips, I couldn't figure why people bother to cook them.
No, sadly, I remember rogue because I spent 36 hours straight playing it one weekend in grad school.
When it was the New Thing.
Even before Rogue-o-Matic.
... rogue runs on Linux.
Damn young whippersnappers, anyway.
Well, I'm certainly an "educated analyst" going back to the days when "GOTO considered harmful" was the cutting edge and from the question I infer with near-100 percent certainty that you're not one. You may be educated, but you've certainly never had to perform an actual meet people in their offices and ask questions analysis task.
i nd+mapping&btnG=Google+Search for some examples) to build up a picture of the information.
You don't develop preconditions, use CASE tools, or define formal workflows in those sessions; you do that after days or weeks of asking questios, accumulating data, and making vague sketches on whiteboards. Before you can do a brilliant analysis, you've got to know something to be brilliant about.
Now, having disposed of that, I'd say that you may not be running into a computer tools problem as much as you're running into an intellectual tools problem. Personally, I find the linear notes on a page model to be badly bandwidth-limited; for that kind of analysis, I like to use a big drawing pad (like this one, except Office Max sells one with half-inch quadrille I like better, but it's not on their web site for some reason) and many colors of pen and highlighter.
I use them to accumulate a series of "mind maps" (see http://www.google.com/search?complete=1&hl=en&q=m
Label each page on a consistent edge with date and time in a consistent format; AFTER the session is done, write some keywords on an orthogonal edge of the paper to remind yourself what the session told you.
If you want th really good CS jobs, you'll get them best by going to a presigious grad school for (at least) a masters.
It's a little chauvinistic of me, since I went there, but I'd say get two-three years of experience and then get into UNC-Chapel Hill. But there are other good schools -- CMU, MIT.
Almost as good as UNC.
That's "Ana Marie", one 'n'.
She's way cuter than Drudge.
Honestly, can someone enlighten me as to how these 80+ hour weeks ever accomplish anything?
No.
Good point, although those really are things we don't know we don't know. Still, as several people have apparently said: "It ain't what we don't know that hurts us, it's what we know that ain't so".
One of my professors in grad school called it "reading like it was a comic book". Don't try to read the whole thing. In technical papers, read the title, the abstract, and the conclusions. Only read the stuff in the middle if you're really interested.
In technical books, don't try to read the whole thing like a novel. Skin it once, twice, even three times. You'll get a "picture" of the overall "shape" of the topic.
Go back and read the introductory material. Do you understand all of it? If so,. you're on the right track. Most of the time, a book is built around introducing some new material and then ringing the changes on it.
Now, if you're not a complete fool, you'll actually think about what Rumfield was saying.
"known knowns" -- there are certain things we know we know: this is Slashdot, we are writing in English, etc.
"known unknowns" -- there are things we know we don't know: P = NP?
"unknown knowns" -- what do we know that we don't realize we know?
"unknown unknowns" -- the real surprises: what we don't know, and don't even realize there is something to be known.
"Features" not "futures".
But yeah, that's the tricky part. You need to both keep it simple and have what you need to do everything you want to do.
Of course, that's also why you need to ask "what do you want to do with the language?"
As far as formality goes, the problem -- and I speak as a confirmed and evangelical formal methodist -- with attempting to determine what you should include with a formal method is that formal methods can easily tell you if what you got is what you wanted, but they can't tell you want to want in the first place.
You don't really say what sort of problems you're talking about or why you want to build the language.
If you just want to build a language that will teach you about programming languages, look at old fashioned Pascal not Delphi or Kylix or even Turbo Pascal, but good old-fashioned Jensen and Wirth 1974 Pascal.
If you want to design a programming language, the best advice is to write some code in the proposed language. Remember Tony Hoare's rule, and keep it simple. Most programming languages, from Perl to Python to Java 5, suffer from being accumulations of features.
Have a look at Ruby, Modula-n, Oberon, and so forth.
If you're looking to learn lots about programming in general, think about things you want to do, and construct a lanaguage that does them. Icon is a nice example. Look at SNOBOL, if only because you'll appreciate the "five miles through the snow" stories we old farts tell.
"An-o-ma-ly".
Couldn't stand it.
Great. The "Votemaster" hasn't lived in the United States for twenty years.
Limited scope of recounts: because the Democrats only pursued recounts in counties that they thought they had political control of (and remember, after the zillions of post facto recounts, Bush always won under any interpretation that would have passed the equal-protection test.)
"Deliberate" use of flawed felon-purge list: required by statute, and applied -- wait for it -- by the County Election Commission, because they're the ones who make those decisions.
I've never heard the third one: got a citation? Prefereably from something a little more reputable than Mother Jones?
I can sympathize, having been round for the beginning of Libertarian Party, but what we've got is surprisingly effective along those lines. You can, after all, vote; that puts you one up on about half the population of the world. You can choose not to vote, if you prefer not to; that puts you one up on places as varied as Cuba and Australia.
You can in general be confident that your local representatives will actually be from somewhere near you, which I see as an advantage over the UK and occasional aberrations like New York State.
You're guaranteed that your vote has as much impact as anyone in your state, and that it has extra leverage in some situations (in the House if you're in a populous state, in the Senate and the Electoral College if your from one of the flyover states like me.)
And, if you don't like the way the votes are being counted in your county, you've only got a relatively few thousand votes in general to change it, or you can move fairly conveniently to someplace else, which you couldn't do if we had national uniform standards.
Is it perfect? No, but I'm increasingly surprised not by how bad it is, but rather by how good it is.