The work has been published in IEEE Transactions on Biomedical Engineering (note that this is a different effort from the virtual world of the same name).
There's a virtual world called IEEE Transactions on Biomedical Engineering??...
I've been reviewing the source, and IceCream is the best thing ever since sliced bread!
There I've found the Coke's formula, a copy of the Kenedy's assasination papers, the address where Elvis is hiding, and the original Fermat's solution to the Last Theorem too!!!!1!1!!eleventyone!!
- Artificial languages are much, much more difficult than natural ones.
So there's nothing in the recall-based, artificial language of the CLI that makes it user-friendly. The Archy project tried to alleviate both in a CLI-like-ish interface that didn't suffer those problems so badly.
The fact is that Google will or will not release Android source (the non-GPL parts) whenever they feel like it, if they feel like it, and will stop releasing whenever they feel like it, if they feel like it.
You mean, like every other open-source project in the world? I've yet to see a Free Software license that warrants access to all possible future releases. The closest thing to that is the KDE Free Qt Foundation's promised right to relicense QT in case it ever gets closed, and that's only up until the last version already published under the free Q Public License.
So far Google has given a very good reason why they don't want the one-shot temporary Honeycomb source to be exposed to the world, that it was an experiment designed to be obsoleted.
And they already have promised a date when the Icecream source will be released. I myself will reserve my judgement on the quality of their word until that date.
BTW the original Mac did not get the final design from this guy; he later put his ideas into the book I linked above. They a mixture were a between a command line and a graphical text editor.
Read about GOMS and the Archy system (you can download and try it) to see how a command line can be made user-friendly.
Human computer interface is not one API, but 7 billion different individual APIs.
That's like saying that you can't script Unix because every copy of it in the world can have different settings. How about programming to what they have in common instead? (hint: humans, like all living things, are self-replicating so they share about 99.999999% of details in common).
Usability is an art, not a science. You can't make an app that everyone will find usable, anymore than you can make a work of art that everyone will find asthetically appealing.
The guy who wrote this book (and helped design the Mac) would disagree.
Surely aesthetic is important to attain usability, but it's just one layer on the toolchain.
Human-computer Interface is just one API to which you can write on, by following certain calling patterns, while respecting the existing constraints to make it work properly. Writing to that API is an engineering feat, not an artistic one.
The broken AJAX and the broken CSS layouts are the worst offenders, they invariably obscure content and impede the standard browser flow.
Several years of it have convinced me that your developers simply don't know how to do it right, at least within the constraints of the Slashcode; it's also clear that they don't test it properly - Slashdot is unreadable in vanilla mobile systems, and on any browser with two or three techy addons.
Re:haskell for the masses? sure, but only...
on
OCaml For the Masses
·
· Score: 1
That's a good explanation, but it's not unique to monads. Any temporal logic shares that "world-in / new-world-out" working.
What's specific to monads is that they can be used to different uses other than state changes - they are a building block to create any sequence of actions, not just state changes.
Re:haskell for the masses? sure, but only...
on
OCaml For the Masses
·
· Score: 1
Because of referential transparency, which you can't get in imperative and is number one reason to go functional.
A clear step forward particularly in terms of reasoning about state in an immutable language
which comes particularly handy when trying to debug a stateful complex program.
but still a bit of a kludge
To that I concur. Trying to handle two different states by boxing/unboxing data with monad transformers is a pain.
observe that functional language != immutable language. People often confuse the two
Yup, that's why I added a remark about the "purest ones", which use immutable descriptions to represent mutable objects (much like logic and math).
Re:haskell for the masses? sure, but only...
on
OCaml For the Masses
·
· Score: 1
It took me a while to grasp why monads use is so widespread in Haskell. But that's not primarily because of their inherent complexity (one understood, they're a rather simple Abstract Data Type) but because the uncountable monad tutorials make a terrible work at explaining their context, why they're useful for, and in which cases you should use them. These tutorials usually introduce monads with super-abstract metaphors and mathematical descriptions, that aren't useful for someone with a background in programming.
The lead paragraph of the Wikipedia article for monads tries to explain this context in terms that are familiar to a general programmer. Basically a monad is a framework to handle side-effects (or other complex control flows) in a small imperative block (the infamous do-block) inside your pure functional, side-effect-free Haskell language. Any state that you could get embedded in the semantics of an imperative language, you can model it explicitly in your library instead - the monad exposes into Haskell definitions the inner workings of the imperative engine.
Once this is understood, they're a pretty effective way to implement the problems that are simple to program in an imperative language but get complicated by a pure functional approach.
Are you aware that there is a State object in the Haskell library just to represent mutable objects? There's nothing in functional languages preventing you to handle state, not even in the purest ones, at least since the application of monads to programming.
With monads you can create sequences of pseudo-imperative actions ("do blocks") that behave like a language with mutable states, but where the only possible side-effects are the ones you have previously embedded in the monad declaration; every other side effect is logically impossible.
Basically a monad is an implementation for an imperative micro-machine that handles one particular type of state changes. What this buys you is simplifying the number of cases you have to take care of (you avoid race conditions, exceptions thrown by rare cases in the input data...)
The cost for it is that you must know what you're doing - you have to know how to create a miniature programming language, so it's not a job for the typical java copy-paste-debug programmer.
I don't need a flickr app, a facebook app and a photo gallery app... I just want to look at my photos regardless of source.
RSS blog aggregators already tried that approach, and it didn't work well.
Applications provide context for the way in which you want to use content. Context that never-ending streams of nearly-identical posts simply don't have.
That's why we need to create new systems every once in a while, to replace the vested interests of the old one with something adapted to the current situation.
The greedy bastards will need one whole generation to take over the new system, during which people can live a reasonable life.
This is how democracy was supposed to work, but now the bastards have taken control over the system-changing process so we need a different mechanism to create the new system. Hopefully the Internet will provide the tools to build it.
After you have pasted text, you can press Ctrl or mouse-select the Paste icon that appears below the pasted text. This opens a context menu to select the formatting style - Text only is for unformatted.
Mid-core gamers don't care about visuals, but still buy AAA-games and are a market beyond 'casual'. Sure, true hard-cores will still buy PS4 and Xbox720 and avoid Wii U, but hard-cores haven't been the target market since the first generation.
Also notice that is not dropping the Wii - backwards compatibility means that casual games will still be targeted for the old and new systems.
It does not - they're still based on the desktop metaphor. What's needed is something like iPad and Windows 8 interfaces, that hide applications management and concentrates on showing lists of content.
The Wii made Nintendo LOTS of money and sold more units than PS3 and XBOX 360 at the time IIRC. So it was a HUGE successly platform; lots of third party titles are not relevant for casual players, the original Wii's target market.
What you miss is that with the new horsepower in the WiiU, finally first-class titles for Xbox and PS3 can ALSO be released for the Wii, so it can appeal to Nintendo's mid-core gamers.
This levels the field for the three consoles to be comparable, with the Wii probably slightly ahead in terms of sold units thanks to being the only one appealing to the general public (Move doesn't count, and Kinnect is a hard sell for someone who doesn't own a X360 already) and that Nintendo doesn't need to sell it at a loss. A clever, clever move.
This controller (too big for extended gaming periods, though it is likely to be revised before launch) and feature-set won't appeal to the hardcore gamer but is perfect for the mid-core gamer.
Backwards compatibility with the original Wii means a neverending stream of casual games (that will continue to be created for both Wii and WiiU), good to share with family and friends; but now finally A-titles will be released for the three main systems, so the mid-core player won't be left behind.
People speculated that this release would signal the 8th generation of consoles. What has happened is that all vendors have reached convergence, with MS Kinect and PS Move reaching maturity and catching up with motion systems, while Nintendo has released a console with competitive performance that can sell for a profit. Welcome to the 7.5 generation.
Now that user interfaces have pretty much been badly done, developers have to justify their existence by dismantling their broken product, and fixing it again.
There, fixed that for you. New interfaces like the World Wide Web first and later the iPod/iPad show that there are better ways for computing than showing applications inside floating windows. That developers keep trying to find a new style of post-wimp interface is usually a good thing.
The desktop metaphor was a necessity in the 80s but is terribly suited for the amount of information we have today. Projects like this Webian Shell, trying to shoehorn desktop elements into the clean Web interface, are two steps in the wrong direction - getting the worse of both worlds for no benefit, as they solve no real world problem.
Slashdot Mirror
There's a virtual world called IEEE Transactions on Biomedical Engineering?? ...
How do I sign up?
I've been reviewing the source, and IceCream is the best thing ever since sliced bread!
There I've found the Coke's formula, a copy of the Kenedy's assasination papers, the address where Elvis is hiding, and the original Fermat's solution to the Last Theorem too!!!!1!1!!eleventyone!!
2 quick points in case you still read this:
- Recognition is easier than recall.
- Artificial languages are much, much more difficult than natural ones.
So there's nothing in the recall-based, artificial language of the CLI that makes it user-friendly. The Archy project tried to alleviate both in a CLI-like-ish interface that didn't suffer those problems so badly.
You mean, like every other open-source project in the world? I've yet to see a Free Software license that warrants access to all possible future releases. The closest thing to that is the KDE Free Qt Foundation's promised right to relicense QT in case it ever gets closed, and that's only up until the last version already published under the free Q Public License.
So far Google has given a very good reason why they don't want the one-shot temporary Honeycomb source to be exposed to the world, that it was an experiment designed to be obsoleted.
And they already have promised a date when the Icecream source will be released. I myself will reserve my judgement on the quality of their word until that date.
BTW the original Mac did not get the final design from this guy; he later put his ideas into the book I linked above. They a mixture were a between a command line and a graphical text editor.
Read about GOMS and the Archy system (you can download and try it) to see how a command line can be made user-friendly.
That's like saying that you can't script Unix because every copy of it in the world can have different settings. How about programming to what they have in common instead? (hint: humans, like all living things, are self-replicating so they share about 99.999999% of details in common).
The guy who wrote this book (and helped design the Mac) would disagree.
Surely aesthetic is important to attain usability, but it's just one layer on the toolchain.
Human-computer Interface is just one API to which you can write on, by following certain calling patterns, while respecting the existing constraints to make it work properly. Writing to that API is an engineering feat, not an artistic one.
The broken AJAX and the broken CSS layouts are the worst offenders, they invariably obscure content and impede the standard browser flow.
Several years of it have convinced me that your developers simply don't know how to do it right, at least within the constraints of the Slashcode; it's also clear that they don't test it properly - Slashdot is unreadable in vanilla mobile systems, and on any browser with two or three techy addons.
That's a good explanation, but it's not unique to monads. Any temporal logic shares that "world-in / new-world-out" working.
What's specific to monads is that they can be used to different uses other than state changes - they are a building block to create any sequence of actions, not just state changes.
Because of referential transparency, which you can't get in imperative and is number one reason to go functional.
which comes particularly handy when trying to debug a stateful complex program.
To that I concur. Trying to handle two different states by boxing/unboxing data with monad transformers is a pain.
Yup, that's why I added a remark about the "purest ones", which use immutable descriptions to represent mutable objects (much like logic and math).
It took me a while to grasp why monads use is so widespread in Haskell. But that's not primarily because of their inherent complexity (one understood, they're a rather simple Abstract Data Type) but because the uncountable monad tutorials make a terrible work at explaining their context, why they're useful for, and in which cases you should use them. These tutorials usually introduce monads with super-abstract metaphors and mathematical descriptions, that aren't useful for someone with a background in programming.
The lead paragraph of the Wikipedia article for monads tries to explain this context in terms that are familiar to a general programmer. Basically a monad is a framework to handle side-effects (or other complex control flows) in a small imperative block (the infamous do-block) inside your pure functional, side-effect-free Haskell language. Any state that you could get embedded in the semantics of an imperative language, you can model it explicitly in your library instead - the monad exposes into Haskell definitions the inner workings of the imperative engine.
Once this is understood, they're a pretty effective way to implement the problems that are simple to program in an imperative language but get complicated by a pure functional approach.
Are you aware that there is a State object in the Haskell library just to represent mutable objects? There's nothing in functional languages preventing you to handle state, not even in the purest ones, at least since the application of monads to programming.
With monads you can create sequences of pseudo-imperative actions ("do blocks") that behave like a language with mutable states, but where the only possible side-effects are the ones you have previously embedded in the monad declaration; every other side effect is logically impossible.
Basically a monad is an implementation for an imperative micro-machine that handles one particular type of state changes. What this buys you is simplifying the number of cases you have to take care of (you avoid race conditions, exceptions thrown by rare cases in the input data...)
The cost for it is that you must know what you're doing - you have to know how to create a miniature programming language, so it's not a job for the typical java copy-paste-debug programmer.
RSS blog aggregators already tried that approach, and it didn't work well.
Applications provide context for the way in which you want to use content. Context that never-ending streams of nearly-identical posts simply don't have.
That's why we need to create new systems every once in a while, to replace the vested interests of the old one with something adapted to the current situation.
The greedy bastards will need one whole generation to take over the new system, during which people can live a reasonable life.
This is how democracy was supposed to work, but now the bastards have taken control over the system-changing process so we need a different mechanism to create the new system. Hopefully the Internet will provide the tools to build it.
Opening a window?
Unless you log out before posting.
After you have pasted text, you can press Ctrl or mouse-select the Paste icon that appears below the pasted text. This opens a context menu to select the formatting style - Text only is for unformatted.
So, this is better than existing unstructured languages like SPARQL, how?
No no no you don't understand... people are free to do what they want, and RMS is free to criticize them for it.
Mid-core gamers don't care about visuals, but still buy AAA-games and are a market beyond 'casual'. Sure, true hard-cores will still buy PS4 and Xbox720 and avoid Wii U, but hard-cores haven't been the target market since the first generation.
Also notice that is not dropping the Wii - backwards compatibility means that casual games will still be targeted for the old and new systems.
I mean, Gnome 3 does not. iOS and Android do work very well with a small amount of applications and lots of data.
It does not - they're still based on the desktop metaphor. What's needed is something like iPad and Windows 8 interfaces, that hide applications management and concentrates on showing lists of content.
The Wii made Nintendo LOTS of money and sold more units than PS3 and XBOX 360 at the time IIRC. So it was a HUGE successly platform; lots of third party titles are not relevant for casual players, the original Wii's target market.
What you miss is that with the new horsepower in the WiiU, finally first-class titles for Xbox and PS3 can ALSO be released for the Wii, so it can appeal to Nintendo's mid-core gamers.
This levels the field for the three consoles to be comparable, with the Wii probably slightly ahead in terms of sold units thanks to being the only one appealing to the general public (Move doesn't count, and Kinnect is a hard sell for someone who doesn't own a X360 already) and that Nintendo doesn't need to sell it at a loss. A clever, clever move.
This controller (too big for extended gaming periods, though it is likely to be revised before launch) and feature-set won't appeal to the hardcore gamer but is perfect for the mid-core gamer.
Backwards compatibility with the original Wii means a neverending stream of casual games (that will continue to be created for both Wii and WiiU), good to share with family and friends; but now finally A-titles will be released for the three main systems, so the mid-core player won't be left behind.
People speculated that this release would signal the 8th generation of consoles. What has happened is that all vendors have reached convergence, with MS Kinect and PS Move reaching maturity and catching up with motion systems, while Nintendo has released a console with competitive performance that can sell for a profit. Welcome to the 7.5 generation.
There, fixed that for you. New interfaces like the World Wide Web first and later the iPod/iPad show that there are better ways for computing than showing applications inside floating windows. That developers keep trying to find a new style of post-wimp interface is usually a good thing.
The desktop metaphor was a necessity in the 80s but is terribly suited for the amount of information we have today. Projects like this Webian Shell, trying to shoehorn desktop elements into the clean Web interface, are two steps in the wrong direction - getting the worse of both worlds for no benefit, as they solve no real world problem.