Moore's law is not a blip. Expand it, thinking not in terms of transistors but in terms of computation power of mankind's tools. The exponential goes back much further. Now, expand it again, thinking in terms of technology capabilities in general (not just computation). You get the law of accelerating returns: http://www.kurzweilai.net/the-...
I agree 100%. Recording advice for specific situations is an Herculean task, bound to fail. I'd go for core values too.
If I had to boil down what my parents taught me through life, it'd be three things:
We love you unconditionally
You can do anything you put your mind into (kid version) / You'll fail at a lot of stuff, but that failure is essential for success (non-kid version)
Happiness is a byproduct of the good you spread around.
Number 1 provides confidence in self, number 2 pushes for an active stance in life and number 3 is the core life mission.
Looking back, specific advice was always based on a reading of these core concepts. You can't possibly predict every specific piece of advice your child will need. You can, however, provide a framework for her to evaluate her options down the road.
Leave her a few videos, exposing *your* core approach to life, so that she can reason like you do. Every word will be treasured. Then, when you have a satisfying length of recorded messages, spend time with her and your wife. Don't fret about setting up memorable events. Just take the time to enjoy yourselves together. She'll remember it fondly.
I did Lasik 11 years ago. Exact same symptoms as you describe, plus eye dryness at the end of a working day. Every symptom disappeared in six to nine months. The first three months saw considerable progress, and then a slower pace. Now, the only remnant of the procedure is higher sensitivity to strong daylight. Solvable with sunglasses, of course.
It's not unaffordable. It's uncompetitive. A Dacia Sandero costs $9k, runs on LPG, transports 4 plus luggage. $16k covers a lot of cost for the fuel price difference, and you get a lot more use cases out of the vehicle.
The problems are such that you don't need huge datasets to choke O(n) solutions in the execution time limit. Winners at these competitions know how to produce efficient code. They may need to learn maintainability, but I'd wager that is an easier skill than producing the kind of efficient *and* correct solutions they come up with.
Try your hand at some of the problems to see how hard they are: http://uva.onlinejudge.org/
Sorry if I sound harsh, but you have to man up. Work conditions in first world countries used to be like that. The current work conditions were the result of decades of unionized fight against employers. They were not handed down on a golden plate. So, go and unionize.
Your argument falls to pieces when you look at the financials of the scientific publishing system: peer reviewers don't get paid; authors don't get paid; most of the added value is retained by publishers because they hold the gateway towards recognition by the scientific community.
In the past, publishers did an important work. Today, they should be replaced by digital tools. And they will. In time.
Yet, a HW guy (EE Major) has arguably the same skills, foundation, and fundamental knowledge as SW guys (CS majors). Its really just that EE guys don't like doing CS, but they could do it easily. I went to a top-tier uni with EECS as a combined major (and this is common at the top uni's). I can tell you the top EE guys aced their CS classes easily and beat out the top CS guys or were on par.
Wrong. Much as Dilbert's PHB, you assume that stuff you don't know is easy, based on the initial learning curve. Granted, throwing in a couple thousand line coding project is easy. That's the algorithmic training, and that is the easy part. Many kids learn that on their own well before their teen years. The difficult part is the system design; the cobbling of many software pieces to work together coherently; the design of clean abstraction layers (non-leaky abstractions are perhaps one of the most difficult engineering tasks); the design of stability pillars for maintainability (test frontiers, on APIs or on abstraction layers, documentation).
To put it into familiar terms, it's as easy for you to code as it is for me to program an FPGA, stuff it into a breadboard, plug in sensors and actuators and produce a prototype. However, CS guys know that they will never ever design a decent electronic circuit for mass production, even if they can tinker with EE stuff. EE guys will, like you do, boast to be able to decently design a decent software stack for mass usage. They can't (mass generalization). Not without relevant training. Information systems can get pretty darned complex, and just because they don't burn on failure or don't crash into rubble doesn't make software design any less difficult, just less appreciated.
Christ! Study your history, man. Portugal was pretty much flat-out broke by the end of the XIX century. The gold reserves were accumulated by a fiscally conservative dictator that ruled the country during the middle XX century (up to '74). You may argue that some of that richess came from Angola and Mozambique, but if you know Portuguese presence there, I can't see how you can call it plundering. When the Portuguese were kicked out, those two countries went 100 years back in time. Only now are they recovering, and the infrastructures are not yet even close to what they were in '74.
First point: this didn't pass into law, after active online campaigning; the law was shelved, will be revised, and may (probably will) be resubmited for approval in the future.
Second point: this wasn't a "pure" tax. This is a compensation scheme to pay back artists for "lost revenue" due to the private copy law. The private copy law (already in effect), allows citizens to copy artist work for private use. Putting an example into it, ripping a CD I own and copying the mp3 onto my ipod is perfectly legal, under the private copy law. Artists somehow believe I would buy the same art twice (once on CD and again on mp3), so they cry out for compensation. In fact, a compensation scheme already exists (on the old private copy law), which levies blank media (tapes, CD-Rs), but it did not include hard disks and solid state storage. This law meant to update the old compensation scheme. It's stupid, designed by someone who doesn't know Moore law, and was rightfully bashed in public.
I just hope it doesn't reappear in camouflage. Or whenever people are distracted by something else. The law is stupid beyond belief.
I call FUD on your comment. You have two paths at your disposal:
a) Statically link every library that may be problematic, or dynamically link against libraries shipped with software. It's the same Windows as OSX apps do; or
b) Use the distribution package managers, something that is incredibly missing from Windows and OSX. State your dependencies. Granted, you'll have to support two different package formats (.deb and.rpm) and two to three distributions (debian, redhat and maybe suse). Nothing that complicated, and a task for which there is lots of supporting software
You are complaining that option b) is a pain. I disagree, but even if I'd grant you that point, you overlook the presence of option a) for release. I can't fathom how having a new avenue for releasing software can be construed as bad.
Hmm, Deciding, on compile time, when an object will no longer be used smells, to me, as a variation on the Halting problem. It is not feasible. You may deallocate some objects, where it is provable that an object is no longer used, but you will leak memory, because not all cases can be proved at compile time.
Time, and the evolution of science it brings, is an amazing thing. Once, developing a nuclear bomb required gathering a super team of scientists, closed off in a campus inventing bleeding edge chemistry and physics. Today, the workings of nuclear bombs are considered trivial by scientists in the area.
Dijkstra's algorithm is, by today's standards, pretty trivial. It's a breadth first search in a graph. Simple enough to be completely described in a single sentence. I'm not negating the brilliance of the scientist, I'm merely stating software has evolved in the last decades.
If the algorithm is simple enough to be described in one sentence, a software engineer, self taught or not, better be able to get there, when asked for a solution to the problem. Again, knowing it by name is irrelevant, but when asked for a shortest-path algorithm for a graph, any half-decent developer should be able to reach a reasonable approximation.
Please re-read my comment. I asked for no such technical detail. I ask for basic knowledge of solution-space search approaches. An SQL developer, to use your example, who does not know that, won't surely be able to distinguish a b-tree index from a hash index and will tangle himself in an SQL knot in a heartbeat when facing non-trivial database tasks. I partially concur with you on UI developer skillsets. We're not yet at the point of being able to use non-techie types for UI development, but the toolset is evolving in that direction.
Frequently, software development isn't about what you know... it's about what you don't know and how quickly you can learn it.
That may be true, but not in Dijkstra's case. Dijkstra is quite simple. If, in an interview, I ask the candidate to design an algorithm for a shortest-path search in a graph, and he does not eventually arrive at a breadth first algorihm (Dijkstra) or a well design depth first, he's out. It's not about the formal knowledge, as much as it is about the thought process. A programmer who can't pass this test will surely design problematic software (in many fronts, like performance or security).
I'd serously doubt the technical ability of someone who could not describe Dijkstra's algorithm. Knowing it by name is not important, but after being asked for a shortest-path-in-a-graph algorithm, any good s/w engineer better come up with a breadth first search quick enough. It's not about memorizable knowledge, it's about mental models.
The vast majority of climate scientists disagree with the 16 non-climate scientists cited by the WSJ.
Please refrain from using democracy as a scientific metric. The "vast majority" of scientists were wrong throughout History many many times. A majority is no measure of scientific quality, otherwise we'd still study geocentric universe models.
I'm not that much of a trekkie to know the workings of the transporter. However, if it'd somehow physically move all my atoms to another place, in the same configuration, I'd go in. If it copies and reproduces, then destroys the original, I concur with you. Thanks but no thanks.
Ok, let's assume you connect, allow consciousness to transfer, then sever the connection but *don't* destroy the biological part. Who am I? I'd wager I'd still be the biological one, albeit the sillicon part may be a perfect copy. Now, kill the biological part. I'm dead. Thanks, but no, thanks. Not until we pinpoint conscience beyond "I think therefore I am".
The J2EE model of web app execution is fundamentally flawed. The logic of keeping one instance of the app alive for each user steers you towards hitting a very fast bottleneck on memory usage. Yes, the model has been adapted, with state serialization and essentially paging out the app when the user is not executing requests, but the root problem is there, and it still shows: It's very very hard to serve a few thousand simultaneous logins.
... PHP under Apache (And really what serious professional would use anything else?)...
Just about any serious professional. nginx + php-fpm is by far a better configuration. Configuration is simpler, the http daemon is a lot more efficient without having to deal with php processes, and you can separately scale static content servers and dynamic content servers horizontally.
My personal default setup for any medium-sized website is nowadays nginx (load balancer) => varnish => nginx (static content) => php-fpm
A mirror test for a dog is no easy feat. You are testing a non-dominant sense. Dogs rely a lot on smell, and there is no mirror for smell. So, on a mirror test, you either add a smell of another dog, or do nothing and let the "other dog" have no smell. One option induces the animal in error using its dominant sense, and the other creates a dissonance between senses. I wouldn't know how to interpret the result. If you go for the second option, you'll observe one of two results: either the animal reacts to the mirror, and he may as well be reacting to the sense dissonance and trying to solve it, or he does not, and it could mean that he passed the test or that he ignored the non-dominant sense. No valid result.
Obviously, I haven't read the mirror test studies on dogs, but I'd approach them with a grain of salt.
They also know the diff. between the TV and an image in a mirror, so you might want to rethink all that m- your so-called "science" is decades out of date.
Dogs have no cones in the retina, only rods, so: They see in black and white, as is widely known; and, more importantly, they see at a higher frequency. The result is that they see the flicker on the TV, making it definitely not lifelike. Oh, and the TV doesn't smell (thankfully), which for dogs is much more relevant than for us.
You can verify the higher operating frequency of rods, by looking at some fluorescent lamps from the corner of your eye. The center of the eye - the fovea - is very dense in cones, but the periphery is not, and rods are more common there. In many situations, you can't see a flicker of a device looking directly, but if you look using the vision edge it is very noticeable.
The funding effect is a hypothesis by climate sceptics who try to explain why there are no results that prove their point.
The climate is such a complex system that the mere fact that there so few hypothesis explaining global warming is itself a proof of hive-minded thinking processes.
Add this fact to your polarization of the subject using terms like "climate sceptics" (what the heck is a climate sceptic?), and you have just proven all my argumentation, without any help from me.
Slashdot Mirror
Moore's law is not a blip. Expand it, thinking not in terms of transistors but in terms of computation power of mankind's tools. The exponential goes back much further. Now, expand it again, thinking in terms of technology capabilities in general (not just computation). You get the law of accelerating returns: http://www.kurzweilai.net/the-...
If I had to boil down what my parents taught me through life, it'd be three things:
Number 1 provides confidence in self, number 2 pushes for an active stance in life and number 3 is the core life mission.
Looking back, specific advice was always based on a reading of these core concepts. You can't possibly predict every specific piece of advice your child will need. You can, however, provide a framework for her to evaluate her options down the road.
Leave her a few videos, exposing *your* core approach to life, so that she can reason like you do. Every word will be treasured. Then, when you have a satisfying length of recorded messages, spend time with her and your wife. Don't fret about setting up memorable events. Just take the time to enjoy yourselves together. She'll remember it fondly.
I did Lasik 11 years ago. Exact same symptoms as you describe, plus eye dryness at the end of a working day. Every symptom disappeared in six to nine months. The first three months saw considerable progress, and then a slower pace. Now, the only remnant of the procedure is higher sensitivity to strong daylight. Solvable with sunglasses, of course.
It's not unaffordable. It's uncompetitive. A Dacia Sandero costs $9k, runs on LPG, transports 4 plus luggage. $16k covers a lot of cost for the fuel price difference, and you get a lot more use cases out of the vehicle.
The problems are such that you don't need huge datasets to choke O(n) solutions in the execution time limit. Winners at these competitions know how to produce efficient code. They may need to learn maintainability, but I'd wager that is an easier skill than producing the kind of efficient *and* correct solutions they come up with. Try your hand at some of the problems to see how hard they are: http://uva.onlinejudge.org/
Sorry if I sound harsh, but you have to man up. Work conditions in first world countries used to be like that. The current work conditions were the result of decades of unionized fight against employers. They were not handed down on a golden plate. So, go and unionize.
Your argument falls to pieces when you look at the financials of the scientific publishing system: peer reviewers don't get paid; authors don't get paid; most of the added value is retained by publishers because they hold the gateway towards recognition by the scientific community.
In the past, publishers did an important work. Today, they should be replaced by digital tools. And they will. In time.
Wrong. Much as Dilbert's PHB, you assume that stuff you don't know is easy, based on the initial learning curve. Granted, throwing in a couple thousand line coding project is easy. That's the algorithmic training, and that is the easy part. Many kids learn that on their own well before their teen years. The difficult part is the system design; the cobbling of many software pieces to work together coherently; the design of clean abstraction layers (non-leaky abstractions are perhaps one of the most difficult engineering tasks); the design of stability pillars for maintainability (test frontiers, on APIs or on abstraction layers, documentation).
To put it into familiar terms, it's as easy for you to code as it is for me to program an FPGA, stuff it into a breadboard, plug in sensors and actuators and produce a prototype. However, CS guys know that they will never ever design a decent electronic circuit for mass production, even if they can tinker with EE stuff. EE guys will, like you do, boast to be able to decently design a decent software stack for mass usage. They can't (mass generalization). Not without relevant training. Information systems can get pretty darned complex, and just because they don't burn on failure or don't crash into rubble doesn't make software design any less difficult, just less appreciated.
Christ! Study your history, man. Portugal was pretty much flat-out broke by the end of the XIX century. The gold reserves were accumulated by a fiscally conservative dictator that ruled the country during the middle XX century (up to '74). You may argue that some of that richess came from Angola and Mozambique, but if you know Portuguese presence there, I can't see how you can call it plundering. When the Portuguese were kicked out, those two countries went 100 years back in time. Only now are they recovering, and the infrastructures are not yet even close to what they were in '74.
First point: this didn't pass into law, after active online campaigning; the law was shelved, will be revised, and may (probably will) be resubmited for approval in the future.
Second point: this wasn't a "pure" tax. This is a compensation scheme to pay back artists for "lost revenue" due to the private copy law. The private copy law (already in effect), allows citizens to copy artist work for private use. Putting an example into it, ripping a CD I own and copying the mp3 onto my ipod is perfectly legal, under the private copy law. Artists somehow believe I would buy the same art twice (once on CD and again on mp3), so they cry out for compensation. In fact, a compensation scheme already exists (on the old private copy law), which levies blank media (tapes, CD-Rs), but it did not include hard disks and solid state storage. This law meant to update the old compensation scheme. It's stupid, designed by someone who doesn't know Moore law, and was rightfully bashed in public.
I just hope it doesn't reappear in camouflage. Or whenever people are distracted by something else. The law is stupid beyond belief.
a) Statically link every library that may be problematic, or dynamically link against libraries shipped with software. It's the same Windows as OSX apps do; or
b) Use the distribution package managers, something that is incredibly missing from Windows and OSX. State your dependencies. Granted, you'll have to support two different package formats (.deb and .rpm) and two to three distributions (debian, redhat and maybe suse). Nothing that complicated, and a task for which there is lots of supporting software
You are complaining that option b) is a pain. I disagree, but even if I'd grant you that point, you overlook the presence of option a) for release. I can't fathom how having a new avenue for releasing software can be construed as bad.
Hmm, Deciding, on compile time, when an object will no longer be used smells, to me, as a variation on the Halting problem. It is not feasible. You may deallocate some objects, where it is provable that an object is no longer used, but you will leak memory, because not all cases can be proved at compile time.
Time, and the evolution of science it brings, is an amazing thing. Once, developing a nuclear bomb required gathering a super team of scientists, closed off in a campus inventing bleeding edge chemistry and physics. Today, the workings of nuclear bombs are considered trivial by scientists in the area.
Dijkstra's algorithm is, by today's standards, pretty trivial. It's a breadth first search in a graph. Simple enough to be completely described in a single sentence. I'm not negating the brilliance of the scientist, I'm merely stating software has evolved in the last decades.
If the algorithm is simple enough to be described in one sentence, a software engineer, self taught or not, better be able to get there, when asked for a solution to the problem. Again, knowing it by name is irrelevant, but when asked for a shortest-path algorithm for a graph, any half-decent developer should be able to reach a reasonable approximation.
Please re-read my comment. I asked for no such technical detail. I ask for basic knowledge of solution-space search approaches. An SQL developer, to use your example, who does not know that, won't surely be able to distinguish a b-tree index from a hash index and will tangle himself in an SQL knot in a heartbeat when facing non-trivial database tasks. I partially concur with you on UI developer skillsets. We're not yet at the point of being able to use non-techie types for UI development, but the toolset is evolving in that direction.
That may be true, but not in Dijkstra's case. Dijkstra is quite simple. If, in an interview, I ask the candidate to design an algorithm for a shortest-path search in a graph, and he does not eventually arrive at a breadth first algorihm (Dijkstra) or a well design depth first, he's out. It's not about the formal knowledge, as much as it is about the thought process. A programmer who can't pass this test will surely design problematic software (in many fronts, like performance or security).
I'd serously doubt the technical ability of someone who could not describe Dijkstra's algorithm. Knowing it by name is not important, but after being asked for a shortest-path-in-a-graph algorithm, any good s/w engineer better come up with a breadth first search quick enough. It's not about memorizable knowledge, it's about mental models.
Please refrain from using democracy as a scientific metric. The "vast majority" of scientists were wrong throughout History many many times. A majority is no measure of scientific quality, otherwise we'd still study geocentric universe models.
I'm not that much of a trekkie to know the workings of the transporter. However, if it'd somehow physically move all my atoms to another place, in the same configuration, I'd go in. If it copies and reproduces, then destroys the original, I concur with you. Thanks but no thanks.
Ok, let's assume you connect, allow consciousness to transfer, then sever the connection but *don't* destroy the biological part. Who am I? I'd wager I'd still be the biological one, albeit the sillicon part may be a perfect copy. Now, kill the biological part. I'm dead. Thanks, but no, thanks. Not until we pinpoint conscience beyond "I think therefore I am".
The J2EE model of web app execution is fundamentally flawed. The logic of keeping one instance of the app alive for each user steers you towards hitting a very fast bottleneck on memory usage. Yes, the model has been adapted, with state serialization and essentially paging out the app when the user is not executing requests, but the root problem is there, and it still shows: It's very very hard to serve a few thousand simultaneous logins.
Just about any serious professional. nginx + php-fpm is by far a better configuration. Configuration is simpler, the http daemon is a lot more efficient without having to deal with php processes, and you can separately scale static content servers and dynamic content servers horizontally.
My personal default setup for any medium-sized website is nowadays nginx (load balancer) => varnish => nginx (static content) => php-fpm
You must be german...
A mirror test for a dog is no easy feat. You are testing a non-dominant sense. Dogs rely a lot on smell, and there is no mirror for smell. So, on a mirror test, you either add a smell of another dog, or do nothing and let the "other dog" have no smell. One option induces the animal in error using its dominant sense, and the other creates a dissonance between senses. I wouldn't know how to interpret the result. If you go for the second option, you'll observe one of two results: either the animal reacts to the mirror, and he may as well be reacting to the sense dissonance and trying to solve it, or he does not, and it could mean that he passed the test or that he ignored the non-dominant sense. No valid result.
Obviously, I haven't read the mirror test studies on dogs, but I'd approach them with a grain of salt.
Dogs have no cones in the retina, only rods, so: They see in black and white, as is widely known; and, more importantly, they see at a higher frequency. The result is that they see the flicker on the TV, making it definitely not lifelike. Oh, and the TV doesn't smell (thankfully), which for dogs is much more relevant than for us.
You can verify the higher operating frequency of rods, by looking at some fluorescent lamps from the corner of your eye. The center of the eye - the fovea - is very dense in cones, but the periphery is not, and rods are more common there. In many situations, you can't see a flicker of a device looking directly, but if you look using the vision edge it is very noticeable.
The climate is such a complex system that the mere fact that there so few hypothesis explaining global warming is itself a proof of hive-minded thinking processes.
Add this fact to your polarization of the subject using terms like "climate sceptics" (what the heck is a climate sceptic?), and you have just proven all my argumentation, without any help from me.