Uh? I'm not even sure if that sentence parses. I basically said "you should use the best tool for the job; get the computer to do all the menial work and you will be freed to use both logic and your natural skills and brainpower on a higher level of abstraction", and your answer was "kill yourself, you dumbass". Hardly a constructive exchange of ideas.
I would have wished for a more interesting debate with a low ID account, but it seems clear that we come from different backgrounds (though I understand your posture, I shared it as an ideal when I was young, but found it impractical for the kind of problems I deal with). What a shame.
Nope, you didn't understand the proposed idea and are making up stuff. I am proposing using the scientific method to build software, you are suggesting using a derivation from first principles.
My approach is similar to physics, yours is similar to logic and math on abstract objects. If you work with data from the real world there's a point when logic and math alone won't work, you have to create hypothesis and test them against reality. That is what's being suggested here.
Engineering is for building bridges. When you try to modal software that reacts to human behavior, you have to deal with uncertainty. Unless your code doesn't react to human behavior, your approach is limited and won't solve all cases.
You have to understand the problem and its cases first and then code it. At least that is what we learned from the analysis of different software development methods
That is the myth of the classical waterfall model. It assumes that you can and already do understand the whole problem in advance. As I said in another thread, that only works if you already have a model for the problem, maybe because it's a classical problem in physics or math. What I say is that you can use software to develop a new model; in that case the first iterations will be necessarily fragile, because you don't know what the possible cases will look like.
My proposition is, if you know what the input is and what the output is and what the cases are
Yup, that makes sense when you know the input and the output. I'm interested in the case when you don't know them and have to find them by exploring the real world with which the program interacts, ideally by using the scientific method (trial and error). We are saying nearly the same, just approaching different classes of problems.
Nope, won't happen. And while we are busy using our 21st century tools that automatically sequence proteins, build nano-structures and discover the hidden structure of English by spidering Wikipedia articles, you will be here trying to repeat the moon voyage with your slide rules. If we used your principles that "everything should be done in your head", we would still be sitting in the cave telling hunting tales instead of painting the chase plan on the walls.
You approach makes lots of sense for writing mathematical of physical code, where you have a perfect model of the world that is the basis of the problem to solve. Your ancient Slashdot ID seems to indicate that this is the kind of that you have experience with; that, or the essential infrastructure for big businesses, which is similarly model-based.
But when your program is for a specific business flow application, for which there is no model and the logic and corner cases must be elucidated from the client by showing a partially working prototype, the only way to extract all the requisites for the program is to throw in a few lines, show it to the user and ask what it's missing or how the current version is wrong, and then fix it; because the program's behavior has not been fully defined yet when the first version was written, it's d^Hrefined as a reaction of the working code.
And why would it be a bad practice using a computer to analyze the available data to discover the possible cases that must be covered, and thus understand what the program needs to do? Sure, the final released code should not contain the tests implemented for the first assumptions about data. But understanding the problem is easier if you can run a primary version of the basic program logic on live data.
Sure the difficult part is the problem. But if you have the computer doing the trivial and menial parts, the programmers mind will have more brain resources to expend analyzing the problem and thus it will be easier to solve the difficult part.
If you need to "run" code, either in your head or on a computer, in order to see what it's going to do, you're probably not really programming and you're definitely not an engineer.
Sure, you can do that in your head. They got to the moon with an abacus and some slide rules, so why do we need computers again?
That you can make it in your head doesn't mean that you should. Human brains are incredibly slow and error-prone at recall and logic, the primary strengths of computers. On the other hand our brains are evolutionary-level good at recognition and pattern matching.
This should make obvious the conclusions in the video: letting the computer do the recall and logic inferences, and the human the thinking and pattern matching, will produce a much more efficient system, two or three orders of magnitude higher than having the engineer produce all the derivations in his head.
It's a shame to the profession that so many slashdotters will laugh and dismiss the idea, and a sign of how incredibly conservative are programmers when it comes to the tools of their trade. In special because these ideas were already implemented and tested in academai before our current batch of business tools (C, Unix and IDEs) were developed, and then abandoned only because they were more difficult to teach even if they were more powerful to use. There, I have said it.
Is App Inventor a tool to train computer scientists? Heck no. Can it be used to teach teenagers how to build simple apps to install in their shiny smartphones? Yes!
Even if the environment lacks that are essential for the professional programmer, it's a working programming language useful to build toy applications, which is exactly the kind that absolute novices should be exposed to. Once the students understand the essence of sequential execution and state changes in variables, they can move on to a real environment like Python (which is as natural change from the block syntax) or Java for a more thorough learning of the professional ropes.
Yup, and what about those fancy Visual Studio and Eclipse stuff? How can a man learn to program with all the distracting colors and tree-view point-and-click windows? You can't even see the assembly bits in binary! How will you recognize the micro-ops?
(Face it, programming has never been about laying out streams of text - that's typing. Programming is about knowing which combination of primitives to place in what order to solve a problem).
The first and main advantage of democarcy over is that a government can be thrown out without a bloody revolution. This prevents common people being hurt by the political plays of violent social climbers, where previously they were used as literal pawns on the battleground.
It usually also has the benefit of keeping the current leader in check; a truly terrible elected government will have a quick fall, so they have to at least pretend to cater to the will of people. This is a small plus that too often can be subverted, but even without it I'd say that the first reason makes democracy worth every penny.
So it is how I thought. In short and by logic alone, the rationale for the Catholic establishment comes directly from the establishment itself. Even if tradition and scripture sets up priests as people dedicated to give service and counsel, there's nothing in the book to create a multi-level hierarchy; what I see in the Matthew episode was Jesus creating an assembly. In order to believe that the Church is intended as a single-boss pyramid organization, first you have to believe what the Vatican says about priesthood as a hierarchy - an interpretation of Peter being "singled-out" above apostles and Jesus preferring a human leader instead of collaboration between peers. I think the later would make more sense for Christians (who should be able to get along if the Holy Spirit works as intended), but whatever.
I'm usually more interested in the essence of arguments and not in the particular details, which as I said is the result of deep thinkers trying to rationalize an initial belief which I don't share. What matters to me is that there are other interpretations that also depend on the standard monotheist religious beliefs and are self-consistent, so the choice between them is by personal feelings more than rationality; even if you have the existence of God as an axiom, logical analysis is not the deciding factor.
Then why is a priestly caste needed as an intermediary to God? Is it because of the way that priests interpret Matthew 16:18, or am I missing something?
History is also full of believers that set out to really study scripture and end up rejecting the dogma for overly complicated; much of it amounts to the number of angels on a pinhead. Modern neurology has shown that belief is an a-priory sentiment and rational people create arguments after the fact to support it; the sharpest the thinker is, the better the argument.
We all know that scholars have been creating rationalizations since Paul of Tarsus for Catholicism, and since much longer for monotheism in general; Religion got a head start of several centuries on atheism based on the scientific method, which is only about 300 or 400 years old.
What scares the shit out of me is that the most careful rational thinkers (like you seem to be) who happen to have a religious sentiment can so easily fall to the trap of a "viral" belief system which is self-sustaining and self-consistent without requiring a connection to reality (yes I've read the likes of Dawkins, and consider it just a likely model and not a proven certainty; certainly something to ponder on). Specially when it makes them support a power-grabbing organization which uses the circular reasoning of "1) You have to believe in Holy things [the original, valid sentiment], 2) the Church says it's Holy, 3) therefore you have to believe what the Church says", and which was a power-grabbing organization long before it was in any way related to the Holy business.
I find troublesome accepting this argument as the only valid one, when alternate explanations exist and are equally logical, but don't require that particular syllogism as an unmovable axiom (and are usually not incompatible with the original belief either). Given two equally logical explanations, why would you stay with the more complex one, if not for your emotional attachment to it?
Slashdot Mirror
Uh? I'm not even sure if that sentence parses. I basically said "you should use the best tool for the job; get the computer to do all the menial work and you will be freed to use both logic and your natural skills and brainpower on a higher level of abstraction", and your answer was "kill yourself, you dumbass". Hardly a constructive exchange of ideas.
I would have wished for a more interesting debate with a low ID account, but it seems clear that we come from different backgrounds (though I understand your posture, I shared it as an ideal when I was young, but found it impractical for the kind of problems I deal with). What a shame.
Nope, you didn't understand the proposed idea and are making up stuff. I am proposing using the scientific method to build software, you are suggesting using a derivation from first principles.
My approach is similar to physics, yours is similar to logic and math on abstract objects. If you work with data from the real world there's a point when logic and math alone won't work, you have to create hypothesis and test them against reality. That is what's being suggested here.
Engineering is for building bridges. When you try to modal software that reacts to human behavior, you have to deal with uncertainty. Unless your code doesn't react to human behavior, your approach is limited and won't solve all cases.
That is the myth of the classical waterfall model. It assumes that you can and already do understand the whole problem in advance. As I said in another thread, that only works if you already have a model for the problem, maybe because it's a classical problem in physics or math. What I say is that you can use software to develop a new model; in that case the first iterations will be necessarily fragile, because you don't know what the possible cases will look like.
Yup, that makes sense when you know the input and the output. I'm interested in the case when you don't know them and have to find them by exploring the real world with which the program interacts, ideally by using the scientific method (trial and error). We are saying nearly the same, just approaching different classes of problems.
Nope, won't happen. And while we are busy using our 21st century tools that automatically sequence proteins, build nano-structures and discover the hidden structure of English by spidering Wikipedia articles, you will be here trying to repeat the moon voyage with your slide rules. If we used your principles that "everything should be done in your head", we would still be sitting in the cave telling hunting tales instead of painting the chase plan on the walls.
You approach makes lots of sense for writing mathematical of physical code, where you have a perfect model of the world that is the basis of the problem to solve. Your ancient Slashdot ID seems to indicate that this is the kind of that you have experience with; that, or the essential infrastructure for big businesses, which is similarly model-based.
But when your program is for a specific business flow application, for which there is no model and the logic and corner cases must be elucidated from the client by showing a partially working prototype, the only way to extract all the requisites for the program is to throw in a few lines, show it to the user and ask what it's missing or how the current version is wrong, and then fix it; because the program's behavior has not been fully defined yet when the first version was written, it's d^Hrefined as a reaction of the working code.
And why would it be a bad practice using a computer to analyze the available data to discover the possible cases that must be covered, and thus understand what the program needs to do? Sure, the final released code should not contain the tests implemented for the first assumptions about data. But understanding the problem is easier if you can run a primary version of the basic program logic on live data.
Sure the difficult part is the problem. But if you have the computer doing the trivial and menial parts, the programmers mind will have more brain resources to expend analyzing the problem and thus it will be easier to solve the difficult part.
That's why you put a human in charge, to recognize the infinite loop conditions and fix them by stopping the inference engine.
Sure, you can do that in your head. They got to the moon with an abacus and some slide rules, so why do we need computers again?
That you can make it in your head doesn't mean that you should. Human brains are incredibly slow and error-prone at recall and logic, the primary strengths of computers. On the other hand our brains are evolutionary-level good at recognition and pattern matching.
This should make obvious the conclusions in the video: letting the computer do the recall and logic inferences, and the human the thinking and pattern matching, will produce a much more efficient system, two or three orders of magnitude higher than having the engineer produce all the derivations in his head.
It's a shame to the profession that so many slashdotters will laugh and dismiss the idea, and a sign of how incredibly conservative are programmers when it comes to the tools of their trade. In special because these ideas were already implemented and tested in academai before our current batch of business tools (C, Unix and IDEs) were developed, and then abandoned only because they were more difficult to teach even if they were more powerful to use. There, I have said it.
'nuff said.
Wrong. N=Non-deterministic, like the Turing machine.
Is App Inventor a tool to train computer scientists? Heck no. Can it be used to teach teenagers how to build simple apps to install in their shiny smartphones? Yes!
Even if the environment lacks that are essential for the professional programmer, it's a working programming language useful to build toy applications, which is exactly the kind that absolute novices should be exposed to. Once the students understand the essence of sequential execution and state changes in variables, they can move on to a real environment like Python (which is as natural change from the block syntax) or Java for a more thorough learning of the professional ropes.
Because you're overstating the importance of typing as opposed to specifying an automated behavior.
And who says the App Inventor visual blocks are not a programming language? It certainly looks like an imperative language to me.
Ok, that should have been language primitives to solve a programming problem. Besides, you can program with Lego.
Yup, and what about those fancy Visual Studio and Eclipse stuff? How can a man learn to program with all the distracting colors and tree-view point-and-click windows? You can't even see the assembly bits in binary! How will you recognize the micro-ops?
(Face it, programming has never been about laying out streams of text - that's typing. Programming is about knowing which combination of primitives to place in what order to solve a problem).
Amen, brother. :-)
When a revolution has people in the streets armed with gun then yes, the battleground is literal. See my sig.
And the solution you propose to that problem is not voting?
I think the morale is, "be wary of people claiming that democracy doesn't work or is no longer necessary".
The first and main advantage of democarcy over is that a government can be thrown out without a bloody revolution. This prevents common people being hurt by the political plays of violent social climbers, where previously they were used as literal pawns on the battleground.
It usually also has the benefit of keeping the current leader in check; a truly terrible elected government will have a quick fall, so they have to at least pretend to cater to the will of people. This is a small plus that too often can be subverted, but even without it I'd say that the first reason makes democracy worth every penny.
So it is how I thought. In short and by logic alone, the rationale for the Catholic establishment comes directly from the establishment itself. Even if tradition and scripture sets up priests as people dedicated to give service and counsel, there's nothing in the book to create a multi-level hierarchy; what I see in the Matthew episode was Jesus creating an assembly. In order to believe that the Church is intended as a single-boss pyramid organization, first you have to believe what the Vatican says about priesthood as a hierarchy - an interpretation of Peter being "singled-out" above apostles and Jesus preferring a human leader instead of collaboration between peers. I think the later would make more sense for Christians (who should be able to get along if the Holy Spirit works as intended), but whatever.
I'm usually more interested in the essence of arguments and not in the particular details, which as I said is the result of deep thinkers trying to rationalize an initial belief which I don't share. What matters to me is that there are other interpretations that also depend on the standard monotheist religious beliefs and are self-consistent, so the choice between them is by personal feelings more than rationality; even if you have the existence of God as an axiom, logical analysis is not the deciding factor.
Uh - this should have been posted as a reply to ConceptJunkie's non-response above.
Then why is a priestly caste needed as an intermediary to God? Is it because of the way that priests interpret Matthew 16:18, or am I missing something?
Funny how ConceptJunkie failed to give a reply to this one :-) What a pity; I'd like to know which is the official explanation against this argument.
History is also full of believers that set out to really study scripture and end up rejecting the dogma for overly complicated; much of it amounts to the number of angels on a pinhead. Modern neurology has shown that belief is an a-priory sentiment and rational people create arguments after the fact to support it; the sharpest the thinker is, the better the argument.
We all know that scholars have been creating rationalizations since Paul of Tarsus for Catholicism, and since much longer for monotheism in general; Religion got a head start of several centuries on atheism based on the scientific method, which is only about 300 or 400 years old.
What scares the shit out of me is that the most careful rational thinkers (like you seem to be) who happen to have a religious sentiment can so easily fall to the trap of a "viral" belief system which is self-sustaining and self-consistent without requiring a connection to reality (yes I've read the likes of Dawkins, and consider it just a likely model and not a proven certainty; certainly something to ponder on). Specially when it makes them support a power-grabbing organization which uses the circular reasoning of "1) You have to believe in Holy things [the original, valid sentiment], 2) the Church says it's Holy, 3) therefore you have to believe what the Church says", and which was a power-grabbing organization long before it was in any way related to the Holy business.
I find troublesome accepting this argument as the only valid one, when alternate explanations exist and are equally logical, but don't require that particular syllogism as an unmovable axiom (and are usually not incompatible with the original belief either). Given two equally logical explanations, why would you stay with the more complex one, if not for your emotional attachment to it?