|
analysis of design predicts properties of implementation
So much for Agile, eh? Agile and design are contradictory terms, in all the Agile shops I've seen.
Marc
|
|
|
|
|
Doesn't have to be, but you're right.
Decrease the belief in God, and you increase the numbers of those who wish to play at being God by being “society’s supervisors,” who deny the existence of divine standards, but are very serious about imposing their own standards on society.-Neal A. Maxwell
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
We are the champions ... of the WORLD!
Decrease the belief in God, and you increase the numbers of those who wish to play at being God by being “society’s supervisors,” who deny the existence of divine standards, but are very serious about imposing their own standards on society.-Neal A. Maxwell
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
No. Engineers share the lessons that they learn through error.
(We need to look at / learn from how medicine [^] and aeronautical engineering work to see how far wrong we are)
modified 17-Jul-15 8:47am.
|
|
|
|
|
Roboticists at the Ransselaer Polytechnic Institute in New York have built a trio of robots that were put through the classic 'wise men puzzle' test of self-awareness - and one of them passed. "Just put up your hand and say, 'I swear I won't kill anyone.'"
|
|
|
|
|
Can someone please unplug it? Like, now?
cheers
Chris Maunder
|
|
|
|
|
"I don't know." 
Marc
|
|
|
|
|
#include <iostream>
int main()
{
std::cout << "What is your question: ";
std::cin.ignore();
std::cout << "I don't know\n";
std::cout << "Sorry, I know now!\n";
std::cout << "All your base are belong to us!\n";
}
What scares me, is when a sentient machine realizes that it can use genetic algorithms to reprogram itself and make itself faster, better, smarter...
New human generations are created every 20 years, and it takes millions of years to evolve.
A machine could evolve at a pace incomprehensible to us. Then let it clone itself and evolve in parallel. My only hope is that the machines evolve the greedy gene and compete against themselves more than the humans.
While this research is valuable and AI should be developed. Reaching the singularity really is letting the demon out of the box.
|
|
|
|
|
I recently watched a TED talk on robotics where the speaker denoted that, if you remove all "reward systems" from his robots, they tend toward self-replication as their primary action. Just a little more to think about....
|
|
|
|
|
Human form replicators can't be far behind...
|
|
|
|
|
While this is not self-replication, if you leave a man and a woman in the same room with nothing to do, i.e. no reward system, I posit they would tend to reproduce... and even more to think about, or not.
|
|
|
|
|
As long as it's not the fifth Johnny, we're fine.
|
|
|
|
|
Microsoft claims that their new Edge web browser beats Google Chrome and Apple Safari, even on the company's JavaScript benchmarks. "Third gear, hang on tight. Faster it's alright"
|
|
|
|
|
So you get to all the things IE complains about your javascript faster than Chrome can say "oh yeah, just do this" and it executes the script?
|
|
|
|
|
Speaking a language fluently is impressive, and speaking many languages is impressive, but ultimately, it’s not about the words. "It's not in the words that you told me"
OK, I'm slapping myself for picking that one now.
|
|
|
|
|
And therefore it is entirely about the words.
|
|
|
|
|
|
I agree with this, and have made similar claims before myself. Knowing the syntax of a particular language doesn't necessarily make you a good programmer. Understanding core design concepts, loose-coupling, abstraction etc are what makes you a good programmer.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I disagree.
Next time you go to an interview, try speaking non-grammatical English. See how far you get.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
What if you were interviewing someone where English wasn't their first language, so maybe their spoken English was poor. But they had a solid understanding of the underlying principles and could write excellent code.
I work (and have worked with) many developers where their English was poor (we had an offshore Vietnamese team at a previous company) who could write code of a very high quality and could grasp new ideas almost instantly.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
The point that I was making was that good human language skills are an essential part of the package.
Yes, I would make allowances for a person whose native language was not English (or whatever language is used by the team). However, if his/her English is so poor that communication is impossible, his/her programming skills are irrelevant.
A software engineer must be able to work with the team, and that includes facility in a human language.
(BTW, I have found that in many cases the English skills of foreigners have been better than those of some so-called "native speakers".)
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Daniel Pfeffer wrote: (BTW, I have found that in many cases the English skills of foreigners have been better than those of some so-called "native speakers".)
We have to think to every word and how to put it in a sentence before saying it out loud, while a native speaker has little-to-zero problems blurting out whatever passes in its mind.
It is true in every language.
Geek code v 3.12 {
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++*
Weapons extension: ma- k++ F+2 X
}
|
|
|
|
|
I agree to a point, but some languages (Haskell and Smalltalk spring to mind) will permanently change the way you look at problems.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Quote: but some languages (Haskell and Smalltalk spring to mind) will permanently change the way you look at problems.
Is that necessarily a bad thing? I've used LISP and Haskell previously, and having done so gives me a bigger view of possibilities to work with.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
No, that's a good thing, but it does indicate that languages do matter, because some will change the way you program forever (for the better).
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
