CPU cycles are the only remote computing service for which bandwidth has been limiting factor. Operating systems development and application development have been done off-site for a long time; removable storage and the postal service provide sufficient bandwidth. System administration is routinely over the network by many companies. The only time those companies visit a piece of hardware physically is when the hardware or system configuration is too far gone to be administered over the wire -- a situation that cannot be eliminated by bandwidth. Applications are also routinely served over networks. None of these things are new. What's new will be the extension of system administration services and application services to home and small-unsavvy-business users. That development is not awaiting sufficient bandwidth; the bandwidth is there are waiting. It's awaiting commodification, which is a very difficult problem involving many technical issues as well as security and privacy issues.
So, when you're talking about greater bandwidth enabling new developments in server-based computing, you're talking about shipping user data across the network to be processed remotely, which is often limited by bandwidth, even for some supercomputer applications. Actually, come to think of it, I forgot about data storage, which is indeed becoming an internet service and was probably held up by lack of bandwidth. I think you're right about data storage.
We're at the point where it's far far cheaper to have the computing in a BFO data centre and decent bandwidth to the home.
Really? Considering that a "dumb" PC-replacement terminal would need a keyboard, mouse, nice LCD monitor, speakers, a network interface, and enough computing power to tie all those together with sophisticated graphics and sound, there isn't much point in stopping short of a full-blown PC.
Server-based computing will never take off as a way to sell computing power, because selling CPU cycles to home users is like selling water to fish. Most likely, software served over the internet (software-as-a-service) will make as much use of local computing resources as possible. Users won't mind or won't notice.
They also buy exclusive deals with whorish universities so they can prevent scientists' research from being published. They are privatizing academic research as fast as they can, changing universities from institutions for advancing and sharing knowledge into institutions for hoarding knowledge and enhancing corporate patent portfolios.
That visibility includes surfacing the fact that the fungMetric system is still being worked on and that the declaration that it was fixed was premature. Management is made up of imperfect human beings working with limited information under competitive pressure. Concealing information from management usually does not improve the quality of decisions management makes.
This is an excellent illustration of the problem. I said that we had a problem with the fungMetric system last week and it was declared fixed. I then said that we're continuing to work on the fungMetric system. To me those statements do not seem contradictory. After all, there's all kinds of work that can be done -- planned enhancements, documentation cleanup, performance testing, etc. However, it is possible to fill in some missing information, read between the lines, and conclude that the problem last week was not fixed. Not only do we have a problem that resists fixing, we can't even tell when it's fixed! Yikes!
That is misinformation, and that is why communication that leaves the development group has to be carefully prepared for external consumption. Developers are not good at this, as my failure here conveniently illustrates. Like a typical developer, I spoke precisely and expected people to ask questions if they wanted to know something I left out, rather than expecting them to fill in the missing pieces by reading between the lines. I made this mistake while self-consciously talking about how people like me tend to make this kind of mistake, yet I was still caught off-guard (honest!) A good manager would know better, because that's part of the job description (and one of the primary requirements that keeps good developers out of management.)
Teams using Dylan, a dynamic language based on Common Lisp, have done very well in the ICFP.
One reason that Haskell and O'Caml have done very well is they are good vehicles for research into typing, hence very popular in theoretical CS. I bet that's the primary relevance of static vs. dynamic typing. I think if the contest existed twenty years ago, there would have been far more Lisp winners than C and Pascal winners.
In huge do-or-die software projects, politics is less of a problem, since the stakeholders will be hurt just as much by failure as the development team. However, such situations are rare, because competent management avoids them. In a stable company, stakeholders are able to survive failed projects, and they allocate their time and resources to different endeavors according to the expected payoff. That means that stakeholders' impressions of the project determine how much help the development team gets.
For example, a troubling series of delays on my current project recently resulted in our primary client contact (our "champion," who has also been doing excellent sales/support engineering work for us) taking on another project and significantly cutting the time he devotes to us. With stakes that high, management tightly controls the communication between developers and customers.
Suppose we had a problem with the fungMetric system last Monday, grossly misjudged how serious it was, and spent the whole week solving it. Everyone was quite relieved when the problem was declared fixed. If I mention that we're still working on the fungMetric system, the stakeholders might believe the problem has resurfaced and poses an ongoing threat to the project. Therefore, maybe we should put off that work until next week and give the fungMetric issue time to die.
At the very least, in the best possible scenario, developers would be burdened with an impossible obligation to talk about their development in terms that don't sound unduly scary or rosy to non-tech people. Do I really want to spend my time thinking about whether "refine the logging policy" or "missing compiler flag" send chills down the spine of a salesman? Do I want my manager to be embarrassed in a meeting because a developer said the AccountReport class is done, and a stakeholder told a VP that the account reporting feature will be in the next release? Most likely we would become masters of a few safe phrases and move our real communications to another channel.
I read a bit about Scrum and realized I misunderstood the role of stakeholders at daily meetings, specifically that the meetings are optional for stakeholders and that stakeholders attend primarily to gauge the team's morale, check for dysfunctionality, and discover ways to help. (I see now that you mentioned that, but it slipped by me.) That makes much more sense to me.
I'm still leery of the distorting effect of reporting, though. If a manager's credibility or ability to act is negatively affected by his developers' daily reports, you can be sure there will be pressure to stop hindering his work. As a developer, I appreciate whatever gives me the widest scope to tackle a problem directly and honestly, and having day-to-day results disseminated beyond technical personnel has always had the opposite effect.
One advantage of traditional project management is that it gives techies a layer of insulation from management politics; they can be completely honest with their manager and trust him to suppress any information that could be used to sabotage the project. Many developers fail to demonstrate the most basic level of political competence even when they spend all day thinking about it. I include myself in that bunch. If it comes up, I tell my managers that any plan requiring me to be politically sensitive is a bad plan.
Perhaps Scrum is just poorly suited to my particular strengths and weaknesses, but I consider myself a pretty typical developer. I value my career over any company's success, I prefer complete honesty because I have never succeeded with any other strategy, and when management turns on bully mode, I just do what they want and call it their loss. That isn't to say I don't value my integrity, merely that I protect my integrity by choosing my working environments very carefully, not by martyring myself if I end up in a bad situation. Putting guys like me out there in front of assorted stakeholders with many people's credibility dependent on our statements is liable to bring all kinds of pressure on us to account for political consequences when we do technical work, and we will not stand up to it very well. I imagine Scrum being of value only in businesses that can depend on esprit de corps to trump politics.
The recursion bottoms out if you don't tell the implementor about the doubling. If the implementor estimates two weeks, you can secretly plan on four. If the implementor finds out the working estimate is four weeks, however, it will take eight.
The 24-hour cycle reminds me of several hellish experiences I've had, especially of a certain project that required developers to make daily reports of progress to a non-technical manager. Here's the problem: What if you can't accomplish anything meaningful to the stakeholders in 24 hours?
For my current project, a really good day would be, "Today, Bob and I designed a tool that dumps the state of module X to text, and Bob wrote a script to parse that state and verify its correctness. I stubbed out a subset of module X and created a small set of test cases that exercise the stubs. Bob and I will implement the state-dumper tomorrow and integrate it with the test cases, giving us an initial test suite that will allow us to begin implemention. Mary investigated a suspicious behavior of the Y module, discovered that it is non-deterministic, and created a test that exercises the module until the bug is triggered. This program occasionally crashes, so we should consider the product unstable until this is resolved. Mary suspects a library bug and hopes to have it identified and reported to the vendor this week, giving us an excellent chance of working around it and/or receiving a bugfix by our release date."
This is an excellent day's work for all involved, but the stakeholders don't give a damn about any of it. This kind of stuff makes nontechnical users' eyes glaze over. Reporting it to them isn't a business activity; it's a social faux pas that results in the development department being made fun of around the water cooler. "Then he started talking about 'loadable modules' and I was like, 'Oh lord, make it stop.'"
In other words, if the daily progress report is supposed to be given to non-technical people, then the work I described above simply can't be done. It can't be reported, and we'll get yelled at if we work a whole day without having anything to report, so when are Bob and Mary and I going to do that stuff? Well, not on any day when we don't want to be yelled at, which turns out to be every day, despite our occasional fantasies of doing the right thing and righteously braving the storm of anger from management.
Here's what happens instead: Bob and I implement module X and, having enough integrity not to report completely untested work, run a couple of jerry-rigged tests and spot-check them by hand. We report that we implemented module X, ran tests, and found no problems. Afterwards we realize to our horror that module X is now officially done and bug-free, and we can never officially work on it again without looking like we falsely reporting our work, which in a sense we did. We know there must be bugs, so we secretly resolve to develop decent test tools for module X on nights and weekend, but all we end up doing is running a few more tests. Mary notices the suspicious behavior in module Y and briefly investigates it, but as a result she doesn't "accomplish" anything all morning. Afraid of having nothing to report, or worse, reporting something that isn't on the development plan, she drops the bug and spends the rest of the day implementing new features. She makes a mental note to return to the suspicious behavior someday, but guess what? Every day requires more reportable progress, and it's better for her career to see the product crash in production than to look lazy or disorganized in front of management.
The problem with reporting to nontechnical people is that they only understand certain kinds of accomplishments, such as "done" on a feature or use case. It means nothing to them that at 8am this morning we had no idea how to test module X and by 5pm this afternoon we had a detailed plan and a few working tools. Every day, you have three options:
1. Slap something together and report it as done. 2. Do a good day's work and try to explain your technical progress to the non-techies. Best case scenario: They decide (correctly) that you suck at communicating with non-techies and assume something has actually been accomplished, even though they don
You seem to forget that Calvin stresses out about facing the school bully every day, constantly being disciplined by his parents, and being shamefully mediocre at schoolwork. Actually, he's pretty awful at every aspect of his life that anyone else attaches any importance to, and he only finds relief in isolation. I wouldn't call that idyllic.
Personally, I cringe when I hear "the math is too complicated".
Perhaps it's better to say the math is rather unconstrained, rather than complicated. I get the impression that there are so many string theories that it's simple to choose the ones that match reality.
For example, suppose I have a class of theories that predict how much my lunch costs. After doing some math, I narrow down my class of theories to the ones that predict my lunch tomorrow will cost between $0 and $100. Then, tomorrow, my lunch costs $12.75, so I toss out all the theories except the ones that predict a lunch cost of $12.75 for that day. Now, if I still have a non-finite number of theories left, or if I still have tens of billions of theories left, I can't claim to be making progress.
I assume that must be the reason why it's so hard to get falsifiable predictions out of string theory. It's like a master of the Tao -- it contains all possibilities and adapts itself to all circumstances. A scientific theory should not be like water, enduring through lack of form. It should be breakable.
Didn't you know? Common Lisp had optional static typing in 1857. Then the Civil War came and people COMPLETELY forgot about it, babbling on about their Gatling guns and submarines and stuff that Lisp had had for years.
(I'm not really sure if Lisp's static typing guarantees compile errors. I'm just a beginner Lisp Weenie. I have potential, though, right?)
Software tricks for converting? Ultimately worse than not having them because it leads to horrible obfuscation because we don't know exactly what is going on when 13,412 lines of Python is turned into C++ because WE DIDN'T WRITE IT AND WE NEVER LEARNED C/C++. "Say Mike, that's great but you're the company code cowboy and you don't do C++ natively and I sure as hell don't read it being management so exactly what happens if this needs to be fixed?"
That isn't how a compiler is used. When you compile a C++ program, you don't throw away your C++ source and check the executable into source control. "Oh, no! We used gcc and now we have a bunch of gobbledygook we don't understand!"
The C++ is an intermediate stage in the make process, akin to the output of various phases of gcc.
Keeping in mind this thread is about the death of native code...
True, but death is always an overstatement. From our perspective, assembly language is thriving in a permanent niche. From the perspective of a programmer from the 70s and 80s, assembly language has died a dramatic and impressive death.
In the end, I don't think a fair comparison between native compilation and virtual machines really matters. The popular and finely tuned virtual machines are designed to support dynamic languages and to prevent or recover from many classes of errors, whereas the popular and finely tuned compiled languages are mostly static and don't do any dynamic checking the programmer doesn't specifically request. For example, the effort put into statically compiling Java code will never begin to compare to the man-years put into the major JIT Java compilers, so it doesn't really matter whether statically compiled Java could theoretically compete with dynamically compiled Java. Similarly, we'll probably never see the full potential of byte-compiled C++ or Fortran. (You can compile C++ for.NET, but the runtime is designed to be a "nicer" platform than bare metal and support nice languages like C#.)
IANAL, but my impression is that no one claims that clean room reverse engineering has ever been required by law anywhere at any time. The clean room method is designed not merely to comply with the law but to be a convincing demonstration that the requirements of the law have been met. Abiding by the law is one thing; being able to cheaply and confidently defend yourself in court against a well-funded attack is another thing entirely.
(Further, if clean room engineering is the de facto standard for documenting compliance with the law, people are likely to assume that the only reason for doing it any other way is to conceal wrongdoing. That attitude may have little to do with the law, but it might have some influence in a courtroom. On that point I'm out of my depth; ask a real lawyer.)
Except they do it online, not offline. Neglecting that difference is obviously unwise.
Yes, it is. Optimizing code using data from real use is fairly potent stuff, and it's rarely done for languages compiled "offline," despite people knowing about the potential for a long time. JIT compilers have made it available to the masses thanks precisely to the online nature of the compilation.
why is it that everyone else things it's still okay to compile to byte code or scripts. It's not; end of story.
Lemme set you straight: once you have code, you clearly aren't working with anything "native" anymore. An FPGA with a nice custom hardware design doesn't need any "code" slowing things down. Just put data on one set of pins and get answers out the other. What's with you software rubes who think the same jack-of-all-trades generic processor should be used to solve every problem in the.... ummm... uh... I think those ASIC guys are coming over here to kick my butt and take my lunch money again. I'm gonna, um, run.
what was so hard is that as I recall, you can't control the guy once you jump.
Pitfall was probably the third video games I played (after Combat and Pac-Man, on the Atari 2600), and perhaps because of its influence on my young, impressionable mind, I've always considered it a ridiculous cop-out to allow a player to change direction in mid-air.
I've spent the last few years performing security reviews on millions of lines of web application code. My experience has shown PHP and MYSQL based web apps to be the worst by far.
Other posters have suggested that PHP gets its bad reputation by enabling ignorant, inexperienced, or simply unintelligent programmers to build working systems, and conversely, other languages prevent bad code by being inhospitable to bad coders. Does your experience support this hypothesis?
Who wants to sell to cash-strapped consumers? I'd rather sell to people who already have 300+ movies on DVDs including dozens of movies that knew they'd probably hate before they bought them. Companies care about dollars, not consumers. A consumer with $20,000 in disposable income is twenty times as good as a consumer with $1,000 is disposable income. That's why electronics stores devote most of their TV display space to TVs costing thousands of dollars and hide the cheap TVs on shelves in a narrow isle, even though more people buy $500 televisions than $5000 televisions.
Your annoyance is completely justified. When reading technical writing, it often happens that what appears to be a poorly written passage turns out to be a very carefully written passage that reveals something the reader did not previously understand. For this reason, readers of technical material do not gloss over sloppy usage as quickly as casual speakers and readers do. Instead, they try to puzzle meaning out of it. Technical writers should keep that in mind and write documents that repay careful reading, rather than punishing it by forcing readers to carefully pick through one sloppy phrase after another.
The only role your lack of native English played here was that it may have taken you a few seconds longer to identify the problem as bad writing rather than misunderstanding on your part.
I think you're mixing up CS theorists with the scientists and engineers who just want to crunch a bunch of numbers and get the answers. You'd like the latter group; they write horrible code and aren't ashamed of it.
You know the saying, "You can write Fortran in any language?" Scientists judge a language by how easy it is to write Fortran in it. That's why C is their second-favorite language.
Slashdot Mirror
CPU cycles are the only remote computing service for which bandwidth has been limiting factor. Operating systems development and application development have been done off-site for a long time; removable storage and the postal service provide sufficient bandwidth. System administration is routinely over the network by many companies. The only time those companies visit a piece of hardware physically is when the hardware or system configuration is too far gone to be administered over the wire -- a situation that cannot be eliminated by bandwidth. Applications are also routinely served over networks. None of these things are new. What's new will be the extension of system administration services and application services to home and small-unsavvy-business users. That development is not awaiting sufficient bandwidth; the bandwidth is there are waiting. It's awaiting commodification, which is a very difficult problem involving many technical issues as well as security and privacy issues.
So, when you're talking about greater bandwidth enabling new developments in server-based computing, you're talking about shipping user data across the network to be processed remotely, which is often limited by bandwidth, even for some supercomputer applications. Actually, come to think of it, I forgot about data storage, which is indeed becoming an internet service and was probably held up by lack of bandwidth. I think you're right about data storage.
Really? Considering that a "dumb" PC-replacement terminal would need a keyboard, mouse, nice LCD monitor, speakers, a network interface, and enough computing power to tie all those together with sophisticated graphics and sound, there isn't much point in stopping short of a full-blown PC.
Server-based computing will never take off as a way to sell computing power, because selling CPU cycles to home users is like selling water to fish. Most likely, software served over the internet (software-as-a-service) will make as much use of local computing resources as possible. Users won't mind or won't notice.
They also buy exclusive deals with whorish universities so they can prevent scientists' research from being published. They are privatizing academic research as fast as they can, changing universities from institutions for advancing and sharing knowledge into institutions for hoarding knowledge and enhancing corporate patent portfolios.
This is an excellent illustration of the problem. I said that we had a problem with the fungMetric system last week and it was declared fixed. I then said that we're continuing to work on the fungMetric system. To me those statements do not seem contradictory. After all, there's all kinds of work that can be done -- planned enhancements, documentation cleanup, performance testing, etc. However, it is possible to fill in some missing information, read between the lines, and conclude that the problem last week was not fixed. Not only do we have a problem that resists fixing, we can't even tell when it's fixed! Yikes!
That is misinformation, and that is why communication that leaves the development group has to be carefully prepared for external consumption. Developers are not good at this, as my failure here conveniently illustrates. Like a typical developer, I spoke precisely and expected people to ask questions if they wanted to know something I left out, rather than expecting them to fill in the missing pieces by reading between the lines. I made this mistake while self-consciously talking about how people like me tend to make this kind of mistake, yet I was still caught off-guard (honest!) A good manager would know better, because that's part of the job description (and one of the primary requirements that keeps good developers out of management.)
Teams using Dylan, a dynamic language based on Common Lisp, have done very well in the ICFP.
One reason that Haskell and O'Caml have done very well is they are good vehicles for research into typing, hence very popular in theoretical CS. I bet that's the primary relevance of static vs. dynamic typing. I think if the contest existed twenty years ago, there would have been far more Lisp winners than C and Pascal winners.
In huge do-or-die software projects, politics is less of a problem, since the stakeholders will be hurt just as much by failure as the development team. However, such situations are rare, because competent management avoids them. In a stable company, stakeholders are able to survive failed projects, and they allocate their time and resources to different endeavors according to the expected payoff. That means that stakeholders' impressions of the project determine how much help the development team gets.
For example, a troubling series of delays on my current project recently resulted in our primary client contact (our "champion," who has also been doing excellent sales/support engineering work for us) taking on another project and significantly cutting the time he devotes to us. With stakes that high, management tightly controls the communication between developers and customers.
Suppose we had a problem with the fungMetric system last Monday, grossly misjudged how serious it was, and spent the whole week solving it. Everyone was quite relieved when the problem was declared fixed. If I mention that we're still working on the fungMetric system, the stakeholders might believe the problem has resurfaced and poses an ongoing threat to the project. Therefore, maybe we should put off that work until next week and give the fungMetric issue time to die.
At the very least, in the best possible scenario, developers would be burdened with an impossible obligation to talk about their development in terms that don't sound unduly scary or rosy to non-tech people. Do I really want to spend my time thinking about whether "refine the logging policy" or "missing compiler flag" send chills down the spine of a salesman? Do I want my manager to be embarrassed in a meeting because a developer said the AccountReport class is done, and a stakeholder told a VP that the account reporting feature will be in the next release? Most likely we would become masters of a few safe phrases and move our real communications to another channel.
I read a bit about Scrum and realized I misunderstood the role of stakeholders at daily meetings, specifically that the meetings are optional for stakeholders and that stakeholders attend primarily to gauge the team's morale, check for dysfunctionality, and discover ways to help. (I see now that you mentioned that, but it slipped by me.) That makes much more sense to me.
I'm still leery of the distorting effect of reporting, though. If a manager's credibility or ability to act is negatively affected by his developers' daily reports, you can be sure there will be pressure to stop hindering his work. As a developer, I appreciate whatever gives me the widest scope to tackle a problem directly and honestly, and having day-to-day results disseminated beyond technical personnel has always had the opposite effect.
One advantage of traditional project management is that it gives techies a layer of insulation from management politics; they can be completely honest with their manager and trust him to suppress any information that could be used to sabotage the project. Many developers fail to demonstrate the most basic level of political competence even when they spend all day thinking about it. I include myself in that bunch. If it comes up, I tell my managers that any plan requiring me to be politically sensitive is a bad plan.
Perhaps Scrum is just poorly suited to my particular strengths and weaknesses, but I consider myself a pretty typical developer. I value my career over any company's success, I prefer complete honesty because I have never succeeded with any other strategy, and when management turns on bully mode, I just do what they want and call it their loss. That isn't to say I don't value my integrity, merely that I protect my integrity by choosing my working environments very carefully, not by martyring myself if I end up in a bad situation. Putting guys like me out there in front of assorted stakeholders with many people's credibility dependent on our statements is liable to bring all kinds of pressure on us to account for political consequences when we do technical work, and we will not stand up to it very well. I imagine Scrum being of value only in businesses that can depend on esprit de corps to trump politics.
The recursion bottoms out if you don't tell the implementor about the doubling. If the implementor estimates two weeks, you can secretly plan on four. If the implementor finds out the working estimate is four weeks, however, it will take eight.
The 24-hour cycle reminds me of several hellish experiences I've had, especially of a certain project that required developers to make daily reports of progress to a non-technical manager. Here's the problem: What if you can't accomplish anything meaningful to the stakeholders in 24 hours?
For my current project, a really good day would be, "Today, Bob and I designed a tool that dumps the state of module X to text, and Bob wrote a script to parse that state and verify its correctness. I stubbed out a subset of module X and created a small set of test cases that exercise the stubs. Bob and I will implement the state-dumper tomorrow and integrate it with the test cases, giving us an initial test suite that will allow us to begin implemention. Mary investigated a suspicious behavior of the Y module, discovered that it is non-deterministic, and created a test that exercises the module until the bug is triggered. This program occasionally crashes, so we should consider the product unstable until this is resolved. Mary suspects a library bug and hopes to have it identified and reported to the vendor this week, giving us an excellent chance of working around it and/or receiving a bugfix by our release date."
This is an excellent day's work for all involved, but the stakeholders don't give a damn about any of it. This kind of stuff makes nontechnical users' eyes glaze over. Reporting it to them isn't a business activity; it's a social faux pas that results in the development department being made fun of around the water cooler. "Then he started talking about 'loadable modules' and I was like, 'Oh lord, make it stop.'"
In other words, if the daily progress report is supposed to be given to non-technical people, then the work I described above simply can't be done. It can't be reported, and we'll get yelled at if we work a whole day without having anything to report, so when are Bob and Mary and I going to do that stuff? Well, not on any day when we don't want to be yelled at, which turns out to be every day, despite our occasional fantasies of doing the right thing and righteously braving the storm of anger from management.
Here's what happens instead: Bob and I implement module X and, having enough integrity not to report completely untested work, run a couple of jerry-rigged tests and spot-check them by hand. We report that we implemented module X, ran tests, and found no problems. Afterwards we realize to our horror that module X is now officially done and bug-free, and we can never officially work on it again without looking like we falsely reporting our work, which in a sense we did. We know there must be bugs, so we secretly resolve to develop decent test tools for module X on nights and weekend, but all we end up doing is running a few more tests. Mary notices the suspicious behavior in module Y and briefly investigates it, but as a result she doesn't "accomplish" anything all morning. Afraid of having nothing to report, or worse, reporting something that isn't on the development plan, she drops the bug and spends the rest of the day implementing new features. She makes a mental note to return to the suspicious behavior someday, but guess what? Every day requires more reportable progress, and it's better for her career to see the product crash in production than to look lazy or disorganized in front of management.
The problem with reporting to nontechnical people is that they only understand certain kinds of accomplishments, such as "done" on a feature or use case. It means nothing to them that at 8am this morning we had no idea how to test module X and by 5pm this afternoon we had a detailed plan and a few working tools. Every day, you have three options:
1. Slap something together and report it as done.
2. Do a good day's work and try to explain your technical progress to the non-techies. Best case scenario: They decide (correctly) that you suck at communicating with non-techies and assume something has actually been accomplished, even though they don
You seem to forget that Calvin stresses out about facing the school bully every day, constantly being disciplined by his parents, and being shamefully mediocre at schoolwork. Actually, he's pretty awful at every aspect of his life that anyone else attaches any importance to, and he only finds relief in isolation. I wouldn't call that idyllic.
Personally, I cringe when I hear "the math is too complicated".
Perhaps it's better to say the math is rather unconstrained, rather than complicated. I get the impression that there are so many string theories that it's simple to choose the ones that match reality.
For example, suppose I have a class of theories that predict how much my lunch costs. After doing some math, I narrow down my class of theories to the ones that predict my lunch tomorrow will cost between $0 and $100. Then, tomorrow, my lunch costs $12.75, so I toss out all the theories except the ones that predict a lunch cost of $12.75 for that day. Now, if I still have a non-finite number of theories left, or if I still have tens of billions of theories left, I can't claim to be making progress.
I assume that must be the reason why it's so hard to get falsifiable predictions out of string theory. It's like a master of the Tao -- it contains all possibilities and adapts itself to all circumstances. A scientific theory should not be like water, enduring through lack of form. It should be breakable.
Didn't you know? Common Lisp had optional static typing in 1857. Then the Civil War came and people COMPLETELY forgot about it, babbling on about their Gatling guns and submarines and stuff that Lisp had had for years.
(I'm not really sure if Lisp's static typing guarantees compile errors. I'm just a beginner Lisp Weenie. I have potential, though, right?)
That isn't how a compiler is used. When you compile a C++ program, you don't throw away your C++ source and check the executable into source control. "Oh, no! We used gcc and now we have a bunch of gobbledygook we don't understand!"
The C++ is an intermediate stage in the make process, akin to the output of various phases of gcc.
Yep, every new tool is just an opportunity for idiots to screw up in new ways.
What a gloomy way of looking at the world.
True, but death is always an overstatement. From our perspective, assembly language is thriving in a permanent niche. From the perspective of a programmer from the 70s and 80s, assembly language has died a dramatic and impressive death.
In the end, I don't think a fair comparison between native compilation and virtual machines really matters. The popular and finely tuned virtual machines are designed to support dynamic languages and to prevent or recover from many classes of errors, whereas the popular and finely tuned compiled languages are mostly static and don't do any dynamic checking the programmer doesn't specifically request. For example, the effort put into statically compiling Java code will never begin to compare to the man-years put into the major JIT Java compilers, so it doesn't really matter whether statically compiled Java could theoretically compete with dynamically compiled Java. Similarly, we'll probably never see the full potential of byte-compiled C++ or Fortran. (You can compile C++ for .NET, but the runtime is designed to be a "nicer" platform than bare metal and support nice languages like C#.)
(Further, if clean room engineering is the de facto standard for documenting compliance with the law, people are likely to assume that the only reason for doing it any other way is to conceal wrongdoing. That attitude may have little to do with the law, but it might have some influence in a courtroom. On that point I'm out of my depth; ask a real lawyer.)
Yes, it is. Optimizing code using data from real use is fairly potent stuff, and it's rarely done for languages compiled "offline," despite people knowing about the potential for a long time. JIT compilers have made it available to the masses thanks precisely to the online nature of the compilation.
Lemme set you straight: once you have code, you clearly aren't working with anything "native" anymore. An FPGA with a nice custom hardware design doesn't need any "code" slowing things down. Just put data on one set of pins and get answers out the other. What's with you software rubes who think the same jack-of-all-trades generic processor should be used to solve every problem in the.... ummm... uh... I think those ASIC guys are coming over here to kick my butt and take my lunch money again. I'm gonna, um, run.
Pitfall was probably the third video games I played (after Combat and Pac-Man, on the Atari 2600), and perhaps because of its influence on my young, impressionable mind, I've always considered it a ridiculous cop-out to allow a player to change direction in mid-air.
Other posters have suggested that PHP gets its bad reputation by enabling ignorant, inexperienced, or simply unintelligent programmers to build working systems, and conversely, other languages prevent bad code by being inhospitable to bad coders. Does your experience support this hypothesis?
Who wants to sell to cash-strapped consumers? I'd rather sell to people who already have 300+ movies on DVDs including dozens of movies that knew they'd probably hate before they bought them. Companies care about dollars, not consumers. A consumer with $20,000 in disposable income is twenty times as good as a consumer with $1,000 is disposable income. That's why electronics stores devote most of their TV display space to TVs costing thousands of dollars and hide the cheap TVs on shelves in a narrow isle, even though more people buy $500 televisions than $5000 televisions.
Yeah, the Amish. That's who I was thinking of. Not millions of subsistence farmers around the world who use oxen because it's their best alternative.
Cell phones have not replaced land lines yet, but tractors have not replaced oxen, either.
Your annoyance is completely justified. When reading technical writing, it often happens that what appears to be a poorly written passage turns out to be a very carefully written passage that reveals something the reader did not previously understand. For this reason, readers of technical material do not gloss over sloppy usage as quickly as casual speakers and readers do. Instead, they try to puzzle meaning out of it. Technical writers should keep that in mind and write documents that repay careful reading, rather than punishing it by forcing readers to carefully pick through one sloppy phrase after another.
The only role your lack of native English played here was that it may have taken you a few seconds longer to identify the problem as bad writing rather than misunderstanding on your part.
You know the saying, "You can write Fortran in any language?" Scientists judge a language by how easy it is to write Fortran in it. That's why C is their second-favorite language.