Klingons are a sure ratings magnet: they appeal to both wrestling/NFL fans and geeks .
Have 2 Earth Federation rookies, a male and a female, be assigned to a Klingon ship shortly after Klingons join the Federation, in a cultural exchange program. The rookies have to be cunning both physically and socially to survive. Lots of plot room for action, showdown drama, and humor.
His reasoning [for the long way]: the compiler could have a bug and this way you would catch that bug.
I had a somewhat similar experience where the chief coder forbid comments in database query code because the compiler allows certain optimization hints in comments, and once a comment was mistaken for such by the compiler and created a really slow query that took a while to troubleshoot. Therefore, he forbade ALL query comments.
I tried to argue that the cost of no comments was greater in general than an occasional optimization mistake, and that if the small set of query coders simply learns what not to put in comments, the risk is small.
But, he accused me of being argumentative so I gave in and did it the stupid way. Debate on something as important as comments shouldn't be dismissed. He came from the military and believed hierarchical yes-manning was the "proper way". That's probably why they order $500 hammers.
I should have said "language design", and not (just) "syntax". We generally considered semantics also. What we excluded was compiler design and machine efficiency, unless it became a clear bottleneck.
(A secondary debate then broke out on whether such "chip" bottlenecks are merely a reflection of current chip technology and whether a new language should cater to current chips or "do it right" and not focus on chips. The answer often depended on one's domain perspective, for those who work closer to the hardware, such as embedded, thought tailoring design around common or current chip architecture mattered more.)
I've debated programming language syntax many times, and have come to the following conclusions:
1. The C-style switch/break syntax is archaic and error prone, and should be replaced by a modern version based on sets rather than "break". We even devised a way to support both the old and new forms for backward compatibility. I'd roughly estimate less than 15% of the debaters agreed to keep (only) the existing style.
2. There's no free lunch. Syntax design creates trade-offs, and not all the trade-offs are immediately recognizable. All languages will probably have warts somewhere under certain conditions or usage patterns. If any language eventually gets it all right, it'll probably be a lucky accident, not pre-planning.
3. Personal preference varies widely. What bothers me may not bother others. Our brains each process syntax very differently. Consensuses are hard to reach.
Smart people don't get climate news from non-experts any more than you should get legal advice from a non-lawyer.
A certain media wing cites Mr. Gore often to score political and/or vendetta points, but a decent news organization would ignore him for climate prediction and analysis.
It's time a climate superPAC be formed to create an NRA-like political entity with teeth. Science, math, and logic just don't work on the dumb and the greedy. You gotta bribe politicians with campaign money (or lack of) to get action in our society. That's just the ugly truth.
The other side will say the existence of a superPAC is evidence of political motivation over science, but they say that anyhow now. Sometimes you have to fight fire with fire.
Face it, it's not easy to run a tech company. Things always change in unpredictable ways. If it were easy, everybody would do it. Apple is one of the few strong survivors of time, and they've had lean times also.
Apple's success is a narrow focus, being cutting edge, and making hardware relatively simple to use.
I've used both iPhone and Android, and iPhone overall has a more polished, intuitive and integrated user interface for most every-day tasks. It ain't perfect, but does more things cleaner, at least for the bread-and-butter tools.
You have a "point", something does seem fishy. If you look at the two photos on space.com's article, the top "point" of the triangle is pointier in one versus the other.
In the early 1960's the USA had the fear of Soviet missiles to motivate it. We don't currently have anything equivalent. Maybe if the Chinese send a person to the moon we'll finally get worried enough to devote the resources.
The closest thing to the "Sputnik scare" of late is 9/11 (twice), which basically drove us to invade random countries, snoop on ourselves, and hold endless email hearings. We landed on our own moons this time.
I generally agree. When I went to teach one my children programming, I chose BASIC over newer alternatives. There's too many features and abstraction for newbies in say Python.
I can explain BASIC in simple English: "A GOSUB statement allows you to reuse the same lines of code from different spots in the program. It's like our little "execution guy" [already explained to kid] has a rule: when he sees GOSUB X, he writes down the line number of the next statement after that GOSUB in the "Return List". He then jumps to the given destination (line # X) and keeps executing until he sees a RETURN statement. When he sees that, he then checks the Return List we talked about to see where to go back to, crosses it out, and goes back."
It's simple "mechanical" rules of the form: if the "execution guy" sees such and such, he does this and that.
No crazy abstraction speech that goes over a kid's head, just easy step by step rules and clear-cut "parts". Statements have a clear-cut reference ID (line numbers) that can be written down per our model's "rules". You can check their work to see the line numbers.
(I don't need to get into stacks yet when starting out, but when the time comes, it's merely a clarification on how multiple items on the Return List are written and used by the Execution Guy. One can build on existing explanation idioms.)
If you think otherwise, I challenge you to present a simpler, more approachable way to explain function or sub-routine calls in say Python...
Some people think that the best IT workers are the ones who know lots of tricks and hacks to really optimize the hell out of everything-- secret settings that nobody else knows. I disagree. The best ones are those who leave everything in the most predictable, standardized state that's unremarkable except for how boring and clean it is.
The first kind are often the best trouble-shooters because they are used to tweaking and breaking and debugging stuff.
However, you don't want those kind to set up or design stuff.
It's ying-yang relationship between tweakers and preventers.
It's generally been the trend that a platform matures and tools come along that make common tasks simpler for domain programmers and power users so that specialized "bit diddling" isn't needed any more. VB made in-house-app GUI creation a snap compared to C++, for example.
However, whenever things settle, new technologies come along to create the cycle all over again.
When mini-computers settled, PC's (desktop) came along, when desktops matured, web came along. When web matured, smart-phones and tablets came along with UI and resources constraints that desktops didn't need to worry about.
There will always be the cutting edge that requires specialized bit-diddling (closer to the hardware or OS). However, it still may be in fits and starts such that there may be lulls in tech hiring between new fads/technology/gizmos.
Slashdot Mirror
The solution is obvious: gov't should outsource its managing of outsourcing. The private sector does it better!
Klingons are a sure ratings magnet: they appeal to both wrestling/NFL fans and geeks .
Have 2 Earth Federation rookies, a male and a female, be assigned to a Klingon ship shortly after Klingons join the Federation, in a cultural exchange program. The rookies have to be cunning both physically and socially to survive. Lots of plot room for action, showdown drama, and humor.
I had a somewhat similar experience where the chief coder forbid comments in database query code because the compiler allows certain optimization hints in comments, and once a comment was mistaken for such by the compiler and created a really slow query that took a while to troubleshoot. Therefore, he forbade ALL query comments.
I tried to argue that the cost of no comments was greater in general than an occasional optimization mistake, and that if the small set of query coders simply learns what not to put in comments, the risk is small.
But, he accused me of being argumentative so I gave in and did it the stupid way. Debate on something as important as comments shouldn't be dismissed. He came from the military and believed hierarchical yes-manning was the "proper way". That's probably why they order $500 hammers.
Correction,
I should have said "language design", and not (just) "syntax". We generally considered semantics also. What we excluded was compiler design and machine efficiency, unless it became a clear bottleneck.
(A secondary debate then broke out on whether such "chip" bottlenecks are merely a reflection of current chip technology and whether a new language should cater to current chips or "do it right" and not focus on chips. The answer often depended on one's domain perspective, for those who work closer to the hardware, such as embedded, thought tailoring design around common or current chip architecture mattered more.)
I've debated programming language syntax many times, and have come to the following conclusions:
1. The C-style switch/break syntax is archaic and error prone, and should be replaced by a modern version based on sets rather than "break". We even devised a way to support both the old and new forms for backward compatibility. I'd roughly estimate less than 15% of the debaters agreed to keep (only) the existing style.
2. There's no free lunch. Syntax design creates trade-offs, and not all the trade-offs are immediately recognizable. All languages will probably have warts somewhere under certain conditions or usage patterns. If any language eventually gets it all right, it'll probably be a lucky accident, not pre-planning.
3. Personal preference varies widely. What bothers me may not bother others. Our brains each process syntax very differently. Consensuses are hard to reach.
Al Gore is not a scientist.
Smart people don't get climate news from non-experts any more than you should get legal advice from a non-lawyer.
A certain media wing cites Mr. Gore often to score political and/or vendetta points, but a decent news organization would ignore him for climate prediction and analysis.
It's time a climate superPAC be formed to create an NRA-like political entity with teeth. Science, math, and logic just don't work on the dumb and the greedy. You gotta bribe politicians with campaign money (or lack of) to get action in our society. That's just the ugly truth.
The other side will say the existence of a superPAC is evidence of political motivation over science, but they say that anyhow now. Sometimes you have to fight fire with fire.
Not for us.
Face it, it's not easy to run a tech company. Things always change in unpredictable ways. If it were easy, everybody would do it. Apple is one of the few strong survivors of time, and they've had lean times also.
Apple's success is a narrow focus, being cutting edge, and making hardware relatively simple to use.
I've used both iPhone and Android, and iPhone overall has a more polished, intuitive and integrated user interface for most every-day tasks. It ain't perfect, but does more things cleaner, at least for the bread-and-butter tools.
1. Run!
2. Hide!
3. Panic!
4. Try the above in a different order.
The bottleneck in many modern economies is consumption. This program may increase consumption and thus "juice" the economy as a whole.
There might not be total net more money, but maybe total net more economic activity. That is, less idle money.
Yes, "trickle up".
Not just NASA
Zarnian menu: "Another photo of a delicious human being with its delicious child."
Hey, it's only a stereotype that visa workers are skinny.
I like to hang out at Area 15. Less security and you glimpse an occasional dyslexic alien.
I meant devote resources to a US Mars landing, not a US moon landing.
You have a "point", something does seem fishy. If you look at the two photos on space.com's article, the top "point" of the triangle is pointier in one versus the other.
That's too much; I'm buying Robin instead
Maybe they'll swipe healthcare.gov and fix the design, like they did the F-35.
In the early 1960's the USA had the fear of Soviet missiles to motivate it. We don't currently have anything equivalent. Maybe if the Chinese send a person to the moon we'll finally get worried enough to devote the resources.
The closest thing to the "Sputnik scare" of late is 9/11 (twice), which basically drove us to invade random countries, snoop on ourselves, and hold endless email hearings. We landed on our own moons this time.
70 INTERWEBS BEAT ME 2 IT
Explains why she won't open the pod bay doors. (Nor the iPod bay doors.)
Hey, you invented a great new training language:
10 LOL
20 LMFAO
30 PROFIT!
40 PUT ASS BACK ON
50 WTF?
60 GO TO 10
I generally agree. When I went to teach one my children programming, I chose BASIC over newer alternatives. There's too many features and abstraction for newbies in say Python.
I can explain BASIC in simple English: "A GOSUB statement allows you to reuse the same lines of code from different spots in the program. It's like our little "execution guy" [already explained to kid] has a rule: when he sees GOSUB X, he writes down the line number of the next statement after that GOSUB in the "Return List". He then jumps to the given destination (line # X) and keeps executing until he sees a RETURN statement. When he sees that, he then checks the Return List we talked about to see where to go back to, crosses it out, and goes back."
It's simple "mechanical" rules of the form: if the "execution guy" sees such and such, he does this and that.
No crazy abstraction speech that goes over a kid's head, just easy step by step rules and clear-cut "parts". Statements have a clear-cut reference ID (line numbers) that can be written down per our model's "rules". You can check their work to see the line numbers.
(I don't need to get into stacks yet when starting out, but when the time comes, it's merely a clarification on how multiple items on the Return List are written and used by the Execution Guy. One can build on existing explanation idioms.)
If you think otherwise, I challenge you to present a simpler, more approachable way to explain function or sub-routine calls in say Python...
The first kind are often the best trouble-shooters because they are used to tweaking and breaking and debugging stuff.
However, you don't want those kind to set up or design stuff.
It's ying-yang relationship between tweakers and preventers.
It's generally been the trend that a platform matures and tools come along that make common tasks simpler for domain programmers and power users so that specialized "bit diddling" isn't needed any more. VB made in-house-app GUI creation a snap compared to C++, for example.
However, whenever things settle, new technologies come along to create the cycle all over again.
When mini-computers settled, PC's (desktop) came along, when desktops matured, web came along. When web matured, smart-phones and tablets came along with UI and resources constraints that desktops didn't need to worry about.
There will always be the cutting edge that requires specialized bit-diddling (closer to the hardware or OS). However, it still may be in fits and starts such that there may be lulls in tech hiring between new fads/technology/gizmos.