To be honest, though, I have a soft spot for any magazine where like 90% of the articles are printed in some kind of weird star-trek typeface on shiny silver paper......
As unreadable as they try to make it, Wired has nothing on Omni!
While Japanese ATMs for a long time had silly "banker's hours" (this policy has relaxed a great deal in recent years, and there are many 24-hour ATMs now), and don't cater to tourists wanting to use their credit card, functionally they've long been pretty sophisticated, way ahead of many other countries. Of course this functionality reflects the Japanese user-base: Japan is still very cash-oriented, with significantly less credit-card usage than many other countries, and the ATMs generally cater to that.
At my Japanese bank's ATMs, I can:
Deposit huge amounts of money, including bills or coins of any denomination, by just dumping it all into the slot, and having the ATM count it for me.
Withdraw huge sums of money (up to like US$10,000 or more) at a normal ATM, or tiny amounts, down to a single yen—yes, if you enter an amount for which there are no bills, it will give you coins too (something I originally found out by accidentally hitting the enter key after typing 1 [yen])...
Transfer money to other people's accounts, at other banks. This is a common way of paying bills. It used to be the case that you could insert a "furikomi card" holding the details of the recipient's account, to avoid the need to re-enter the information—and if you did a transfer to somebody for the first time, the ATM would offer to print you a new furikomi card (on stiff cardboard stock). [newer ATMs just remember recent transfers and let you choose from a list]
Update my [physical] bank-book with recent account transactions (I don't actually use a bank-book, but they're still oddly popular in Japan).
As you might imagine, these ATMs are mechanically very complicated, but they're really quite cool to see in action, they just do all this stuff...
[It's not really true that "In general, you cannot draw money from another bank's ATM." Mostly, you can, but there are certain divisions that can't be crossed, and sometimes this include cards that might be popular amongst foreigners—e.g., my friend had an account at Citibank, which has its own Japanese ATMs, and he couldn't use most other banks' ATMs. I have an account at a Japanese bank, though, and my card works in almost every "bank ATM" I've encountered.]
While I don't necessarily disagree with you, people said the same thing about color. Color film (vs B&W) is a more "real-life" experience.
Color has almost no downside for the audiences though, whereas "3D" is chock full of 'em (and there's little evidence that will change anytime soon).
If they can come up with some 3D tech that doesn't require glasses and doesn't degrade the image quality, maybe people will start to see it as something other than a often annoying gimmick that theaters use as an excuse to charge higher ticket prices...
That's like asking why we use Excel instead of paper spreadsheets. I'm not sure how the answer isn't immediately and painfully obvious to anyone.
I'm sure you love your kindle etc, and for you it may be the best thing, but the comparison with a spreadsheet is silly.
The sort of tasks most people, even "casual" users, use a spreadsheet for are hugely cumbersome to do on paper. So it's "immediately and painfully obvious" that a spreadsheet is better than paper for such use.
The same can't be said of ebooks or electronic note-taking for much typical usage: while having a million books with you might be cool, for many people it's completely pointless most of the time, and a single lightweight paperback is fine (and a good paperback [like Japanese bunko] is often considerably lighter and easier to stick in your pocket). Similarly, note-taking with a pen on paper is absolutely fine for many many uses, and often more convenient than dragging out the laptop or pecking something into your iphone.
The attitude of many towards lisp/scheme was probably a factor, but I think not the major one. As can be seen by the huge number of Emacs extensions, people can deal with lisp, even if it's not everybody's first choice. [...and note that this is true even with Emacs' somewhat inelegant lisp dialect and lack of many modern features; people will put up with a lot of crap if the reward is immediate...]
The real problem, I think, was that Guile never had a particularly usable or attractive implementation—it was kind of bloated and slow, and the interfaces were not particularly good. Lua, by contrast, although it also has its weaknesses, really hit the sweet spot for language embedding; for somebody who just thinks "hmm, I'd like to add an extension language," it's easy to quickly add Lua to your app, it works well, and doesn't add many dependencies (Lua is so small it's perfectly practical to just include the entire Lua source tree with your app). Python is a bit clumsier and resource-intensive, but has tons of tool support, and works well in practice; moreover with its popularity, one can get a big payback from the effort required, with the huge amount of libraries available and widespread user familiarity.
In other words, Guile was a pretty good idea, but the reality never lived up to it.
I've heard that Guile has improved a lot in the last few years, but it may be too late for it to gain much ground with so many good alternatives already in widespread use. If a popular app like Emacs were to start using it (besides the "GNU dogfooding" aspect, Guile would probably be a better fit for Emacs than non-lisp languages), that would help to keep the project going, and maybe it could win over more people in the future, but... I'm not holding my breath.
Hmmm, of course such libraries do exist for Lua, it's just that you'll have to download them separately rather than finding them in the tarball that contains the actual interpreter...
The most common use of Lua is as an "embedded" language—app is written in C, but linked with a Lua interpreter which the app calls to do whatever stuff it wants. I don't think actual sandboxing is all that common—it's common, for instance, for "embedded" Lua code to load various external modules/libraries to do stuff.
[There's no particular reason not to write an entire app in Lua (works fine), it's just that its small size, standalone nature / lack of dependencies, and good C interface make it a very good fit for those times when you want to add an interpreter to your app...]
They can easily interface with the outside (unlike Lua) and the C API works similarly, but python wins due to its more traditional syntax and larger developer base.
Wait, what? How do you come to the conclusion that Lua "can't easily interface with the outside"?
[Lua and Python / Guile are very similar in overall form. Lua is much faster, much smaller, easier to embed, and has a better C interface than Python, but Python has more libraries (including many that are included by default) and a larger user-base. Guile I dunno about, it seems to have the bad points of both (large/bloated + not much support or user-base)...]
I suspect NYC would be ecstatic to be rid of the shackles-of-Albany as well—Albany is constantly screwing over the city to please suburban voters, even when the law/policy/agency in question mainly affects NYC.
Not gonna happen of course, 'cause Albany likes those taxes...
The policy at the time was 6 characters, with at least 1 capital and at least 1 number, and couldn't be the same as the last one.
What do you want? One character passwords?
Of course not, but also not useless-yet-annoying rules like the above...
Require a capital letter? 95% will make it the first one. Require a digit? 95% will just append "0". Increase in difficulty for someone trying to guess passwords? Zero.
Correct me if I'm wrong, but it would appear this is a continuation on other patents, with the original being filed in 1993.
So tell me, twenty years ago was this obvious to any of the users here? Or is it obvious now only because they "invented" it?
No it's not "only obvious because they invented it." They didn't "invent" anything, as it's an utterly straight-forward (as in it basically duplicates other IEEE FP formats) application of long established practice with different (but "obvious") parameters.
Sure it's a good idea to do that—but you can't patent "good ideas," remember? Oh wait, with today's new "income oriented" patent office you can...
[And that's the problem with many other idiotic patents these days—they're basically "existing technique, only in green!"]
Great! I hope they fixed the currently broken AVR support.
The page I linked to above also shows many changes to AVR support; whether that makes it non-"broken" or not, I don't know.
Re:C6X support is surprising
on
Linux 3.3 Released
·
· Score: 4, Informative
Also, it's quite surprising to me since as far as I know it's necessary to use TI's compiler to generate C6X code. I found one initiative to port GCC to it, but afaik it didn't get finished. My understanding is that it is no small job to get Linux to compile on non-supported compilers, so I'm interested in the toolchain they are using.
GCC 4.7 (which will be released soonish; it's basically already done) supports the C6X architecture.
Lets say you spend years working on a book or a series of books only to have some one steal all your ideas. In your word there would be nothing you could do about it.
Yeah! After all, Tolkien has only been dead for 37 years; he's clearly going to be furious.
How dare popular culture embrace your ideas and make your language part of the common parlance!
Er, doesn't one actually have to, you know, engage in trade (in the covered category) to own a trademark?
Given that the entire purpose of trademarks is to protect the earned reputation and identity of companies, it would seem completely idiotic if people were allowed to simply trademark random words in random categories...
Yes, our broken patent system is crazy. It stifles innovation and harms society. That's why it should be significantly reformed (i.e., gutted).
That won't happen, of course, because companies like MS and Apple can afford to make it not happen. What's actually good for society is pretty much irrelevant.
Er, that doesn't seem like a very fair label for that picture—lying on your back like that will emphasize anybody's ribs, 'cause your organs etc, obey gravity too...!
... continued the researchers at the infamous "Fat University," pausing to wash down the cake they were continually stuffing into their mouths with a milkshake, "low calorie foods should be bannnnnnned,... those horrible skinny people think they're so great and "attractive", but we know they're unnatural freaks! Fat is beautiful and.... we'l......asl34!!%*" (at this point the spokesman keeled over from an apparent heart attack.. or maybe he just choked to death on cake; more on this breaking story as it develops)
Not really true. Lots of people, even relatively "ordinary" people had computers at home back then, albeit somewhat crappy computers by today's standards. I was the hacker type in my family, so I had a single-board thingy which I programmed in assembly—but my completely non-techy brother had an Atari 400 (cheap, mostly used for games, but a real computer nonetheless). Friends had VIC-20s, some richer ones had the original IBM PC or Apple IIs, the Commodore 64 was gaining popularity, etc. The TRS-80 etc had been around for years.
Obviously many fewer people had computers then than now, but computer ownership was definitely gaining at that point, and starting to go beyond the enthusiast class (often in the guise of a "game machine with a keyboard", many of which were relatively cheap).
Because frankly, Python is no better than Javascript as a language (python is hardly "an extremely polished language with very few issues"). Both languages are basically "OK". Although both have some odd quirks (e.g. both have funny scoping rules, significant whitespace in python), they can reasonably serve the purpose.
However Javascript also has the advantage that it's ubiquotous these days, in way that not even Python can claim to be. It's a reasonable choice.
Slashdot Mirror
ASFE: "Another Fucking Scripting Engine"
It isn't really, of course—it's Lua, which has a long history and is widely used, and is perfectly suited for the application...
To be honest, though, I have a soft spot for any magazine where like 90% of the articles are printed in some kind of weird star-trek typeface on shiny silver paper......
As unreadable as they try to make it, Wired has nothing on Omni!
Cool... thanks slashdot for screwing up my carefully entered (and previewed!) formatting with your weird stylesheet...
While Japanese ATMs for a long time had silly "banker's hours" (this policy has relaxed a great deal in recent years, and there are many 24-hour ATMs now), and don't cater to tourists wanting to use their credit card, functionally they've long been pretty sophisticated, way ahead of many other countries. Of course this functionality reflects the Japanese user-base: Japan is still very cash-oriented, with significantly less credit-card usage than many other countries, and the ATMs generally cater to that.
At my Japanese bank's ATMs, I can:
As you might imagine, these ATMs are mechanically very complicated, but they're really quite cool to see in action, they just do all this stuff...
[It's not really true that "In general, you cannot draw money from another bank's ATM." Mostly, you can, but there are certain divisions that can't be crossed, and sometimes this include cards that might be popular amongst foreigners—e.g., my friend had an account at Citibank, which has its own Japanese ATMs, and he couldn't use most other banks' ATMs. I have an account at a Japanese bank, though, and my card works in almost every "bank ATM" I've encountered.]
While I don't necessarily disagree with you, people said the same thing about color. Color film (vs B&W) is a more "real-life" experience.
Color has almost no downside for the audiences though, whereas "3D" is chock full of 'em (and there's little evidence that will change anytime soon).
If they can come up with some 3D tech that doesn't require glasses and doesn't degrade the image quality, maybe people will start to see it as something other than a often annoying gimmick that theaters use as an excuse to charge higher ticket prices...
Eh? I was just explaining why your analogy was silly...
That's like asking why we use Excel instead of paper spreadsheets. I'm not sure how the answer isn't immediately and painfully obvious to anyone.
I'm sure you love your kindle etc, and for you it may be the best thing, but the comparison with a spreadsheet is silly.
The sort of tasks most people, even "casual" users, use a spreadsheet for are hugely cumbersome to do on paper. So it's "immediately and painfully obvious" that a spreadsheet is better than paper for such use.
The same can't be said of ebooks or electronic note-taking for much typical usage: while having a million books with you might be cool, for many people it's completely pointless most of the time, and a single lightweight paperback is fine (and a good paperback [like Japanese bunko] is often considerably lighter and easier to stick in your pocket). Similarly, note-taking with a pen on paper is absolutely fine for many many uses, and often more convenient than dragging out the laptop or pecking something into your iphone.
The attitude of many towards lisp/scheme was probably a factor, but I think not the major one. As can be seen by the huge number of Emacs extensions, people can deal with lisp, even if it's not everybody's first choice. [...and note that this is true even with Emacs' somewhat inelegant lisp dialect and lack of many modern features; people will put up with a lot of crap if the reward is immediate...]
The real problem, I think, was that Guile never had a particularly usable or attractive implementation—it was kind of bloated and slow, and the interfaces were not particularly good. Lua, by contrast, although it also has its weaknesses, really hit the sweet spot for language embedding; for somebody who just thinks "hmm, I'd like to add an extension language," it's easy to quickly add Lua to your app, it works well, and doesn't add many dependencies (Lua is so small it's perfectly practical to just include the entire Lua source tree with your app). Python is a bit clumsier and resource-intensive, but has tons of tool support, and works well in practice; moreover with its popularity, one can get a big payback from the effort required, with the huge amount of libraries available and widespread user familiarity.
In other words, Guile was a pretty good idea, but the reality never lived up to it.
I've heard that Guile has improved a lot in the last few years, but it may be too late for it to gain much ground with so many good alternatives already in widespread use. If a popular app like Emacs were to start using it (besides the "GNU dogfooding" aspect, Guile would probably be a better fit for Emacs than non-lisp languages), that would help to keep the project going, and maybe it could win over more people in the future, but ... I'm not holding my breath.
Hmmm, of course such libraries do exist for Lua, it's just that you'll have to download them separately rather than finding them in the tarball that contains the actual interpreter...
The most common use of Lua is as an "embedded" language—app is written in C, but linked with a Lua interpreter which the app calls to do whatever stuff it wants. I don't think actual sandboxing is all that common—it's common, for instance, for "embedded" Lua code to load various external modules/libraries to do stuff.
[There's no particular reason not to write an entire app in Lua (works fine), it's just that its small size, standalone nature / lack of dependencies, and good C interface make it a very good fit for those times when you want to add an interpreter to your app...]
You are misformed. Lua is much faster than python in pretty much any normal application. [and that's normal Lua—LuaJIT is of course, even faster.]
Python has its strong points, but speed is not one of them.
They can easily interface with the outside (unlike Lua) and the C API works similarly, but python wins due to its more traditional syntax and larger developer base.
Wait, what? How do you come to the conclusion that Lua "can't easily interface with the outside"?
[Lua and Python / Guile are very similar in overall form. Lua is much faster, much smaller, easier to embed, and has a better C interface than Python, but Python has more libraries (including many that are included by default) and a larger user-base. Guile I dunno about, it seems to have the bad points of both (large/bloated + not much support or user-base)...]
Maybe they can get Uwe Boll to give acting a shot...
I suspect NYC would be ecstatic to be rid of the shackles-of-Albany as well—Albany is constantly screwing over the city to please suburban voters, even when the law/policy/agency in question mainly affects NYC.
Not gonna happen of course, 'cause Albany likes those taxes...
The policy at the time was 6 characters, with at least 1 capital and at least 1 number, and couldn't be the same as the last one.
What do you want? One character passwords?
Of course not, but also not useless-yet-annoying rules like the above...
Require a capital letter? 95% will make it the first one. Require a digit? 95% will just append "0". Increase in difficulty for someone trying to guess passwords? Zero.
Correct me if I'm wrong, but it would appear this is a continuation on other patents, with the original being filed in 1993.
So tell me, twenty years ago was this obvious to any of the users here? Or is it obvious now only because they "invented" it?
No it's not "only obvious because they invented it." They didn't "invent" anything, as it's an utterly straight-forward (as in it basically duplicates other IEEE FP formats) application of long established practice with different (but "obvious") parameters.
Sure it's a good idea to do that—but you can't patent "good ideas," remember? Oh wait, with today's new "income oriented" patent office you can...
[And that's the problem with many other idiotic patents these days—they're basically "existing technique, only in green!"]
Great! I hope they fixed the currently broken AVR support.
The page I linked to above also shows many changes to AVR support; whether that makes it non-"broken" or not, I don't know.
Also, it's quite surprising to me since as far as I know it's necessary to use TI's compiler to generate C6X code. I found one initiative to port GCC to it, but afaik it didn't get finished. My understanding is that it is no small job to get Linux to compile on non-supported compilers, so I'm interested in the toolchain they are using.
GCC 4.7 (which will be released soonish; it's basically already done) supports the C6X architecture.
From the GCC 4.7 release notes:
It's pretty frickin' scary that facebook "has emotional value for people"...
Lets say you spend years working on a book or a series of books only to have some one steal all your ideas. In your word there would be nothing you could do about it.
Yeah! After all, Tolkien has only been dead for 37 years; he's clearly going to be furious.
How dare popular culture embrace your ideas and make your language part of the common parlance!
Er, doesn't one actually have to, you know, engage in trade (in the covered category) to own a trademark?
Given that the entire purpose of trademarks is to protect the earned reputation and identity of companies, it would seem completely idiotic if people were allowed to simply trademark random words in random categories...
Yes, our broken patent system is crazy. It stifles innovation and harms society. That's why it should be significantly reformed (i.e., gutted).
That won't happen, of course, because companies like MS and Apple can afford to make it not happen. What's actually good for society is pretty much irrelevant.
in the early 50s you find pictures like this rack-o-ribs that show her looking rather emaciated.
Er, that doesn't seem like a very fair label for that picture—lying on your back like that will emphasize anybody's ribs, 'cause your organs etc, obey gravity too...!
... continued the researchers at the infamous "Fat University," pausing to wash down the cake they were continually stuffing into their mouths with a milkshake, "low calorie foods should be bannnnnnned, ... those horrible skinny people think they're so great and "attractive", but we know they're unnatural freaks! Fat is beautiful and.... we'l......asl34!!%*"
(at this point the spokesman keeled over from an apparent heart attack.. or maybe he just choked to death on cake; more on this breaking story as it develops)
nobody had a computer at home
Not really true. Lots of people, even relatively "ordinary" people had computers at home back then, albeit somewhat crappy computers by today's standards. I was the hacker type in my family, so I had a single-board thingy which I programmed in assembly—but my completely non-techy brother had an Atari 400 (cheap, mostly used for games, but a real computer nonetheless). Friends had VIC-20s, some richer ones had the original IBM PC or Apple IIs, the Commodore 64 was gaining popularity, etc. The TRS-80 etc had been around for years.
Obviously many fewer people had computers then than now, but computer ownership was definitely gaining at that point, and starting to go beyond the enthusiast class (often in the guise of a "game machine with a keyboard", many of which were relatively cheap).
Because frankly, Python is no better than Javascript as a language (python is hardly "an extremely polished language with very few issues"). Both languages are basically "OK". Although both have some odd quirks (e.g. both have funny scoping rules, significant whitespace in python), they can reasonably serve the purpose.
However Javascript also has the advantage that it's ubiquotous these days, in way that not even Python can claim to be. It's a reasonable choice.