The problem is, most contracts I've seen regarding hosting/housing/internet services specifically protects the provider against any kind of legal responsability. So you won't have ISPs refusing unless it's their own sites.
It's funny how a (somewhat)developed country with one of the highest unemployment rates (>20%), with an estimate of 40% of its finantial sector completely deregulated (through an interesting concept of "non profit" or "associative" banks), with a recently elected government, and the likely candidate for rescue in 2012 by the IMF and the european fund, has "time" to vote and pass this kind of legislation, that probably will be voided when disputed on an european court.
Europe is not the USA. A law approved by whatever congress equivalent you have can be discarded as inconstitutional, if it violates rights present in the constitution. Also, Spain is bounded by EU law in many domains, and citizen rights violations can be forwarded to EU tribunals (such as the subversion of the principle "innocent until proven guilty"), so even if the government is serious about it (which I doubt, this seems to be a "pleaser" law), they could be walking into some serious fines if someone appeals to an EU court.
Anything other than a judge decreting a site to be closed is likely unconstitutional, and the first ISP to drag a case to the court will void the law, because the law itself voids the principle of "innocent until guilty". I'm not spanish (I'm from a neighour country), but it seems if one of these cases reaches an european court it will stand no chance, so this seems to be a "pleaser" law - it's written and whatnot (and given that Spain recently changed powers, it's not difficult to guess why now), but if you try to enforce it on the wong people, a shitstorm will rise. Considering that Spain is one of the countries that signed the Lisbon Treaty (and one of the few countries to referend it), the ones actually approving this law will have no interest whatsoever in enforcing it, specially considering the precarious finance state of the country.
Yeah, the ISP refuses and goes to court to dispute it (as in proving they're not infringing). If you are a suspected murder, you usually go to court _before_ being forced to do anything. That's called presumption of innocence, and it's somewhat of a big thing in Europe.
The 80286 instruction set was simply god-awful. It was basicly a 8086 with better performance and a castrated and inconsistent protected mode support.
You can't write truly cross platform assembly in most of the available RISC processors either. There's always extensions, issues, extra register, hiccups and whatnot.
Intel has been translating x86 legacy instructions to RISC operands for ages. It happens in almost every major CPU released in the last decade. So, technically, x86 is already gone a long time.
Smaller dies means more defects per wafer. And electric problems at subatomic level. And defects that may manifest only when voltage is applied (leaking electrons, capacitance problems, etc). Also, smaller dies means that the specs for the raw materials are tightened, so it usually translates to "more expensive".
I won't argue that ARM architectures are probably simpler to implement (chipwise) than Intel's x86/ADM64. What is usally called x86 instruction set is actually a blend of multiple instruction sets of different generations of processors, but most instructions aren't implemented in silicon, and Intel clearly describes it in the architecture manuals. CISC instructions are decoded in "micro-ops" (internal RISC instructions) and then those instructions are fed to the execution pipelines. You have microcode updates for "upgrading" the translation mechanism and, if needed, correct bugs on existing instructions. The instruction by itself set isn't directly related to the complexity of the processor (usually data/address paths and register size ARE the limiting factors).
...And x86 was a lot cheaper and easier to license (Amd, Cyrix, TTI, etc). And the software offer was vastly superior. But the funny thing is, Intel did have RISC processors (i860 and i960), and they were quite popular as general-purpose cpu's. Most modern Intel cpus _are_ RISC, as they translate CISC instructions to what they call "micro-ops" (internal RISC instructions), so the line between x86/CISC and RISC design has been blurred at least since the old Pentium II.
It is not a personal attack, and knowing how a compiler works is paramonut to decide which coding style is appropriate. I haven't read the book you mentioned (but yes I'm familiar with the title and its reputation). I'm shure the book is awesome, but the habit of following those decade-old "good programming practices" and abuse of local variables has had some interesting side effects that probably aren't covered in the book. I'm talking of a decade of buffer overflows and other stack smashing techniques, that use and abuse both the proliferation of local variables and the lack of boundary detection in many base functions, and orphaned allocated memory blocks. In fact, the problem is SO severe, that the 2 features most advertised on "modern" compiled languages is precisely the impossibility of stack smashing (because local vars are no longer in the stack), and garbage collection, to avoid the memory pollution problem. What do you think will work better, to have a C++ business database app opening and closing datasets somewhere inside methods as needed, or having well defined generic datasets with global scope? Which approach you think the programmer is more likely to learn? Yes, you can have a broker delivering those datasets as needed (and then you wouldn't need to declare them explicitly in the global scope), or create even more complex solutions to a simple problem, but I'm shure you get my point. The prejudice against global vars is largely unfunded (regardless of what any book would say).
And not everyone is writing code for xeon workstations - there is a ton of C code being written for PICs, microcontrollers, 8 bit microprocessors and DSP devices, where the available stack space is limited. Amost every modern EE is capable of programming in C or an equivalent language, even on their first-year jobs.
Don't take my words as any kind of attack on you, it is not my intent. I believe it is important that programmers know how things actually work, so they can make their own decisions. Relying on gospels and dogmas do more harm to the field than good, because no innovation will come out of it.
Task: Write a for() cycle in C with an integer variable increasing from 1 to 1 million. Make it so it is compilable in any architecture C is available for. Do the same in Basic.
The thing is that many old-time Basic programmers were casual programmers. They didn't learn to program to be professionals, they started programming for fun and, more often than not, to create software suitable to their needs. They don't need C or OO concepts, they need to lay some lines of code and see the result. Now if you want to do some "quick and dirty" simple application like many people did back then, you don't have much choice. You probably need to learn about GUI, and learn about objects and learn about compilers and packages and modules and libraries. You don't get a self-contained executable that just works - you need to "install" applications. That's why many of those casual programmers stopped programming, because it became too complex to do simple things. Many of them still use the same algorithmic concepts they learned with basic when working with spreadsheets, macro languages or database systems, but they're not programmers - they are power users.
If you want to DO more (whatever that means) in a PIC environment with C, you might as well use Assembly and spare the trouble of actually having to learn a 3rd party language.
Most business-oriented BASIC interpreters and compilers available in the mid-80's did allow a fairly complete procedural approach to application writing - it's not their fault if you insisted on using GWBasic or the ZX Spectrum basic interpreter.
While I get the point you were making, the notion that excess global variables are always "bad" is an amusing one, and shows how little serious coding you actually did back then. In compiled languages, global variables are usually defined in program space, and that translates to "the binary will not load if not enough memory is available to load it" instead of "oops this broke because we ran out of stack space". Declaring your "heavy" variables with global scope would give you some kind of assurance that you'd not run out of memory when allocating them. Yes you could use stack monitoring, but most stack overflow check routines were computationaly expensive. In modern systems, concentrating sensitive variables in the global space allows the program to mark them as non-pageable, so you can be shure they are always present in memory (and not on some swap file). So yeah, global variables may be bad, or not. Depends on what you're trying to use.
In the beginning of this millenium, you probably had more Basic business code running than all the Cobol code created since the language's creation. It was used from microcontrollers (8052AHBASIC as an example), automation systems (soo many RS232 control systems written in lame Basic!), business software development (TuboBasic/PowerBasic in the late 80's and Visual Basic in the 90s, and derived Basic-like languages such as Clipper.
From what I know, Basic was mainly absent from mainframe environment, and Cobol, RPG and Fortran did sell a lot compiler licenses and programming materials such as books and courses.
1) C, C++, hell even Java : c = a+b (1 assembly instruction)
Actually, in most environments that would be compiled as at least 2 instructions, assuming the compiler was optimizing for register use. There are some marginal cases where you can actually combine the operation if calculating a offset address, but by your code I doubt that's the case. And that is, of course, assuming a and b are <=16-bit integers, so you can actually compare them on a 8086.
This means that a C program running on an 8086 will actually calculate faster than a python program running on a current pc.
Probably yes. But do not assume that a 8086 will execute 1 instruction per clock cycle (heck, a 8/16/32bit mul on a 486DX takes up to 11 clock cycles!), and most modern processors with out-of-order execution will execute up to 3 instructions per cycle. The cache and RAM timing is often the limiting factor of the processor, so you can say many modern processors idle very well while they wait for memory operations, when executing code not specifically optimized for their prefetch queue size and memory alignment requirements.
I'm not a python user nor a python fan. I use other dynamic languages such as PHP that suffer from some of the problems you mention, but I think you are mixing apple and oranges. Just because you _can_ use python to prototype some calculations, it doesn't mean it's the right tool for the job. Sometime in my career I worked as a Cobol programmer, and I've used DirectX with Cobol just for kicks. It doesn't mean it's the right tool for the job (and believe me, Cobol is NEVER the right tool for the job:D). The problems you describe with memory consumption are what I consider "rookie mistakes" (maybe in your specific case aren't, but as a generic example they are) - classes aren't the answer for everything, and variable sized datasets should always be windowed, regardless of language.
I should point out the pain that is to work with both basic datatypes (byte, int, long) and strings in languages as C and C++. If your compiling your simple example above on a 8086 and b happens to have the value 70000d, you'd need at least 4 or 5 instructions in a loop to complete the operation. You usually cannot make strong assumptions about the size of your datatypes, at the cost that the compiler will figure it out. Most often than not, it won't, and that's why an algorithm in plain C written on a 32 bit processor can fail on a 16 bit one.
Regarding language learning, I am a strong supporter of both Pascal-styled languages and Assembly. People should learn how the machine actually works, because knowing the details of execution WILL make them better programmers. I somewhat understand the void left by "old basic", as you could access and change memory contents and device addresses directly, and it was simple enough to learn the basic structure of a program. Touting OO languages as a first language is a horrible horrible idea that will dumb down future programmers to "one-size fits all" solutions.
Reality check - in most of the western world, the newspapers are owned by economic groups with a political agenda. Liberal unafiilliated media is a pipe dream, because journalism is not about facts and truth - it's about passing a point of view.
My desktops at the time all had (at least) 128MB of RAM, so XP actually felt faster than W2K. USB 2.0, System Restore, prefetch improvements, and ClearType were more-than-enough reasons to want to run XP at the time.
It should be noted that the hardware requirements for W7 are about the same as Vista Premium, and it feels a lot snappier. I haven't used much Vista (went from xP64 to W7 64), most machines with it were third party computers.
Given the amount of errors I've found in books over the years, I'd say don't believe anything you read - period. Our lives are ridden with little lies and myths perpetualized in written form. A good example is how history books are written and rewritten describing different versions of facts, according to the place you live.
Slashdot Mirror
They only ram it up your ass when you don't give your face for what you believe to be right. We're not all ACs.
The problem is, most contracts I've seen regarding hosting/housing/internet services specifically protects the provider against any kind of legal responsability. So you won't have ISPs refusing unless it's their own sites.
(to be read with Simpon's Apu voice)
You are not welcome here anymore. Thank you, come again!
It's funny how a (somewhat)developed country with one of the highest unemployment rates (>20%), with an estimate of 40% of its finantial sector completely deregulated (through an interesting concept of "non profit" or "associative" banks), with a recently elected government, and the likely candidate for rescue in 2012 by the IMF and the european fund, has "time" to vote and pass this kind of legislation, that probably will be voided when disputed on an european court.
Europe is not the USA. A law approved by whatever congress equivalent you have can be discarded as inconstitutional, if it violates rights present in the constitution. Also, Spain is bounded by EU law in many domains, and citizen rights violations can be forwarded to EU tribunals (such as the subversion of the principle "innocent until proven guilty"), so even if the government is serious about it (which I doubt, this seems to be a "pleaser" law), they could be walking into some serious fines if someone appeals to an EU court.
Anything other than a judge decreting a site to be closed is likely unconstitutional, and the first ISP to drag a case to the court will void the law, because the law itself voids the principle of "innocent until guilty". I'm not spanish (I'm from a neighour country), but it seems if one of these cases reaches an european court it will stand no chance, so this seems to be a "pleaser" law - it's written and whatnot (and given that Spain recently changed powers, it's not difficult to guess why now), but if you try to enforce it on the wong people, a shitstorm will rise. Considering that Spain is one of the countries that signed the Lisbon Treaty (and one of the few countries to referend it), the ones actually approving this law will have no interest whatsoever in enforcing it, specially considering the precarious finance state of the country.
Yeah, the ISP refuses and goes to court to dispute it (as in proving they're not infringing). If you are a suspected murder, you usually go to court _before_ being forced to do anything. That's called presumption of innocence, and it's somewhat of a big thing in Europe.
The 80286 instruction set was simply god-awful. It was basicly a 8086 with better performance and a castrated and inconsistent protected mode support. You can't write truly cross platform assembly in most of the available RISC processors either. There's always extensions, issues, extra register, hiccups and whatnot.
Intel has been translating x86 legacy instructions to RISC operands for ages. It happens in almost every major CPU released in the last decade. So, technically, x86 is already gone a long time.
Smaller dies means more defects per wafer. And electric problems at subatomic level. And defects that may manifest only when voltage is applied (leaking electrons, capacitance problems, etc). Also, smaller dies means that the specs for the raw materials are tightened, so it usually translates to "more expensive".
I won't argue that ARM architectures are probably simpler to implement (chipwise) than Intel's x86/ADM64. What is usally called x86 instruction set is actually a blend of multiple instruction sets of different generations of processors, but most instructions aren't implemented in silicon, and Intel clearly describes it in the architecture manuals. CISC instructions are decoded in "micro-ops" (internal RISC instructions) and then those instructions are fed to the execution pipelines. You have microcode updates for "upgrading" the translation mechanism and, if needed, correct bugs on existing instructions. The instruction by itself set isn't directly related to the complexity of the processor (usually data/address paths and register size ARE the limiting factors).
...And x86 was a lot cheaper and easier to license (Amd, Cyrix, TTI, etc). And the software offer was vastly superior. But the funny thing is, Intel did have RISC processors (i860 and i960), and they were quite popular as general-purpose cpu's. Most modern Intel cpus _are_ RISC, as they translate CISC instructions to what they call "micro-ops" (internal RISC instructions), so the line between x86/CISC and RISC design has been blurred at least since the old Pentium II.
It is not a personal attack, and knowing how a compiler works is paramonut to decide which coding style is appropriate. I haven't read the book you mentioned (but yes I'm familiar with the title and its reputation). I'm shure the book is awesome, but the habit of following those decade-old "good programming practices" and abuse of local variables has had some interesting side effects that probably aren't covered in the book. I'm talking of a decade of buffer overflows and other stack smashing techniques, that use and abuse both the proliferation of local variables and the lack of boundary detection in many base functions, and orphaned allocated memory blocks. In fact, the problem is SO severe, that the 2 features most advertised on "modern" compiled languages is precisely the impossibility of stack smashing (because local vars are no longer in the stack), and garbage collection, to avoid the memory pollution problem. What do you think will work better, to have a C++ business database app opening and closing datasets somewhere inside methods as needed, or having well defined generic datasets with global scope? Which approach you think the programmer is more likely to learn? Yes, you can have a broker delivering those datasets as needed (and then you wouldn't need to declare them explicitly in the global scope), or create even more complex solutions to a simple problem, but I'm shure you get my point. The prejudice against global vars is largely unfunded (regardless of what any book would say).
And not everyone is writing code for xeon workstations - there is a ton of C code being written for PICs, microcontrollers, 8 bit microprocessors and DSP devices, where the available stack space is limited. Amost every modern EE is capable of programming in C or an equivalent language, even on their first-year jobs.
Don't take my words as any kind of attack on you, it is not my intent. I believe it is important that programmers know how things actually work, so they can make their own decisions. Relying on gospels and dogmas do more harm to the field than good, because no innovation will come out of it.
They recently stopped printing one of their magazines, I think it was Queue. But CACM is excellent, I'd recommend it.
They already invested on mobile platforms (iOS) http://www.embarcadero.com/products/delphi .
Unfortunely, it may be a little to late to keep the interest in Delphi.
Basic Stamp is somewhat modern. Loot at the 8052 microcontroller, it had a version with a Basic intepreter in firmware (the 8052 AH-Basic).
I'd mod you up if I had mod points :)
Task: Write a for() cycle in C with an integer variable increasing from 1 to 1 million. Make it so it is compilable in any architecture C is available for. Do the same in Basic.
But! God bless the 8086 div/idiv instruction...
The thing is that many old-time Basic programmers were casual programmers. They didn't learn to program to be professionals, they started programming for fun and, more often than not, to create software suitable to their needs. They don't need C or OO concepts, they need to lay some lines of code and see the result. Now if you want to do some "quick and dirty" simple application like many people did back then, you don't have much choice. You probably need to learn about GUI, and learn about objects and learn about compilers and packages and modules and libraries. You don't get a self-contained executable that just works - you need to "install" applications. That's why many of those casual programmers stopped programming, because it became too complex to do simple things. Many of them still use the same algorithmic concepts they learned with basic when working with spreadsheets, macro languages or database systems, but they're not programmers - they are power users.
If you want to DO more (whatever that means) in a PIC environment with C, you might as well use Assembly and spare the trouble of actually having to learn a 3rd party language.
Most business-oriented BASIC interpreters and compilers available in the mid-80's did allow a fairly complete procedural approach to application writing - it's not their fault if you insisted on using GWBasic or the ZX Spectrum basic interpreter.
While I get the point you were making, the notion that excess global variables are always "bad" is an amusing one, and shows how little serious coding you actually did back then. In compiled languages, global variables are usually defined in program space, and that translates to "the binary will not load if not enough memory is available to load it" instead of "oops this broke because we ran out of stack space". Declaring your "heavy" variables with global scope would give you some kind of assurance that you'd not run out of memory when allocating them. Yes you could use stack monitoring, but most stack overflow check routines were computationaly expensive. In modern systems, concentrating sensitive variables in the global space allows the program to mark them as non-pageable, so you can be shure they are always present in memory (and not on some swap file). So yeah, global variables may be bad, or not. Depends on what you're trying to use.
In the beginning of this millenium, you probably had more Basic business code running than all the Cobol code created since the language's creation. It was used from microcontrollers (8052AHBASIC as an example), automation systems (soo many RS232 control systems written in lame Basic!), business software development (TuboBasic/PowerBasic in the late 80's and Visual Basic in the 90s, and derived Basic-like languages such as Clipper.
From what I know, Basic was mainly absent from mainframe environment, and Cobol, RPG and Fortran did sell a lot compiler licenses and programming materials such as books and courses.
1) C, C++, hell even Java : c = a+b (1 assembly instruction)
Actually, in most environments that would be compiled as at least 2 instructions, assuming the compiler was optimizing for register use. There are some marginal cases where you can actually combine the operation if calculating a offset address, but by your code I doubt that's the case. And that is, of course, assuming a and b are <=16-bit integers, so you can actually compare them on a 8086.
This means that a C program running on an 8086 will actually calculate faster than a python program running on a current pc.
Probably yes. But do not assume that a 8086 will execute 1 instruction per clock cycle (heck, a 8/16/32bit mul on a 486DX takes up to 11 clock cycles!), and most modern processors with out-of-order execution will execute up to 3 instructions per cycle. The cache and RAM timing is often the limiting factor of the processor, so you can say many modern processors idle very well while they wait for memory operations, when executing code not specifically optimized for their prefetch queue size and memory alignment requirements.
:D). The problems you describe with memory consumption are what I consider "rookie mistakes" (maybe in your specific case aren't, but as a generic example they are) - classes aren't the answer for everything, and variable sized datasets should always be windowed, regardless of language.
I'm not a python user nor a python fan. I use other dynamic languages such as PHP that suffer from some of the problems you mention, but I think you are mixing apple and oranges. Just because you _can_ use python to prototype some calculations, it doesn't mean it's the right tool for the job. Sometime in my career I worked as a Cobol programmer, and I've used DirectX with Cobol just for kicks. It doesn't mean it's the right tool for the job (and believe me, Cobol is NEVER the right tool for the job
I should point out the pain that is to work with both basic datatypes (byte, int, long) and strings in languages as C and C++. If your compiling your simple example above on a 8086 and b happens to have the value 70000d, you'd need at least 4 or 5 instructions in a loop to complete the operation. You usually cannot make strong assumptions about the size of your datatypes, at the cost that the compiler will figure it out. Most often than not, it won't, and that's why an algorithm in plain C written on a 32 bit processor can fail on a 16 bit one.
Regarding language learning, I am a strong supporter of both Pascal-styled languages and Assembly. People should learn how the machine actually works, because knowing the details of execution WILL make them better programmers. I somewhat understand the void left by "old basic", as you could access and change memory contents and device addresses directly, and it was simple enough to learn the basic structure of a program. Touting OO languages as a first language is a horrible horrible idea that will dumb down future programmers to "one-size fits all" solutions.
Reality check - in most of the western world, the newspapers are owned by economic groups with a political agenda. Liberal unafiilliated media is a pipe dream, because journalism is not about facts and truth - it's about passing a point of view.
My desktops at the time all had (at least) 128MB of RAM, so XP actually felt faster than W2K. USB 2.0, System Restore, prefetch improvements, and ClearType were more-than-enough reasons to want to run XP at the time.
It should be noted that the hardware requirements for W7 are about the same as Vista Premium, and it feels a lot snappier. I haven't used much Vista (went from xP64 to W7 64), most machines with it were third party computers.
Given the amount of errors I've found in books over the years, I'd say don't believe anything you read - period. Our lives are ridden with little lies and myths perpetualized in written form. A good example is how history books are written and rewritten describing different versions of facts, according to the place you live.