Bottom Line: Corporations have power but it must be shared with other competitors. Consumers hold the power of choice to make a corporation succeed or go bankrupt (Circuit city, wards, GM). In contrast the government holds the monopoly on the power to jail, take, or kill.
Distinguishing between corporate power and government power is somewhat pointless, since corporations are themselves exercises of government power. All corporate power is government power.
This is actually an interesting example of how fluid our conception of "race" is:
Except that its not.
in the 1950s, the Cuban Desi Arnaz was considered "white," and "Hispanic" as a racial category didn't exist.
It still doesn't. In the spectrum of artificially contrived social categories with no objective basis, "Hispanic" is an ethnic category that is orthogonal to "racial" categories; a person can be "Hispanic" and be of any "racial" category or combination of "racial" categories.
This doesn't make sense to me. With old unstructured BASIC there is never a case when the student would need to encounter a DATA or GOSUB without first being introduced to it. (I don't know of any mystical routines accessed via GOSUB -- any routine you'd call is one that you've written. Could you explain this further?)
IME, its very common and useful for introductory courses, regardless of language, to want, fairly early on, to introduce simple concepts through compelling demonstration uses which rely on things whose implementation relies on techniques that have not been taught (and in some cases which are beyond the scope of the course.) In structured languages where this can be presented as a simple call out, this isn't distracting. Where you have to include the code directly, it is distracting.
Lisp and Scheme (and others, like forth) share this advantage, but have other barriers, like prefix notation, that make them less than ideal.
Prefix notation for procedure and function application is fairly directly analogous to verb-first word order in natural language, which is what, for instance, English uses for the imperative and for many questions. Since procedure and function application maps fairly directly to either imperative commands or questions, prefix notation should be fairly easy to teach to English speakers.
It probably makes things harder if you start trying to teach prefix notation focussing on mathematical operations using mathematic symbols rather than words for operators, since that does conflict with how people are used to seeing those things used.
The leap from the sentence "add 5 and 5" to "add 5 5" (in REBOL) or "(add 5 5)" (in a language using lispish notation) is fairly obvious.
The leap from "5 + 5" to "(+ 5 5)" is greater.
(Incidentally, that's one of the things I do think is a problem with HtDP.)
I'd disagree, on the basis of my experience. The approach the book introduces concepts in an order I see as inappropriate for beginners -- All-in-all the book is a bit ham-fisted in it's approach. Topics don't build on (or flow into) one another and Related concepts aren't generally presented together.
Its kind of hard to respond to subjective impressions with no specific cited basis, so I'll just say that I think that my subjective impression is that the topics in the book do build on each other quite well (the approach builds both breadth and depth as the course progresses, which I personally find is better than breadth-first -- e.g., covering all simple operations before starting either function definitions or control structures -- which is really the only alternative.)
This isn't really a problem if you want to learn Scheme and a bit about functional programming -- it actually works rather well -- but in the classroom, such a presentation quickly turns into a confusing mess.
Again, I don't think that's really the strength of HtBP. What its really good for is learning general approaches to problem analysis and solution design with programming as a vehicle; it teaches less about computers as technology and more about analysis than most introductory approaches. Given its stated intent, that's unsurprising.
I disagree. I think the beginner does not want to design anything, much less a complex software system. I think the beginner wants to learn how to make the computer follow some instructions, like add some numbers, or move a square from one part of the screen to another.
I think you are misunderstanding what I wrote. I am not arguing that "the beginner" wants a design focus. In fact, people who are new to programming may want different things, and may not know what they want.
In the part of GP that you quote in your post, I refer to suitability of certain programming languages to a first course where the intent (of the course) is to focus on designing solutions to problems (inherently, this is not "complex software systems", although the skills learned in such a course are transferrable to more complex systems.)
In other parts of GP, I refer to the suitability of different programming langauges for first courses with a different focus.
To the extent that your post rests on the idea that "the beginner", universally, has a single preference and thus that there is only one true and correct focus for a first course, I disagree strongly, and to the extent that your post appears to be directed as a response to a perception that part of my post was arguing on the same premise but with ascribing a different singular preference to "the beginner" I feel obliged to point out that that is a misreading of what I wrote.
Why? You quite obviously know what I mean by 'cruft' (necessary code incomprehensible to the student within the context of the material presented)
In that case, I would say both "zero" and say that procedural, functional, and OO languages -- which permit single-line calls to externally-implemented code that can be explained as telling something else what to do are actually are better at minimizing cruft than old-style BASIC is with mystical routines accessed with GOSUBS and arcane DATA statements.
That being said, you probably want to avoid languages where library access is "in your face" for common I/O tasks (if you have to do an explicit import of an I/O library to read from and write to the console, its probably not the best choice; OTOH it may for some languages be possible to conceal this by not using the normal program running facilities and using a "bootstrapping" mechanism which adds these things in invisibly behind the scenes; if you are teaching concepts and not the particular language and library structure, this may make sense if the other features of the language make it good for the task.)
Remember that the discussion is about teaching programming concepts to children.
I am aware of that. And I remain convinced that the relative merits of structured languages vs. something like old-style BASIC in a language to ise for that vary based on what the purpose of teaching "programming concepts" is: whether its more about teaching programming-as-a-vehicle-to-understanding-computers or programming-as-a-vehicle-to-understand-problem-solving.
That doesn't really change with the age of the audience, though there may be some reason to choose particular languages within broad families based on the age of the audience.
I'm familiar with the book and while I think it's one of the best for introducing functional programming to already competent programmers, I wouldn't use it to teach programming to beginners.
I disagree, I think HtDP great for teaching programming to beginners (I think that's what it is best for, and indeed that's what it is designed for) -- again, if the focus is on problem solving rather than understanding how computers work at a low level, either of which is a valid focus for a first course involving programming. I wouldn't consider it a great book for teaching functional programming, as such, to competent programmers, though I think could be a good book to teach competent coders to be better at structured analysis and design of solutions.
Given the content, I certainly wouldn't use it to teach children under the age of 15.
I'd agree with that as far as the book as a text is concerned, I was citing it as an illustration of a basic approach. I'd use the basic approach (though not necessarily either the book or Scheme specifically as the language) at any age where I wanted to teach programming-as-problem-solving.
Programming-as-a-window-into-the-workings-of-a-computer I think old-style BASIC is still the most accessible language for novice programmers to use. I'm not sure the best approach for that, its not really something I've spent as much time thinking about.
And the -- different but somewhat related -- programming-to-get-over-the-idea-that-its-a-magic-box-that-someone-else-has-to-make-work-for-you can you any language that is readily accessible. Old-style BASIC's line-oriented structure might make it particularly strong here for younger learners, but I'm not sure that it is better than, e.g., Logo for this.
Define "cruft" concretely enough that it is possible to measure it quantitatively, and then we can discuss that question.
I think any amount is too much, for the reasons stated above.
I don't think most dynamic OO languages impose any "cruft" that must be included before you can begin addressing basic concepts. I think that (and this is true of most procedural and functional languages in general, as well as OO languages) that there are certain concepts (e.g., arbitrary flow control) that are harder to express in those languages, which makes them less suitable for an introduction to programming whose purpose is to teach a low-level understanding of how computers work (compared to BASIC, whose structure, despite the more accessible syntax, is more similar to assembly language.)
OTOH, I think that the ease of expressing structure in functional, OO, and procedural languages makes any of those models better than old-school BASIC for teaching introductory programming in a context where the intent is to focus on designing solutions to problems. (I think each model has different strengths here, but I think a decent curriculum in this regard could be based around a language supporting any of those models, or modern multi-paradigm dynamic languages like Ruby or Python. The best specific implementation I've seen of an introduction of this type is the book How to Design Programs, which uses a series of successively more involved versions of a Scheme-derived pedagogical language.)
Programming should NEVER begin with OO. If for no other reason than the cruft you need to add in OO languages before you can even begin to introducing basic concepts.
That's not really true of OO languages generally, its mostly true of the those languages whose heritage or inspiration in a static procedural language like C or Pascal that then had an OO layer bolted on to it; the Pascal-derived branch of that tree is pretty much dead now, I think, but the C-derived branch, including C++, Java, and C# is still going strong.
OO languages like Smalltalk (for class-based OO) or Self (for prototype-based OO) and those inspired by them (like Ruby and JavaScript) that haven't, somewhere along the line, tried to wed OO structure with an existing static procedural language, don't really feature much boilerplate cruft that needs to be included in simple programs before beginning to introduce basic concepts.
I learned Basic on a Commodore VIC-20 in 1978. I think it is a terrible choice for learning to program. I suggest newbies learn Scheme, a very simple language that will lead you as far down the rabbit hole as you are willing to go.
I learned BASIC, approximately in parallel, on the VIC-20, the TI-99/4A, and a Timex-Sinclair 1000 in elementary school in the early 1980s.
I think its a fine language for learning to program as part of learning how computers work; its high-level enough to be accessible, especially to young students, but structured similarly to assembly languages and provides a good vehicle for teaching about how computers work at a basic level.
I think Scheme is a much better language for teaching how to design programs to solve problems, but the features that make it good for this purpose are precisely the features that obscure the low level process.
I'm not convinced that that is the case. Various Lisps (Common Lisp, Scheme, specialized dialects used in particular applications, and other varieties) continue in a number of important uses in production environments, continue to be actively developed, and Lisp features continue to be one of major influences on the evolution of many popular languages as areas that have long been noted as Lisp strengths become recognized as important in modern application development.
How, precisely, is that Lisp is supposed to have "failed"?
The meta-law would act to make such funds-direction aspects of a proposed bill invalid, not to be considered part of the bill when voted on or passed into law.
The US Constitutional system doesn't have a category of "meta-law". A federal law is either a Constitutional provisions, a ratified treaty, or an act of Congress. Treaties are irrelevant here, and An act of Congress cannot limit a future act of Congress. If some text is part of the text of an act of Congress as actually voted on and adopted, even if some earlier act of Congress purports to prohibit such text from being in the bill, the it is part of the act and given whatever force is due to that act, including superceding previous conflicting acts of Congress.
As I said in GP, therefore, under the actual system in the US Constitution, such a provision --even ignoring the problem of vagueness -- would have no substantive impact unless the so-called "meta-law" were, in fact, adopted as a Constitutional Amendment, which -- as part of the Constitution -- can constrain acts of Congress.
If you can find someone who has, borrow a few of them and try this experiment: Measure the diagonal size of each one and average the measurements. It's about... say it with me... seven inches.
You seem to referring to mass market paperbacks, which are about 7", but aren't what I was talking about. There is a difference between mass market paperbacks and trade paperbacks.
If you do that for typical trade paperbacks (which is what I specifically call out in GP), which are 6"x9", you'll find that the diagonal measure is 12.7" for the full page, and with fairly typical margin sizes right around 10" for the text. Which is why, in GP, I said: Assuming the page of text is designed to read on a letter/A4 page, a ~14" display is necessary to display the full page at the size it is designed to be viewed. A 10" screen is about right for typical trade paperback size pages. (Though an astute observer will note that I did make the mistake of being inconsistent in using the approximate full page size for the letter/A4 and the typical printed area for trade paperback size.)
Even if I read Rolling Stone, I really don't need to view it in original size.
Maybe you don't, so what? As I said in GP: How much reduction below design size is tolerable will vary from person to person, but many documents are already at the limit of readability at their design size, so any smaller device screen will require zooming and panning for a substantial fraction of users, even if it had the clarity of print.
I figured part of the reason for the 10" widescreen was to be pretty close to 8.5x11 erring on the size of smaller.
Even assuming 1" margins all around (so you have 7.5"x10"), a letter-size device would be 12.5" diagonal, which is significantly greater than the 9.7" of the iPad. The largest Android tablets, in the 11.6-12.1" range, are close in diagonal measure, but tend to be 16:9-ish widescreens, so they they're a bit narrow and tall for viewing unreduced letter size material, even shaving the margins.
That's funny because before the iPad came out all Slashdotters could do was point out how the iPad was nothing new and how tablets had been around for ages, etc etc. And now that the iPad has pretty much owned the entire market the excuse is that "there are no viable competitors". Would it kill you people to admit you were wrong about the iPad and it's likely success?
"Slashdot" is not a hivemind. Just because the posts that you notice most currently contradict the posts you remember most from quite a long time ago doesn't mean that any of the people involved have changed positions, or even that the overall opinion on Slashdot has changed.
Because, believe it or not, Apple came in at a price point that nobody could match without Apple's sales volume. The only way to under cut Apple's price is to reduce the screen size. By half, it turns out (7^2 = 49, 10^2 =100).
The ViewSonic G is the same price as an iPad wifi, with a 10.1" (1024x600) screen compared to the iPad's 9.7" (1024x768) screen. It is not alone among 10" Android tablets in being price competitive with the iPad.
Its certainly hard for other manufacturers to price compete with Apple given Apple's beating everyone to the market and being able to leverage the App Store advantage, and superior consumer brand image. But its equally certainly not the case that 7" tablets are simply a matter of being the only thing other manufacturers can do to price compete, though it is something they can do to differentiate themselves and target a market segment and interest that Apple isn't already hitting.
Just like the 11.6"-12.1" 1366x768 tablets are, on the other end. (These tend to be more expensive than the iPad, but then that shouldn't be surprising.)
If I purchase blank CD's, DVD's or hard drives and I got charged a "Piracy Tax", I would consider that my payment to copyright holders and I would pirate all I wanted.
The U.S. has such a levy/tax on blank audio recording media, adopted as part of the Audio Home Recording Act of 1992.
Anyway, If anyone could make a 10" iPad competitor at $500 or less, they'd have done so by now.
There's actually quite a few ~10" Android tablets that have been announced at that price point; all 4 of the Notion Ink Adam 10.1" (1024x600) models which sold out of preorders this month had prices under $550, 3 of the 4 under $500 (all but the Pixel Qi + 3G model).
The ViewSonic G 10.1" (1024x600) tablet that has been on sale since November seems to be $399.99 at most major online retailers that sell it, slighlty lower at some.
That everyone who is trying is coming in at half the screen size should be confirmation.
Actually, several competing models that have been announced (including a few already available) are in the 11.6" to 12.1" range (typically 16:9, 1366x768), and quite a few are 10.1" (1024x600) devices.
So Apple sell a netbook with no keyboard and an ARM CPU for twice the price of a netbook and no-one can compete with it on price?
No one has anything like the way of driving revenue after the sale of the device itself like Apple has with the App Store that was established for the iPhone before the iPad came out. The App Store lets Apple sell iPads at a lower price than it would otherwise be able to.
It is not about it being 7 inches, it is about it ALL OF THEM being 7 inches.
If by "THEM" you mean "tablets that aren't the iPad", they aren't all 7 inches. Of those on the market or announced, the range is something like 4-12 inches. 7 in. seems to be the most common, but it is far from the only size.
There's actually quite a few 11.6" and 12.1", 1366x768 tablets.
10" minimum - to comfortably read a page of text in landscape without zooming.
Assuming the page of text is designed to read on a letter/A4 page, a ~14" display is necessary to display the full page at the size it is designed to be viewed. A 10" screen is about right for typical trade paperback size pages.
How much reduction below design size is tolerable will vary from person to person, but many documents are already at the limit of readability at their design size, so any smaller device screen will require zooming and panning for a substantial fraction of users, even if it had the clarity of print.
What if a law was passed invalidating all porkbarrelling clauses in federal legislation, including retroactively?
It would probably be unenforceable due to vagueness: "porkbarrelling" is a subjective description applied to laws directing funds in a manner which the speaker feels does more to benefit the political interest of a legislator than the national interest.
Even if it wasn't unenforceable due to vagueness, and it wasn't a Constitutional amendment, any newer law specifically directing funds in a manner inconsistent with the "meta-law" would supercede the "meta-law" to the extent that they conflicted, as newer enactments trump older ones.
In any case, it wouldn't have any substantive effect.
Wait, wait, wait. The wife in this story is cheating on her third husband with her ex-second, who by the way has a criminal record for abusing her. The third goes into her email and provides it to the first husband, the father of their son, so that he might intervene and prevent any contact between his son and the second.
And the third is the asshole?
See, here's your problem: you think being an asshole is exclusive.
Taking the story as you relate it, the woman, the second husband, and the third husband are all assholes.
Considering that when you are married, in terms of property rights, you are considered a single legal entity, I honestly don't see how this would stand up in court.
Well, for one thing, there is the fact that, in most U.S. jurisdictions, being married does not mean you are treated as a "single legal entity" for property rights.
Slashdot Mirror
Bottom Line: Corporations have power but it must be shared with other competitors. Consumers hold the power of choice to make a corporation succeed or go bankrupt (Circuit city, wards, GM). In contrast the government holds the monopoly on the power to jail, take, or kill.
Distinguishing between corporate power and government power is somewhat pointless, since corporations are themselves exercises of government power. All corporate power is government power.
This is actually an interesting example of how fluid our conception of "race" is:
Except that its not.
in the 1950s, the Cuban Desi Arnaz was considered "white," and "Hispanic" as a racial category didn't exist.
It still doesn't. In the spectrum of artificially contrived social categories with no objective basis, "Hispanic" is an ethnic category that is orthogonal to "racial" categories; a person can be "Hispanic" and be of any "racial" category or combination of "racial" categories.
An Amendment would serve, then.
Sure, once you deal with the more fundamental problem that "porkbarrel spending" is not an objective category.
This doesn't make sense to me. With old unstructured BASIC there is never a case when the student would need to encounter a DATA or GOSUB without first being introduced to it. (I don't know of any mystical routines accessed via GOSUB -- any routine you'd call is one that you've written. Could you explain this further?)
IME, its very common and useful for introductory courses, regardless of language, to want, fairly early on, to introduce simple concepts through compelling demonstration uses which rely on things whose implementation relies on techniques that have not been taught (and in some cases which are beyond the scope of the course.) In structured languages where this can be presented as a simple call out, this isn't distracting. Where you have to include the code directly, it is distracting.
Lisp and Scheme (and others, like forth) share this advantage, but have other barriers, like prefix notation, that make them less than ideal.
Prefix notation for procedure and function application is fairly directly analogous to verb-first word order in natural language, which is what, for instance, English uses for the imperative and for many questions. Since procedure and function application maps fairly directly to either imperative commands or questions, prefix notation should be fairly easy to teach to English speakers.
It probably makes things harder if you start trying to teach prefix notation focussing on mathematical operations using mathematic symbols rather than words for operators, since that does conflict with how people are used to seeing those things used.
The leap from the sentence "add 5 and 5" to "add 5 5" (in REBOL) or "(add 5 5)" (in a language using lispish notation) is fairly obvious.
The leap from "5 + 5" to "(+ 5 5)" is greater.
(Incidentally, that's one of the things I do think is a problem with HtDP.)
I'd disagree, on the basis of my experience. The approach the book introduces concepts in an order I see as inappropriate for beginners -- All-in-all the book is a bit ham-fisted in it's approach. Topics don't build on (or flow into) one another and Related concepts aren't generally presented together.
Its kind of hard to respond to subjective impressions with no specific cited basis, so I'll just say that I think that my subjective impression is that the topics in the book do build on each other quite well (the approach builds both breadth and depth as the course progresses, which I personally find is better than breadth-first -- e.g., covering all simple operations before starting either function definitions or control structures -- which is really the only alternative.)
This isn't really a problem if you want to learn Scheme and a bit about functional programming -- it actually works rather well -- but in the classroom, such a presentation quickly turns into a confusing mess.
Again, I don't think that's really the strength of HtBP. What its really good for is learning general approaches to problem analysis and solution design with programming as a vehicle; it teaches less about computers as technology and more about analysis than most introductory approaches. Given its stated intent, that's unsurprising.
I disagree. I think the beginner does not want to design anything, much less a complex software system. I think the beginner wants to learn how to make the computer follow some instructions, like add some numbers, or move a square from one part of the screen to another.
I think you are misunderstanding what I wrote. I am not arguing that "the beginner" wants a design focus. In fact, people who are new to programming may want different things, and may not know what they want.
In the part of GP that you quote in your post, I refer to suitability of certain programming languages to a first course where the intent (of the course) is to focus on designing solutions to problems (inherently, this is not "complex software systems", although the skills learned in such a course are transferrable to more complex systems.)
In other parts of GP, I refer to the suitability of different programming langauges for first courses with a different focus.
To the extent that your post rests on the idea that "the beginner", universally, has a single preference and thus that there is only one true and correct focus for a first course, I disagree strongly, and to the extent that your post appears to be directed as a response to a perception that part of my post was arguing on the same premise but with ascribing a different singular preference to "the beginner" I feel obliged to point out that that is a misreading of what I wrote.
Why? You quite obviously know what I mean by 'cruft' (necessary code incomprehensible to the student within the context of the material presented)
In that case, I would say both "zero" and say that procedural, functional, and OO languages -- which permit single-line calls to externally-implemented code that can be explained as telling something else what to do are actually are better at minimizing cruft than old-style BASIC is with mystical routines accessed with GOSUBS and arcane DATA statements.
That being said, you probably want to avoid languages where library access is "in your face" for common I/O tasks (if you have to do an explicit import of an I/O library to read from and write to the console, its probably not the best choice; OTOH it may for some languages be possible to conceal this by not using the normal program running facilities and using a "bootstrapping" mechanism which adds these things in invisibly behind the scenes; if you are teaching concepts and not the particular language and library structure, this may make sense if the other features of the language make it good for the task.)
Remember that the discussion is about teaching programming concepts to children.
I am aware of that. And I remain convinced that the relative merits of structured languages vs. something like old-style BASIC in a language to ise for that vary based on what the purpose of teaching "programming concepts" is: whether its more about teaching programming-as-a-vehicle-to-understanding-computers or programming-as-a-vehicle-to-understand-problem-solving.
That doesn't really change with the age of the audience, though there may be some reason to choose particular languages within broad families based on the age of the audience.
I'm familiar with the book and while I think it's one of the best for introducing functional programming to already competent programmers, I wouldn't use it to teach programming to beginners.
I disagree, I think HtDP great for teaching programming to beginners (I think that's what it is best for, and indeed that's what it is designed for) -- again, if the focus is on problem solving rather than understanding how computers work at a low level, either of which is a valid focus for a first course involving programming. I wouldn't consider it a great book for teaching functional programming, as such, to competent programmers, though I think could be a good book to teach competent coders to be better at structured analysis and design of solutions.
Given the content, I certainly wouldn't use it to teach children under the age of 15.
I'd agree with that as far as the book as a text is concerned, I was citing it as an illustration of a basic approach. I'd use the basic approach (though not necessarily either the book or Scheme specifically as the language) at any age where I wanted to teach programming-as-problem-solving.
Programming-as-a-window-into-the-workings-of-a-computer I think old-style BASIC is still the most accessible language for novice programmers to use. I'm not sure the best approach for that, its not really something I've spent as much time thinking about.
And the -- different but somewhat related -- programming-to-get-over-the-idea-that-its-a-magic-box-that-someone-else-has-to-make-work-for-you can you any language that is readily accessible. Old-style BASIC's line-oriented structure might make it particularly strong here for younger learners, but I'm not sure that it is better than, e.g., Logo for this.
So... how much cruft do think is acceptable?
Define "cruft" concretely enough that it is possible to measure it quantitatively, and then we can discuss that question.
I think any amount is too much, for the reasons stated above.
I don't think most dynamic OO languages impose any "cruft" that must be included before you can begin addressing basic concepts. I think that (and this is true of most procedural and functional languages in general, as well as OO languages) that there are certain concepts (e.g., arbitrary flow control) that are harder to express in those languages, which makes them less suitable for an introduction to programming whose purpose is to teach a low-level understanding of how computers work (compared to BASIC, whose structure, despite the more accessible syntax, is more similar to assembly language.)
OTOH, I think that the ease of expressing structure in functional, OO, and procedural languages makes any of those models better than old-school BASIC for teaching introductory programming in a context where the intent is to focus on designing solutions to problems. (I think each model has different strengths here, but I think a decent curriculum in this regard could be based around a language supporting any of those models, or modern multi-paradigm dynamic languages like Ruby or Python. The best specific implementation I've seen of an introduction of this type is the book How to Design Programs, which uses a series of successively more involved versions of a Scheme-derived pedagogical language.)
Programming should NEVER begin with OO. If for no other reason than the cruft you need to add in OO languages before you can even begin to introducing basic concepts.
That's not really true of OO languages generally, its mostly true of the those languages whose heritage or inspiration in a static procedural language like C or Pascal that then had an OO layer bolted on to it; the Pascal-derived branch of that tree is pretty much dead now, I think, but the C-derived branch, including C++, Java, and C# is still going strong.
OO languages like Smalltalk (for class-based OO) or Self (for prototype-based OO) and those inspired by them (like Ruby and JavaScript) that haven't, somewhere along the line, tried to wed OO structure with an existing static procedural language, don't really feature much boilerplate cruft that needs to be included in simple programs before beginning to introduce basic concepts.
I learned Basic on a Commodore VIC-20 in 1978. I think it is a terrible choice for learning to program. I suggest newbies learn Scheme, a very simple language that will lead you as far down the rabbit hole as you are willing to go.
I learned BASIC, approximately in parallel, on the VIC-20, the TI-99/4A, and a Timex-Sinclair 1000 in elementary school in the early 1980s.
I think its a fine language for learning to program as part of learning how computers work; its high-level enough to be accessible, especially to young students, but structured similarly to assembly languages and provides a good vehicle for teaching about how computers work at a basic level.
I think Scheme is a much better language for teaching how to design programs to solve problems, but the features that make it good for this purpose are precisely the features that obscure the low level process.
Lisp failed [...]
I'm not convinced that that is the case. Various Lisps (Common Lisp, Scheme, specialized dialects used in particular applications, and other varieties) continue in a number of important uses in production environments, continue to be actively developed, and Lisp features continue to be one of major influences on the evolution of many popular languages as areas that have long been noted as Lisp strengths become recognized as important in modern application development.
How, precisely, is that Lisp is supposed to have "failed"?
The meta-law would act to make such funds-direction aspects of a proposed bill invalid, not to be considered part of the bill when voted on or passed into law.
The US Constitutional system doesn't have a category of "meta-law". A federal law is either a Constitutional provisions, a ratified treaty, or an act of Congress. Treaties are irrelevant here, and An act of Congress cannot limit a future act of Congress. If some text is part of the text of an act of Congress as actually voted on and adopted, even if some earlier act of Congress purports to prohibit such text from being in the bill, the it is part of the act and given whatever force is due to that act, including superceding previous conflicting acts of Congress.
As I said in GP, therefore, under the actual system in the US Constitution, such a provision --even ignoring the problem of vagueness -- would have no substantive impact unless the so-called "meta-law" were, in fact, adopted as a Constitutional Amendment, which -- as part of the Constitution -- can constrain acts of Congress.
Geeze, you've never read a paperback?
Yes, I have. Quite a few. Of various kinds.
If you can find someone who has, borrow a few of them and try this experiment: Measure the diagonal size of each one and average the measurements. It's about... say it with me... seven inches.
You seem to referring to mass market paperbacks, which are about 7", but aren't what I was talking about. There is a difference between mass market paperbacks and trade paperbacks.
If you do that for typical trade paperbacks (which is what I specifically call out in GP), which are 6"x9", you'll find that the diagonal measure is 12.7" for the full page, and with fairly typical margin sizes right around 10" for the text. Which is why, in GP, I said: Assuming the page of text is designed to read on a letter/A4 page, a ~14" display is necessary to display the full page at the size it is designed to be viewed. A 10" screen is about right for typical trade paperback size pages. (Though an astute observer will note that I did make the mistake of being inconsistent in using the approximate full page size for the letter/A4 and the typical printed area for trade paperback size.)
Even if I read Rolling Stone, I really don't need to view it in original size.
Maybe you don't, so what? As I said in GP: How much reduction below design size is tolerable will vary from person to person, but many documents are already at the limit of readability at their design size, so any smaller device screen will require zooming and panning for a substantial fraction of users, even if it had the clarity of print.
I figured part of the reason for the 10" widescreen was to be pretty close to 8.5x11 erring on the size of smaller.
Even assuming 1" margins all around (so you have 7.5"x10"), a letter-size device would be 12.5" diagonal, which is significantly greater than the 9.7" of the iPad. The largest Android tablets, in the 11.6-12.1" range, are close in diagonal measure, but tend to be 16:9-ish widescreens, so they they're a bit narrow and tall for viewing unreduced letter size material, even shaving the margins.
That's funny because before the iPad came out all Slashdotters could do was point out how the iPad was nothing new and how tablets had been around for ages, etc etc. And now that the iPad has pretty much owned the entire market the excuse is that "there are no viable competitors". Would it kill you people to admit you were wrong about the iPad and it's likely success?
"Slashdot" is not a hivemind. Just because the posts that you notice most currently contradict the posts you remember most from quite a long time ago doesn't mean that any of the people involved have changed positions, or even that the overall opinion on Slashdot has changed.
The question becomes: What other choices will we have? The question is not: Who has the most sales?
Those are both valid questions. Which is more relevant and important depends what the purpose of asking the question is.
Because, believe it or not, Apple came in at a price point that nobody could match without Apple's sales volume. The only way to under cut Apple's price is to reduce the screen size. By half, it turns out (7^2 = 49, 10^2 =100).
The ViewSonic G is the same price as an iPad wifi, with a 10.1" (1024x600) screen compared to the iPad's 9.7" (1024x768) screen. It is not alone among 10" Android tablets in being price competitive with the iPad.
Its certainly hard for other manufacturers to price compete with Apple given Apple's beating everyone to the market and being able to leverage the App Store advantage, and superior consumer brand image. But its equally certainly not the case that 7" tablets are simply a matter of being the only thing other manufacturers can do to price compete, though it is something they can do to differentiate themselves and target a market segment and interest that Apple isn't already hitting.
Just like the 11.6"-12.1" 1366x768 tablets are, on the other end. (These tend to be more expensive than the iPad, but then that shouldn't be surprising.)
If I purchase blank CD's, DVD's or hard drives and I got charged a "Piracy Tax", I would consider that my payment to copyright holders and I would pirate all I wanted.
The U.S. has such a levy/tax on blank audio recording media, adopted as part of the Audio Home Recording Act of 1992.
Anyway, If anyone could make a 10" iPad competitor at $500 or less, they'd have done so by now.
There's actually quite a few ~10" Android tablets that have been announced at that price point; all 4 of the Notion Ink Adam 10.1" (1024x600) models which sold out of preorders this month had prices under $550, 3 of the 4 under $500 (all but the Pixel Qi + 3G model).
The ViewSonic G 10.1" (1024x600) tablet that has been on sale since November seems to be $399.99 at most major online retailers that sell it, slighlty lower at some.
That everyone who is trying is coming in at half the screen size should be confirmation.
Actually, several competing models that have been announced (including a few already available) are in the 11.6" to 12.1" range (typically 16:9, 1366x768), and quite a few are 10.1" (1024x600) devices.
So Apple sell a netbook with no keyboard and an ARM CPU for twice the price of a netbook and no-one can compete with it on price?
No one has anything like the way of driving revenue after the sale of the device itself like Apple has with the App Store that was established for the iPhone before the iPad came out. The App Store lets Apple sell iPads at a lower price than it would otherwise be able to.
It is not about it being 7 inches, it is about it ALL OF THEM being 7 inches.
If by "THEM" you mean "tablets that aren't the iPad", they aren't all 7 inches. Of those on the market or announced, the range is something like 4-12 inches. 7 in. seems to be the most common, but it is far from the only size.
There's actually quite a few 11.6" and 12.1", 1366x768 tablets.
10" minimum - to comfortably read a page of text in landscape without zooming.
Assuming the page of text is designed to read on a letter/A4 page, a ~14" display is necessary to display the full page at the size it is designed to be viewed. A 10" screen is about right for typical trade paperback size pages.
How much reduction below design size is tolerable will vary from person to person, but many documents are already at the limit of readability at their design size, so any smaller device screen will require zooming and panning for a substantial fraction of users, even if it had the clarity of print.
Why are all these ipad competitors doing 7 inch screens?
Not all the non-iPad tablets that have been announced, had specs leaked, or, for that matter, are already on the market have 7" screens.
Some of them have 10" screens, like the iPad. Some of them have 7" screens. Some of them have bigger screens. Some of them have smaller screens.
And the reason for the variety of screen sizes is because not every manufacturer thinks that 10 inches is the One True Size for tablets.
What if a law was passed invalidating all porkbarrelling clauses in federal legislation, including retroactively?
It would probably be unenforceable due to vagueness: "porkbarrelling" is a subjective description applied to laws directing funds in a manner which the speaker feels does more to benefit the political interest of a legislator than the national interest.
Even if it wasn't unenforceable due to vagueness, and it wasn't a Constitutional amendment, any newer law specifically directing funds in a manner inconsistent with the "meta-law" would supercede the "meta-law" to the extent that they conflicted, as newer enactments trump older ones.
In any case, it wouldn't have any substantive effect.
Wait, wait, wait. The wife in this story is cheating on her third husband with her ex-second, who by the way has a criminal record for abusing her. The third goes into her email and provides it to the first husband, the father of their son, so that he might intervene and prevent any contact between his son and the second.
And the third is the asshole?
See, here's your problem: you think being an asshole is exclusive.
Taking the story as you relate it, the woman, the second husband, and the third husband are all assholes.
Considering that when you are married, in terms of property rights, you are considered a single legal entity, I honestly don't see how this would stand up in court.
Well, for one thing, there is the fact that, in most U.S. jurisdictions, being married does not mean you are treated as a "single legal entity" for property rights.