I read the Kurzweil book (The Singularity Is Near) and did have a lot of sympathy with it, but not on the topic of singularity itself.
What is a technological singularity? Kurzweil believes technological knowledge is expanding at an exponential rate. He describes it as the point in time where the rate at which a technology advances is greater than the capacity for you to catch up if you are not there at the time. He thinks it will happen in 2040-50 on current projections.
I think that this is fine, but there is a small issue. Children. It may well be that we will have different views on a number of things in 40 years time (40 years ago environmentalism was the province of erm, nutters, now my town council has seperate bins for glass, paper and food etc.) but I think we will still have children and value them. They will move from 0 to where we are on this exponential curve in the course of education. Either education will improve, or get longer, or progress will slow.
I personally think it will be a mixture of all three.
Either way this means that a Singularity as some descibe it will not happen. If you can help a child to catch up, you can help an adult who dropped out of the loop.
If the net is tiered and Google has to pay a surcharge on traffic, you can bet your bottom dollar that Google will start charging you for searches. They will come up with some way to offset the cost. We all know who loses in the end. Money is moved from one persons pocket to another. One of the merits of an efficient market is that costs are allocated to those who benefit. [Google|insert name of corporate] makes money - benefits. If they think a faster response earns them more than the cost of being faster, they will pay, otherwise not. This is like the google pricing algorithm. [tinfoil hat]There is not a great net loss until the beneficiary (payee) is not human - Kurzweil thinks the first AI intelligences will emerge around 2025[/tinfoil hat]
This extension has changed my life - it is as common to have a computer connected to the intenet as it is to have USB ports enabled - and you cannot lose a GSpace. Providing an extensible framework is genuinely useful and I expect to see more of the same - never mind point releases.
This is a very good explanation of why designers want full control over web page display - they see a page of information as more of a whole 'image' - which comprises pictures and text. If you really want that, use PDF - or Flash, as many commercial sites do when they are there primarily to promote the brand 'image' http://www.bmw.com/com/en/index_highend.html
If you want to communicate in text - use HTML.
If you do not like Flash, you need to provide a constructive alternative. What is suggested here is just one of the first. Given the reception and the fact that if I set the font on my browser appropriately, the 'image' is not what the designer envisaged, I think attention will focus on something else.
Use the law against the patent holders. If I was ill and someone actively prevented me from receiving medical aid then I am su re that that person would be breaking the law. If the owner of the Hepatitis C virus is standing in the way of a possible cure, surely they are doing the same thing to all Hepatitis C sufferers. I hope you can hear the rumbling of a class action lawsuit in the distance.
Before anyone responds - well fine, but this means that we should be able to sue hospitals for not providing free drugs - this is wrong - it is very unlikely that researchers will use any of the patent holders knowledge.
I think the whole way we write and think about software is wrong.... we will not be writing programs bigger than about 10 million lines of code, no matter how fast our processors become I manage the development of a product that has over 1m lines of code (excluding comments before anyone asks) today. It deals with a small corner of the processes a business needs to follow. I see no problem in it growing to be over 10m lines at some point in the future. Systems like SAP etc must be more than 10 times this size if you count all the components, so this is nonsense right now. I do believe that software will start to share some of the characteristics of a biological organism - if you prod a random piece of DNA you get some random change from blue eyes to spontaneous abortion. if you amend a random piece of code you might not be able to log in or the background colour of a window may (embarrasingly) be buttonface. Aren't bugs just a limitation of human minds?
No, no, they're not. Rubbish. Bugs are a failure in communication, at some point in the chain between a requirement of the orginal requirement and the end product. If the human mind can express the requirement clearly, and an algorithm for the solution, but not produce a solution then he may have a point. If nature worked that way, the universe would crash all the time. I read that the majority of conceptions for women over 45 do not make it to term. (no sources I am sure someone can expand) I would call this the universe crashing in a most upsetting manner.
We need to be very careful before call something a success or failure. In the same way that cities are built on the ashes of older civilisations and they just seem to be getting larger, noone says cities are broken as a concept (now they may not be nice if you live in one but that is different - failure for the individual, success for the city). could you design a search engine that would encourage people to do more complex searches than they can do on a service like Google today, but still do them easily? Sit behind your mum or dad and watch them use IE, wince, and think well, yes. I hoped something more than the obvious from a good mind.
It is not a mistake that Linux and windows look alike. Cars look alike because they all have to move things (people) through the same environment (roads).
One of the biggest challenges facing the Open Source movement that has not been faced (yet) is for someone to develop hardware that is not supported by Windows. Until then do not be surprised that the two areas will converge.
New cars look the same too
on
Exegesis 4 Out
·
· Score: 1
Don't know if it is me getting old or what, but it seems like there is a gradual convergence of 'mainstream' languages, especially in the core functionality set. (I do not count lisp / scheme / z as mainstream) There was a comment somewhere in this months PC Plus (uk edition) on the ease of transferring from VB to their version of c# (or was it j#). I think that this is a good thing. You can use a telephone / car / toaster in any country (that has wires / roads / bread), why not have a common core for computer languages?
but our programmers absolutely do not spend 25h a week looking at code. This may have been true some years ago (like 15) but not now.
The discipline of software engineering is rapidly maturing - not least because some of the brightest minds are spending their lives doing it.
In the same way that the engineers working on the dover - calais channel tunnel worked very long hours and were paid well there will still be high paid and high pressure jobs - viz the current dotcompanies (and I wonder what next), however the secrets of success are not really secrets, but just good guides to probable success.
Mr Greenspun span a homespun truth in that a good product has one or two people architecting it, more will compromise the integrity of the vision. Therafter I seem to lose track of the flow.
If the design of the product is correct then different teams can work on different 'leaf nodes' without having to read each others code at all, or one team can work on different areas without having to carry out a lot of research.
If the specification of the product is correct then the programmer will have a very clear idea of what is wanted.
If the requirements of the product are clear then a good test plan can be constructed that will catch most errors (I did not say all)
As a nascent manager, having worked as a programmer for years the only times I had to work long hours was when it was not clear what was wanted, or the estimate was woefully incorrect.
Both these errors are mostly management errors.
The principal error I (and others) continually make is in not communicating clearly, in obtaining requirements (time and cost) or to other people or code.
I see creating software as an exercize in communication and creativity. Long hours count against both these.
Slashdot Mirror
wasn't the first sign of skynet a loss of performance and outages in large distributed computing networks?
One simple CPU.
Do a calculation.
Send the result back in time - just a little.
Repeat until done!
I read the Kurzweil book (The Singularity Is Near) and did have a lot of sympathy with it, but not on the topic of singularity itself.
What is a technological singularity?
Kurzweil believes technological knowledge is expanding at an exponential rate.
He describes it as the point in time where the rate at which a technology advances is greater than the capacity for you to catch up if you are not there at the time.
He thinks it will happen in 2040-50 on current projections.
I think that this is fine, but there is a small issue.
Children.
It may well be that we will have different views on a number of things in 40 years time (40 years ago environmentalism was the province of erm, nutters, now my town council has seperate bins for glass, paper and food etc.) but I think we will still have children and value them.
They will move from 0 to where we are on this exponential curve in the course of education.
Either education will improve, or get longer, or progress will slow.
I personally think it will be a mixture of all three.
Either way this means that a Singularity as some descibe it will not happen. If you can help a child to catch up, you can help an adult who dropped out of the loop.
If the net is tiered and Google has to pay a surcharge on traffic, you can bet your bottom dollar that Google will start charging you for searches. They will come up with some way to offset the cost. We all know who loses in the end.
Money is moved from one persons pocket to another. One of the merits of an efficient market is that costs are allocated to those who benefit.
[Google|insert name of corporate] makes money - benefits. If they think a faster response earns them more than the cost of being faster, they will pay, otherwise not. This is like the google pricing algorithm.
[tinfoil hat]There is not a great net loss until the beneficiary (payee) is not human - Kurzweil thinks the first AI intelligences will emerge around 2025[/tinfoil hat]
This extension has changed my life - it is as common to have a computer connected to the intenet as it is to have USB ports enabled - and you cannot lose a GSpace.
Providing an extensible framework is genuinely useful and I expect to see more of the same - never mind point releases.
This is a very good explanation of why designers want full control over web page display - they see a page of information as more of a whole 'image' - which comprises pictures and text.
If you really want that, use PDF - or Flash, as many commercial sites do when they are there primarily to promote the brand 'image'
http://www.bmw.com/com/en/index_highend.html
If you want to communicate in text - use HTML.
If you do not like Flash, you need to provide a constructive alternative. What is suggested here is just one of the first. Given the reception and the fact that if I set the font on my browser appropriately, the 'image' is not what the designer envisaged, I think attention will focus on something else.
Use the law against the patent holders.
If I was ill and someone actively prevented me from receiving medical aid then I am su re that that person would be breaking the law.
If the owner of the Hepatitis C virus is standing in the way of a possible cure, surely they are doing the same thing to all Hepatitis C sufferers.
I hope you can hear the rumbling of a class action lawsuit in the distance.
Before anyone responds - well fine, but this means that we should be able to sue hospitals for not providing free drugs - this is wrong - it is very unlikely that researchers will use any of the patent holders knowledge.
I think the whole way we write and think about software is wrong. ... we will not be writing programs bigger than about 10 million lines of code, no matter how fast our processors become
I manage the development of a product that has over 1m lines of code (excluding comments before anyone asks) today. It deals with a small corner of the processes a business needs to follow. I see no problem in it growing to be over 10m lines at some point in the future.
Systems like SAP etc must be more than 10 times this size if you count all the components, so this is nonsense right now.
I do believe that software will start to share some of the characteristics of a biological organism - if you prod a random piece of DNA you get some random change from blue eyes to spontaneous abortion. if you amend a random piece of code you might not be able to log in or the background colour of a window may (embarrasingly) be buttonface.
Aren't bugs just a limitation of human minds?
No, no, they're not.
Rubbish. Bugs are a failure in communication, at some point in the chain between a requirement of the orginal requirement and the end product.
If the human mind can express the requirement clearly, and an algorithm for the solution, but not produce a solution then he may have a point.
If nature worked that way, the universe would crash all the time.
I read that the majority of conceptions for women over 45 do not make it to term. (no sources I am sure someone can expand) I would call this the universe crashing in a most upsetting manner.
We need to be very careful before call something a success or failure.
In the same way that cities are built on the ashes of older civilisations and they just seem to be getting larger, noone says cities are broken as a concept (now they may not be nice if you live in one but that is different - failure for the individual, success for the city).
could you design a search engine that would encourage people to do more complex searches than they can do on a service like Google today, but still do them easily?
Sit behind your mum or dad and watch them use IE, wince, and think well, yes. I hoped something more than the obvious from a good mind.
It is not a mistake that Linux and windows look alike. Cars look alike because they all have to move things (people) through the same environment (roads).
One of the biggest challenges facing the Open Source movement that has not been faced (yet) is for someone to develop hardware that is not supported by Windows. Until then do not be surprised that the two areas will converge.
Don't know if it is me getting old or what, but it seems like there is a gradual convergence of 'mainstream' languages, especially in the core functionality set. (I do not count lisp / scheme / z as mainstream)
There was a comment somewhere in this months PC Plus (uk edition) on the ease of transferring from VB to their version of c# (or was it j#).
I think that this is a good thing. You can use a telephone / car / toaster in any country (that has wires / roads / bread), why not have a common core for computer languages?
but our programmers absolutely do not spend 25h a week looking at code. This may have been true some years ago (like 15) but not now. The discipline of software engineering is rapidly maturing - not least because some of the brightest minds are spending their lives doing it. In the same way that the engineers working on the dover - calais channel tunnel worked very long hours and were paid well there will still be high paid and high pressure jobs - viz the current dotcompanies (and I wonder what next), however the secrets of success are not really secrets, but just good guides to probable success. Mr Greenspun span a homespun truth in that a good product has one or two people architecting it, more will compromise the integrity of the vision. Therafter I seem to lose track of the flow. If the design of the product is correct then different teams can work on different 'leaf nodes' without having to read each others code at all, or one team can work on different areas without having to carry out a lot of research. If the specification of the product is correct then the programmer will have a very clear idea of what is wanted. If the requirements of the product are clear then a good test plan can be constructed that will catch most errors (I did not say all) As a nascent manager, having worked as a programmer for years the only times I had to work long hours was when it was not clear what was wanted, or the estimate was woefully incorrect. Both these errors are mostly management errors. The principal error I (and others) continually make is in not communicating clearly, in obtaining requirements (time and cost) or to other people or code. I see creating software as an exercize in communication and creativity. Long hours count against both these.