I never quite undestood why RIM was so strong in the American corporate market while in the rest of the world it really was all Nokia and Symbian, which has great corporate integration. Nokia's predicament actually comes from ignoring the consumer... Windows Phone is also a step backwards in the corporate sense, but let us hope MS at least leverages Office there.
Well, I'm a Finn, so we count as a "Socialist medicine" country, and as a somewhat severely disabled person by birth who still has been patched up to be a happy taxpayer, I certainly count as a huge and probably never fully profitable beneficiary of our system, but anyway...
I frankly do not believe in the "UHC people do not care about the cost to benefit" argument. At least in civilized countries, people will have some common sense that even when they might totally destroy their health, it's not going to be fun even though they might get healthcare in the end. You'll want to avoid getting an organ transplant in general even though it might be paid for. When there are obvious public health concerns, such as the generally excessive alcohol intake in Finland, educating the public is a relatively small "totalitarian" cost as the objective benefit is so easy to see. Pure Libertarians will of course always disagree, and I can appreciate that.
The benefit of general social insurance not only in economic but ethical terms just outweighs any abuse concerns. Those who would, really deserve the pain that comes with the unfortunately necessary pain that comes with the condition they put themselves into, regardless of the healthcare they're getting.
And when it comes to actually *how* to provide the healthcare, it's all actually mercifully objective -- it's not like buying a car. Medicine is a science. We know that certain treatments work, in a scientific sense, and others do not. Hospitals do not need to be hotels. During my lifetime, I've been treated by incredibly skilled and compassionate public-sector doctors and nurses who have done their best -- and yet I've always been glad to be out of the hospital, as that means I'm getting better. And the outcome has been pretty good so far, yet I'm not so sure after all the cuts that are being imposed at the moment. Even the public sector can't run on thin air:-)
So typical of Muslims. We must be destroyed and subjugated, and if we resist, we fuel your bullshit sense of victimhood.
Mind you, nothing actually could describe Fenno-Swedes better, either. We must be assimilated into "Norden", and if we don't agree, we violate their human rights.
Well, programming language design and compiler theory and so on are a subfield of CS, but otherwise I'm in agreement. Personally I've learned a lot from the more academic languages such as Lisp and Haskell although I don't really use them in my day to day job.
How awesome that Swedish civilization is finally reaching Slashdot too. Here in Finland we've been at the receiving and of you for a long time and it's just getting "better" all the time. Nowadays the required dogma is that we're a bunch of barbarians if we don't take it in deep when as young as possible while we're still soft and malleable so that we don't develop "attitude problems" by getting this idea that we might actually have a "right" not to suck it and love it.
But anyway, glad to see you're bringing the gift of your awesomeness to here as well. Too bad I'm sure you'll be oppressed by being modded down, but don't be discouraged; by finding other minority-rights minded people, I am sure you will be able to demand a change in Slashdot's policies so that everyone will have to actually read you, and perhaps in the future, also have the right to produce exactly the same kind of material, so that they will not be oppressed by the future equal-rights rules of actually having to post exactly like you!
Now, if your main concern is code readability, maintenance and/or moving onto the next product as soon as this one compiles with no errors, higher level languages are undoubtedly far more appropriate.
Well, code readability and maintainability often mean a good design, which means that the problem is understood correctly and that the program can be seen to be correct. These are very good qualities in a language if it helps in achieving this.
Productivity is just a side-effect of a good language; for me this issue is more philosophical than that. The actual conceptual features of higher-level languages outright produce better thinking about issues...
Turing completeness is an abstraction that, while useful in the Itower is less useful out where users can type just about anything, at anytime, with any intent, and then produce just about any complaint in response to any response the software might make.
I'm not sure I understand how this is relevant; what I was saying is intended to be abstract. All languages once in a certain class (which, according ot that one guy in some other post, I am not allowed to mention so that I don't sound arrogant) are equivalent, so at least going down to asm does not give us any more theoretical power. Therefore, we're free to choose a representation, and my position says that for the human mind, asm is a remarkably bad representation for a symbolic expression in that class of languages, and coding in it does not produce as much insight about programming in general as some people try to claim. I am a bit of a believer in the Sapir-Worf hypothesis as far as programming languages go -- programming languages shape thinking processes about problems. And I never have had a symbolic thinking process about a problem that represents asm a bit.
This is not a problem if the software is trivial, but if the software is non-trivial than it becomes a much more difficult problem. Turing completeness is such a simple thing it cannot capture real-world complexity in software use.
As far as I agree with it -- I sort of do, but it's not a Turing-completeness issue -- it seems like my preference for higher-level languages would indeed manage complexity in non-trivial software better, no?
Also...
I would rather rescue the drowning Libertarian, not play insensitive games as if her life were of no value.
Well, that exercise is outright designed to find the fair value of his life... I suspect that to both of us, the value is actually quite high indeed, and we'd come to an agreement about that.
Yes, when I first was learning, pointers were a somewhat hard concept. I'm not sure you need assembly for that though; some basic education on computer architecture should suffice, and the rest really, semantically speaking, is a matter of having "indirection variables"... variables that know where to find some other value.
Yes, I suspected you were after something like that while I assume you still understanding perfectly well what I was saying. Or maybe you don't.
You are still intentionally missing my point in all of my posts, though, and choosing to slander me instead on irrelevancies. For the purposes of what is interesting to the discussion, programming languages really are the Turing-complete ones, as they, if needed, will also encompass the lesser classes. It does not matter that you may actually use, say, a regular expression to provide a solution to a sub-problem in a program, or that you use finite languages in your enumerations, or in the set of your programming language keywords...
The point is that we have this class of symbolic languages that we know are equivalent theoretically, and within that class, we're free to choose a representation. I personally do not believe that assembly does, in any sense, convey any particularly interesting meanings to the programmer within that class. This is the reason why higher-level programming languages exist.
I am not sure how I could actually mention Turing-complete languages without sounding like I'm somehow "proud" of understanding of the meaning of the term. Sorry, but I can't avoid using it when its usage is appropriate.
If there is a designer on the project who has derived his programmatic thinking only from asm and does not understand, for example, why functional programming conceptually matters, the whole project is hosed from the start and I'd prefer to steer clear of such idiocy... designers need a FAR more high-level, abstract understanding of things. And of course in the end you cannot separate the two roles; a developer will have to be a designer in the end.
I still honestly don't get your problem here. We have Turing-complete languages which are equivalent in terms of problems they solve; then we have more restricted languages that are unable to solve those problems (regexps, markup languages etc). As far as I know, we do not have programming languages that go beyond what a Turing machine is capable of solving. If you know of some, please let me know.
Uh, no. I'm defining programming languages strictly as Turing-complete ones, which is the class of the languages that we know to be capable of solving the problems we work with in automated computation... I don't understand what the controversy is in this statement.
I seriously doubt McCarthy was concerned with exactly how an algorithm worked on a given processor while he was discovering an alternative computing model to Turing machines.
If you're thinking Lambda Calculus, it's from Alonzo Church, not McCarthy, although McCarthy's Lisp has its roots there. But theoretically, all of them are equivalent.
Sure, they may be "good" inside their specific niche, but they have no versatility in their problem solving.
Actually it sounds like you are the one coming from a specific niche -- probably some kind of embedded development. It is exactly the versatility in problem solving that is, in my view, not tied to any kind of processor architectures or anything of the sort -- it comes from exposure to both problems (in their abstract form, as the same stuff shows up in various real-life incarnations) and various kinds of solution styles. As my argument goes, assembly just simply doesn't provide the latter -- you still need to know what to actually do with it, even if you had to implement something strictly in terms of a processor architecture.
By the way, the most gifted programmers I have met -- really, "thinkers about programs" -- have been avid Lispers. Interacting with one years ago made me a Lisper, too... best investment in a programming language I ever made.
Just because something is modular does not explicitly make it good code, nor does it being non-modular make it explicitly bad code.
Modularity usually is a sign that the problem's components have been recognized correctly. In 99% of the cases a well written piece of code where the programmer has understood the problem, is decomposed sensibly into some kind of units. In the remaining 1% the programmer really better be a programming god, and even if he were, he still should have been able to do provide a better decomposition.
There's a lot of coding that goes nowhere near the level of abstraction of assembly.
I suspect you mean "lack of abstraction"? Anyway, I disagree with the notion that for some weird reason, the "strongest" programming happens on the asm level and that it is the assembly itself that somehow, as a language, is special in the sense of gifting a deep understanding of programming in general. It's just a limited set of small instructions, and just because it is "hard" (in the "lot of work" sense), doesn't mean it's actually "informative" -- and as a thought experiment, I'm willing to bet a lot of money that a proficient high-level programmer is able to actually do something with asm when exposed to it, than a hypothetical asm-only programmer would be able to do only in asm. The building blocks for ideas are simply not present there.
I suppose I should have read TACOP earlier in life so that the book would have had a fair shot of "educating" me from ground up on its own terms. As I am, I was a bit underwhelmed by how much pages he spends on things that are relatively straightforward. I'm not saying the stuff isn't "fundamental", it's just that I'm not sure it is particularly useful for an experienced CS type, and as far as teaching the "art" of programming, IMO, both the selected topics and the presentation would be different in my own version... which would probably be closer to Structure and Interpretation of Computer Programs:-)
When you are working on a specific real world field, any of them, they present their real-world requirements which must be taken into account. This is software engineering.
Proving that something is deterministic has to happen in theory, and then robustly implemented in ways that preserve the logic of the proof. Anything else is folly.
This is a bit of an Engineering vs. CS debate at its core. I am not an "engineer", but more of a math-style CS guy, so for me it's both the asymptotic behaviour of algorithms that really matters, and there programming is not necessarily involved much if at all. What I am interested in programming, though, is in "how" we express programs in a symbolic way, and how that influences our thinking regarding the program and the problem solution it represents. There asm fails, IMO, and the claims of guys who think they see bits fly in the air Matrix-style as they code, seem suspect.
In another very real sense, the processor is not imperative in the way asm makes it look like -- there are micro-instructions, parallel pipelines, the works. What I am trying to get across that as long as your formalism is Turing-complete,
And I hope that you do understand that by functional programming I mean something quite different from something like a C function -- it's not a clever compiler trick, but pretty much a whole programming paradigm with its roots in formal logic and math...
Yes, exactly. For example, in my view, writing web pages does not count as programming, as the language is not equivalent to a Turing machine -- which all the "real programming languages" are. Well, we don't have infinite memory, but still..
I'm not sure you got my point, or otherwise I'm just missing yours. To make things clearer, what exactly is it that you disagree with in my statement that programming is the act of formulating solutions to problems using Turing-complete languages?
Slashdot Mirror
I never quite undestood why RIM was so strong in the American corporate market while in the rest of the world it really was all Nokia and Symbian, which has great corporate integration. Nokia's predicament actually comes from ignoring the consumer... Windows Phone is also a step backwards in the corporate sense, but let us hope MS at least leverages Office there.
Well, I'm a Finn, so we count as a "Socialist medicine" country, and as a somewhat severely disabled person by birth who still has been patched up to be a happy taxpayer, I certainly count as a huge and probably never fully profitable beneficiary of our system, but anyway...
I frankly do not believe in the "UHC people do not care about the cost to benefit" argument. At least in civilized countries, people will have some common sense that even when they might totally destroy their health, it's not going to be fun even though they might get healthcare in the end. You'll want to avoid getting an organ transplant in general even though it might be paid for. When there are obvious public health concerns, such as the generally excessive alcohol intake in Finland, educating the public is a relatively small "totalitarian" cost as the objective benefit is so easy to see. Pure Libertarians will of course always disagree, and I can appreciate that.
The benefit of general social insurance not only in economic but ethical terms just outweighs any abuse concerns. Those who would, really deserve the pain that comes with the unfortunately necessary pain that comes with the condition they put themselves into, regardless of the healthcare they're getting.
And when it comes to actually *how* to provide the healthcare, it's all actually mercifully objective -- it's not like buying a car. Medicine is a science. We know that certain treatments work, in a scientific sense, and others do not. Hospitals do not need to be hotels. During my lifetime, I've been treated by incredibly skilled and compassionate public-sector doctors and nurses who have done their best -- and yet I've always been glad to be out of the hospital, as that means I'm getting better. And the outcome has been pretty good so far, yet I'm not so sure after all the cuts that are being imposed at the moment. Even the public sector can't run on thin air :-)
So typical of Muslims. We must be destroyed and subjugated, and if we resist, we fuel your bullshit sense of victimhood.
Mind you, nothing actually could describe Fenno-Swedes better, either. We must be assimilated into "Norden", and if we don't agree, we violate their human rights.
LoOoOoOooOoooOooooOOOooL
Yeah, but how many people with the actual surname "Suomi" do you know anyway... :-)
As a Finn, I'm glad to have "Finland" (in Finnish) up there in orbit :-)
Well, programming language design and compiler theory and so on are a subfield of CS, but otherwise I'm in agreement. Personally I've learned a lot from the more academic languages such as Lisp and Haskell although I don't really use them in my day to day job.
How awesome that Swedish civilization is finally reaching Slashdot too. Here in Finland we've been at the receiving and of you for a long time and it's just getting "better" all the time. Nowadays the required dogma is that we're a bunch of barbarians if we don't take it in deep when as young as possible while we're still soft and malleable so that we don't develop "attitude problems" by getting this idea that we might actually have a "right" not to suck it and love it.
But anyway, glad to see you're bringing the gift of your awesomeness to here as well. Too bad I'm sure you'll be oppressed by being modded down, but don't be discouraged; by finding other minority-rights minded people, I am sure you will be able to demand a change in Slashdot's policies so that everyone will have to actually read you, and perhaps in the future, also have the right to produce exactly the same kind of material, so that they will not be oppressed by the future equal-rights rules of actually having to post exactly like you!
Now, if your main concern is code readability, maintenance and/or moving onto the next product as soon as this one compiles with no errors, higher level languages are undoubtedly far more appropriate.
Well, code readability and maintainability often mean a good design, which means that the problem is understood correctly and that the program can be seen to be correct. These are very good qualities in a language if it helps in achieving this.
Productivity is just a side-effect of a good language; for me this issue is more philosophical than that. The actual conceptual features of higher-level languages outright produce better thinking about issues...
Turing completeness is an abstraction that, while useful in the Itower is less useful out where users can type just about anything, at anytime, with any intent, and then produce just about any complaint in response to any response the software might make.
I'm not sure I understand how this is relevant; what I was saying is intended to be abstract. All languages once in a certain class (which, according ot that one guy in some other post, I am not allowed to mention so that I don't sound arrogant) are equivalent, so at least going down to asm does not give us any more theoretical power. Therefore, we're free to choose a representation, and my position says that for the human mind, asm is a remarkably bad representation for a symbolic expression in that class of languages, and coding in it does not produce as much insight about programming in general as some people try to claim. I am a bit of a believer in the Sapir-Worf hypothesis as far as programming languages go -- programming languages shape thinking processes about problems. And I never have had a symbolic thinking process about a problem that represents asm a bit.
This is not a problem if the software is trivial, but if the software is non-trivial than it becomes a much more difficult problem. Turing completeness is such a simple thing it cannot capture real-world complexity in software use.
As far as I agree with it -- I sort of do, but it's not a Turing-completeness issue -- it seems like my preference for higher-level languages would indeed manage complexity in non-trivial software better, no?
Also...
I would rather rescue the drowning Libertarian, not play insensitive games as if her life were of no value.
Well, that exercise is outright designed to find the fair value of his life... I suspect that to both of us, the value is actually quite high indeed, and we'd come to an agreement about that.
Yes, when I first was learning, pointers were a somewhat hard concept. I'm not sure you need assembly for that though; some basic education on computer architecture should suffice, and the rest really, semantically speaking, is a matter of having "indirection variables"... variables that know where to find some other value.
Yes, I suspected you were after something like that while I assume you still understanding perfectly well what I was saying. Or maybe you don't.
You are still intentionally missing my point in all of my posts, though, and choosing to slander me instead on irrelevancies. For the purposes of what is interesting to the discussion, programming languages really are the Turing-complete ones, as they, if needed, will also encompass the lesser classes. It does not matter that you may actually use, say, a regular expression to provide a solution to a sub-problem in a program, or that you use finite languages in your enumerations, or in the set of your programming language keywords...
The point is that we have this class of symbolic languages that we know are equivalent theoretically, and within that class, we're free to choose a representation. I personally do not believe that assembly does, in any sense, convey any particularly interesting meanings to the programmer within that class. This is the reason why higher-level programming languages exist.
I am not sure how I could actually mention Turing-complete languages without sounding like I'm somehow "proud" of understanding of the meaning of the term. Sorry, but I can't avoid using it when its usage is appropriate.
Ah, so you're a troll... no need to respond then :-)
If there is a designer on the project who has derived his programmatic thinking only from asm and does not understand, for example, why functional programming conceptually matters, the whole project is hosed from the start and I'd prefer to steer clear of such idiocy... designers need a FAR more high-level, abstract understanding of things. And of course in the end you cannot separate the two roles; a developer will have to be a designer in the end.
I still honestly don't get your problem here. We have Turing-complete languages which are equivalent in terms of problems they solve; then we have more restricted languages that are unable to solve those problems (regexps, markup languages etc). As far as I know, we do not have programming languages that go beyond what a Turing machine is capable of solving. If you know of some, please let me know.
Ok, so I hadn't heard of that yet. Doesn't alter my actual point one bit though.
Uh, no. I'm defining programming languages strictly as Turing-complete ones, which is the class of the languages that we know to be capable of solving the problems we work with in automated computation... I don't understand what the controversy is in this statement.
I seriously doubt McCarthy was concerned with exactly how an algorithm worked on a given processor while he was discovering an alternative computing model to Turing machines.
If you're thinking Lambda Calculus, it's from Alonzo Church, not McCarthy, although McCarthy's Lisp has its roots there. But theoretically, all of them are equivalent.
Sure, they may be "good" inside their specific niche, but they have no versatility in their problem solving.
Actually it sounds like you are the one coming from a specific niche -- probably some kind of embedded development. It is exactly the versatility in problem solving that is, in my view, not tied to any kind of processor architectures or anything of the sort -- it comes from exposure to both problems (in their abstract form, as the same stuff shows up in various real-life incarnations) and various kinds of solution styles. As my argument goes, assembly just simply doesn't provide the latter -- you still need to know what to actually do with it, even if you had to implement something strictly in terms of a processor architecture.
By the way, the most gifted programmers I have met -- really, "thinkers about programs" -- have been avid Lispers. Interacting with one years ago made me a Lisper, too... best investment in a programming language I ever made.
Just because something is modular does not explicitly make it good code, nor does it being non-modular make it explicitly bad code.
Modularity usually is a sign that the problem's components have been recognized correctly. In 99% of the cases a well written piece of code where the programmer has understood the problem, is decomposed sensibly into some kind of units. In the remaining 1% the programmer really better be a programming god, and even if he were, he still should have been able to do provide a better decomposition.
There's a lot of coding that goes nowhere near the level of abstraction of assembly.
I suspect you mean "lack of abstraction"? Anyway, I disagree with the notion that for some weird reason, the "strongest" programming happens on the asm level and that it is the assembly itself that somehow, as a language, is special in the sense of gifting a deep understanding of programming in general. It's just a limited set of small instructions, and just because it is "hard" (in the "lot of work" sense), doesn't mean it's actually "informative" -- and as a thought experiment, I'm willing to bet a lot of money that a proficient high-level programmer is able to actually do something with asm when exposed to it, than a hypothetical asm-only programmer would be able to do only in asm. The building blocks for ideas are simply not present there.
I suppose I should have read TACOP earlier in life so that the book would have had a fair shot of "educating" me from ground up on its own terms. As I am, I was a bit underwhelmed by how much pages he spends on things that are relatively straightforward. I'm not saying the stuff isn't "fundamental", it's just that I'm not sure it is particularly useful for an experienced CS type, and as far as teaching the "art" of programming, IMO, both the selected topics and the presentation would be different in my own version... which would probably be closer to Structure and Interpretation of Computer Programs :-)
When you are working on a specific real world field, any of them, they present their real-world requirements which must be taken into account. This is software engineering.
Proving that something is deterministic has to happen in theory, and then robustly implemented in ways that preserve the logic of the proof. Anything else is folly.
This is a bit of an Engineering vs. CS debate at its core. I am not an "engineer", but more of a math-style CS guy, so for me it's both the asymptotic behaviour of algorithms that really matters, and there programming is not necessarily involved much if at all. What I am interested in programming, though, is in "how" we express programs in a symbolic way, and how that influences our thinking regarding the program and the problem solution it represents. There asm fails, IMO, and the claims of guys who think they see bits fly in the air Matrix-style as they code, seem suspect.
In another very real sense, the processor is not imperative in the way asm makes it look like -- there are micro-instructions, parallel pipelines, the works. What I am trying to get across that as long as your formalism is Turing-complete,
And I hope that you do understand that by functional programming I mean something quite different from something like a C function -- it's not a clever compiler trick, but pretty much a whole programming paradigm with its roots in formal logic and math...
Yes, exactly. For example, in my view, writing web pages does not count as programming, as the language is not equivalent to a Turing machine -- which all the "real programming languages" are. Well, we don't have infinite memory, but still..
Basic stuff.
I'm not sure you got my point, or otherwise I'm just missing yours. To make things clearer, what exactly is it that you disagree with in my statement that programming is the act of formulating solutions to problems using Turing-complete languages?