The appeal of scripting languages in business apps, to me, is embedding. I don't really care whether it's Javascript, Python, Lua, Groovy or whatever else. Write the core of your application in Java or C, embed a script interpreter, bind some classes/functions and program the high level logic in the more readable, malleable scripting language.
This doesn't mean that non-programmers can be trusted to write those parts. But it means you can free up cognitive load when writing the business logic; the scripting language letting you express the logic more cleanly.
JS has the advantage that lots of people know the syntax. See how it's used as the query language for CouchDB for example.
It can't be done. The problem is that the language itself is so horribly broken that anything built upon it, be it libraries, applications, tutorials or books, will inherently be horrible, too. JavaScript just can't be salvaged. It needs to be discarded.
I used to think this, but I don't any more. The aforementioned Crockford book is the bible on this.
There is a "pleasant" Javascript community, and what they have done is to separate Javascript into three parts:
- the good parts -- use them
- the bad parts -- avoid using them altogether
- the missing parts -- build acceptable workarounds to these using what's available
For example, Javascript has a horrible tendency for scripts to pollute the global variable namespace. The community came up with the CommonJS module convention, which solves the problem rather neatly.
You can emulate any turing-complete system in any other turing-complete system. It's just a matter of having the tools and performance to achieve it without going mad.
And we don't know he didn't go mad... or start mad...
So if one day Amazon's servers go down, you switch to non-Silk mode, and carry on your way. Slower than normal, but still working.
Even though we are both using the word scale I assume we are talking about resampling. If the image was 2048x1024 pixels then Amazon would decide it only needed to be 1024x512 for the Fire and send it as that size? If so, no thanks. In my experience traditional browsers load the whole 2048x1024 image but resample/resize it to fit the browser window. The full-size image is there in the local cache if you want it though.
Why download the whole 2048x1024 image, if you're not going to view it at that scale? Bearing in mind: you're using a low spec tablet. It will take longer to download, it's going to consumer scarce memory, it will take time and battery power to resample. Why not let Amazon resample it for you, saving you all those costs. In most cases you wouldn't even wait for them to resample it -- they would have a resampled version in their own cache.
In the 1% of occasions you actually do want the full size image, it'll fetch that for you when you ask for it.
If you were worrying about the privacy implications of Silk, I'd understand. But you seem to be objecting to it on other grounds that make no sense.
Suppose Amazon's servers are overloaded, then your browsing sucks even though your browser and Internet connection are fine.
Why do you suppose Amazon's servers would get overloaded. They have huge resources and an interest in keeping Fires working well. When you buy S3 or EC2 or whatever, you also rely on Amazon having capacity.
And I don't want scaled images, I want the image that the site sends.
Why, if your browser is going to scale it when it arrives?
And how much of a performance hit are DNS lookups and open sockets?
A couple of milliseconds, but it all adds up.
In Chrome, hit Ctrl-shift-I for the developer tools, load a page, and look at the gantt-like chart it produces. See how chatty it is - ask for something, get it, parse it, notice that it includes something else, request that, run some javascript, that notices you need something else, request that, etc. Think how much faster it could be if the remote end already knew all the stuff you were going to need, and sent it as a neat all-in-one bundle.
But again, the proof of the pudding is in the benchmarks we're bound to see in the next week or so.
Not at all. The iPad is the Audi A8 of tablets. The Fire is the Ford Focus.
Not to say the iPad/Audi isn't a great product, nor that it's overpriced. The people who buy them get their money's worth.
But some people are on a budget. They just can't justify the cost of an Audi or an iPad. They make some compromises. With the car, perhaps a less smooth ride and a less luxurious finish. With the tablet, the occasional stutter when scrolling.
The *purpose* of funnelling everything through Amazon's servers, is to *improve* performance.
It means the browser makes fewer DNS lookups, opens fewer sockets, sends fewer HTTP headers, needn't scale images itself, needn't download images larger than it will display.
I don't imagine it will be long until one of the tech sites does some benchmarks, with Silk turned on versus Silk turned off.
Suggesting that users won't notice unresponsive screens, buttons, an general lag is just burying your head in the sand. I foresee some initial excitement for this pad just like all the others before it, and then buyers remorse will kick in about the time the larger reviews do.
I think the $250 price difference is likely to compensate for the occasional slowdown.
Aside from you already owning a Kindle, why isn't it for reading?
In my own view: distractions.
The easier it is to check my email, twitter, etc., the less likely I am to get into my book.
The appeal of the original Kindle to me, is that it's a single purpose device (yeah, it has a browser, but not one that's accessible enough to be a distraction)
Blue screens of death have nothing to do with Windows 7, because NT6.x is rock solid. The only way to get a BSOD with NT6.x is faulty hardware and/or drivers.
This is XP unfortunately (it is what my employer provides)
My frequent BSODs may be due to faulty hardware or drivers. However, nobody has ever been able to diagnose it. My computer passes all the tests on Dell's diagnostics CD, on the most thorough setting. I haven't got any exotic hardware or drivers, and tools like WhoCrashed are never able to point the finger at anything consistent.
I long ago decided that tolerating the BSODs was better use of my time than curing it.
I do think that a modern OS ought to be able to sandbox device drivers such that *at the very least* their failure can be logged. For all I know Windows 7 does that.
I'm not claiming that Linux or OSX are better in this respect - only that I have not presonally experienced issues with them. The only time I got a kernel panic from a Linux box was when the hard drive connector wasn't fully seated.
There's a sweet spot somewhere, where the costs work out such that the market value of the good is so low that you still would pay someone to take it away.
Let's say it costs me $10 to collect a tonne of grease, $10 to process it into biofuel, which I can sell for £20. I've not made a profit. If I also charge $10 for collecting the grease, I've made $10 profit.
My competitor in the grease disposal business, who doesn't sell biofuel, has to charge $20 collection, to make the same profit. (and that's discounting his disposal costs)
Client-side, you probably want a screen and an input device. Something based on those super-cheap Chinese Android tablets might be a better bet.
I'm not confident enough to get one for myself, because I read reviews of the WiFi being awful on them -- but if you have a research budget, it would be worth a go.
It's true that's an issue, but it's a matter of user-education, and not an unreasonable one.
On phones, for example, I think even the daftest user is likely to understand when the installer says "this installer is requesting permission to read your SMS messages" ("it's a puzzle game; why would it need that?").
If it's too easy to click past without reading it, that's a UI design issue. Serious questions deserve "are you sure" dialogues.
Of course not, but the point is that the installer tells you what resources the app is demanding access to, and you have the choice to say "yeah, that makes sense", or "no, why the hell does it need that?"
Let's say you install a text editor, and it says it needs the ability to add/remove user accounts -- you'd raise your eyebrows.
OK, not the "central authority can veto apps" part.
But the "app package declares what system calls it needs to access; package manager reports it; sandbox enforces it" part.
You can achieve it in a limited way with things like chroot, but having it conveniently bundled is nice.
# apt-get install gnuTunes INFO: gnuTunes requires:
- read/write access to ~/.gnuTunes/ for the user
- access to audio output
- read access to the optical drive
- read/write access to ~/Music/ for the user
- read access to/usr/share/Music/
- make HTTP requests to http://gracenote.com/... and so on.
Slashdot Mirror
The appeal of scripting languages in business apps, to me, is embedding. I don't really care whether it's Javascript, Python, Lua, Groovy or whatever else. Write the core of your application in Java or C, embed a script interpreter, bind some classes/functions and program the high level logic in the more readable, malleable scripting language.
This doesn't mean that non-programmers can be trusted to write those parts. But it means you can free up cognitive load when writing the business logic; the scripting language letting you express the logic more cleanly.
JS has the advantage that lots of people know the syntax. See how it's used as the query language for CouchDB for example.
I think the implication is that if it's amenable to copy/paste, it ought to be in a library.
I see where you're coming from, but the book *does* list the bad parts that it suggests you don't use, and they're not *that* numerous.
The nutty parts are horrible (equality and null and so forth), but he provides rules-of-thumb which, if followed, mean you won't get bitten.
The book is mostly short because Javascript is a small language.
The huge JS books are big because they go into great detail about the DOM, which is out of scope for Crockford.
It can't be done. The problem is that the language itself is so horribly broken that anything built upon it, be it libraries, applications, tutorials or books, will inherently be horrible, too. JavaScript just can't be salvaged. It needs to be discarded.
I used to think this, but I don't any more. The aforementioned Crockford book is the bible on this.
There is a "pleasant" Javascript community, and what they have done is to separate Javascript into three parts:
- the good parts -- use them
- the bad parts -- avoid using them altogether
- the missing parts -- build acceptable workarounds to these using what's available
For example, Javascript has a horrible tendency for scripts to pollute the global variable namespace. The community came up with the CommonJS module convention, which solves the problem rather neatly.
It's not a "discovery".
You can emulate any turing-complete system in any other turing-complete system. It's just a matter of having the tools and performance to achieve it without going mad.
And we don't know he didn't go mad... or start mad...
Let me introduce you to Jetty.
Give it to a child, plug it into a TV or monitor and a keyboard, and you allow them to be creative.
The software side of things will be intended to push that side of things.
Think OLPC, only not so squarely aimed at the developing world, and assuming that people can source screens and keyboards separately.
So if one day Amazon's servers go down, you switch to non-Silk mode, and carry on your way. Slower than normal, but still working.
Even though we are both using the word scale I assume we are talking about resampling. If the image was 2048x1024 pixels then Amazon would decide it only needed to be 1024x512 for the Fire and send it as that size? If so, no thanks. In my experience traditional browsers load the whole 2048x1024 image but resample/resize it to fit the browser window. The full-size image is there in the local cache if you want it though.
Why download the whole 2048x1024 image, if you're not going to view it at that scale? Bearing in mind: you're using a low spec tablet. It will take longer to download, it's going to consumer scarce memory, it will take time and battery power to resample. Why not let Amazon resample it for you, saving you all those costs. In most cases you wouldn't even wait for them to resample it -- they would have a resampled version in their own cache.
In the 1% of occasions you actually do want the full size image, it'll fetch that for you when you ask for it.
If you were worrying about the privacy implications of Silk, I'd understand. But you seem to be objecting to it on other grounds that make no sense.
Suppose Amazon's servers are overloaded, then your browsing sucks even though your browser and Internet connection are fine.
Why do you suppose Amazon's servers would get overloaded. They have huge resources and an interest in keeping Fires working well. When you buy S3 or EC2 or whatever, you also rely on Amazon having capacity.
And I don't want scaled images, I want the image that the site sends.
Why, if your browser is going to scale it when it arrives?
And how much of a performance hit are DNS lookups and open sockets?
A couple of milliseconds, but it all adds up.
In Chrome, hit Ctrl-shift-I for the developer tools, load a page, and look at the gantt-like chart it produces. See how chatty it is - ask for something, get it, parse it, notice that it includes something else, request that, run some javascript, that notices you need something else, request that, etc. Think how much faster it could be if the remote end already knew all the stuff you were going to need, and sent it as a neat all-in-one bundle.
But again, the proof of the pudding is in the benchmarks we're bound to see in the next week or so.
Not at all. The iPad is the Audi A8 of tablets. The Fire is the Ford Focus.
Not to say the iPad/Audi isn't a great product, nor that it's overpriced. The people who buy them get their money's worth.
But some people are on a budget. They just can't justify the cost of an Audi or an iPad. They make some compromises. With the car, perhaps a less smooth ride and a less luxurious finish. With the tablet, the occasional stutter when scrolling.
The *purpose* of funnelling everything through Amazon's servers, is to *improve* performance.
It means the browser makes fewer DNS lookups, opens fewer sockets, sends fewer HTTP headers, needn't scale images itself, needn't download images larger than it will display.
I don't imagine it will be long until one of the tech sites does some benchmarks, with Silk turned on versus Silk turned off.
Suggesting that users won't notice unresponsive screens, buttons, an general lag is just burying your head in the sand. I foresee some initial excitement for this pad just like all the others before it, and then buyers remorse will kick in about the time the larger reviews do.
I think the $250 price difference is likely to compensate for the occasional slowdown.
Aside from you already owning a Kindle, why isn't it for reading?
In my own view: distractions.
The easier it is to check my email, twitter, etc., the less likely I am to get into my book.
The appeal of the original Kindle to me, is that it's a single purpose device (yeah, it has a browser, but not one that's accessible enough to be a distraction)
Blue screens of death have nothing to do with Windows 7, because NT6.x is rock solid. The only way to get a BSOD with NT6.x is faulty hardware and/or drivers.
This is XP unfortunately (it is what my employer provides)
My frequent BSODs may be due to faulty hardware or drivers. However, nobody has ever been able to diagnose it. My computer passes all the tests on Dell's diagnostics CD, on the most thorough setting. I haven't got any exotic hardware or drivers, and tools like WhoCrashed are never able to point the finger at anything consistent.
I long ago decided that tolerating the BSODs was better use of my time than curing it.
I do think that a modern OS ought to be able to sandbox device drivers such that *at the very least* their failure can be logged. For all I know Windows 7 does that.
I'm not claiming that Linux or OSX are better in this respect - only that I have not presonally experienced issues with them. The only time I got a kernel panic from a Linux box was when the hard drive connector wasn't fully seated.
Last time I had a BSOD with Windows: 8+ years ago
Last time I had a BSOD with Windows: 7 days ago (and it's been an unusually BSOD-free week).
My anecdote beats yours, in a "one black swan" kind of way.
It could work.
There's a sweet spot somewhere, where the costs work out such that the market value of the good is so low that you still would pay someone to take it away.
Let's say it costs me $10 to collect a tonne of grease, $10 to process it into biofuel, which I can sell for £20. I've not made a profit. If I also charge $10 for collecting the grease, I've made $10 profit.
My competitor in the grease disposal business, who doesn't sell biofuel, has to charge $20 collection, to make the same profit. (and that's discounting his disposal costs)
The summary is wrong. It's "pull a cord for smoke".
"Insect puke". That does indeed make it sound horrible.
But by the same token, black pudding is pig scab. ... and alongside your black pudding, you might serve a fried hen period.
Honey is delicious.
4GB USB thumb drive MP3 players are less than £20. Is that enough hours of music?
Then there's FM radio...
KISS.
Client-side, you probably want a screen and an input device. Something based on those super-cheap Chinese Android tablets might be a better bet.
I'm not confident enough to get one for myself, because I read reviews of the WiFi being awful on them -- but if you have a research budget, it would be worth a go.
I'm a computer programmer, but I'm also a skinflint. I have my eye on Raspberry Pi as a really cheap, low energy Squeezebox server.
I have read slashdot everyday for nearly 10 years and I have no clue what "Raspberry Pi" is.
One of these claims must be false. There have been loads of Raspberry Pi stories in recent months.
Or you have some sort of memory disorder.
It's true that's an issue, but it's a matter of user-education, and not an unreasonable one.
On phones, for example, I think even the daftest user is likely to understand when the installer says "this installer is requesting permission to read your SMS messages" ("it's a puzzle game; why would it need that?").
If it's too easy to click past without reading it, that's a UI design issue. Serious questions deserve "are you sure" dialogues.
Of course not, but the point is that the installer tells you what resources the app is demanding access to, and you have the choice to say "yeah, that makes sense", or "no, why the hell does it need that?"
Let's say you install a text editor, and it says it needs the ability to add/remove user accounts -- you'd raise your eyebrows.
OK, not the "central authority can veto apps" part.
But the "app package declares what system calls it needs to access; package manager reports it; sandbox enforces it" part.
You can achieve it in a limited way with things like chroot, but having it conveniently bundled is nice.
# apt-get install gnuTunes /usr/share/Music/ ... and so on.
INFO: gnuTunes requires:
- read/write access to ~/.gnuTunes/ for the user
- access to audio output
- read access to the optical drive
- read/write access to ~/Music/ for the user
- read access to
- make HTTP requests to http://gracenote.com/