People toss it into every crevace of their cars, and into jars in their houses. They complain about having $5 worth of assorted change in their pocket books. They go to machines in stores and pay a nontrivial percentage of the total sum to get rid of their change and replace it with bills.
That right there is the problem. Change is only a problem if you don't spend it. If you actually use it, it doesn't accumulate to the point that you need to lug 20 pounds of metal in to get it replaced with bills.
The thing about coins is that we use them only for the lowest denominations. I bet there wouldn't be a lot of $50 coins in between sofa cushions.
No, it's because carrying around a wallet full of $1 bills (vending maching cash) is a lot lighter than carrying around a wallet full of $1 coins.
This argument is bogus. This exact same argument could be made in favour of replacing quarters, dimes, nickels, and pennies with bills. Why don't you do that? Because the weight of the coins just doesn't matter in practice.
I'm not the strongest guy I know, but I can certainly manage to carry half a dozen loonies in my wallet without breaking a sweat. Personally, I'm looking forward to the $5 coins.
Wow... and that even after the entire world has been searching for it for 42 years and didn't find it...
You say that as though 42 years were a long time. That's like some Roman engineer claiming it's impossible to dig a tunnel under the English Channel.
The one claim of MMM I disagree with most strongly is that we are within an order of magnitude of the most productive we will ever be in terms of software development. I firmly believe that 99+% of a typical developer's time is spent fighting with tools and reinventing wheels in a way that will seem pittifully primitive 50 years from now, and will be looked back on with awe and nostalgic reverence 200 years from now.
Wow and this made it past the Slashdot editors. Good job guys! Maybe it's because the editors have no clue about most science. Maybe they need to hire someone who does.
Wow, lighten up, Chicken Little. Yes, the name is arbitrary. That's no reason to spew invective.
Update For for the dupe. Not going well. Appreciate all the hate mail. Really encourages improvement.
All together now: "Aaawwwwwwwww".
I've never been one to complain about dupes. I figure I already get way more than I pay for from this site (which is zero). But if people are frustrated about dupes, maybe it's because it's an exceedingly simple problem to solve, and the Slashdot editors give every appearance of not bothering to lift a finger to solve it.
The part that's interesting is the ripples on the leading edge that become droplets. Having zero background knowledge, my first guess would be that it's turbulence in the air that causes the ripples.
No problem. I was just trying to explain why people might want to use a scripting language for some tasks.
Wrong. Aliases has nothing to do with a language. You can alias w=java -jar myapp.jar or whatever command line you want, or write a shell script to do the same, which is the usual way to start a Java program.
My point was that you can't possibly write a meaningful one-character Java program. Your example doesn't change that fact.
A file containing the single character "w" can't possibly be a valid Java program, but it can be a valid bash program.
So in fact you've omitted a whole class of languages from your analysis: the modern statically-typed languages which are almost as flexible and quick to code in as Perl or Python, while also being just as robust and scalable as Java or C++.
Agreed. There's nothing fundamental about my analysis. I see no reason a language couldn't beat bash, Python, Java, Eiffel, and C++ across the board. I'm sorry I didn't make that clear in my original post.
Yes. Consider having multiple programs like UNIX's "cat", "sort", "uniq", "sed", and "awk" tied together with shell scripts, instead of one generalized reporting program that tries to do everything for everyone.
If the information you're missing by omitting type annotations matters to you, then don't use a dynamic language. However, dynamic languages are good for prototypes, and for simple systems. They scale downward further than statically-typed languages. I use them for fun hobby programming, but (for the reasons you mentioned) I don't use them much for professional work.
I'll give you a pathological example. Consider the Hello World program written in bash (a dynamic language) and Java (a static one). Java looks like this:
public class Hello { public static void main(String[] args){ System.out.println("Hello, world"); } }
Bash looks like this:
echo Hello, world
This isn't really a fair comparison per se, but hopefully it illustrates my point regarding the complexity of the problem versus the effort required to code the solution. On the one extreme, you have the "static" languages designed for coding entire "systems programming products" (to borrow a term from Fred Brooks). Of these, the good ones (eg. Eiffel, with its superb multiple inheritance facilities) scale up well to large systems, so the asymptotic slope of the complexity-effort curve is small. However, that curve doesn't cross the origin; that is, as the problem becomes trivially simple, the code required to express the solution reaches some fixed minimum size. In the case of Java, for instance, every program must declare a class with one public static void method taking an array of strings as an argument. That's why nobody uses Java as a command shell.
On the other extreme, you have shell languages. They do indeed intersect the origin of the complexity-effort curve: that is, it is possible to write a two-character program that does something very simple, such as "cd" or "fg" in bash. If you allow aliases, or UNIX commands like "w", you can write meaningful one-character programs. (This is impossible in Java, no matter what definitions or libraries you presuppose.) However, the slope of the complexity-effort curve is high, and after a program gets larger than a few hundred lines of code, bash becomes almost unusably awkward.
In between, you have "dynamic" languages like Python. Its curve doesn't hit the origin, and its asymptote's slope is higher than Java's, but there is a sizeable range of programs for which a Python solution requires less effort (at least for me) than bash or Java.
So, as many others have said, it pays to have a number of tools in your toolchest.
I'm guessing that the Mythbusters team did something incorrectly regarding the focusing of their mirrors.
Agreed. If you saw the episode, you can tell they have recurring focus problems, and seem completely mystified as to how to achieve good focus. They conclude that it was impossible.
Then they go on to create a wooden platform with dozens of (maybe) two-foot mirrors mounted to it. However, the "spot" of sunlight they create on their target is more like six feet across. Again, focusing problems.
The thing that occurred to me, watching that episode, is that they missed Archimedes' real invention here: the focusing device. I imagine he gave a hundred men each one reflective surface attached to some sort of sextant-like aiming device. Each man would look through some sight, lining up some spot of sunlight with the image of the target, and voila: perfect focus.
And your link says they used a circular configuration which is only good in limited cases since the light is focused in a line (which isn't really focus) rather than a point. This was parabolic setup which is why he was able to melt plastic and set a rose on fire.
I think you're mistaken. The "circular configuration" is just the way the mirrors looked head-on, from a viewpoint along the axis of revolution. I'm sure they knew enough to build a proper fresnel arrangement (though they failed as I described above).
Most (all?) structures, machines, circuits and other engineering constructs are described via pictures. Implementation follows directly from these with no intermediate "text". Recently various tools have had to "serialize" this data for the benefit of machines, but the reference document is the image, not the intermediate.
Are you sure? I'm not in the hardware field, but I seem to recall that very large-scale circuit design is being done increasingly using textual languages like VHDL.
GIPSpin, Aardappel and many others reflect a desire by a long continuum of programmers to illustrate their thinking and, in turn, translate illustrations directly into implementation. Is there something provably wrong with this desire? Are you claiming to know this is misguided?
No, I can't make that claim. I just think that expressing anything as complex as a typical software application visually in a manner that is clearer than the current textual techniques will take a feat of stunning ingenuity. I very much look forward to seeing someone achieve it, but I'm not holding my breath.
I believe we simply haven't had enough time to wrap our collective head around software.... It's a couple centuries too early for that conclusion.
Excellent points. Blueprints and maps may have a lot to teach the visual programming folks. They seem to want to base their languages on only slightly modified flow charts (in which group I would include pretty much all UML diagrams).
Here's why... Why don't you reply to this note and show me a sample code snippet from your visual language?
Check out the Aardappel language. I think it's a very interesting, powerful language, with one major flaw: it's a visual language. This makes it so awkward to deal with that even Aardappel's own inventor broke down and created a textual equivalent language for the sample code in his PhD thesis.
Text is better than pictures for describing anything complex. We have thousands of years of experience to back this up.
Slashdot Mirror
According to IMDb, you're right.
The thing about coins is that we use them only for the lowest denominations. I bet there wouldn't be a lot of $50 coins in between sofa cushions.
I'm not the strongest guy I know, but I can certainly manage to carry half a dozen loonies in my wallet without breaking a sweat. Personally, I'm looking forward to the $5 coins.
Dup of this.
Dubious:
1. Fraught with uncertainty or doubt; undecided.
Well, sometimes the wheel needs reinventing. A Roman chariot wheel wouldn't be much good on a formula-1 race car.
Read it again. That is a link to pictures of the brothers.
The one claim of MMM I disagree with most strongly is that we are within an order of magnitude of the most productive we will ever be in terms of software development. I firmly believe that 99+% of a typical developer's time is spent fighting with tools and reinventing wheels in a way that will seem pittifully primitive 50 years from now, and will be looked back on with awe and nostalgic reverence 200 years from now.
The picture on the link posted changes every day. Here's the permanent URL of the one referred to:
http://antwrp.gsfc.nasa.gov/apod/ap050401.html.
Dude, that just means Wikipedia got trolled. Are you aware of what Wikipedia is? Check again.
I've never been one to complain about dupes. I figure I already get way more than I pay for from this site (which is zero). But if people are frustrated about dupes, maybe it's because it's an exceedingly simple problem to solve, and the Slashdot editors give every appearance of not bothering to lift a finger to solve it.
The part that's interesting is the ripples on the leading edge that become droplets. Having zero background knowledge, my first guess would be that it's turbulence in the air that causes the ripples.
Where's the part of your theory where you explain why removing the air from the chamber makes the splash go away?
A file containing the single character "w" can't possibly be a valid Java program, but it can be a valid bash program.
Yes. Consider having multiple programs like UNIX's "cat", "sort", "uniq", "sed", and "awk" tied together with shell scripts, instead of one generalized reporting program that tries to do everything for everyone.
I'll give you a pathological example. Consider the Hello World program written in bash (a dynamic language) and Java (a static one). Java looks like this:
Bash looks like this:This isn't really a fair comparison per se, but hopefully it illustrates my point regarding the complexity of the problem versus the effort required to code the solution. On the one extreme, you have the "static" languages designed for coding entire "systems programming products" (to borrow a term from Fred Brooks). Of these, the good ones (eg. Eiffel, with its superb multiple inheritance facilities) scale up well to large systems, so the asymptotic slope of the complexity-effort curve is small. However, that curve doesn't cross the origin; that is, as the problem becomes trivially simple, the code required to express the solution reaches some fixed minimum size. In the case of Java, for instance, every program must declare a class with one public static void method taking an array of strings as an argument. That's why nobody uses Java as a command shell.On the other extreme, you have shell languages. They do indeed intersect the origin of the complexity-effort curve: that is, it is possible to write a two-character program that does something very simple, such as "cd" or "fg" in bash. If you allow aliases, or UNIX commands like "w", you can write meaningful one-character programs. (This is impossible in Java, no matter what definitions or libraries you presuppose.) However, the slope of the complexity-effort curve is high, and after a program gets larger than a few hundred lines of code, bash becomes almost unusably awkward.
In between, you have "dynamic" languages like Python. Its curve doesn't hit the origin, and its asymptote's slope is higher than Java's, but there is a sizeable range of programs for which a Python solution requires less effort (at least for me) than bash or Java.
So, as many others have said, it pays to have a number of tools in your toolchest.
Then they go on to create a wooden platform with dozens of (maybe) two-foot mirrors mounted to it. However, the "spot" of sunlight they create on their target is more like six feet across. Again, focusing problems.
The thing that occurred to me, watching that episode, is that they missed Archimedes' real invention here: the focusing device. I imagine he gave a hundred men each one reflective surface attached to some sort of sextant-like aiming device. Each man would look through some sight, lining up some spot of sunlight with the image of the target, and voila: perfect focus.
I think you're mistaken. The "circular configuration" is just the way the mirrors looked head-on, from a viewpoint along the axis of revolution. I'm sure they knew enough to build a proper fresnel arrangement (though they failed as I described above).Excellent points. Blueprints and maps may have a lot to teach the visual programming folks. They seem to want to base their languages on only slightly modified flow charts (in which group I would include pretty much all UML diagrams).
Check out the Aardappel language. I think it's a very interesting, powerful language, with one major flaw: it's a visual language. This makes it so awkward to deal with that even Aardappel's own inventor broke down and created a textual equivalent language for the sample code in his PhD thesis.
Text is better than pictures for describing anything complex. We have thousands of years of experience to back this up.