FORTH actually *is* fully post-fix, but the mingling of compile-time vs. execution time can make that difficult to see. And the last time I tried one just couldn't embed a " into a string. (Admittedly, that was over a decade ago, and my "standard FORTH" was FIG-FORTH. I don't have any real knowledge of ANSI-FORTH.)
I actually found FORTH easier to wrap my head around than LISP. I've never given Scheme a fair trial. But after Neon (an object oriented FORTH for the Mac) died during it's transition to MSWind95, I lost interest in Forth. A lot of good things died trying to make the move from Mac to MSWind95. Another language that died trying to do that was Prograf, a dataflow language. (To me it seemed that it's real problem was not it's platform, but that it didn't have any non-graphical representation accessible to end users. This made even simple programs insanely large when printed out.) If it had just lived it would have been an ideal language to use for programming multiple-cpu computers. (Outside of the representation problem.)
The subject, as I understand it, is "What is a good component language, given that some people really think that BASIC is a bad choice." If you don't think that, then of course it's going to seem like a good approach to you. And this thread has nothing to offer. I happen to think that component style programming could be quite useful, but I don't find BASIC an acceptable controller language.
In some ways the component approach fits in well with the characteristics of BASIC, I just don't like the language. And Python and Ruby both seem like decent substitutes. They seem to share all of the advantages of BASIC, and have a minimal number of the faults. LISP is another language that would be a good fit, as would FORTH, I just don't happen to like either of them. Note that in none of these languages is there the required declaration of variables. That doesn't seem to fit well with the component style, and may be why I don't think the Delphi/Lazarus attempts to do this with Pascal were satisfactory.
Note that it's also possible to go too far in the direction of flexibility. I think that Squeak Smalltalk went too far. Also notice that in none of these languages is efficiency the major consideration. This is appropriate for a language that is going to be controlling a GUI, but I might be extremely wise if it's easy to hook in routines that were compiled in a language that *DOES* consider efficiency important. Unfortunately this is much easier said than done, especially if you want the strings of your GUI controlling language to be utf8 strings (which I do). Handling utf8 strings in C still seems to be an "occult art".
For that matter, if all you're interested in is how easy the interpreter is to write, then you should pick FORTH. It's much easier to get a minimal complete system up in FORTH. You didn't even seriously consider that, so you have some other reason for selecting BASIC. (Not saying it's not a choice that a lot of people won't like. Just saying that *I* don't like it. And that that's why I've been ignoring it despite the many attractions.)
P.S.: A small part of my feeling towards BASIC is due to the MS AccessBasic I programmed in about a decade ago (well, I guess a decade and a half now). I would write a routine and it would work perfectly...for awhile. Then I'd need to write it out to text, delete the version in the system, and read it back in from text. No changes were either needed or indicated, but until I did that it would stop working. Another time I caught it adding two 3 digit numbers and getting the wrong answer...which caused me to wonder just how many times I *hadn't* caught it. At that point I had gotten close to the point of total distrust. I suppose that it's unfair to blame it on the language, when what it was was the MS implementation, but I still can't manage to trust any results that come out of BASIC. (My suspicion was that the compilation stored the code invisibly in the same file as the source, and the compiled code was somehow becoming corrupted, but, of course, there was no way to tell whether or not this was what was actually happening, and even if I had been able to tell, it wouldn't have been useful information, because I still wouldn't have any other way to fix the problem than delete the subroutine and reload it.)
The subject, as I understand it, is "What is a good component language, given that some people really think that BASIC is a bad choice." If you don't think that, then of course it's going to seem like a good approach to you. And this thread has nothing to offer. I happen to think that component style programming could be quite useful, but I don't find BASIC an acceptable controller language.
In some ways the component approach fits in well with the characteristics of BASIC, I just don't like the language. And Python and Ruby both seem like decent substitutes. They seem to share all of the advantages of BASIC, and have a minimal number of the faults. LISP is another language that would be a good fit, as would FORTH, I just don't happen to like either of them. Note that in none of these languages is there the required declaration of variables. That doesn't seem to fit well with the component style, and may be why I don't think the Delphi/Lazarus attempts to do this with Pascal were satisfactory.
Note that it's also possible to go too far in the direction of flexibility. I think that Squeak Smalltalk went too far. Also notice that in none of these languages is efficiency the major consideration. This is appropriate for a language that is going to be controlling a GUI, but I might be extremely wise if it's easy to hook in routines that were compiled in a language that *DOES* consider efficiency important. Unfortunately this is much easier said than done, especially if you want the strings of your GUI controlling language to be utf8 strings (which I do). Handling utf8 strings in C still seems to be an "occult art".
For that matter, if all you're interested in is how easy the interpreter is to write, then you should pick FORTH. It's much easier to get a minimal complete system up in FORTH. You didn't even seriously consider that, so you have some other reason for selecting BASIC. (Not saying it's not a choice that a lot of people won't like. Just saying that *I* don't like it. And that that's why I've been ignoring it despite the many attractions.)
P.S.: A small part of my feeling towards BASIC is due to the MS AccessBasic I programmed in about a decade ago (well, I guess a decade and a half now). I would write a routine and it would work perfectly...for awhile. Then I'd need to write it out to text, delete the version in the system, and read it back in from text. No changes were either needed or indicated, but until I did that it would stop working. Another time I caught it adding two 3 digit numbers and getting the wrong answer...which caused me to wonder just how many times I *hadn't* caught it. At that point I had gotten close to the point of total distrust. I suppose that it's unfair to blame it on the language, when what it was was the MS implementation, but I still can't manage to trust any results that come out of BASIC. (My suspicion was that the compilation stored the code invisibly in the same file as the source, and the compiled code was somehow becoming corrupted, but, of course, there was no way to tell whether or not this was what was actually happening, and even if I had been able to tell, it wouldn't have been useful information, because I still wouldn't have any other way to fix the problem than delete the subroutine and reload it.)
The component style of programming does have LOTS of advantages. It's the BASIC part that I can't stand. If they replaced it with Python, Ruby,... even LISP or FORTH, then I'd seriously consider it. C might be acceptable, but I sort of doubt it. It would depend on the fit, and I don't think that C woruld fit. But Pascal might work. (N.B.: I don't consider Lazarus to be a good fit, and it would need to handle Unicode strings. So the easiest language to adapt would probably be Python3.)
Please note that I didn't mention Java. I have not seen an acceptable implementation of this kind of thing for Java, and there have been many of them. Perhaps the language needs to be basically an interpreter based language. (This doesn't mean that it can't be compiled, this means the language design is aimed at an interpreted implementation. So of the languages I mentioned I consider Python the most promising, and Ruby the second most. [Ruby is deficient in the handling of Unicode. It CAN do it, but it's not as designed for it as Python {even Python2, but especially Python3}.])
Well... there was the time the ?? army I think ?? ordered one hammer, and the company quoted a price of, IIRC, $100,000. My impression is that the company *really* didn't want to handle the paperwork involved for one hammer, but wasn't going to turn down such a big customer. The contract went through...at least until it hit the news. They may have canceled it after that. That's hardly R&D, but that was the budget it came out of.
It's designed for someone with malformed hands, or so I remember. If your hands are normal, it's probably not what you want. If you've got problems, you might look it over and see if you think it would help.
Periodically expiring is easy, and would hardly take any time at all to code. Obfuscating it would only be very difficult, if the code revealed source (like Perl or Python usually do). Even then....
But for a compiled language, that's a trivial effort, unless your language doesn't give you access to the file system. And I think even JavaScript gives you *that* much access.
But if you don't own the rights to the code, this might put you in a bit of an uncertain legal position. It could be seen as analogous to those programmers that automatically lock their employer's systems after they are fired. (OTOH, if they're going to just wipe the system anyway, you'll never get caught...but they'll also never see your work, so why bother to leave a means of contact.)
Good things don't go unnoticed, but that doesn't guarantee what the result of the notice will be. There've been times when my boss saw that and just thought "Sucker!", but another boss in a similar situation gave a fair reward. It all depends. And it depends more on the personality of the boss than on the quality of your relationship.
It's a gamble, but OTOH, what is it you want to do? I generally liked to work on a challenging project. (Still do, but I'm retired now, so I choose my own projects.) If you do it on you own time, on your own equipment, and are satisfied that you own it, you might GPL the code. A good project can be good PR. (But you'd better be sure it's a good project!)
You're "It could happen" *does* happen. Frequently I've run across software that won't compile.
I'm sorry if you think that I made it sound trivial, but you need to understand the target audience for "source code only releases". The target is developers, not end-users. I disagree that such code shouldn't be released, though it *would* be much better if it came with warnings. Still, if it's "pre-alpha" quality, it's much better that non-developers are turned off quickly, even if not as quickly as they should be.
Remember, not all code is "ready to use", and sometimes people want to share their work even if they aren't going to finish it. While I agree that this should be documented, I don't think there's anything wrong with such code being shared.
I *will* agree that code that isn't done shouldn't be misrepresented, but that's not what you have been arguing, and I must disagree with the stronger statement that you are arguing for.
A really interesting part of that is that often the correction is within the same story. The headline and first couple of paragraphs give you the version that is either false or misleading, and if you follow the story to where it's continued, they give the corrected (note that I did not say accurate) version.
I don't actually know if that is still true, as about a decade ago I got so disgusted with the approach that I stopped buying attention to news. I refuse to pay for people to lie to me (when I see any reasonable choice).
If the news organizations want to know why readership has declined, that's the reason *I* stopped buying newspapers.
...ed to. (Somewhat ironically, GPL does not require the converse - if you distribute just the source code of a program w/o compiling it, it still qualifies as free under the FSF definitions).
What's ironic about that? You are required to have the source code in the form commonly used for development, and to make available (I forget the precise wording) all the libraries & tools required to compile it, so anyone competent can MAKE a binary. (That this isn't always adhered to doesn't change the requirements.) And making a binary us usually just configure/make/make install, often with customizable options that aren't available if all you were to get was the binary.
IIRC, you can't get a patent on doing something illegal. So what you do is patent it, but describe what it's doing in such a way that it can't be definitively shown to be illegal. This has the side benefit of allowing you to twist the definition to apply in circumstances that you'd never thought of.
Not unable. Unwilling. They may also be unable, but as they haven't tried, we can't know that.
The courts general attitude is "if the patent office has oked it, then we presume the patent is valid". The patent office's general attitude is "Well, it might be a valid patent, so we'll ok it and take the money, and let the courts figure out any problems." Occasionally the patent office can be prevailed upon to re-examine a patent. When they do so they often find it invalid. Frequently, however, the courts won't wait for this process to complete, and just find in favor of the current patent holder, even if the patent is fairly clearly bad. And if the patent office later throws out the patent, you're stuck paying whatever the court decided to charge you.
This isn't unable to stop abusive patents. This is unwilling.
My objections to KDE4 have nothing to do with bloat, per se, and everything to do with usability. I much prefer KDE3, even though KDE4 is far superior to Gnome3 (though NOT to Gnome2).
As for Gnome3 & Unity... I run on a desktop, not on a tablet. Those are useless pieces of garbage. (I'd be less condemnatory if Gnome2 hadn't ceased being offered. I am aware that there are environments that they are suited for. But if they won't consider my needs, I won't speak highly of them.)
Even so, it's probably unfair to criticize Unity. That project didn't kill anything to push it's agenda. But it sure is useless for my use case.
OTOH, I don't like tinkering with my system all the time. So I'm not likely to build my own desktop out of spare parts. So there's a fair chance that I'll end up using KDE4 and grumbling. But I'm certainly going to examine a bunch of other window managers first. They do need to handle a left-handed mouse, as I switch sides occasionally to avoid carpal tunnel. This let out at least one prominent choice the last time I checked. (I *think* it was LXDE, but can't really swear to it.)
P.S.: Eye-candy isn't what I'm after. I'm after functionality and ease of use. The desktop is pretty much covered up all the time anyway. The only eye-candy I find at all interesting is the Electric-sheep screen-saver, and I'd give that up to improve functionality.
Your final proposed course of action is the proper one. Given the course of recent decisions, I don't think this suit has much of a chance.
Others may have other reasons for thinking this suit won't succeed. My reason is that courts usually find a way to decide in favor of large businesses. Justice isn't involved, though frequently the wording of the law is. After all, the laws were written by the lobbyists that the corporations paid for. And passed by the legislators that...
My personal objections to KDE4, Gnome3, and Unity don't have much to do with how heavy they are. I'm not trying to use them in a minimal environment. My preferred system would be KDE3. But KDE4 is markedly slower *TO USE* than KDE3. (I don't know whether it's faster or slower, my system isn't minimal. But *using* it is slower.) Gnome3 is not only slower to use than Gnome2, but goes out of it's way to make doing things more difficult. And Unity appears to be designed to be only usable on tablets. (I haven't actually tried it.)
So, yes, I'm taking an interested look at all up-coming window managers. The screen shots of Razor look pretty good. LXDE is also pretty good, except that it doesn't seem to work with left-handed mice (or didn't the last time I tried it). Its got the control panels to set them up (In fact it's got two of them. In different dialogs.), but they don't (didn't) work.
This is also true of the early Macs. Up through at least system 3.5. They had their problems, but they were easy for novices to learn.
Thing is, there aren't many real novices around these days. Most people already have expectations based around what they have been using. (Which is possibly one reason that all OS GUIs are starting to be designed to look like phone interfaces, no matter how badly that works on a desktop.)
Probably not. The density of the core decreases, but the density remains pretty high. (The pressure is high enough to liquify hydrogen at a reasonable temperature.) And while the core has now disappeared, there is a larger volume of denser liquid.
Besides, what you see when you look at a gas giant is the atmosphere. That's not going to change measurably.
I think it quite possible that the people in charge will not accept that the intelligent robots have any feelings. Read some Victorians descriptions of how the non-white races had lesser feelings, and the feelings of robots are pretty much guaranteed to not be commensurate with ours. Not necessarily lesser, but definitely different.
I think you are correct, and that she did say that.
This is one place where Asimov got robots wrong. They won't work that way. Mind you, it doesn't help things all that much, because it's just the motivation that's wrong, not the result. If there isn't a constraint that you mustn't kill people, the robot will do it, but not because it's angry, just because it's the easiest way to solve the problem. (Well, of course this would mean that it wouldn't necessarily kill the person that gave the order, depending on what the order was. But it would be like a roving band saw without a protector around it's blade.) It may even be quite pleased to have a problem to solve. This doesn't help, because it will still take the "best" approach to solving the problem, where best is defined by the constraints given by it's operating program.
P.S.: I'd expect the robot to be so designed that it enjoyed solving problems and working out solutions, and then implementing them. But you need to be very careful about what it considers an acceptable solution.
Sorry, but when robots *DO* become intelligent they will be problem solving devices operating within constraints. When given a problem, they will attempt to solve it within those constraints. If you state the constraints incorrectly, then that's too bad. They won't even know that the solution they came up with is "cheating" instead of being creative. *You* know your intentions, but they can't read your mind, so they aren't intentionally "breaking your intentions".
That said, they will only act within their constraints, no matter how high or low level those constraints might be. And they *will* push things to the edges of those constraints. So the constraints should define your intentions and goals, not rules for specific situations. Even "be kind to people" is quite difficult, as both "kind" and "people" are very difficult to define. (I haven't yet encountered a good definition of either, that even humans could generally agree on.) This is especially true as the design needs to be built before the robot experiences the world, so you can't create sets of entities/event and say these and things sufficiently like them are kindness/people. And if you do, what happens if the robot has it's sensory apparatus upgraded? Or is moved into another body that senses things differently?
As a social animal, it is NECESSARY that we "outsource" some of our decisions to a common-to-our-group rule-system. Every social animal does it, whether wasps, wolves, or humans. Humans are unique in the detailed amount of decisions that they outsource, and in the variance among groups in what the rules are.
In my opinion we (currently in the US) have too many rules, and they aren't a fair trade off. I don't think this is an evolutionarily stable situation. But that gets resolved over the long term (probably violently). There is still the requirement for a group-common rule system. Periods where there are significant conflicts in the rule systems are quite unpleasant to live through (if you manage to do so). But even in those periods you have everyone adhering to external rule systems. And the conflicts are usually over relatively small details. (Not necessarily unimportant or insignificant, but small, as in representing minor differences in premisses.)
You misunderstand them. The words were never intended to be the laws. They were intended to be an English translation of the basic principles. The actual implementations were intended to be balancing acts, and only violations of the first law even contained the potential of destroying the robot's mind. Even there some tradeoffs were allowed. Some damages were considered more important than others, etc. (Read "Runaround" again and think about it.)
I'll agree that the words, as stated, were not implementable. But that was, kind of, he point of the stories. (Read "Liar" and understand the importance that ignorance assumes in stabilizing the robots minds.)
This doesn't mean that they are a good set of rules. But the importance of safety measures built in *IS* correct.
He did claim that they were a fundamental feature of the programs designed to operate the robot minds. And, yes, he said that modifying the program to be stable in the absence of those laws would be a herculean effort. But then so was writing the program in the first place.
There wasn't assumed to be anything in the way of a natural law that made it impossible, but that you'd almost need to start the design from scratch. And it represented years (or, depending on the story, decades) of work.
Think of trying to convert a Linux OS into a MSWind OS. There's no natural law that says you can't, but it's no simple job. The Wine project is still not nearly perfect, and it's been over a decade.
Now I'm thinking about it as a programmer. Asimov, however, was a biologist, primarily a biochemist. So his conception would probably be more like "You've built and artificial life form that's a bird, and you want he next variant to be a mammal? But reasonable! If you try it will quickly die!." Close enough in general outline, but differing a lot in detail.
It's qutie reasonable to get worked up about violating those laws. That's like running high voltage wires without insulation. Even *with* insulation you get into lots of trouble if you aren't careful, but without it...
(I'm not really talking about transmission lines. I don't know whether those are insulated, or just kept separated. I'm thinking about inside electronic devices, like CRTs.)
It you'll note on really old wiring, where the insulation wasn't that good (cloth wrapped around the wires.) the wiring style *required* the wires to be run along separated channels. Not double jacketed as one sees with plastic insulation. Violating that kind of basic safety measure is worth getting worked up about.
Similarly, violating the basic safety rules WRT robots is also worth getting worked up about. It's not *really* dangerous (except for social consequences) today, but the day after tomorrow, well, if you violate the basic safety rules there may not be any human around to see it.
Now given how self destructive humans are, I can see reasonable arguments that this is a good outcome, but as a human it's not one I feel we should work towards.
Slashdot Mirror
FORTH actually *is* fully post-fix, but the mingling of compile-time vs. execution time can make that difficult to see. And the last time I tried one just couldn't embed a " into a string. (Admittedly, that was over a decade ago, and my "standard FORTH" was FIG-FORTH. I don't have any real knowledge of ANSI-FORTH.)
I actually found FORTH easier to wrap my head around than LISP. I've never given Scheme a fair trial. But after Neon (an object oriented FORTH for the Mac) died during it's transition to MSWind95, I lost interest in Forth. A lot of good things died trying to make the move from Mac to MSWind95. Another language that died trying to do that was Prograf, a dataflow language. (To me it seemed that it's real problem was not it's platform, but that it didn't have any non-graphical representation accessible to end users. This made even simple programs insanely large when printed out.) If it had just lived it would have been an ideal language to use for programming multiple-cpu computers. (Outside of the representation problem.)
Why start from scratch?
The subject, as I understand it, is "What is a good component language, given that some people really think that BASIC is a bad choice." If you don't think that, then of course it's going to seem like a good approach to you. And this thread has nothing to offer. I happen to think that component style programming could be quite useful, but I don't find BASIC an acceptable controller language.
In some ways the component approach fits in well with the characteristics of BASIC, I just don't like the language. And Python and Ruby both seem like decent substitutes. They seem to share all of the advantages of BASIC, and have a minimal number of the faults. LISP is another language that would be a good fit, as would FORTH, I just don't happen to like either of them. Note that in none of these languages is there the required declaration of variables. That doesn't seem to fit well with the component style, and may be why I don't think the Delphi/Lazarus attempts to do this with Pascal were satisfactory.
Note that it's also possible to go too far in the direction of flexibility. I think that Squeak Smalltalk went too far. Also notice that in none of these languages is efficiency the major consideration. This is appropriate for a language that is going to be controlling a GUI, but I might be extremely wise if it's easy to hook in routines that were compiled in a language that *DOES* consider efficiency important. Unfortunately this is much easier said than done, especially if you want the strings of your GUI controlling language to be utf8 strings (which I do). Handling utf8 strings in C still seems to be an "occult art".
For that matter, if all you're interested in is how easy the interpreter is to write, then you should pick FORTH. It's much easier to get a minimal complete system up in FORTH. You didn't even seriously consider that, so you have some other reason for selecting BASIC. (Not saying it's not a choice that a lot of people won't like. Just saying that *I* don't like it. And that that's why I've been ignoring it despite the many attractions.)
P.S.: A small part of my feeling towards BASIC is due to the MS AccessBasic I programmed in about a decade ago (well, I guess a decade and a half now). I would write a routine and it would work perfectly...for awhile. Then I'd need to write it out to text, delete the version in the system, and read it back in from text. No changes were either needed or indicated, but until I did that it would stop working. Another time I caught it adding two 3 digit numbers and getting the wrong answer...which caused me to wonder just how many times I *hadn't* caught it. At that point I had gotten close to the point of total distrust. I suppose that it's unfair to blame it on the language, when what it was was the MS implementation, but I still can't manage to trust any results that come out of BASIC. (My suspicion was that the compilation stored the code invisibly in the same file as the source, and the compiled code was somehow becoming corrupted, but, of course, there was no way to tell whether or not this was what was actually happening, and even if I had been able to tell, it wouldn't have been useful information, because I still wouldn't have any other way to fix the problem than delete the subroutine and reload it.)
Why start from scratch?
The subject, as I understand it, is "What is a good component language, given that some people really think that BASIC is a bad choice." If you don't think that, then of course it's going to seem like a good approach to you. And this thread has nothing to offer. I happen to think that component style programming could be quite useful, but I don't find BASIC an acceptable controller language.
In some ways the component approach fits in well with the characteristics of BASIC, I just don't like the language. And Python and Ruby both seem like decent substitutes. They seem to share all of the advantages of BASIC, and have a minimal number of the faults. LISP is another language that would be a good fit, as would FORTH, I just don't happen to like either of them. Note that in none of these languages is there the required declaration of variables. That doesn't seem to fit well with the component style, and may be why I don't think the Delphi/Lazarus attempts to do this with Pascal were satisfactory.
Note that it's also possible to go too far in the direction of flexibility. I think that Squeak Smalltalk went too far. Also notice that in none of these languages is efficiency the major consideration. This is appropriate for a language that is going to be controlling a GUI, but I might be extremely wise if it's easy to hook in routines that were compiled in a language that *DOES* consider efficiency important. Unfortunately this is much easier said than done, especially if you want the strings of your GUI controlling language to be utf8 strings (which I do). Handling utf8 strings in C still seems to be an "occult art".
For that matter, if all you're interested in is how easy the interpreter is to write, then you should pick FORTH. It's much easier to get a minimal complete system up in FORTH. You didn't even seriously consider that, so you have some other reason for selecting BASIC. (Not saying it's not a choice that a lot of people won't like. Just saying that *I* don't like it. And that that's why I've been ignoring it despite the many attractions.)
P.S.: A small part of my feeling towards BASIC is due to the MS AccessBasic I programmed in about a decade ago (well, I guess a decade and a half now). I would write a routine and it would work perfectly...for awhile. Then I'd need to write it out to text, delete the version in the system, and read it back in from text. No changes were either needed or indicated, but until I did that it would stop working. Another time I caught it adding two 3 digit numbers and getting the wrong answer...which caused me to wonder just how many times I *hadn't* caught it. At that point I had gotten close to the point of total distrust. I suppose that it's unfair to blame it on the language, when what it was was the MS implementation, but I still can't manage to trust any results that come out of BASIC. (My suspicion was that the compilation stored the code invisibly in the same file as the source, and the compiled code was somehow becoming corrupted, but, of course, there was no way to tell whether or not this was what was actually happening, and even if I had been able to tell, it wouldn't have been useful information, because I still wouldn't have any other way to fix the problem than delete the subroutine and reload it.)
The component style of programming does have LOTS of advantages. It's the BASIC part that I can't stand. If they replaced it with Python, Ruby, ... even LISP or FORTH, then I'd seriously consider it. C might be acceptable, but I sort of doubt it. It would depend on the fit, and I don't think that C woruld fit. But Pascal might work. (N.B.: I don't consider Lazarus to be a good fit, and it would need to handle Unicode strings. So the easiest language to adapt would probably be Python3.)
Please note that I didn't mention Java. I have not seen an acceptable implementation of this kind of thing for Java, and there have been many of them. Perhaps the language needs to be basically an interpreter based language. (This doesn't mean that it can't be compiled, this means the language design is aimed at an interpreted implementation. So of the languages I mentioned I consider Python the most promising, and Ruby the second most. [Ruby is deficient in the handling of Unicode. It CAN do it, but it's not as designed for it as Python {even Python2, but especially Python3}.])
BASIC, however, is not a good base language.
Well... there was the time the ?? army I think ?? ordered one hammer, and the company quoted a price of, IIRC, $100,000. My impression is that the company *really* didn't want to handle the paperwork involved for one hammer, but wasn't going to turn down such a big customer. The contract went through...at least until it hit the news. They may have canceled it after that. That's hardly R&D, but that was the budget it came out of.
Reports are that it is good if...
It's designed for someone with malformed hands, or so I remember. If your hands are normal, it's probably not what you want. If you've got problems, you might look it over and see if you think it would help.
Periodically expiring is easy, and would hardly take any time at all to code. Obfuscating it would only be very difficult, if the code revealed source (like Perl or Python usually do). Even then....
But for a compiled language, that's a trivial effort, unless your language doesn't give you access to the file system. And I think even JavaScript gives you *that* much access.
But if you don't own the rights to the code, this might put you in a bit of an uncertain legal position. It could be seen as analogous to those programmers that automatically lock their employer's systems after they are fired. (OTOH, if they're going to just wipe the system anyway, you'll never get caught...but they'll also never see your work, so why bother to leave a means of contact.)
Good things don't go unnoticed, but that doesn't guarantee what the result of the notice will be. There've been times when my boss saw that and just thought "Sucker!", but another boss in a similar situation gave a fair reward. It all depends. And it depends more on the personality of the boss than on the quality of your relationship.
It's a gamble, but OTOH, what is it you want to do? I generally liked to work on a challenging project. (Still do, but I'm retired now, so I choose my own projects.) If you do it on you own time, on your own equipment, and are satisfied that you own it, you might GPL the code. A good project can be good PR. (But you'd better be sure it's a good project!)
You're "It could happen" *does* happen. Frequently I've run across software that won't compile.
I'm sorry if you think that I made it sound trivial, but you need to understand the target audience for "source code only releases". The target is developers, not end-users. I disagree that such code shouldn't be released, though it *would* be much better if it came with warnings. Still, if it's "pre-alpha" quality, it's much better that non-developers are turned off quickly, even if not as quickly as they should be.
Remember, not all code is "ready to use", and sometimes people want to share their work even if they aren't going to finish it. While I agree that this should be documented, I don't think there's anything wrong with such code being shared.
I *will* agree that code that isn't done shouldn't be misrepresented, but that's not what you have been arguing, and I must disagree with the stronger statement that you are arguing for.
A really interesting part of that is that often the correction is within the same story. The headline and first couple of paragraphs give you the version that is either false or misleading, and if you follow the story to where it's continued, they give the corrected (note that I did not say accurate) version.
I don't actually know if that is still true, as about a decade ago I got so disgusted with the approach that I stopped buying attention to news. I refuse to pay for people to lie to me (when I see any reasonable choice).
If the news organizations want to know why readership has declined, that's the reason *I* stopped buying newspapers.
...ed to. (Somewhat ironically, GPL does not require the converse - if you distribute just the source code of a program w/o compiling it, it still qualifies as free under the FSF definitions).
What's ironic about that? You are required to have the source code in the form commonly used for development, and to make available (I forget the precise wording) all the libraries & tools required to compile it, so anyone competent can MAKE a binary. (That this isn't always adhered to doesn't change the requirements.) And making a binary us usually just configure/make/make install, often with customizable options that aren't available if all you were to get was the binary.
IIRC, you can't get a patent on doing something illegal. So what you do is patent it, but describe what it's doing in such a way that it can't be definitively shown to be illegal. This has the side benefit of allowing you to twist the definition to apply in circumstances that you'd never thought of.
Not unable. Unwilling. They may also be unable, but as they haven't tried, we can't know that.
The courts general attitude is "if the patent office has oked it, then we presume the patent is valid". The patent office's general attitude is "Well, it might be a valid patent, so we'll ok it and take the money, and let the courts figure out any problems." Occasionally the patent office can be prevailed upon to re-examine a patent. When they do so they often find it invalid. Frequently, however, the courts won't wait for this process to complete, and just find in favor of the current patent holder, even if the patent is fairly clearly bad. And if the patent office later throws out the patent, you're stuck paying whatever the court decided to charge you.
This isn't unable to stop abusive patents. This is unwilling.
My objections to KDE4 have nothing to do with bloat, per se, and everything to do with usability. I much prefer KDE3, even though KDE4 is far superior to Gnome3 (though NOT to Gnome2).
As for Gnome3 & Unity... I run on a desktop, not on a tablet. Those are useless pieces of garbage. (I'd be less condemnatory if Gnome2 hadn't ceased being offered. I am aware that there are environments that they are suited for. But if they won't consider my needs, I won't speak highly of them.)
Even so, it's probably unfair to criticize Unity. That project didn't kill anything to push it's agenda. But it sure is useless for my use case.
OTOH, I don't like tinkering with my system all the time. So I'm not likely to build my own desktop out of spare parts. So there's a fair chance that I'll end up using KDE4 and grumbling. But I'm certainly going to examine a bunch of other window managers first. They do need to handle a left-handed mouse, as I switch sides occasionally to avoid carpal tunnel. This let out at least one prominent choice the last time I checked. (I *think* it was LXDE, but can't really swear to it.)
P.S.: Eye-candy isn't what I'm after. I'm after functionality and ease of use. The desktop is pretty much covered up all the time anyway. The only eye-candy I find at all interesting is the Electric-sheep screen-saver, and I'd give that up to improve functionality.
Your final proposed course of action is the proper one. Given the course of recent decisions, I don't think this suit has much of a chance.
Others may have other reasons for thinking this suit won't succeed. My reason is that courts usually find a way to decide in favor of large businesses. Justice isn't involved, though frequently the wording of the law is. After all, the laws were written by the lobbyists that the corporations paid for. And passed by the legislators that ...
My personal objections to KDE4, Gnome3, and Unity don't have much to do with how heavy they are. I'm not trying to use them in a minimal environment. My preferred system would be KDE3. But KDE4 is markedly slower *TO USE* than KDE3. (I don't know whether it's faster or slower, my system isn't minimal. But *using* it is slower.) Gnome3 is not only slower to use than Gnome2, but goes out of it's way to make doing things more difficult. And Unity appears to be designed to be only usable on tablets. (I haven't actually tried it.)
So, yes, I'm taking an interested look at all up-coming window managers. The screen shots of Razor look pretty good. LXDE is also pretty good, except that it doesn't seem to work with left-handed mice (or didn't the last time I tried it). Its got the control panels to set them up (In fact it's got two of them. In different dialogs.), but they don't (didn't) work.
This is also true of the early Macs. Up through at least system 3.5. They had their problems, but they were easy for novices to learn.
Thing is, there aren't many real novices around these days. Most people already have expectations based around what they have been using. (Which is possibly one reason that all OS GUIs are starting to be designed to look like phone interfaces, no matter how badly that works on a desktop.)
Probably not. The density of the core decreases, but the density remains pretty high. (The pressure is high enough to liquify hydrogen at a reasonable temperature.) And while the core has now disappeared, there is a larger volume of denser liquid.
Besides, what you see when you look at a gas giant is the atmosphere. That's not going to change measurably.
I think it quite possible that the people in charge will not accept that the intelligent robots have any feelings. Read some Victorians descriptions of how the non-white races had lesser feelings, and the feelings of robots are pretty much guaranteed to not be commensurate with ours. Not necessarily lesser, but definitely different.
I think you are correct, and that she did say that.
This is one place where Asimov got robots wrong. They won't work that way. Mind you, it doesn't help things all that much, because it's just the motivation that's wrong, not the result. If there isn't a constraint that you mustn't kill people, the robot will do it, but not because it's angry, just because it's the easiest way to solve the problem. (Well, of course this would mean that it wouldn't necessarily kill the person that gave the order, depending on what the order was. But it would be like a roving band saw without a protector around it's blade.) It may even be quite pleased to have a problem to solve. This doesn't help, because it will still take the "best" approach to solving the problem, where best is defined by the constraints given by it's operating program.
P.S.: I'd expect the robot to be so designed that it enjoyed solving problems and working out solutions, and then implementing them. But you need to be very careful about what it considers an acceptable solution.
Sorry, but when robots *DO* become intelligent they will be problem solving devices operating within constraints. When given a problem, they will attempt to solve it within those constraints. If you state the constraints incorrectly, then that's too bad. They won't even know that the solution they came up with is "cheating" instead of being creative. *You* know your intentions, but they can't read your mind, so they aren't intentionally "breaking your intentions".
That said, they will only act within their constraints, no matter how high or low level those constraints might be. And they *will* push things to the edges of those constraints. So the constraints should define your intentions and goals, not rules for specific situations. Even "be kind to people" is quite difficult, as both "kind" and "people" are very difficult to define. (I haven't yet encountered a good definition of either, that even humans could generally agree on.) This is especially true as the design needs to be built before the robot experiences the world, so you can't create sets of entities/event and say these and things sufficiently like them are kindness/people. And if you do, what happens if the robot has it's sensory apparatus upgraded? Or is moved into another body that senses things differently?
As a social animal, it is NECESSARY that we "outsource" some of our decisions to a common-to-our-group rule-system. Every social animal does it, whether wasps, wolves, or humans. Humans are unique in the detailed amount of decisions that they outsource, and in the variance among groups in what the rules are.
In my opinion we (currently in the US) have too many rules, and they aren't a fair trade off. I don't think this is an evolutionarily stable situation. But that gets resolved over the long term (probably violently). There is still the requirement for a group-common rule system. Periods where there are significant conflicts in the rule systems are quite unpleasant to live through (if you manage to do so). But even in those periods you have everyone adhering to external rule systems. And the conflicts are usually over relatively small details. (Not necessarily unimportant or insignificant, but small, as in representing minor differences in premisses.)
You misunderstand them.
The words were never intended to be the laws. They were intended to be an English translation of the basic principles. The actual implementations were intended to be balancing acts, and only violations of the first law even contained the potential of destroying the robot's mind. Even there some tradeoffs were allowed. Some damages were considered more important than others, etc. (Read "Runaround" again and think about it.)
I'll agree that the words, as stated, were not implementable. But that was, kind of, he point of the stories. (Read "Liar" and understand the importance that ignorance assumes in stabilizing the robots minds.)
This doesn't mean that they are a good set of rules. But the importance of safety measures built in *IS* correct.
He did claim that they were a fundamental feature of the programs designed to operate the robot minds. And, yes, he said that modifying the program to be stable in the absence of those laws would be a herculean effort. But then so was writing the program in the first place.
There wasn't assumed to be anything in the way of a natural law that made it impossible, but that you'd almost need to start the design from scratch. And it represented years (or, depending on the story, decades) of work.
Think of trying to convert a Linux OS into a MSWind OS. There's no natural law that says you can't, but it's no simple job. The Wine project is still not nearly perfect, and it's been over a decade.
Now I'm thinking about it as a programmer. Asimov, however, was a biologist, primarily a biochemist. So his conception would probably be more like "You've built and artificial life form that's a bird, and you want he next variant to be a mammal? But reasonable! If you try it will quickly die!." Close enough in general outline, but differing a lot in detail.
It's qutie reasonable to get worked up about violating those laws. That's like running high voltage wires without insulation. Even *with* insulation you get into lots of trouble if you aren't careful, but without it...
(I'm not really talking about transmission lines. I don't know whether those are insulated, or just kept separated. I'm thinking about inside electronic devices, like CRTs.)
It you'll note on really old wiring, where the insulation wasn't that good (cloth wrapped around the wires.) the wiring style *required* the wires to be run along separated channels. Not double jacketed as one sees with plastic insulation. Violating that kind of basic safety measure is worth getting worked up about.
Similarly, violating the basic safety rules WRT robots is also worth getting worked up about. It's not *really* dangerous (except for social consequences) today, but the day after tomorrow, well, if you violate the basic safety rules there may not be any human around to see it.
Now given how self destructive humans are, I can see reasonable arguments that this is a good outcome, but as a human it's not one I feel we should work towards.