You are making the assumption that they didn't intend this result. Or at least that they weren't aware that this would be the result. I find that quite dubious. As you say, it was obvious by inspection
OTOH, what would have been the result of disbanding the Iraqi army? You've created a bunch of people trained in violence suddenly out of work. I'm not convinced that it would have resulted in a better situation, though clearly it would be a different situation. And long term occupation would also have tremendous probabilities for disaster.
The real mistake was deciding to invade. After that I don't think there was a decent exit strategy...not if you are counting human cost. But this *must* have been obvious ahead of time, so clearly that wasn't their consideration. Who benefited? Who expected to benefit? How? It strikes me as a clearly political decision with only political gains.
True, there also needs to be a maximum length of any given law which includes in the length all other laws cited by reference.
I also think there needs to be a reasonable test for intelligibility. It's not right that everyone should understand every law, that's an impossibily high bar, but an average high school senior should. And at minimum should be able to. I can't think of a simple way of phrasing that test though that isn't of the form "Take a bunch of average high school seniors and have them write an essay about what the law means, and what it means is the intersection of what they claim it means", and that's also a poor idea, because it would eliminate everything...but I can't think of an objective "average understanding" evaluator.
How persistent is the storage over time? I've had CDs become unreadable due to media degradation...though I don't know whether it was fading of the dyes or yellowing of the covering...or some other reason...but it wasn't scratches.
OTOH, air pressure at sea level is a variable which can change significantly in even a short period of time. Still, dramatic changes don't happen, but it's better to measure it in.... sorry, I should be metric, but I only think in PSI (pounds / square inch).
Well....sort of. The CMB is modified by galaxies that are too faint to see, though I don't know by how much. It's filtered by intervening dust clouds moving WRT both us and the "origin of the signals". Etc. I normally assume that this is taken account of as best we can, but it's not unmodified signal. If you look at the raw (uncorrected) observations, I don't know how much noise is present, but clearly that are signals too weak to be recognized even though detected.
OTOH, I am not a cosmologist. But I do recognize that error bars are important, and that they tend to get left out of popular articles.
Yes. There are numerous reasons to "not fight city hall". But that doesn't mean you can't do it for a good enough reason. E.g., I use tab spacing at the start of Python lines. This causes formatting problems if I use idle, but to me its worth the cost. And I've occasionally had reasons to use a length terminated string in C...though I usually also zero terminate it. (IIRC the reason was that I needed to include 0 valued bytes in the string.)
Similarly you can use zero delimited strings in Pascal, but you need to write the support routines that you would need, and since current Pascal has a string type that isn't limited to 255 chars it they would appear to be rarely needed.
No. Python is an open source project. Ruby is an open source project. Squeak is an open source project. D is an open source project. Racket (scheme) is an open source project. ALL have decent language documentation. And that was just a list off the top of my head. Being an open source project is not an excuse for lousy documentation.
Did you ever try to run C on the Apple ][? UCSD Pascal was available, and worked well. C required an add on z-80 chip, and it was still a subset implementation. (Check out "Lifeboat C", though I think that was a later, and more capable version.)
So the situation is more complicated than you are assuming. I didn't get a full C compiler until AFTER I had gotten an 8086...which means probably that the IBM PC was already around.
Sorry, but the length defined strings are optional, though common in Pascal. UCSD (and other early) Pascals usually buit that into the language, but I believe that now it's a part of a standard library, and alternates can be defined (though probably not with the same name). I'm not sure why you consider Pascal data structures more "well defined" than C structs.
P.S.: Strings in C can also be handled with a length byte. The zero terminated strings are purely a library convention, and can be overridden.
FWIW fpc Pascal has a string type in it's library that uses a length value longer than a byte.
FWIW, there's nothing intrinsically wrong with Pascal...or less than with C or C++. Java is worse, hobbled by 16-bit unicode, a horrible decision, which was justifiable at the time the decision was made. (Unicode should be either utf-8 or utf-32 [UCS-4]. I generally prefer utf-8, but that requires more complex library support.)
OTOH, the only real advantage of Pascal is fast compile times, and optimal execution times (which can easily be matched in C).
So, yes, its underrated, but there's probably no good reason to change to it.
From my point of view, the problem is lack of documentation. I *think* that fpc Pascal can not properly handle utf8 strings, and determine the general character class of individual characters (something that Java struggles with), but the documentation is so bad that I'm not sure. And I didn't bother to test because I couldn't find any good samples to start from. Lazarus has a lot of good press, so i can accept that it is a powerful GUI development tool, but that's not what I'm doing.
FWIW, I've got a long series of desires for my programming language, and no language that I'm aware of satisfies all of them. But if its a lot different from languages that I already know, then I'm less willing to invest time learning. Pascal should have a clear bonus here, as I used to program in Object Pascall on the Mac II, but the documentation is so bad that I've tried radically different languages (e.g., Racket Scheme) and passed over fpc. (Mind you, a few years ago it was missing some needed features, but now I think that it has all the features I need, probably, but I can't be sure.)
References are essentially the same as pointers anyway for what matters here.
I think this is why we are disagreeing. I don't consider them the same. (Reference in Python doesn't mean the same as reference in C++. Those are, indeed, essentially pointers.)
Using Python references does, indeed, enable a high level understanding, but it doesn't facilitate a low level understanding. And I consider hash tables (dicts) much more important than priority queues...which, of course, is why Python has them built-in.
Well, no. Pickle doesn't solve this, as it requires the entire file to be one image. Shelve is closer, but still doesn't fit my needs. I need to stick data structs into a database, and what I settled on as the best option available is a combination of rexpr and ast.literal_eval. But that *does* mean converting everything into text to save it. (Pickle allows untrusted data arbitrary execution, whereas ast.literal_eval just reconstitutes forms that are built-in and are safe, or at least that's what the docs say.)
Python doesn't implement its data structures in Python, though there is usually a Python implementation with the same interface...but which is a LOT slower. But Python doesn't have pointers. (References are close, but not really the same.) So Python isn't a good choice for implementing data structures as a teaching environment. I haven't looked into how Smalltalk implements them, but I suspect its basically the same approach. The advantage of references is that they allow garbage collection to be efficient, but the concept is sufficiently different from pointers that it prevents actual understanding at a low level.
OTOH, I'm not sure how a pointer language should handle memory allocation and release in an introductory course. (I started with assembler and FORTRAN IV, so I don't have the correct perspective.)
Well, when I started the first thing we were taught was assembler...of course, assemblers were simpler then. I found it useful for quite awhile, but these days I never look at assembly code (though others do).
To me it seems that C is the proper language to start with for high school or later. Younger students might benefit more by learning something like Scratch. But C is a "portable assembler". (Well, almost.) It is simple enough to do simple things in, and it enables the teaching of data structures, logic, debugging, etc. BUT DON'T STOP THERE. You also should teach Java, at least a bit of Scheme or Lisp, and probably Python and Ruby. And, of course, some C++. These latter languages don't need the depth of coverage that you should give to the first language (i.e., C), but enough that you can see what their strengths are. Say a week on each, in each case translating some program that you've done earlier in C.
I've probably outlined more than a one year class, however.
The word you are looking for is "compile", not "handle". Python handles blocks of text better than C does (by many measures). It does, however, depend on code being "properly indented" to compile it properly.
FWIW, Python compiles text file to run on a virtual machine, so it's a compiler. I'll agree that it's not particularly efficient, but most things I work with end up being I/O bound, so Python is "fast enough".
What I don't like is that it's difficult to dump a piece of data to the disk without converting it into text first. Everything ends up depending on pointers (hidden from the user, so you don't need to worry as long as everything stays in RAM). This would make structs useless even if Python supported them. And this is the kind of inherent inefficiency that bothers me...but it's so much faster to develop in, that I'm using it now, and after I finish I'll consider what parts to convert to something else.
P.S.: For many things Python is quite efficient, because so much can be done with built-in libraries (that were hand-coded and optimized in C). I'm not claiming that it's totally efficient, but there are lots of tradeoffs.
The thing is, if you're using Python you don't implement lists, you use the built-in functions. So it seriously depends on what you want to teach.
If you want to teach data structures, C is a better language, because you aren't teaching them to ignore the characteristics of the language. If you just want to teach basic sequencing, etc., something like Scratch is better. It's sort of a graphical subset of Smalltalk adapted for simple animations, or perhaps a cross between Smalltalk and Logo, but the programming is visual rather than typing. It's designed to be useful for grade school children. It's great for teaching sequencing, composition, logic, etc. It's lousy for teaching data structures.
Personally, I can't see any justification for selecting VB *or* VB.net. I.e., I can't imagine what you are trying to teach that would make VB the preferred language. And while Python is a better choice, I can't see that as an introductory language either. Were I doing it I'd probably have them use Scratch first and then switch over to C, or a C++ subset that was equivalent. This would, however, be a jarring transition. Scratch is a contained environment designed to be attractive to young children. It would be an easier transition if one started with Squeak's etoys, but it would make for a rough start, and the last time I tried it (years ago) there were several bugs that would make getting started difficult.
It seems to be crucially dependent on the size of the area. Towns often have decent governments, cities more rarely, states... only the small ones. The country...no.
That said, another factor is the number of more powerful groups looking over your shoulder. If a city or town becomes too corrupt either the state or the feds are likely to step in. (I don't know how analogous this is to Canada, but I suspect it's a global property.)
You are mistaken in equating the two. KDE attempts to serve a large user community, who have diverse interests. Gnome attempts to serve a large coprorate community who have diverse interests. There's a lot of difference in what their goals are. (Even given that I consider Gnome3 a mistake.)
OTOH, both are serving systems running on large general purpose computers. Both *can* be run headless, but neither is designed for that purpose.
If you're going to run on a small system you should pick a different desktop, if any. I can't even give any guidelines, as which is a good choice depends on which constraints you have, and if you're even considering KDE, something like blackbox would be unreasonable. You might look at fwvm.
Slashdot Mirror
You are making the assumption that they didn't intend this result. Or at least that they weren't aware that this would be the result. I find that quite dubious. As you say, it was obvious by inspection
OTOH, what would have been the result of disbanding the Iraqi army? You've created a bunch of people trained in violence suddenly out of work. I'm not convinced that it would have resulted in a better situation, though clearly it would be a different situation. And long term occupation would also have tremendous probabilities for disaster.
The real mistake was deciding to invade. After that I don't think there was a decent exit strategy...not if you are counting human cost. But this *must* have been obvious ahead of time, so clearly that wasn't their consideration. Who benefited? Who expected to benefit? How? It strikes me as a clearly political decision with only political gains.
True, there also needs to be a maximum length of any given law which includes in the length all other laws cited by reference.
I also think there needs to be a reasonable test for intelligibility. It's not right that everyone should understand every law, that's an impossibily high bar, but an average high school senior should. And at minimum should be able to. I can't think of a simple way of phrasing that test though that isn't of the form "Take a bunch of average high school seniors and have them write an essay about what the law means, and what it means is the intersection of what they claim it means", and that's also a poor idea, because it would eliminate everything...but I can't think of an objective "average understanding" evaluator.
How persistent is the storage over time? I've had CDs become unreadable due to media degradation...though I don't know whether it was fading of the dyes or yellowing of the covering...or some other reason...but it wasn't scratches.
OTOH, air pressure at sea level is a variable which can change significantly in even a short period of time. Still, dramatic changes don't happen, but it's better to measure it in .... sorry, I should be metric, but I only think in PSI (pounds / square inch).
Well....sort of. The CMB is modified by galaxies that are too faint to see, though I don't know by how much. It's filtered by intervening dust clouds moving WRT both us and the "origin of the signals". Etc. I normally assume that this is taken account of as best we can, but it's not unmodified signal. If you look at the raw (uncorrected) observations, I don't know how much noise is present, but clearly that are signals too weak to be recognized even though detected.
OTOH, I am not a cosmologist. But I do recognize that error bars are important, and that they tend to get left out of popular articles.
Nonsense. The cat does not hate the mouse, the cat LOVES the mouse. It's delicious.
Yes. There are numerous reasons to "not fight city hall". But that doesn't mean you can't do it for a good enough reason. E.g., I use tab spacing at the start of Python lines. This causes formatting problems if I use idle, but to me its worth the cost. And I've occasionally had reasons to use a length terminated string in C...though I usually also zero terminate it. (IIRC the reason was that I needed to include 0 valued bytes in the string.)
Similarly you can use zero delimited strings in Pascal, but you need to write the support routines that you would need, and since current Pascal has a string type that isn't limited to 255 chars it they would appear to be rarely needed.
No.
Python is an open source project. Ruby is an open source project. Squeak is an open source project. D is an open source project. Racket (scheme) is an open source project. ALL have decent language documentation. And that was just a list off the top of my head. Being an open source project is not an excuse for lousy documentation.
Did you ever try to run C on the Apple ][? UCSD Pascal was available, and worked well. C required an add on z-80 chip, and it was still a subset implementation. (Check out "Lifeboat C", though I think that was a later, and more capable version.)
So the situation is more complicated than you are assuming. I didn't get a full C compiler until AFTER I had gotten an 8086...which means probably that the IBM PC was already around.
Sorry, but the length defined strings are optional, though common in Pascal. UCSD (and other early) Pascals usually buit that into the language, but I believe that now it's a part of a standard library, and alternates can be defined (though probably not with the same name). I'm not sure why you consider Pascal data structures more "well defined" than C structs.
P.S.: Strings in C can also be handled with a length byte. The zero terminated strings are purely a library convention, and can be overridden.
FWIW fpc Pascal has a string type in it's library that uses a length value longer than a byte.
FWIW, there's nothing intrinsically wrong with Pascal...or less than with C or C++. Java is worse, hobbled by 16-bit unicode, a horrible decision, which was justifiable at the time the decision was made. (Unicode should be either utf-8 or utf-32 [UCS-4]. I generally prefer utf-8, but that requires more complex library support.)
OTOH, the only real advantage of Pascal is fast compile times, and optimal execution times (which can easily be matched in C).
So, yes, its underrated, but there's probably no good reason to change to it.
fpc is Object Pascal, and not a proprietary language. Unfortunately, its also poorly documented.
From my point of view, the problem is lack of documentation. I *think* that fpc Pascal can not properly handle utf8 strings, and determine the general character class of individual characters (something that Java struggles with), but the documentation is so bad that I'm not sure. And I didn't bother to test because I couldn't find any good samples to start from. Lazarus has a lot of good press, so i can accept that it is a powerful GUI development tool, but that's not what I'm doing.
FWIW, I've got a long series of desires for my programming language, and no language that I'm aware of satisfies all of them. But if its a lot different from languages that I already know, then I'm less willing to invest time learning. Pascal should have a clear bonus here, as I used to program in Object Pascall on the Mac II, but the documentation is so bad that I've tried radically different languages (e.g., Racket Scheme) and passed over fpc. (Mind you, a few years ago it was missing some needed features, but now I think that it has all the features I need, probably, but I can't be sure.)
That, however, is not only unrelated to public domain, it's also unrelated to copyright. That's a patent law disagreement.
First to file only applies, I believe, if you also independently invent. And in any case that's patent law, not copyright law.
References are essentially the same as pointers anyway for what matters here.
I think this is why we are disagreeing. I don't consider them the same. (Reference in Python doesn't mean the same as reference in C++. Those are, indeed, essentially pointers.)
Using Python references does, indeed, enable a high level understanding, but it doesn't facilitate a low level understanding. And I consider hash tables (dicts) much more important than priority queues...which, of course, is why Python has them built-in.
Well, no. Pickle doesn't solve this, as it requires the entire file to be one image. Shelve is closer, but still doesn't fit my needs. I need to stick data structs into a database, and what I settled on as the best option available is a combination of rexpr and ast.literal_eval. But that *does* mean converting everything into text to save it. (Pickle allows untrusted data arbitrary execution, whereas ast.literal_eval just reconstitutes forms that are built-in and are safe, or at least that's what the docs say.)
Python doesn't implement its data structures in Python, though there is usually a Python implementation with the same interface...but which is a LOT slower. But Python doesn't have pointers. (References are close, but not really the same.) So Python isn't a good choice for implementing data structures as a teaching environment. I haven't looked into how Smalltalk implements them, but I suspect its basically the same approach. The advantage of references is that they allow garbage collection to be efficient, but the concept is sufficiently different from pointers that it prevents actual understanding at a low level.
OTOH, I'm not sure how a pointer language should handle memory allocation and release in an introductory course. (I started with assembler and FORTRAN IV, so I don't have the correct perspective.)
Well, when I started the first thing we were taught was assembler...of course, assemblers were simpler then. I found it useful for quite awhile, but these days I never look at assembly code (though others do).
To me it seems that C is the proper language to start with for high school or later. Younger students might benefit more by learning something like Scratch. But C is a "portable assembler". (Well, almost.) It is simple enough to do simple things in, and it enables the teaching of data structures, logic, debugging, etc. BUT DON'T STOP THERE. You also should teach Java, at least a bit of Scheme or Lisp, and probably Python and Ruby. And, of course, some C++. These latter languages don't need the depth of coverage that you should give to the first language (i.e., C), but enough that you can see what their strengths are. Say a week on each, in each case translating some program that you've done earlier in C.
I've probably outlined more than a one year class, however.
The word you are looking for is "compile", not "handle". Python handles blocks of text better than C does (by many measures). It does, however, depend on code being "properly indented" to compile it properly.
What is a "scripting language"?
FWIW, Python compiles text file to run on a virtual machine, so it's a compiler. I'll agree that it's not particularly efficient, but most things I work with end up being I/O bound, so Python is "fast enough".
What I don't like is that it's difficult to dump a piece of data to the disk without converting it into text first. Everything ends up depending on pointers (hidden from the user, so you don't need to worry as long as everything stays in RAM). This would make structs useless even if Python supported them. And this is the kind of inherent inefficiency that bothers me...but it's so much faster to develop in, that I'm using it now, and after I finish I'll consider what parts to convert to something else.
P.S.: For many things Python is quite efficient, because so much can be done with built-in libraries (that were hand-coded and optimized in C). I'm not claiming that it's totally efficient, but there are lots of tradeoffs.
The thing is, if you're using Python you don't implement lists, you use the built-in functions. So it seriously depends on what you want to teach.
If you want to teach data structures, C is a better language, because you aren't teaching them to ignore the characteristics of the language. If you just want to teach basic sequencing, etc., something like Scratch is better. It's sort of a graphical subset of Smalltalk adapted for simple animations, or perhaps a cross between Smalltalk and Logo, but the programming is visual rather than typing. It's designed to be useful for grade school children. It's great for teaching sequencing, composition, logic, etc. It's lousy for teaching data structures.
Personally, I can't see any justification for selecting VB *or* VB.net. I.e., I can't imagine what you are trying to teach that would make VB the preferred language. And while Python is a better choice, I can't see that as an introductory language either. Were I doing it I'd probably have them use Scratch first and then switch over to C, or a C++ subset that was equivalent. This would, however, be a jarring transition. Scratch is a contained environment designed to be attractive to young children. It would be an easier transition if one started with Squeak's etoys, but it would make for a rough start, and the last time I tried it (years ago) there were several bugs that would make getting started difficult.
Einstein offered theories that could be checked by others. And were.
It seems to be crucially dependent on the size of the area. Towns often have decent governments, cities more rarely, states ... only the small ones. The country...no.
That said, another factor is the number of more powerful groups looking over your shoulder. If a city or town becomes too corrupt either the state or the feds are likely to step in. (I don't know how analogous this is to Canada, but I suspect it's a global property.)
You are mistaken in equating the two. KDE attempts to serve a large user community, who have diverse interests. Gnome attempts to serve a large coprorate community who have diverse interests. There's a lot of difference in what their goals are. (Even given that I consider Gnome3 a mistake.)
OTOH, both are serving systems running on large general purpose computers. Both *can* be run headless, but neither is designed for that purpose.
If you're going to run on a small system you should pick a different desktop, if any. I can't even give any guidelines, as which is a good choice depends on which constraints you have, and if you're even considering KDE, something like blackbox would be unreasonable. You might look at fwvm.