The very nature of life at all levels is competition and self preservation. It would be nice if we could all agree on a cooperation model, but it doesn't currently exist.
At best we can position ourselves to meet any offensive attack with a solid defense while attempting to increase cooperation and reducing armed conflict. But you can't just leave yourself open or weak because not everyone in the world agrees with the current state of things and less so for future state.
Section 1 Paragraph 1:
Try real hard not to kill people. We're not exactly saying it's completely against the rules, but we really want you to try super hard not to kill anyone.
I'm not an expert on Outlook so I might not be aware of how to do it, but it seems like I've struggled to sort the search results (by whatever data element I might want to sort by) or to add additional search filters applied to the current set of results to whittle it down further.
It's the same thing software and hardware vendors have been doing for decades, including additional capabilities that can be unlocked with configuration. It's no different than a hotel that says "sure, you can use the empty room next to you also, for a charge." Or an airline that says "sure you can use the unused seat next to you, for a charge."
Clearly some Tesla owners disagree with you and are glad they have the freedom to choose based on their own opinion and not based on some poster on slashdot's opinion.
But those are outweighed by the complexity to do basic stuff. In the 80's we cranked out business erp type apps far more rapidly than today. This is one of my primary drivers at work is to put tools in place that will get us back to that level of productivity while still taking advantage of the positives of the newer technologies like web (vs client app).
But what the business needs hasn't really changed much for those types of apps. It's still a matter of maintaining master data and entering transaction data. Today's ERP apps generally look the same as 80x40 but inside a GUI window instead, and the reason is because the actual app requirements are the same: enter character based master and transactional data. There are some examples where graphics adds real value, like displaying images of items, or grids of detail with cut and paste, but most of the apps haven't changed much.
What you wrote is exactly the problem he is talking about. His point, and it's valid, is that the evolution has ended up in a place that has reduced productivity for X% of apps. The ideal state would be for that evolution to increase the quality/functionality over time while preserving productivity (which requires good tools/environments etc.).
It's a difficult problem because it's good to retain the independent flexibility for people to go any direction they want/need, but that creates a more complex environment with a reduced chance of optimal solutions (compared to a benevolent dictator that forces everyone to solve problems a specific way that has been identified as good/optima/productive).
When he says programming is harder, I think he means that for X% of problems, especially enterprise business apps, the amount of effort to do basic stuff has increased, and he's right. During the 80's I was creating business apps on midrange computers and the tools were pretty simple allowing us to be extremely productive. Far more productive than today when measured by how fast large enterprise apps can be built out.
One problem I think he is seeing is that different technologies get introduced that solve specific problems and provide advantages for some scenarios (e.g. web allows us not to install app code all over the place), but also increase the level of effort to create those simple business apps. There is definitely room for tools/environments/frameworks that pull together the various technologies in a simplified cohesive manner so we can be more productive on the high-volume low-complexity stuff.
HTML/CSS is an example of something that started out solving problem X, morphed into solving problems X+Y and in the process became a productivity sink even though it is providing advantages at the same time.
I think the actual skill that really matters is the ability to mentally model what is happening, manipulate the problem and solution abstractly and model the solution.
I can see the limit on some people when trying to walk them through specific problems, drawing things on the white board, explaining the implications of X, Y and Z etc., and they really struggle to see it. But the people that are good get it naturally with limited information transfer.
I do think that having an environment/set of tools that allows for some percentage of problems to be handled with the simpler tools is a good thing. There is a continuum of problems and not all of them require advanced tools.
But remember that node comparisons between companies are apples to oranges. Intel 14nm is approx the same as other fabs 10nm. In addition, they aren't exactly sitting on their hands, they made a choice in their process approach that is turning out to be probably a poor choice and they are struggling, but that's not the same as sitting on their hands.
Costco and Amazon have different labor requirements. In brick and mortar stores, the consumer performs the picking operation, meaning they walk to each aisle/bay and pick the items they want to buy and then walk them to the checkout/packing operation.
Amazon, on the other hand, must spend money on human labor and mechanical systems to perform the picking operation for each consumers order and then do more time consuming packing operation compared to brick and mortar (just place it in a bag). In a DC/Warehouse, especially for large ones with many different types of items and especially for high volume small order processing (ecommerce), picking walk distance is the largest cost/waste/nonproductive aspect that is targeted for automation first.
In a partially optimized cart/batch picking environment, pickers easily walk 10 miles per day, which is money down the drain. In a zone pick system with conveyor, that can be cut in half (or more), but the offset is expensive conveyor system. With Kiva robots, they can mostly eliminate the picking operation by humans, although there is a cost for the robots and it doesn't flex as well at peak holiday time because you can't just hire a bunch of temps, you need to have excess robots sitting on the sidelines all year.
No matter how you solve the problem, Amazon's employees and systems must do more work per order than a store like Costco where they need to replen the picking bays but they don't have to pay for the picking operation.
Your comment led me to read the patent thinking that maybe this one is legit. Unfortunately it's as ridiculous as most software patents. I used this exact same technique under some conditions back when I was in high school writing video games on the trash 80 color computer (around 1982).
Was it because I had come up with something worthy of a patent? Nope. It was because I was a competent programmer and doing the same things that pretty much every other competent programmer doing the same type of work was doing.
I'm very aware of the OpenWorm project and I think it's a great idea to start with the smallest brain rather than others that think they can jump right into simulating a rat brain or a human brain.
Having said that, they will first need to figure out how the astrocytes performs their computations and neuroscientists are absolutely nowhere near that level of information. In addition, even in the neuron, DNA is involved in computations (synapse strength is altered by turning on/off genes via epigenetic mechanisms and those alternations are what sustain the synapse at the current strength). So, OpenWorm idea is good but they are a looooong way off from having enough info to simulate the computations that happen.
Unless the OpenWorm project is also simulating the astrocytes that modulate and manage synapse activity, it's probably not going to be successful. For further info, google astrocyte tripartite synapse and you will find that neuroscientists now consider the astrocyte to be managing/controlling the synapse, (responding to neurotransmitters and signalling neurons on either side of the synapse as well as other glial cells).
The very nature of life at all levels is competition and self preservation. It would be nice if we could all agree on a cooperation model, but it doesn't currently exist.
At best we can position ourselves to meet any offensive attack with a solid defense while attempting to increase cooperation and reducing armed conflict. But you can't just leave yourself open or weak because not everyone in the world agrees with the current state of things and less so for future state.
"But master, if you created everything, who created you?" BZZZZAAAAAPPPPP
Section 1 Paragraph 1:
Try real hard not to kill people. We're not exactly saying it's completely against the rules, but we really want you to try super hard not to kill anyone.
I'm not an expert on Outlook so I might not be aware of how to do it, but it seems like I've struggled to sort the search results (by whatever data element I might want to sort by) or to add additional search filters applied to the current set of results to whittle it down further.
Trials in Washington state, uses a vacuum kind of thing to grab the apple. It may not be ready today but the writing is on the wall.
https://www.youtube.com/watch?...
Sounds like the Time Cube to me.
Yep, good point, that's a better one.
It's the same thing software and hardware vendors have been doing for decades, including additional capabilities that can be unlocked with configuration. It's no different than a hotel that says "sure, you can use the empty room next to you also, for a charge." Or an airline that says "sure you can use the unused seat next to you, for a charge."
Clearly some Tesla owners disagree with you and are glad they have the freedom to choose based on their own opinion and not based on some poster on slashdot's opinion.
in which the interior is as hot as molten lava
But those are outweighed by the complexity to do basic stuff. In the 80's we cranked out business erp type apps far more rapidly than today. This is one of my primary drivers at work is to put tools in place that will get us back to that level of productivity while still taking advantage of the positives of the newer technologies like web (vs client app).
But what the business needs hasn't really changed much for those types of apps. It's still a matter of maintaining master data and entering transaction data. Today's ERP apps generally look the same as 80x40 but inside a GUI window instead, and the reason is because the actual app requirements are the same: enter character based master and transactional data. There are some examples where graphics adds real value, like displaying images of items, or grids of detail with cut and paste, but most of the apps haven't changed much.
What you wrote is exactly the problem he is talking about. His point, and it's valid, is that the evolution has ended up in a place that has reduced productivity for X% of apps. The ideal state would be for that evolution to increase the quality/functionality over time while preserving productivity (which requires good tools/environments etc.).
It's a difficult problem because it's good to retain the independent flexibility for people to go any direction they want/need, but that creates a more complex environment with a reduced chance of optimal solutions (compared to a benevolent dictator that forces everyone to solve problems a specific way that has been identified as good/optima/productive).
When he says programming is harder, I think he means that for X% of problems, especially enterprise business apps, the amount of effort to do basic stuff has increased, and he's right. During the 80's I was creating business apps on midrange computers and the tools were pretty simple allowing us to be extremely productive. Far more productive than today when measured by how fast large enterprise apps can be built out.
One problem I think he is seeing is that different technologies get introduced that solve specific problems and provide advantages for some scenarios (e.g. web allows us not to install app code all over the place), but also increase the level of effort to create those simple business apps. There is definitely room for tools/environments/frameworks that pull together the various technologies in a simplified cohesive manner so we can be more productive on the high-volume low-complexity stuff.
HTML/CSS is an example of something that started out solving problem X, morphed into solving problems X+Y and in the process became a productivity sink even though it is providing advantages at the same time.
I think the actual skill that really matters is the ability to mentally model what is happening, manipulate the problem and solution abstractly and model the solution.
I can see the limit on some people when trying to walk them through specific problems, drawing things on the white board, explaining the implications of X, Y and Z etc., and they really struggle to see it. But the people that are good get it naturally with limited information transfer.
I do think that having an environment/set of tools that allows for some percentage of problems to be handled with the simpler tools is a good thing. There is a continuum of problems and not all of them require advanced tools.
But remember that node comparisons between companies are apples to oranges. Intel 14nm is approx the same as other fabs 10nm. In addition, they aren't exactly sitting on their hands, they made a choice in their process approach that is turning out to be probably a poor choice and they are struggling, but that's not the same as sitting on their hands.
Costco and Amazon have different labor requirements. In brick and mortar stores, the consumer performs the picking operation, meaning they walk to each aisle/bay and pick the items they want to buy and then walk them to the checkout/packing operation.
Amazon, on the other hand, must spend money on human labor and mechanical systems to perform the picking operation for each consumers order and then do more time consuming packing operation compared to brick and mortar (just place it in a bag). In a DC/Warehouse, especially for large ones with many different types of items and especially for high volume small order processing (ecommerce), picking walk distance is the largest cost/waste/nonproductive aspect that is targeted for automation first.
In a partially optimized cart/batch picking environment, pickers easily walk 10 miles per day, which is money down the drain. In a zone pick system with conveyor, that can be cut in half (or more), but the offset is expensive conveyor system. With Kiva robots, they can mostly eliminate the picking operation by humans, although there is a cost for the robots and it doesn't flex as well at peak holiday time because you can't just hire a bunch of temps, you need to have excess robots sitting on the sidelines all year.
No matter how you solve the problem, Amazon's employees and systems must do more work per order than a store like Costco where they need to replen the picking bays but they don't have to pay for the picking operation.
breaking news?
Your comment led me to read the patent thinking that maybe this one is legit. Unfortunately it's as ridiculous as most software patents. I used this exact same technique under some conditions back when I was in high school writing video games on the trash 80 color computer (around 1982).
Was it because I had come up with something worthy of a patent? Nope. It was because I was a competent programmer and doing the same things that pretty much every other competent programmer doing the same type of work was doing.
And those patents shouldn't exist in the first place due to the non-obvious test.
Patents are supposed to be non-obvious. That is the big problem, 99.99999999% of software patents are pretty damn obvious to a competent dev.
Yes, it was the the wrong half.
I'm very aware of the OpenWorm project and I think it's a great idea to start with the smallest brain rather than others that think they can jump right into simulating a rat brain or a human brain.
Having said that, they will first need to figure out how the astrocytes performs their computations and neuroscientists are absolutely nowhere near that level of information. In addition, even in the neuron, DNA is involved in computations (synapse strength is altered by turning on/off genes via epigenetic mechanisms and those alternations are what sustain the synapse at the current strength). So, OpenWorm idea is good but they are a looooong way off from having enough info to simulate the computations that happen.
Unless the OpenWorm project is also simulating the astrocytes that modulate and manage synapse activity, it's probably not going to be successful. For further info, google astrocyte tripartite synapse and you will find that neuroscientists now consider the astrocyte to be managing/controlling the synapse, (responding to neurotransmitters and signalling neurons on either side of the synapse as well as other glial cells).
They're uber proud of their progress