And read your employment contract, or consult a lawyer. Some companies have been claiming that any programming done while you are an employee belongs to them. Be sure this doesn't apply to you.
I don't think this could be called a vaccine. It's intent is not to stimulate the immune system, but rather to supplement it. And the cells generating the supplementation are muscle cells.
You are presuming that they are blunders rather than something more sinister. This may be a correct presumption, but should not be presumed so. The actual fact is, we don't know why they are doing this. If it's a mistake, someone else will take advantage of it, if it's intentional, they will, perhaps by selling the information, perhaps more directly.
So the reason is less important than the fact. But it's not unimportant, so it shouldn't be presumed. While there's insufficient information it should remain undecided.
That said, yes, there are reasons why FOSS is generally more secure. One of them is the expectation of errors being revealed. We all want to avoid embarrassment. Closed source software doesn't usually need to worry about that.
Unfortunately, this sounds like basic flaws in simple designs. Either the products are incredibly shoddy (possible when everything is being done as fast as possible as cheaply as possible), or the companies intend to take advantage of the errors which were not expected to be made public. Perhaps one of the law suits that have been launched over Carrier IQ will provide information to decide which.
IIRC Apple *installed* Carrier IQ, but it wasn't activated unless you enabled "send debugging information". Something like that. I don't have an IPhone, and I can't quite remember the precise activation mechanism.
Now of course this doesn't mean that they might not activate it in the future via some "security upgrade". That kind of behavior is what turned me off to Apple. But *currently* they appear to be using it in a reasonable manner.
That's great. Until you need to support it. Then you don't know what the person you're talking to is complaining about, because they've so customized the GUI that you don't have common language to describe it. So if it's easy to reset to defaults, then I agree that allowing customization is reasonable. If not, not. And in Squeak if you want to make it resettable to defaults, you need a chunk of code that can re-write the code that draws the GUI. So it's doable, but it's a major pain in the ass.
N.B.: This may not still be true. In Croquette Smalltalk when I asked I was told that it was not true. It's not a property of the language per se, but of the user interface.
6 times faster than the interpreter isn't all that great when the interpreter is 30 times slower than a competing language. It *is* (reported to be) a lot faster than it was, but "it" is a specific implementation that doesn't appear to have all that large a community. The Smalltalk community was already small, and when it splits into a bunch of pieces...I have to wonder how viable each separate piece is.
There's Squeak, Pharo, Croquette, CogVM, etc. I know that these pieces all work together, but that's lots of separate dependencies. Now I don't need Croquette, because I'm not interested in high-bandwidth communication over the internet...or do I? I want to run several processes on multiple cores of the same machine, so maybe I do need it. But only one reasonably uses the graphic controller, and Croquette looks like it assigns a graphic controller to each process.
And if I'm looking for documentation, where do I find how virtual memory is handled, and how I deal with a really large data space that only needs a part of it to be RAM resident at any one time? Has ANYONE documented that? Or does it just crash?
If there's a single project, then there's some place I can ask these questions. When there's a thicket of projects, I can't tell where to ask who.
So while it's really nice to hear that there's a project that is speeding up Squeak (and renaming it to avoid conflict), it's also a bit disconcerting that it's a separate project.
P.S.: At one point the Squeak library contained the start of a B+Tree class. When I last looked it didn't write things out to disk, but just held them in RAM. Did this ever get finished. (As in saving dirty buffers to a disk file.) If it did that would make Squeak much more attractive. I don't want a SQL relational database, I just want a decent B+Tree class. Nobody seems to be delivering that any more. (In many places it's available as a component of something else, but even BerkeleyDB (the old SleepyCatDB) doesn't offer a simple B+Tree anymore.)
I did program in HyperCard, back when it was installed by default with the system. I never used it much on the LC II, and stopped using it before "HyperCard Player" was released. Did they eventually add color? Perhaps that's what killed it. It was already a very slow system.
P.S.: Read what I wrote again. Python makes Java look fast because it is slower than Java when both languages are doing the same thing. (I could have continued with Java makes C look fast, but that is disputed, for reasons that I don't understand. C is in my experience LOTS faster than Java. And it's not just startup time. But many Java proponents claim that despite all evidence Java is as fast as C, so I stopped before there.)
Squeak is a particular dialect of Smalltalk. It's very flexible and truly general purpose (outside of that GUI limitation I mentioned), but it's quite slow. Just not as slow as HyperCard.
N.B.: Of course ANY ranking of languages by speed is making assumptions about implementation and environment. There are environments where Forth is the only reasonable choice. They just aren't very common. (If you go back to that radio-telescope that Forth was invented to control, there still isn't any other option but assembler. The compilers and interpreters and associated libraries won't fit.)
Wrong. Google specifically chose to release Android under a license that allowed the carriers to close it. If they had chosen GPL they probably wouldn't be in court against Oracle right now. And Oracle had made representations to Google before Android was released.
So Google chose this route with considerable in the way of reasons not to do so. The safe way would have been for them to use GPL licensing. They didn't. So there is some reason. One may speculate as to what that reason is, but that such a reason exists if obvious.
Actually, thanks to a Supreme Court ruling in the late 1960's or early 1970's, they'll be worse off than anyone else. Because it's impossible to legally have residence requirements for providing local assistance. That ruling killed off cities supporting residents that were having trouble, because if a city became known as generous, it would get swamped by people from all over. Currently even state level programs are under a lot of pressure already. Expect it to only get worse. Chintzy states and cities experience people they've outcast leaving them, which must distress them greatly, and generous locales have to support everyone in the country.
As has been said, it's a race to the bottom. Only federal level programs are potentially exempt, and that's the exact opposite of the way it should be done.
We are further along that path than you imagine. Already there is automation replacing some uses of paralegals and junior lawyers. It didn't take Watson, if just required the court records being digitized. And some key word & phrase recognition software that had already been developed for other purposes. At the moment, of course, it's still quite limited. IIUC it's limited to specialized searches for prior art in patent databases. But that's just the first model.
Re-educate themselves? They're already in debt for college tuition to get a legal degree, for a job that's disappeared, and you're recommending that they try to get another college loan, and postpone payments on the current one?
We *ALREADY* need a new social contract. We still have a bit of time to get one before things turn violent, but I think it's easily measured in years rather than decades.
That may be the case now, but it didn't used to be the case. When I grew up there were independent hardware stores and grocery stores in each small town. Locally owned and operated. Often several. And *one* Supermarket for things that weren't called for all that much. A few people (the ones living near by) shopped there for everything, but most people only went there for rare needs.
If you go back a bit further there wasn't any Supermarket, and rare needs were met by placing an order and picking it up when it got filled. For some water pump parts we had to drive an extra 40 miles to a town that had a larger and specialized hardware store.
This distribution of stores was killed off partially by improved transportation, partially by zoning laws, partially by insurance, and partially by tax changes. Note the heavy government influence. I can't really say that the new way is any more convenient or any cheaper in any way, for the things I want to buy. Now I live in a city, and There are lots of chain stores around. They're a bit cheaper than the smaller stores, and they have a larger variety of merchandise. But they aren't "better" in any general sense. The smaller stores aren't chains, so the taxes they pay stay in the community. The smaller stores have most of what I want to buy. In fact, we do almost all our shopping at a store that has two branches. When my wife wants something special, she has to mail order it, because the chain hardware stores don't carry anything unusual, and won't order it. (There *aren't* any hardware stores that aren't chain stores.)
So AFAIKT the changes were driven by the government, and they provide *NO* net advantage to the customer. Wallmart may be cheaper, but what they sell is basically junk, even when it's new. (And not even good junk. My wife orders lots of what I would call junk mail order, but it's both cheaper than Walmart, and it's what she wants, which Walmart doesn't provide.)
So what was said is true about cities as well as towns. The big businesses have prospered because of governmental interference, and they provide no net advantage to the citizens or to the local economy. Often they make things much worse. But they *do* tend to destroy their competitors, leaving people with no quality choice.
As an example of that., Barnes and Nobel moved a bookstore into town. It stayed open a month longer than needed to drive our local bookstore out of business. Then they closed the store and told us to go to one of their other stores around 10-15 miles further away. I've heard good things about the Nook, but I really hate to give them any business, so I haven't bought one. But there's no way at all that this has improved my life. And it's damaged the city tax base. (The local bookstore was a large one, and it's still empty.) I used to walk to our local book store. The redirection involved driving on a freeway. There isn't even decent bus access.
Do I think corporations need to be regulated? Damn straight. If they're going to be counted as people, start sending them to jail for negligent manslaughter when someone dies during the construction of a building. (Sometimes admittedly negligent manslaughter isn't a severe enough crime to charge them with, e.g. when they intentionally skimp on adhering to safety regulations. That's not negligent, that's intentionally reckless behavior. Probably not premeditated murder, as they don't usually have anyone in particular in mind, but analogous to firing a pistol into a crowded room without aiming. I don't know what they call that in criminal law.)
Now of course, that's silly. You can't send a corporation to jail, because it doesn't have any physical existence. It's an infosystem. But that just means that a corporation isn't a person. So what you should do is send their executive managers to jail. And possibly the board of directors. And any stockholder who holds more than 10-20% of the corporate stock. Because just because corporations aren't people doesn't mean that the
Yes, adding features can make a successful program a failure, when the success of the program is based on its simplicity. Also important, however, was that HyperCard came with the OS installed on every Mac. This is not true of any proposed competitor except HTML+Javascript, it's current closest replacement. (And frankly, that "current closest replacement" is shit when attempting to address the set of problems that HyperCard was designed to be optimal for.)
I don't know about LiveCode, but SuperCard was not an adequate replacement for HyperCard. It was more complex, harder to use, the version I used was buggier. and it wasn't available with the computer.
Python is a closer replacement. In fact there's something called PythonCard, though the last time I tried it it was pretty buggy itself. And it doesn't come with the system. And, IIRC, it requires programming in Python to use. It also seems sort of dead...as in not under development for Python3 (or for any changes in the last few years). But it apparently still works, if what you want is what it does.
Actually, Squeak with e-toys is a closer replacement, but again there's a steeper learning curve. (Not exactly. But you need someone to set it up for you and to talk you through it.) Or Scratch (from MIT).
HTML + Javascript can probably do most things that HyperCard could. Note that "most". Both were designed to have difficulty in accessing local storage. Intentionally. For this and other reasons HyperCard was better than them at some tasks. And it was a lot simpler, and made debugging easier.
So, while you can do anything with them that you could do with HyperCard (though you may need an external application), they are a lot more complex to use. And to learn. They don't serve the same purpose. (No surprise, that isn't their goal.)
HyperCard was, indeed, quite limited. But this didn't mean it wasn't quite useful. In fact, it's utility was nearly dependent on its limitations. Because its interface was simple, it was easy to do things quickly. And it encouraged debugging.
If you try to push it beyond what it's designed to do, you run into problems. But this is true of ANY language, including C and Java. That the limitations are different just means that they are better for different problems. Did you know I've quite given up writing code in assembler? It's theoretically capable of handling anything, but if you push it into a project that's supposed to be large and shared, it doesn't work well. (Actually, the reason I gave it up was that processors kept changing their instruction sets, so I kept having to rewrite code. But the other was another good reason. And processors haven't been changing their instruction sets nearly as often in the last decade or so.)
You don't want to have just one tool in your toolbox. You want to be able to choose the right tool for the right job. For some jobs, HyperCard was the right tool. There is currently no decent replacement. (Scratch and Squeak come the closest of anything I've encountered, and they don't really handle the same sets of problems.)
Supercard was not an adequate replacement for HyperCard. It increased the level of complexity to where it was competing with other things, like Javascript, Python, Smalltalk. And it was only better than any of those in that it was more like HyperCard.
HyperCard was useful for getting things done *QUICKLY*. That was pretty much it. It got extended in lots of ways, but every extension took away from it's core value.
Additionally, HyperCard was valuable BECAUSE you could count on every Mac having a copy. When this stopped being true, it immediately lost a lot of its value. And that value can't be replaced by anything where you can't depend on being able to run an arbitrary application on any computer it happens to land on. Javascript has pretty much taken this position, but it has severe limitations wrt local storage of information. (Cookies just aren't sufficient.) If Javascript were merged with, say, SQLite... (And have the interface handle the SQL...no user access. This is just a way to persist information.)... then you'd have a reasonable successor to HyperCard. But note that this would need to be a part of the Javascript standard, because part of what makes this work is having it available on every machine. (P.S.: This might be a *VERY* bad idea, as I imagine that it could be the basis of a reasonably powerful botnet. HyperCard didn't have networking, so it avoided this problem.)
Interesting use of the word "best". I've never considered it synonymous with "most popular" or "easiest to sell", though, of course, for some purposes it is.
I *don't* think that "locked in" is best...except for certain specific purposes. Common purposes, but still fairly specific. When I design a GUI I want limits around how the end-user can customize it...unless it really easy to reset it to the default values. This is the real defect with Smalltalk designs (well, Squeak, anyway). HTML doesn't have this problem.
For me the main problem with HyperCard was that it was too SLOW!!!! It made Squeak look fast, and Squeak makes Ruby look fast, and Ruby makes Python look fast, and Python makes Java look fast. So HyperCard was REALLY slow once you got more than a few things going on at once. That said, it was very useful. Things that would take far too long to program in Python could be done in reasonable amounts of time. And if you need the application done by an hour before now next week, that's important. Especially as you need to sandwich that development into the rest of what you are doing, which isn't getting reduced. The competitors that started getting released never understood that properly. They added more bells and whistles (color graphics, multiple card stacks, etc.) but the new capabilities got in the way of rapid development. Squeak was better than most of them, but it was deficient in locking down the appearance of the windows, unless you REALLY wanted to lock it down (as in, the end-user can't change it, but neither can you). So you need to keep multiple copies of the source code around (each one a full Squeak image...not small). This just didn't hit the same sweet spot.
OTOH, it's hard to see how HyperCard could have been enhanced with, e.g., color, without loosing it's simplicity. (It would always have been slow, but faster processors would have ameliorated the problem.)
All that said, I was never a big fan of HyperCard. It was really useful for some specific purposes, but they were rather limited. Still, it was a nice tool to have in the toolbox.
P.S.: Actually, color would be pretty easy as long as the images were only altered by an external application. But not if the application is allowed to manipulate the image other than scaling, rotation, or moving.
It may have been included, but it wasn't operating on the system I saw. Could have been either memory or software constraints, or maybe the sysadmin just didn't like the overhead. Whatever, I didn't see it.
Yeah, and I wouldn't touch it until around 1.4. (Don't remember precisely.) Of course, I wasn't tracking it frequently. I don't think I saw an version active before around 1.3.?) And the first time I saw it, it didn't even have X Window. But the earliest version I saw really wasn't usable except as a development platform.
This may well be similar. If the developer groups keeps working at it,it may turn into something very important. But right now it's not clear what it even promises.
Yeah, there are lots of silly warning labels. And they wouldn't have helped in this case. This is more a problem of "The coffee was too hot, and the containers were defective by design". What she asked for was fair. I'm not sure that what the jury awarded was fair, but it got reduced anyway. She should probably have been awarded twice or three times her expenses (including time), because since McDonalds refused to pay reasonable damages without a fight she was put to considerable extra time and expense and danger of not having her medical expenses covered.
Coffee should NEVER be served so hot that it removes your skin. Never. Nor should any other beverage. And one should not reasonably be expected that it would be so served. I don't really care what the manufacturers of the equipment say. If McDonalds relied on them as experts, it should sue them. (That said, I'm not quite sure just how hot 185 degrees is. I is, however, only 5 degrees cooler than the temperature at which one scalds milk. And that's clearly too hot to be served.)
Wisely from their point of view isn't necessarily wisely from mine. So far I haven't bothered to get a smart phone, and have seen no real reason to want to.
OTOH, I've nothing really against Dalvik, but I wouldn't want to comit to it until after Google wins the suit that Oracle has pressed against it. Even then Java's really *not* my favorite language. I prefer Python or D.
*Today's* Robots and software cannot sufficiently deal with malicious human actors.
There are lots of jobs that today’s robots and software can't handle. That doesn't tell you much about tomorrow's. Or the day after tomorrow.
If society doesn't adapt to this, things will get brutal. You want a "Butlerian Jihad"? This is the way to get it. The Luddites weren't being unreasonable, they were fighting to keep the jobs that their survival depended upon. Popular history tells the story the bosses used, but the facts are there if you dig them up.
Did you ever hear about the riots caused by calendar reform when the Gregorian calendar replaced the Julian calendar in Britain? Guess what those were about. "Give us back our 21 days!" meant that the landlords charged everyone nearly an extra months rent. THAT's what those riots were about. It wasn't people being silly and superstitious, as I was taught in grade school. Whenever you hear of mobs of upset people being "silly and superstious" throughout history, if you check carefully you will usually find that the story has been corrupted, and they were protesting a vile injustice being committed upon them. (They didn't always pick the right target. Scapegoating is common. But they [nearly?] always have an actual injustice that they are protesting.)
This business of requiring that everyone have a job when the decent jobs are disappearing is a catastrophe waiting to happen.
The elite class you fear already exists, and writes many of the laws. My proposal would make the legislators less beholden to them, so that they didn't feel compelled (for one reason or another or bribery in fact if not in law) to do them favors.
Slashdot Mirror
And read your employment contract, or consult a lawyer. Some companies have been claiming that any programming done while you are an employee belongs to them. Be sure this doesn't apply to you.
If the hourly wage is written into the law, what happens as inflation occurs?
I don't think this could be called a vaccine. It's intent is not to stimulate the immune system, but rather to supplement it. And the cells generating the supplementation are muscle cells.
You are presuming that they are blunders rather than something more sinister. This may be a correct presumption, but should not be presumed so. The actual fact is, we don't know why they are doing this. If it's a mistake, someone else will take advantage of it, if it's intentional, they will, perhaps by selling the information, perhaps more directly.
So the reason is less important than the fact. But it's not unimportant, so it shouldn't be presumed. While there's insufficient information it should remain undecided.
That said, yes, there are reasons why FOSS is generally more secure. One of them is the expectation of errors being revealed. We all want to avoid embarrassment. Closed source software doesn't usually need to worry about that.
Unfortunately, this sounds like basic flaws in simple designs. Either the products are incredibly shoddy (possible when everything is being done as fast as possible as cheaply as possible), or the companies intend to take advantage of the errors which were not expected to be made public. Perhaps one of the law suits that have been launched over Carrier IQ will provide information to decide which.
IIRC Apple *installed* Carrier IQ, but it wasn't activated unless you enabled "send debugging information". Something like that. I don't have an IPhone, and I can't quite remember the precise activation mechanism.
Now of course this doesn't mean that they might not activate it in the future via some "security upgrade". That kind of behavior is what turned me off to Apple. But *currently* they appear to be using it in a reasonable manner.
That's great. Until you need to support it. Then you don't know what the person you're talking to is complaining about, because they've so customized the GUI that you don't have common language to describe it. So if it's easy to reset to defaults, then I agree that allowing customization is reasonable. If not, not. And in Squeak if you want to make it resettable to defaults, you need a chunk of code that can re-write the code that draws the GUI. So it's doable, but it's a major pain in the ass.
N.B.: This may not still be true. In Croquette Smalltalk when I asked I was told that it was not true. It's not a property of the language per se, but of the user interface.
6 times faster than the interpreter isn't all that great when the interpreter is 30 times slower than a competing language. It *is* (reported to be) a lot faster than it was, but "it" is a specific implementation that doesn't appear to have all that large a community. The Smalltalk community was already small, and when it splits into a bunch of pieces...I have to wonder how viable each separate piece is.
There's Squeak, Pharo, Croquette, CogVM, etc. I know that these pieces all work together, but that's lots of separate dependencies. Now I don't need Croquette, because I'm not interested in high-bandwidth communication over the internet...or do I? I want to run several processes on multiple cores of the same machine, so maybe I do need it. But only one reasonably uses the graphic controller, and Croquette looks like it assigns a graphic controller to each process.
And if I'm looking for documentation, where do I find how virtual memory is handled, and how I deal with a really large data space that only needs a part of it to be RAM resident at any one time? Has ANYONE documented that? Or does it just crash?
If there's a single project, then there's some place I can ask these questions. When there's a thicket of projects, I can't tell where to ask who.
So while it's really nice to hear that there's a project that is speeding up Squeak (and renaming it to avoid conflict), it's also a bit disconcerting that it's a separate project.
P.S.: At one point the Squeak library contained the start of a B+Tree class. When I last looked it didn't write things out to disk, but just held them in RAM. Did this ever get finished. (As in saving dirty buffers to a disk file.) If it did that would make Squeak much more attractive. I don't want a SQL relational database, I just want a decent B+Tree class. Nobody seems to be delivering that any more. (In many places it's available as a component of something else, but even BerkeleyDB (the old SleepyCatDB) doesn't offer a simple B+Tree anymore.)
I did program in HyperCard, back when it was installed by default with the system. I never used it much on the LC II, and stopped using it before "HyperCard Player" was released. Did they eventually add color? Perhaps that's what killed it. It was already a very slow system.
P.S.: Read what I wrote again. Python makes Java look fast because it is slower than Java when both languages are doing the same thing. (I could have continued with Java makes C look fast, but that is disputed, for reasons that I don't understand. C is in my experience LOTS faster than Java. And it's not just startup time. But many Java proponents claim that despite all evidence Java is as fast as C, so I stopped before there.)
Squeak is a particular dialect of Smalltalk. It's very flexible and truly general purpose (outside of that GUI limitation I mentioned), but it's quite slow. Just not as slow as HyperCard.
N.B.: Of course ANY ranking of languages by speed is making assumptions about implementation and environment. There are environments where Forth is the only reasonable choice. They just aren't very common. (If you go back to that radio-telescope that Forth was invented to control, there still isn't any other option but assembler. The compilers and interpreters and associated libraries won't fit.)
Wrong. Google specifically chose to release Android under a license that allowed the carriers to close it. If they had chosen GPL they probably wouldn't be in court against Oracle right now. And Oracle had made representations to Google before Android was released.
So Google chose this route with considerable in the way of reasons not to do so. The safe way would have been for them to use GPL licensing. They didn't. So there is some reason. One may speculate as to what that reason is, but that such a reason exists if obvious.
Considering how those laws are enforced, funny was an appropriate moderation. With bitters and a slice of wry.
Actually, thanks to a Supreme Court ruling in the late 1960's or early 1970's, they'll be worse off than anyone else. Because it's impossible to legally have residence requirements for providing local assistance. That ruling killed off cities supporting residents that were having trouble, because if a city became known as generous, it would get swamped by people from all over. Currently even state level programs are under a lot of pressure already. Expect it to only get worse. Chintzy states and cities experience people they've outcast leaving them, which must distress them greatly, and generous locales have to support everyone in the country.
As has been said, it's a race to the bottom. Only federal level programs are potentially exempt, and that's the exact opposite of the way it should be done.
We are further along that path than you imagine. Already there is automation replacing some uses of paralegals and junior lawyers. It didn't take Watson, if just required the court records being digitized. And some key word & phrase recognition software that had already been developed for other purposes. At the moment, of course, it's still quite limited. IIUC it's limited to specialized searches for prior art in patent databases. But that's just the first model.
Re-educate themselves? They're already in debt for college tuition to get a legal degree, for a job that's disappeared, and you're recommending that they try to get another college loan, and postpone payments on the current one?
We *ALREADY* need a new social contract. We still have a bit of time to get one before things turn violent, but I think it's easily measured in years rather than decades.
That may be the case now, but it didn't used to be the case. When I grew up there were independent hardware stores and grocery stores in each small town. Locally owned and operated. Often several. And *one* Supermarket for things that weren't called for all that much. A few people (the ones living near by) shopped there for everything, but most people only went there for rare needs.
If you go back a bit further there wasn't any Supermarket, and rare needs were met by placing an order and picking it up when it got filled. For some water pump parts we had to drive an extra 40 miles to a town that had a larger and specialized hardware store.
This distribution of stores was killed off partially by improved transportation, partially by zoning laws, partially by insurance, and partially by tax changes. Note the heavy government influence. I can't really say that the new way is any more convenient or any cheaper in any way, for the things I want to buy. Now I live in a city, and There are lots of chain stores around. They're a bit cheaper than the smaller stores, and they have a larger variety of merchandise. But they aren't "better" in any general sense. The smaller stores aren't chains, so the taxes they pay stay in the community. The smaller stores have most of what I want to buy. In fact, we do almost all our shopping at a store that has two branches. When my wife wants something special, she has to mail order it, because the chain hardware stores don't carry anything unusual, and won't order it. (There *aren't* any hardware stores that aren't chain stores.)
So AFAIKT the changes were driven by the government, and they provide *NO* net advantage to the customer. Wallmart may be cheaper, but what they sell is basically junk, even when it's new. (And not even good junk. My wife orders lots of what I would call junk mail order, but it's both cheaper than Walmart, and it's what she wants, which Walmart doesn't provide.)
So what was said is true about cities as well as towns. The big businesses have prospered because of governmental interference, and they provide no net advantage to the citizens or to the local economy. Often they make things much worse. But they *do* tend to destroy their competitors, leaving people with no quality choice.
As an example of that., Barnes and Nobel moved a bookstore into town. It stayed open a month longer than needed to drive our local bookstore out of business. Then they closed the store and told us to go to one of their other stores around 10-15 miles further away. I've heard good things about the Nook, but I really hate to give them any business, so I haven't bought one. But there's no way at all that this has improved my life. And it's damaged the city tax base. (The local bookstore was a large one, and it's still empty.) I used to walk to our local book store. The redirection involved driving on a freeway. There isn't even decent bus access.
Do I think corporations need to be regulated? Damn straight. If they're going to be counted as people, start sending them to jail for negligent manslaughter when someone dies during the construction of a building. (Sometimes admittedly negligent manslaughter isn't a severe enough crime to charge them with, e.g. when they intentionally skimp on adhering to safety regulations. That's not negligent, that's intentionally reckless behavior. Probably not premeditated murder, as they don't usually have anyone in particular in mind, but analogous to firing a pistol into a crowded room without aiming. I don't know what they call that in criminal law.)
Now of course, that's silly. You can't send a corporation to jail, because it doesn't have any physical existence. It's an infosystem. But that just means that a corporation isn't a person. So what you should do is send their executive managers to jail. And possibly the board of directors. And any stockholder who holds more than 10-20% of the corporate stock. Because just because corporations aren't people doesn't mean that the
Yes, adding features can make a successful program a failure, when the success of the program is based on its simplicity. Also important, however, was that HyperCard came with the OS installed on every Mac. This is not true of any proposed competitor except HTML+Javascript, it's current closest replacement. (And frankly, that "current closest replacement" is shit when attempting to address the set of problems that HyperCard was designed to be optimal for.)
I don't know about LiveCode, but SuperCard was not an adequate replacement for HyperCard. It was more complex, harder to use, the version I used was buggier. and it wasn't available with the computer.
Python is a closer replacement. In fact there's something called PythonCard, though the last time I tried it it was pretty buggy itself. And it doesn't come with the system. And, IIRC, it requires programming in Python to use. It also seems sort of dead...as in not under development for Python3 (or for any changes in the last few years). But it apparently still works, if what you want is what it does.
Actually, Squeak with e-toys is a closer replacement, but again there's a steeper learning curve. (Not exactly. But you need someone to set it up for you and to talk you through it.) Or Scratch (from MIT).
HTML + Javascript can probably do most things that HyperCard could. Note that "most". Both were designed to have difficulty in accessing local storage. Intentionally. For this and other reasons HyperCard was better than them at some tasks. And it was a lot simpler, and made debugging easier.
So, while you can do anything with them that you could do with HyperCard (though you may need an external application), they are a lot more complex to use. And to learn. They don't serve the same purpose. (No surprise, that isn't their goal.)
HyperCard was, indeed, quite limited. But this didn't mean it wasn't quite useful. In fact, it's utility was nearly dependent on its limitations. Because its interface was simple, it was easy to do things quickly. And it encouraged debugging.
If you try to push it beyond what it's designed to do, you run into problems. But this is true of ANY language, including C and Java. That the limitations are different just means that they are better for different problems. Did you know I've quite given up writing code in assembler? It's theoretically capable of handling anything, but if you push it into a project that's supposed to be large and shared, it doesn't work well. (Actually, the reason I gave it up was that processors kept changing their instruction sets, so I kept having to rewrite code. But the other was another good reason. And processors haven't been changing their instruction sets nearly as often in the last decade or so.)
You don't want to have just one tool in your toolbox. You want to be able to choose the right tool for the right job. For some jobs, HyperCard was the right tool. There is currently no decent replacement. (Scratch and Squeak come the closest of anything I've encountered, and they don't really handle the same sets of problems.)
Supercard was not an adequate replacement for HyperCard. It increased the level of complexity to where it was competing with other things, like Javascript, Python, Smalltalk. And it was only better than any of those in that it was more like HyperCard.
HyperCard was useful for getting things done *QUICKLY*. That was pretty much it. It got extended in lots of ways, but every extension took away from it's core value.
Additionally, HyperCard was valuable BECAUSE you could count on every Mac having a copy. When this stopped being true, it immediately lost a lot of its value. And that value can't be replaced by anything where you can't depend on being able to run an arbitrary application on any computer it happens to land on. Javascript has pretty much taken this position, but it has severe limitations wrt local storage of information. (Cookies just aren't sufficient.) If Javascript were merged with, say, SQLite... (And have the interface handle the SQL...no user access. This is just a way to persist information.) ... then you'd have a reasonable successor to HyperCard. But note that this would need to be a part of the Javascript standard, because part of what makes this work is having it available on every machine. (P.S.: This might be a *VERY* bad idea, as I imagine that it could be the basis of a reasonably powerful botnet. HyperCard didn't have networking, so it avoided this problem.)
Interesting use of the word "best". I've never considered it synonymous with "most popular" or "easiest to sell", though, of course, for some purposes it is.
I *don't* think that "locked in" is best...except for certain specific purposes. Common purposes, but still fairly specific. When I design a GUI I want limits around how the end-user can customize it...unless it really easy to reset it to the default values. This is the real defect with Smalltalk designs (well, Squeak, anyway). HTML doesn't have this problem.
For me the main problem with HyperCard was that it was too SLOW!!!! It made Squeak look fast, and Squeak makes Ruby look fast, and Ruby makes Python look fast, and Python makes Java look fast. So HyperCard was REALLY slow once you got more than a few things going on at once. That said, it was very useful. Things that would take far too long to program in Python could be done in reasonable amounts of time. And if you need the application done by an hour before now next week, that's important. Especially as you need to sandwich that development into the rest of what you are doing, which isn't getting reduced. The competitors that started getting released never understood that properly. They added more bells and whistles (color graphics, multiple card stacks, etc.) but the new capabilities got in the way of rapid development. Squeak was better than most of them, but it was deficient in locking down the appearance of the windows, unless you REALLY wanted to lock it down (as in, the end-user can't change it, but neither can you). So you need to keep multiple copies of the source code around (each one a full Squeak image...not small). This just didn't hit the same sweet spot.
OTOH, it's hard to see how HyperCard could have been enhanced with, e.g., color, without loosing it's simplicity. (It would always have been slow, but faster processors would have ameliorated the problem.)
All that said, I was never a big fan of HyperCard. It was really useful for some specific purposes, but they were rather limited. Still, it was a nice tool to have in the toolbox.
P.S.: Actually, color would be pretty easy as long as the images were only altered by an external application. But not if the application is allowed to manipulate the image other than scaling, rotation, or moving.
It may have been included, but it wasn't operating on the system I saw. Could have been either memory or software constraints, or maybe the sysadmin just didn't like the overhead. Whatever, I didn't see it.
Yeah, and I wouldn't touch it until around 1.4. (Don't remember precisely.) Of course, I wasn't tracking it frequently. I don't think I saw an version active before around 1.3.?) And the first time I saw it, it didn't even have X Window. But the earliest version I saw really wasn't usable except as a development platform.
This may well be similar. If the developer groups keeps working at it,it may turn into something very important. But right now it's not clear what it even promises.
Yeah, there are lots of silly warning labels. And they wouldn't have helped in this case. This is more a problem of "The coffee was too hot, and the containers were defective by design". What she asked for was fair. I'm not sure that what the jury awarded was fair, but it got reduced anyway. She should probably have been awarded twice or three times her expenses (including time), because since McDonalds refused to pay reasonable damages without a fight she was put to considerable extra time and expense and danger of not having her medical expenses covered.
Coffee should NEVER be served so hot that it removes your skin. Never. Nor should any other beverage. And one should not reasonably be expected that it would be so served. I don't really care what the manufacturers of the equipment say. If McDonalds relied on them as experts, it should sue them. (That said, I'm not quite sure just how hot 185 degrees is. I is, however, only 5 degrees cooler than the temperature at which one scalds milk. And that's clearly too hot to be served.)
Wisely from their point of view isn't necessarily wisely from mine. So far I haven't bothered to get a smart phone, and have seen no real reason to want to.
OTOH, I've nothing really against Dalvik, but I wouldn't want to comit to it until after Google wins the suit that Oracle has pressed against it. Even then Java's really *not* my favorite language. I prefer Python or D.
*Today's* Robots and software cannot sufficiently deal with malicious human actors.
There are lots of jobs that today’s robots and software can't handle. That doesn't tell you much about tomorrow's. Or the day after tomorrow.
If society doesn't adapt to this, things will get brutal. You want a "Butlerian Jihad"? This is the way to get it. The Luddites weren't being unreasonable, they were fighting to keep the jobs that their survival depended upon. Popular history tells the story the bosses used, but the facts are there if you dig them up.
Did you ever hear about the riots caused by calendar reform when the Gregorian calendar replaced the Julian calendar in Britain? Guess what those were about. "Give us back our 21 days!" meant that the landlords charged everyone nearly an extra months rent. THAT's what those riots were about. It wasn't people being silly and superstitious, as I was taught in grade school. Whenever you hear of mobs of upset people being "silly and superstious" throughout history, if you check carefully you will usually find that the story has been corrupted, and they were protesting a vile injustice being committed upon them. (They didn't always pick the right target. Scapegoating is common. But they [nearly?] always have an actual injustice that they are protesting.)
This business of requiring that everyone have a job when the decent jobs are disappearing is a catastrophe waiting to happen.
The elite class you fear already exists, and writes many of the laws. My proposal would make the legislators less beholden to them, so that they didn't feel compelled (for one reason or another or bribery in fact if not in law) to do them favors.