Is it fair to say that applets, beans, and swing are different versions of the same thing?
Applets are a method for embedding a Java component into a web page. Microsoft equivalent would be ActiveX or Silverlight.
Beans are a method to create components that can be manipulated by designers. Basically, Sun's answer to Microsoft's graphical Visual Basic GUI builders.
Swing is the Java GUI API. The windows equivalent would be the win32 MFC GUI classes, or whatever C#'s GUI API is.
An Applet could be assembled out of Beans which use the Swing API. In no way did one of these replace any of the others.
1) Deallocation of memory, bounds checking in arrays... is done manually
2) Lots of direct pointer manipulation. You can't abstract away the "how the computer is going to do this"
3) Multiple inheritance
Getting rid of those things gives you Java which is much easier to learn but doesn't have the performance. The question is why did you choose C++ in the first place if you don't want the excellent performance?
What makes C++ difficult is the pointlessly complicated syntax and type system. What makes it worse, is all the top C++ people from Djikstra on down sing the praises of how templates are going to save the world, whereas in practice no compilers exist which can handle them the "proper" way. The problem with C++ is that the language design would never give AN INCH on theoretical perfection to accommodate practical considerations. Djikstra's book talks about "programming units" instead of files, just in case you should happen to be storing your code someplace other than a file system. This kind of pointlessly baroque exercise is the problem, trying to make today's technology work better with hypothetical future technology that doesn't exist.
20 years on, and there still does not exist a compiler which can handle templates in the "proper" way that the books tell you they should be.
The good part about C++ is that it has a basically usable sub-language inside it, namely C. In my (limited) experience, as C++ is used practically it is basically just C with this syntactic sugar:
do_something(my_stuct*) ===> my_class::do_something()
</rant>
My opinion / experience, for what it's worth, is that the style of education can only do so much to turn out a good programmer. The smart, motivated students will be stuffing themselves to the gills with everything they can get their hands on. The resources online are incredibly abundant. There is MIT opencourseware, tons of books are made available by their authors free online, pretty much every other book is available via torrents. Not to mention hundreds of programming blogs, and sites like this. Even more importantly, the FOSS movement has triumphed in making so many programming tools available for free. Someone trying to learn a new mainstream language can expect to start by downloading a good, free IDE.
In short, I think that the good students have the resources available to make themselves into great programmers. The students that see computer science as a gravy train, and just want to scrape by with the minimum necessary to pass each class are never going to be great programmers. No matter how much the curriculum prods them towards greatness, as soon as they don't have a grade on the line they will stop working. I met way too many of these second class of student in my undergraduate career, and precious few of the first.
In Electrical Engineering, it is accepted that many of the graduates are going to be second class. The career path for these individuals is sales, technical management, and marketing/application engineers. Maybe it would be helpful to have a similar tacit understanding in Computer Science. Only the top 10% or so are actually going to be programmers, the rest should go into sales, management, IT, etc.
The grass is always greener on the other side. Software developers marvel at the much higher reliability that other engineering disciplines have in their shipped products. Other engineers marvel at the incredible cheapness of software development.
The practices commonly used in creating software reflect the most effective set of trade-offs given the realities of how the software is used. One of those realities is that software crashes don't kill people. In the case that a software crash can kill people, the development process is approached differently, and the software costs much more to produce.
Also, it may be a false dichotomy to contrast car design with software engineering. Software is an important component in a modern car (computer controller traction and fuel injection for example.)
Hrm... it is more like a technical justification than explanation.
The concept is that the sun is being eaten away by stable super-symmetry particles. More and more matter is decaying into super-symmetry particles. source.
Ok, fine. However, how in the world is dropping a gigantic atom bomb on the Sun going to change that equation? The explanation, that the explosion will be so energetic that it will break down the particles is silly. Even if you could somehow "ignite" the entire Sun hotter than the core is now, that would create a supernova. So, Earth is destroyed anyway.
Even besides the premise, there are so many little problems.
Those stupid rotating reflectors on the outside of the ship. Those things were so misguided -- if the point is to reduce heating, it doesn't matter which direction the light is bounced to. Just make the whole surface shiny.
The "greenhouse" for life support. Why not just carry consumables? The ship only needs to last months, not decades. Even if you were going to have that setup for some reason, why not use hydroponics and algae that would be far more efficient?
Maybe it is still possible to come up with an explanation for what the bomb was supposed to do that is consistent with the movie. However, I think it is pretty clear that this wasn't the intention of the script.
I think this is one of those stories that circulates based on how things USED to work.
I've talked to old timer HDD engineers who say in the 70s you could actually put a paper with metal dust on it ontop of the platter, and gently shake it and be able to "see" the 1's and 0's as the metal bits aligned themselves with the magnetic fields. (This was apparently used as a diagnostic tool.)
I wouldn't go so far as to say it was actually possible to recover overwritten data back then. Only that I don't know that it was impossible.
My understanding is RFID is intended to only encode a small amount of data.
But, that doesn't matter. There are many hardware mechanisms for keeping data with you (just carry a USB flash in your pocket).
The challenge for what you describe would be having universal data formats for each of these things. Everyone would need to have the infrastructure in place so that, for example, every time you went to a job interview they were set up to process the same format of input file.
XML? JSON? Something new?
It is probably inevitable that true open, extensible, simple data formats will become universal. I agree with you 100% that this will have a huge impact on society.
Can't change current without changing voltage. Can't change voltage without changing current.
LED only has a narrow range of operating voltage.
However, LEDs have an extremely fast response time (imperceptible to human sight). This means they can be "flickered" on and off for varying amounts of time to simulate different levels of brightness. If our eyes were 1000x as fast it would look awful.
Flicker technique is more generally known as "pulse width modulation" (PWM). It is a simple way for digital electronics to generate analog outputs. (You just need to pass it through an analog low-pass filter / "averager".)
I had to learn Win32 GUI stuff (MFC) in 2008. For some reason someone in 2003 decided to write an app from scratch using that API, and I get to support it =-/
An interesting phenomenon has occurred in instruction sets. Things have stratified into approximately four layers. Each layer is more expensive, takes more power, and has higher capabilities. At the high end are x86 CPUs which have stuck with x86 for software compatibility. Below the x86 CPUs are ARM processors. Below that are vendor specific instruction sets. And, at the very bottom, x86 again!
For really, really low powered hardware applications where you really don't care about performance, x86 is king. The kind of applications where you take a 16 MHz chip and under-clock it to 500 kHz to save power.
computers do math in binary (or, to be pedantic, hexadecimal).
I'll see your pedantically discriminating between binary and hexidecimal, and raise you pedantically pointing out that hexidecimal is just a display format for binary data.
We may as well say this comment is written in English*
*: actually Times New Roman
Re:Old Man's War and Last Colony
on
Zoe's Tale
·
· Score: 1
Although, the technology in Old Man's War is pretty erratic.
Everything seems to boil down to "magic" nanites and what they can and cannot do. The soldiers all run around with one nano-tech gun that can transform itself into anything on a whim. They even replace their blood with the stuff.
However, guns and soldiers bodies are apparently the only things that benefit from this nanotech miracle. None of the spaceships seem to be capable of any self repair or modification. The soldiers don't even deploy with tanks or planes because those rifles they carry are just so awesome or something (?).
And yet, history is rife with examples of laissez faire economics leading to large trusts and cartels being formed as the largest players in the markets collude.
Thank you to you and the others who challenged me on about this. You have caused me to learn something new today:-).
What is actually being done though is a bit different than what I interpreted GP to be saying. Talking about needing to keep the number of 1's and 0's constant. That makes me imagine a system in which charge just flows from the gate of one transistor to the gate of another.
This is not anything anyone has proposed. I stand by my assertion that technology where transistors are not directly closing the connection between either a positive or negative source.
Take a look at the pdf here. There are a couple of circuit diagrams for different types of "Adiabatic" circuits. (I put adiabatic in quotes, because these are not adiabatic in the thermodynamic sense that GP was discussing, just very low power.) Adiabatic Circuits Paper
Those circuits are of the same family as what I describe in my original post. The main difference is that the positive and negative sources are functions rather than constant.
It is an interesting idea. I don't think even this is practical though, for a simple reason. Clock skew is one of the biggest problems in modern circuit design. For this to work, you need to have this perfectly smooth wave that passes over one logic stage after another so that each one generates the output while generating minimum heat, and stays on just long enough for the input to be received by the next stage.
But, hey it would be really neat.
Also, just to reiterate. This will have zero impact on programming. There is nothing here about conserving 1's and 0's. That is Star Trek stuff.
The idea of "not wasting" precious electrons inside your CPU is seriously out there technology. Like, Warp Drive and Teleporters out there.
Let's take an asynchronous AND for example. Here is how it works:
1- two logical inputs connect to each of two transistors (2 PMOS, 2 NMOS; 2 positive on, 2 negative on)
2- the positive on transistors are connected between high voltage and the output; the negative on transistors are connected between ground and the output
3- the positive on transistors are in series; if both inputs are high, then they will "turn on" closing the connection between output and the high voltage source
4- the negative on transistors are in parallel; if either input is low, then one or the other transistor will "turn on" closing the connection between output and the ground source
So, between every step of logic the electrons are flushed clean through the system. The "input" electrons actually have no path to the output.
Caches are SRAM, composed of purely logic transistors. (i.e. SRAM is made of the same stuff you build CPUs out of.)
Main memory is DRAM, which is much much less expensive per bit due to much higher density. This higher density is achieved by using fewer parts per bit. DRAM is *not* made out of just logic transistors. One capacitor per bit is also required. So, it isn't just a matter of re-arranging parts that they already use in CPUs. ("Parts" meaning electrical components you can etch on a die, not anything discrete.)
"The advantage of DRAM is its structural simplicity: only one transistor and a capacitor are required per bit, compared to six transistors in SRAM." (source wikipedia)
Being able to put DRAM on the same die as a CPU would change the equation a little bit. Even if it didn't find its way into workstation grade CPUs, it would probably be useful for system on a chip applications / ASICs / FPGAs.
Basically, anywhere that you only want to have a single chip for cost reasons. You can have flash, SRAM, voltage regulator, analog to digital and digital to analog conversion, all integrated into the same die as your CPU. But, if you want to have DRAM you need a second chip.
That virus episode was the last one I watched. I remember Ronald Moore in the commentary to the Battlestar Galactica mini-series DVD explaining how he always hated the "technobabble" plot holes in Star Trek. He explained that one of their goals with BSG was not to go down that route.
I don't think it is so much that the show got less believable, as that the rules started changing from episode to episode. So you end up with REALLY weird arbitrary shit resolving plots. Another example, Boomer cuts her wrist and sticks some random wire into her arm, and stops an entire Cylon fleet cold. Yet, apparently nobody considers trying to do this ever again.
What you say is true. But, this isn't really an OOP issue. You could shoot yourself in the foot just as effectively in C if you did this:
char* recvPacket();/*receives the next packet, allocating memory to store it in; returns a pointer to this new memory location*/
The solution, in both C and Java is to NOT re-allocate your buffer with every packet. No matter if that buffer is a raw array or wrapped up in an object.
Take a look at java.net.DatagramSocket:
receive(DatagramPacket p);
The function takes a pointer to the buffer that the packet is to be stored in. This is exactly as it would be done in C. What is the big deal that the "buffer" in this case is represented by an object?
Is it fair to say that applets, beans, and swing are different versions of the same thing?
Applets are a method for embedding a Java component into a web page. Microsoft equivalent would be ActiveX or Silverlight.
Beans are a method to create components that can be manipulated by designers. Basically, Sun's answer to Microsoft's graphical Visual Basic GUI builders.
Swing is the Java GUI API. The windows equivalent would be the win32 MFC GUI classes, or whatever C#'s GUI API is.
An Applet could be assembled out of Beans which use the Swing API. In no way did one of these replace any of the others.
What makes C++ difficult is C. That is
1) Deallocation of memory, bounds checking in arrays... is done manually
2) Lots of direct pointer manipulation. You can't abstract away the "how the computer is going to do this"
3) Multiple inheritance
Getting rid of those things gives you Java which is much easier to learn but doesn't have the performance. The question is why did you choose C++ in the first place if you don't want the excellent performance?
What makes C++ difficult is the pointlessly complicated syntax and type system. What makes it worse, is all the top C++ people from Djikstra on down sing the praises of how templates are going to save the world, whereas in practice no compilers exist which can handle them the "proper" way. The problem with C++ is that the language design would never give AN INCH on theoretical perfection to accommodate practical considerations. Djikstra's book talks about "programming units" instead of files, just in case you should happen to be storing your code someplace other than a file system. This kind of pointlessly baroque exercise is the problem, trying to make today's technology work better with hypothetical future technology that doesn't exist.
20 years on, and there still does not exist a compiler which can handle templates in the "proper" way that the books tell you they should be.
The good part about C++ is that it has a basically usable sub-language inside it, namely C. In my (limited) experience, as C++ is used practically it is basically just C with this syntactic sugar:
do_something(my_stuct*) ===> my_class::do_something()
</rant>
My opinion / experience, for what it's worth, is that the style of education can only do so much to turn out a good programmer. The smart, motivated students will be stuffing themselves to the gills with everything they can get their hands on. The resources online are incredibly abundant. There is MIT opencourseware, tons of books are made available by their authors free online, pretty much every other book is available via torrents. Not to mention hundreds of programming blogs, and sites like this. Even more importantly, the FOSS movement has triumphed in making so many programming tools available for free. Someone trying to learn a new mainstream language can expect to start by downloading a good, free IDE.
In short, I think that the good students have the resources available to make themselves into great programmers. The students that see computer science as a gravy train, and just want to scrape by with the minimum necessary to pass each class are never going to be great programmers. No matter how much the curriculum prods them towards greatness, as soon as they don't have a grade on the line they will stop working. I met way too many of these second class of student in my undergraduate career, and precious few of the first.
In Electrical Engineering, it is accepted that many of the graduates are going to be second class. The career path for these individuals is sales, technical management, and marketing/application engineers. Maybe it would be helpful to have a similar tacit understanding in Computer Science. Only the top 10% or so are actually going to be programmers, the rest should go into sales, management, IT, etc.
The grass is always greener on the other side. Software developers marvel at the much higher reliability that other engineering disciplines have in their shipped products. Other engineers marvel at the incredible cheapness of software development.
The practices commonly used in creating software reflect the most effective set of trade-offs given the realities of how the software is used. One of those realities is that software crashes don't kill people. In the case that a software crash can kill people, the development process is approached differently, and the software costs much more to produce.
Also, it may be a false dichotomy to contrast car design with software engineering. Software is an important component in a modern car (computer controller traction and fuel injection for example.)
Hrm... it is more like a technical justification than explanation.
The concept is that the sun is being eaten away by stable super-symmetry particles. More and more matter is decaying into super-symmetry particles. source.
Ok, fine. However, how in the world is dropping a gigantic atom bomb on the Sun going to change that equation? The explanation, that the explosion will be so energetic that it will break down the particles is silly. Even if you could somehow "ignite" the entire Sun hotter than the core is now, that would create a supernova. So, Earth is destroyed anyway.
Even besides the premise, there are so many little problems.
Those stupid rotating reflectors on the outside of the ship. Those things were so misguided -- if the point is to reduce heating, it doesn't matter which direction the light is bounced to. Just make the whole surface shiny.
The "greenhouse" for life support. Why not just carry consumables? The ship only needs to last months, not decades. Even if you were going to have that setup for some reason, why not use hydroponics and algae that would be far more efficient?
Maybe it is still possible to come up with an explanation for what the bomb was supposed to do that is consistent with the movie. However, I think it is pretty clear that this wasn't the intention of the script.
I think this is one of those stories that circulates based on how things USED to work.
I've talked to old timer HDD engineers who say in the 70s you could actually put a paper with metal dust on it ontop of the platter, and gently shake it and be able to "see" the 1's and 0's as the metal bits aligned themselves with the magnetic fields. (This was apparently used as a diagnostic tool.)
I wouldn't go so far as to say it was actually possible to recover overwritten data back then. Only that I don't know that it was impossible.
You think Bush gave a shit about sensitivity to the families of dead soldiers?
Yes. It's clear that he did. He personally wrote a letter to the family of *every* dead soldier
Trying to get a source for that, this is the best I can do: Washington Times
Didn't slashdot have an article recently about there now being one ARM processor per person? 7 billion shipped or something?
Anyway, every PC has several ARM processors in it. Hard drive, add-in cards, etc all have ARMs in them.
http://www.buy.com/prod/3k-razorbook-400-ce-ultra-mobile-pc-arm-400mhz-7-wvga-128mb-ddr2-sdram/q/loc/101/210401409.html?dcaid=15890
3K RazorBook 7-inch Notebook with ARM CPU, 128MB, 4GB & Card Reader New Coupon
$147.99 with Free Shipping
Buy.com has this 3K notebook for $147.99 with free shipping.
# Specs:ARM 400MHz processor
# 7-inch LCD screen
# 128MB of memory
# 4GB SSD hard drive
# Card Reader
# Wi-Fi card
My understanding is RFID is intended to only encode a small amount of data.
But, that doesn't matter. There are many hardware mechanisms for keeping data with you (just carry a USB flash in your pocket).
The challenge for what you describe would be having universal data formats for each of these things. Everyone would need to have the infrastructure in place so that, for example, every time you went to a job interview they were set up to process the same format of input file.
XML? JSON? Something new?
It is probably inevitable that true open, extensible, simple data formats will become universal. I agree with you 100% that this will have a huge impact on society.
Just, I think RFID is a separate issue.
Can't change current without changing voltage.
Can't change voltage without changing current.
LED only has a narrow range of operating voltage.
However, LEDs have an extremely fast response time (imperceptible to human sight). This means they can be "flickered" on and off for varying amounts of time to simulate different levels of brightness. If our eyes were 1000x as fast it would look awful.
Flicker technique is more generally known as "pulse width modulation" (PWM). It is a simple way for digital electronics to generate analog outputs. (You just need to pass it through an analog low-pass filter / "averager".)
A CLI is better than a web program?
:-) whatever you type in is run by the Javascript interpreter. Plus there is a tiny API of a few AJAX functions.
How about a web program that is a CLI?
Something I whipped up for fun
I had to learn Win32 GUI stuff (MFC) in 2008. For some reason someone in 2003 decided to write an app from scratch using that API, and I get to support it =-/
List of 8051 manufacturers.
An interesting phenomenon has occurred in instruction sets. Things have stratified into approximately four layers. Each layer is more expensive, takes more power, and has higher capabilities. At the high end are x86 CPUs which have stuck with x86 for software compatibility. Below the x86 CPUs are ARM processors. Below that are vendor specific instruction sets. And, at the very bottom, x86 again!
For really, really low powered hardware applications where you really don't care about performance, x86 is king. The kind of applications where you take a 16 MHz chip and under-clock it to 500 kHz to save power.
computers do math in binary (or, to be pedantic, hexadecimal).
I'll see your pedantically discriminating between binary and hexidecimal, and raise you pedantically pointing out that hexidecimal is just a display format for binary data.
We may as well say this comment is written in English*
*: actually Times New Roman
Although, the technology in Old Man's War is pretty erratic.
Everything seems to boil down to "magic" nanites and what they can and cannot do. The soldiers all run around with one nano-tech gun that can transform itself into anything on a whim. They even replace their blood with the stuff.
However, guns and soldiers bodies are apparently the only things that benefit from this nanotech miracle. None of the spaceships seem to be capable of any self repair or modification. The soldiers don't even deploy with tanks or planes because those rifles they carry are just so awesome or something (?).
And yet, history is rife with examples of laissez faire economics leading to large trusts and cartels being formed as the largest players in the markets collude.
Just a few years ago we had an issue of RAM makers colluding to fix prices.
I think it is a very good thing that there are strict laws forcing companies to remain competitive with each other.
Awesome :-)
Thank you to you and the others who challenged me on about this. You have caused me to learn something new today :-).
What is actually being done though is a bit different than what I interpreted GP to be saying. Talking about needing to keep the number of 1's and 0's constant. That makes me imagine a system in which charge just flows from the gate of one transistor to the gate of another.
This is not anything anyone has proposed. I stand by my assertion that technology where transistors are not directly closing the connection between either a positive or negative source.
Take a look at the pdf here. There are a couple of circuit diagrams for different types of "Adiabatic" circuits. (I put adiabatic in quotes, because these are not adiabatic in the thermodynamic sense that GP was discussing, just very low power.) Adiabatic Circuits Paper
Those circuits are of the same family as what I describe in my original post. The main difference is that the positive and negative sources are functions rather than constant.
It is an interesting idea. I don't think even this is practical though, for a simple reason. Clock skew is one of the biggest problems in modern circuit design. For this to work, you need to have this perfectly smooth wave that passes over one logic stage after another so that each one generates the output while generating minimum heat, and stays on just long enough for the input to be received by the next stage.
But, hey it would be really neat.
Also, just to reiterate. This will have zero impact on programming. There is nothing here about conserving 1's and 0's. That is Star Trek stuff.
Er... wha?
The idea of "not wasting" precious electrons inside your CPU is seriously out there technology. Like, Warp Drive and Teleporters out there.
Let's take an asynchronous AND for example. Here is how it works:
1- two logical inputs connect to each of two transistors (2 PMOS, 2 NMOS; 2 positive on, 2 negative on)
2- the positive on transistors are connected between high voltage and the output; the negative on transistors are connected between ground and the output
3- the positive on transistors are in series; if both inputs are high, then they will "turn on" closing the connection between output and the high voltage source
4- the negative on transistors are in parallel; if either input is low, then one or the other transistor will "turn on" closing the connection between output and the ground source
So, between every step of logic the electrons are flushed clean through the system. The "input" electrons actually have no path to the output.
Caches are SRAM, composed of purely logic transistors. (i.e. SRAM is made of the same stuff you build CPUs out of.)
Main memory is DRAM, which is much much less expensive per bit due to much higher density. This higher density is achieved by using fewer parts per bit. DRAM is *not* made out of just logic transistors. One capacitor per bit is also required. So, it isn't just a matter of re-arranging parts that they already use in CPUs. ("Parts" meaning electrical components you can etch on a die, not anything discrete.)
"The advantage of DRAM is its structural simplicity: only one transistor and a capacitor are required per bit, compared to six transistors in SRAM." (source wikipedia)
Being able to put DRAM on the same die as a CPU would change the equation a little bit. Even if it didn't find its way into workstation grade CPUs, it would probably be useful for system on a chip applications / ASICs / FPGAs.
Basically, anywhere that you only want to have a single chip for cost reasons. You can have flash, SRAM, voltage regulator, analog to digital and digital to analog conversion, all integrated into the same die as your CPU. But, if you want to have DRAM you need a second chip.
That virus episode was the last one I watched. I remember Ronald Moore in the commentary to the Battlestar Galactica mini-series DVD explaining how he always hated the "technobabble" plot holes in Star Trek. He explained that one of their goals with BSG was not to go down that route.
I don't think it is so much that the show got less believable, as that the rules started changing from episode to episode. So you end up with REALLY weird arbitrary shit resolving plots. Another example, Boomer cuts her wrist and sticks some random wire into her arm, and stops an entire Cylon fleet cold. Yet, apparently nobody considers trying to do this ever again.
What you say is true. But, this isn't really an OOP issue. You could shoot yourself in the foot just as effectively in C if you did this: /*receives the next packet, allocating memory to store it in; returns a pointer to this new memory location*/
char* recvPacket();
The solution, in both C and Java is to NOT re-allocate your buffer with every packet. No matter if that buffer is a raw array or wrapped up in an object.
Take a look at java.net.DatagramSocket:
receive(DatagramPacket p);
The function takes a pointer to the buffer that the packet is to be stored in. This is exactly as it would be done in C. What is the big deal that the "buffer" in this case is represented by an object?
Those speeds are typical for current generation spinning media disks as well.
See, for example, here: Tom's Hardware 1TB disk performance
It really isn't either/or on HDD speed versus capacity. Higher capacity drives are ALSO faster.
you can design highways to deliver wireless power
You think highway repairs are expensive now...