Still do you think that Haskell is a suitable language for writing 'mainstream' applications (like, say, a vector drawing package)? It seems to me a bit too uncomfortable to work through monad machinery and other weirdness to interact with the outside world. However I'd like to be proved wrong.
Is the GTK-Haskell binding usable - how does it compare to writing the same code in C, or a C++ binding like gtkmm?
Yes but EasyInternetCafe is rather cool. You can even download PuTTY onto the machines and ssh somewhere to work. Unfortunately it doesn't seem as cheap as it used to be (was formerly two pounds for 24 hours, now more like L4.40).
Hmm. So does this mean that SAPDB is to Postgres what Postgres is to MySQL - a more-capable but less popular and somewhat harder-to-set-up alternative?
Apart from the Oracle system tables emulation what other features does SAPDB have over Postgres? Does it have its own PL/SQL-like language? Are there benchmarks?
I must say that if the next version of MySQL has the industrial-strength-databaseness of SAPDB and the ease of use of MySQL, that's good news for everyone. I hope it will also have the multi-version concurrency control of Oracle and Postgres (so that writers never wait for readers and vice versa).
I don't really understand why the movie studios would object to this. If they are getting paid the same amount either way, what difference is it to them whether the consumer pays $10 or $1? If you assume that the low-cost cinemas will increase the number of cinemas paying money to the movie studios, then they win.
Another way of looking at it is that any business wants its distributors to take a smaller cut of the final sale price, and a bigger cut for itself. If consumers are prepared to pay N dollars to see a movie then it obviously makes sense for most of that amount to go to the movie studios and not get creamed off by cinemas.
The situation with Levi's jeans is not quite the same: they are a luxury item in a way that movies are not; you wear expensive jeans partly to be seen in them, but nobody goes to the cinema in order to be seen at the cinema (unlike opera?). The movie studios needn't worry that fewer people will see films if they're no longer perceived as expensive. That's not the reason why people see them at the moment.
But lamda libraries for C++ are cheating, in a way: they all involve proxy objects and redefining standard functions like + to operate on the proxy objects and wrapping any real functions you want to call.
I kinda agree with you about Haskell but you are being unfair to ML. Both SML/NJ and OCaml have production-quality compilers and a good standard library, and the language itself is not particularly 'pure' (ML functions can have side effects).
You can get higher order functions in C++, just about (eg for_each in the standard library). But the syntax is awkward and without anonymous functions (lambda) it gets more awkward.
Perl has higher order functions, and is reasonably 'mainstream'. So do Python and Tcl and most other scripting languages that let you pass around pointers to functions. But without typechecking it can get a bit error-prone to do the kind of really complex stuff you might do in Haskell or ML.
A nice website means nothing more than a nice budget for graphics design.
No - it seems to me that website usability and graphics design budget are inversely correlated.
Content management tools do address a real problem, but not one that couldn't be addressed better with CVS and a text editor. But doing that requires your users to learn HTML (or at least use a decent HTML editor).
Suppose you pour blue light in during forty days and forty nights. It might take 44 days for the light to emerge as red, so at the end of the 40 days the crystal has stored 4 days of light. How can it store that much energy efficiently? There must be a limit to how much energy, and thus how much light, can be stored inside the crystal. Emission of pure red light must be temporary before the crystal gets 'full up' and starts to leak blue light, or gets too hot and breaks, or something.
You could OTOH do it with pulses of blue light, as others have mentioned.
No you misunderstand - of course I didn't mean that the light beam once it has exited the crystal will somehow revert back to its original frequency at the stroke of midnight. I meant, *for how long* can the crystal go on producing light at a different frequency? Can it do so continuously or just for short bursts?
OK, we will have to disagree. I think that the practical example of Java shows that public/protected/private access control is a good mechanism for controlling access to resources and providing security.
Yes the light emerges at a new frequency, *but for how long*? Can you shine in a continuous beam of red light and see at the other end a continuous beam of blue light? The article really didn't make this clear.
I'm sorry I can't think any harder. Since Slashdot is a public forum, you might assume that at least some of the readership (although maybe only a small part) is as stupid as I am and equally unable to work out the riddle. So please, explain the answer and justify your statement about encapsulation.
Number is not frequency: you could still see the same number at a lower or higher frequency, the total observation would just take a longer or
shorter time.
But in this case the speed of the light going in equals that of it going out. You can't store light inside the crystal for more than a short time. The crystal is not moving towards or away from the observer.
Suppose you are shining in continuous blue light and in a given time period a certain number of waves go into the crystal. At the other end red light is emitted, with a lower wavelength, so in the same time period fewer waves come out. What has happened to the 'missing' ones? They are inside the crystal doing the hall-of-mirrors thing presumably. But surely the number of light waves inside the crystal is limited. And anyway the moving mirrors to trap the light happen only during the shock wave.
Or take it the other way round - send in a continuous beam of red light, how do you get a continuous beam of blue light from that without 'running out' of waves? Any blue light produced must be just for a short time.
Yup, that makes sense. But if you put continuous green light in there you'd get - what? It seems like you should get alternating red and blue pulses.
And certainly you can't shine red light in (whether pulsed or continuous) and get continuous blue light.
It seems to me that this technique could be described as 'saving' or 'borrowing' wave cycles. They have to be paid back eventually. You can't keep on sending out higher frequency light than came in.
Yes you could have pulsed light I imagine. But as I said this is only 'for a short time' (the duration of one pulse). And if the output frequency is higher than the input frequency, the output pulses would be shorter.
One or two rhetorical questions is okay but you asked such a large number of them.
- What's different between between language access levels in C++ and Java? Not very much if you take the language definitions themselves. In C++ you are able to 'cheat' more easily by compiling your own code with different headers, at least for most current implementations of C++ where the check is done at compile time.
What's different between JVM access levels when run with a security manager and C++ access levels? - I think the answer to this is the same as above.
- What's different between C++ access levels and hardware memory protection? Access levels are a language feature. If they are enforced for all running code, they provide relatively fine-grained access control over resources. Hardware memory protection provides control over reading or writing whole pages, and doesn't correspond closely to most language constructs (apart from 'const' maybe).
- What's different between Java access levels and hardware memory protection? I assume you mean the access checking done at runtime (or at bytecode verification time) by some JVMs. Well, again it is finer-grained and can be done statically. Then again, it's possible to prove statically that a valid C or C++ program does not transgress hardware memory protection, unless it uses a lot of pointers (most C++ code does not).
- What's the different between C# access levels and Java access levels? I don't know, I am not familiar with C#. But the point we are discussing should be valid with Java as well?
- What is different between JVM and CLR security managers? Ditto.
- What's different between a lexical closure, an aluminum can, and an encrypted profanity? Don't see the relevance, none of these three language features are present in Java or C++ (although Perl has two of them).
Now can you explain what you meant by saying (and I quote it correctly this time, sorry) 'Encapsulation is not a practical means of securing access to regions of memory or code.' By 'encapsulation' did you mean the access control mechanisms in Java or similar languages? If not, what did you mean by it?
Reading the article it seems that the light frequency is altered for only a short time, the time during which the shock wave passes through the crystal. So I don't think it's some magic filter where you can shine a green light in one end and get red light out the other. In the long term the number of peaks and troughs you put in at one end must equal the number seen at the other, so you can't consistently alter the frequency of a light beam in this way.
IANAP, anyone care to provide more detail than seen in the article? Will the planned demonstration of the work give results observable to the human eye?
I don't understand why the questions you ask are germane to this particular point. I just wanted to pick up on your remark about 'encapsulation is not a practical means of securing access control'. Access control to private members seems to work well enough in Java for applets, and so it would seem to be 'practical' for that application at least. Of course if encapsulation via access control is checked only by the compiler, and ignored by the runtime system, then it is useless for security. That is obvious.
Could you explain what you meant by 'encapsulation is not a practical means...'?
Encapsulation is not a practical means of securing access to regions of memory or code.
I assume by encapsulation you mean access control, so that methods or fields marked 'private' cannot be used by just anyone. This is one tool you can use to provide encapsulation, but the tool is not the same as the idea (you can write well-encapsulated libraries in any language).
But access control does seem to work fairly well with Java applets. It may not be the one and only way to control access: it would be difficult to control file permissions by changing method access control (though possible, in some wacky highly-dynamic OO environment). But you do need access controls as a basis to build more sophisticated access controls. Consider the classic Unix kernel - it has public functions (system calls) and internal kernel functions and data structures. There could be no security without access control to stop people calling the internal functions directly.
I believe it's true that Java can be compiled down to native code and optimized to the same degree as C/C++ and still retain the type safety... that's what's really novel about Java.
Er... C and C++ can be 'compiled down to native code' and 'still retain the type safety'. C++ in particular has a lot more type safety than Java, if you use the STL's typesafe containers and other well-written libraries. This is changing with the introduction of templates in the latest Java version, I know. But still I wouldn't place Java ahead of C++ for safety, just roughly equal at best. Unless you define type safety as making it impossible to circumvent the type system even deliberately, rather than just making it hard to have type errors accidentally.
(Does the latest Java version have 'const', for example? That always seemed to be a big omission. How about declaring a parameter that must not be null? (in C++ you use references to state that)?)
at runtime you can make further optimizations based on the *behavior* of the code... things you can't do statically.
This is true. But then again you can have profile-driven optimizers for C and other compiled languages.
Well ideally there would be a high enough resolution to distinguish between the front of one page and the front of the facing page. But suppose the resolution were low enough for the two to get blurred into one. Could you still scan the pages?
I'd say yes, if you have some idea of what glyphs look like (a 'g' is on page 1, a back-to-front 'g' is on page two). Combine that with some semantic checks like spelling, and it could work well enough.
Instead of picking the book up and flipping the pages, couldn't you use X-ray tomography (or possibly microwave tomography) to get a 3d image of the book and extract pages from that?
This assumes two things: that the ink makes a difference to X-ray penetration compared to just paper, and that the resolution of the scanner is high enough to pick out individual pages. But typical medical scanners are pretty high-res I think. Has anyone tried this?
Of course, the same applies to straightforwardly compiled languages: you can prove at compile time that stack overflows and underflows won't happen in C++, unless the programmer deliberately chooses to scribble over the stack. The difference is that Java has a two-stage compilation, first from source code to bytecode (which is pretty trivial) and then a second 'compilation' or at least semantic check before interpreting the bytecode.
Of course you can disassemble a class and find what its private members are. You can do that in any language; relying on people not figuring things out from the object code is just trying to get security through obscurity.
Slashdot Mirror
Still do you think that Haskell is a suitable language for writing 'mainstream' applications (like, say, a vector drawing package)? It seems to me a bit too uncomfortable to work through monad machinery and other weirdness to interact with the outside world. However I'd like to be proved wrong.
Is the GTK-Haskell binding usable - how does it compare to writing the same code in C, or a C++ binding like gtkmm?
Yes but EasyInternetCafe is rather cool. You can even download PuTTY onto the machines and ssh somewhere to work. Unfortunately it doesn't seem as cheap as it used to be (was formerly two pounds for 24 hours, now more like L4.40).
Hmm. So does this mean that SAPDB is to Postgres what Postgres is to MySQL - a more-capable but less popular and somewhat harder-to-set-up alternative?
Apart from the Oracle system tables emulation what other features does SAPDB have over Postgres? Does it have its own PL/SQL-like language? Are there benchmarks?
I must say that if the next version of MySQL has the industrial-strength-databaseness of SAPDB and the ease of use of MySQL, that's good news for everyone. I hope it will also have the multi-version concurrency control of Oracle and Postgres (so that writers never wait for readers and vice versa).
I don't really understand why the movie studios would object to this. If they are getting paid the same amount either way, what difference is it to them whether the consumer pays $10 or $1? If you assume that the low-cost cinemas will increase the number of cinemas paying money to the movie studios, then they win.
Another way of looking at it is that any business wants its distributors to take a smaller cut of the final sale price, and a bigger cut for itself. If consumers are prepared to pay N dollars to see a movie then it obviously makes sense for most of that amount to go to the movie studios and not get creamed off by cinemas.
The situation with Levi's jeans is not quite the same: they are a luxury item in a way that movies are not; you wear expensive jeans partly to be seen in them, but nobody goes to the cinema in order to be seen at the cinema (unlike opera?). The movie studios needn't worry that fewer people will see films if they're no longer perceived as expensive. That's not the reason why people see them at the moment.
But lamda libraries for C++ are cheating, in a way: they all involve proxy objects and redefining standard functions like + to operate on the proxy objects and wrapping any real functions you want to call.
Writing something like
f = lambda(_1 + wrap_unary_function(g)(_2));
isn't nearly as clean IMHO as
f = lambda(x, y) { return x + g(y); };
I kinda agree with you about Haskell but you are being unfair to ML. Both SML/NJ and OCaml have production-quality compilers and a good standard library, and the language itself is not particularly 'pure' (ML functions can have side effects).
You can get higher order functions in C++, just about (eg for_each in the standard library). But the syntax is awkward and without anonymous functions (lambda) it gets more awkward.
Perl has higher order functions, and is reasonably 'mainstream'. So do Python and Tcl and most other scripting languages that let you pass around pointers to functions. But without typechecking it can get a bit error-prone to do the kind of really complex stuff you might do in Haskell or ML.
No - it seems to me that website usability and graphics design budget are inversely correlated.
Content management tools do address a real problem, but not one that couldn't be addressed better with CVS and a text editor. But doing that requires your users to learn HTML (or at least use a decent HTML editor).
Suppose you pour blue light in during forty days and forty nights. It might take 44 days for the light to emerge as red, so at the end of the 40 days the crystal has stored 4 days of light. How can it store that much energy efficiently? There must be a limit to how much energy, and thus how much light, can be stored inside the crystal. Emission of pure red light must be temporary before the crystal gets 'full up' and starts to leak blue light, or gets too hot and breaks, or something.
You could OTOH do it with pulses of blue light, as others have mentioned.
No you misunderstand - of course I didn't mean that the light beam once it has exited the crystal will somehow revert back to its original frequency at the stroke of midnight. I meant, *for how long* can the crystal go on producing light at a different frequency? Can it do so continuously or just for short bursts?
OK, we will have to disagree. I think that the practical example of Java shows that public/protected/private access control is a good mechanism for controlling access to resources and providing security.
Yes the light emerges at a new frequency, *but for how long*? Can you shine in a continuous beam of red light and see at the other end a continuous beam of blue light? The article really didn't make this clear.
I'm sorry I can't think any harder. Since Slashdot is a public forum, you might assume that at least some of the readership (although maybe only a small part) is as stupid as I am and equally unable to work out the riddle. So please, explain the answer and justify your statement about encapsulation.
But in this case the speed of the light going in equals that of it going out. You can't store light inside the crystal for more than a short time. The crystal is not moving towards or away from the observer.
Suppose you are shining in continuous blue light and in a given time period a certain number of waves go into the crystal. At the other end red light is emitted, with a lower wavelength, so in the same time period fewer waves come out. What has happened to the 'missing' ones? They are inside the crystal doing the hall-of-mirrors thing presumably. But surely the number of light waves inside the crystal is limited. And anyway the moving mirrors to trap the light happen only during the shock wave.
Or take it the other way round - send in a continuous beam of red light, how do you get a continuous beam of blue light from that without 'running out' of waves? Any blue light produced must be just for a short time.
Yup, that makes sense. But if you put continuous green light in there you'd get - what? It seems like you should get alternating red and blue pulses.
And certainly you can't shine red light in (whether pulsed or continuous) and get continuous blue light.
It seems to me that this technique could be described as 'saving' or 'borrowing' wave cycles. They have to be paid back eventually. You can't keep on sending out higher frequency light than came in.
Yes you could have pulsed light I imagine. But as I said this is only 'for a short time' (the duration of one pulse). And if the output frequency is higher than the input frequency, the output pulses would be shorter.
One or two rhetorical questions is okay but you asked such a large number of them.
- What's different between between language access levels in C++ and Java? Not very much if you take the language definitions themselves. In C++ you are able to 'cheat' more easily by compiling your own code with different headers, at least for most current implementations of C++ where the check is done at compile time.
What's different between JVM access levels when run with a security manager and C++ access levels? - I think the answer to this is the same as above.
- What's different between C++ access levels and hardware memory protection? Access levels are a language feature. If they are enforced for all running code, they provide relatively fine-grained access control over resources. Hardware memory protection provides control over reading or writing whole pages, and doesn't correspond closely to most language constructs (apart from 'const' maybe).
- What's different between Java access levels and hardware memory protection? I assume you mean the access checking done at runtime (or at bytecode verification time) by some JVMs. Well, again it is finer-grained and can be done statically. Then again, it's possible to prove statically that a valid C or C++ program does not transgress hardware memory protection, unless it uses a lot of pointers (most C++ code does not).
- What's the different between C# access levels and Java access levels? I don't know, I am not familiar with C#. But the point we are discussing should be valid with Java as well?
- What is different between JVM and CLR security managers? Ditto.
- What's different between a lexical closure, an aluminum can, and an encrypted profanity? Don't see the relevance, none of these three language features are present in Java or C++ (although Perl has two of them).
Now can you explain what you meant by saying (and I quote it correctly this time, sorry) 'Encapsulation is not a practical means of securing access to regions of memory or code.' By 'encapsulation' did you mean the access control mechanisms in Java or similar languages? If not, what did you mean by it?
Reading the article it seems that the light frequency is altered for only a short time, the time during which the shock wave passes through the crystal. So I don't think it's some magic filter where you can shine a green light in one end and get red light out the other. In the long term the number of peaks and troughs you put in at one end must equal the number seen at the other, so you can't consistently alter the frequency of a light beam in this way.
IANAP, anyone care to provide more detail than seen in the article? Will the planned demonstration of the work give results observable to the human eye?
I don't understand why the questions you ask are germane to this particular point. I just wanted to pick up on your remark about 'encapsulation is not a practical means of securing access control'. Access control to private members seems to work well enough in Java for applets, and so it would seem to be 'practical' for that application at least. Of course if encapsulation via access control is checked only by the compiler, and ignored by the runtime system, then it is useless for security. That is obvious.
Could you explain what you meant by 'encapsulation is not a practical means...'?
I assume by encapsulation you mean access control, so that methods or fields marked 'private' cannot be used by just anyone. This is one tool you can use to provide encapsulation, but the tool is not the same as the idea (you can write well-encapsulated libraries in any language).
But access control does seem to work fairly well with Java applets. It may not be the one and only way to control access: it would be difficult to control file permissions by changing method access control (though possible, in some wacky highly-dynamic OO environment). But you do need access controls as a basis to build more sophisticated access controls. Consider the classic Unix kernel - it has public functions (system calls) and internal kernel functions and data structures. There could be no security without access control to stop people calling the internal functions directly.
Er... C and C++ can be 'compiled down to native code' and 'still retain the type safety'. C++ in particular has a lot more type safety than Java, if you use the STL's typesafe containers and other well-written libraries. This is changing with the introduction of templates in the latest Java version, I know. But still I wouldn't place Java ahead of C++ for safety, just roughly equal at best. Unless you define type safety as making it impossible to circumvent the type system even deliberately, rather than just making it hard to have type errors accidentally.
(Does the latest Java version have 'const', for example? That always seemed to be a big omission. How about declaring a parameter that must not be null? (in C++ you use references to state that)?)
This is true. But then again you can have profile-driven optimizers for C and other compiled languages.
Well ideally there would be a high enough resolution to distinguish between the front of one page and the front of the facing page. But suppose the resolution were low enough for the two to get blurred into one. Could you still scan the pages?
I'd say yes, if you have some idea of what glyphs look like (a 'g' is on page 1, a back-to-front 'g' is on page two). Combine that with some semantic checks like spelling, and it could work well enough.
Instead of picking the book up and flipping the pages, couldn't you use X-ray tomography (or possibly microwave tomography) to get a 3d image of the book and extract pages from that?
This assumes two things: that the ink makes a difference to X-ray penetration compared to just paper, and that the resolution of the scanner is high enough to pick out individual pages. But typical medical scanners are pretty high-res I think. Has anyone tried this?
Of course, the same applies to straightforwardly compiled languages: you can prove at compile time that stack overflows and underflows won't happen in C++, unless the programmer deliberately chooses to scribble over the stack. The difference is that Java has a two-stage compilation, first from source code to bytecode (which is pretty trivial) and then a second 'compilation' or at least semantic check before interpreting the bytecode.
Of course you can disassemble a class and find what its private members are. You can do that in any language; relying on people not figuring things out from the object code is just trying to get security through obscurity.