As apparently all of us are into learning, I hope you don't mind:
Incorrect name: Knan -> Khan Missing verb: I them to be horrendous -> I find them to be horrendous (I guess) Different word: shutter to think -> shudder to think
I just started my daughter, age 5, on Scratch (http://scratch.mit.edu/). The problem is that she is limited as much by some design choices as by her age. For example, icons and widgets are fairly small to click on; some functions can be accessed by right mouse click (or long left click) context menus; there is no full screen mode, i.e. a child can accidentally switch out of the program; and the worst offense, it requires numerical input. This last one would be easy to fix by sliders: very simple for continuous variables, and the number of dots could be used for small integers (such as number of loop iterations). Otherwise she enjoys it a lot, but I need to unnecessarily attend to any time numeric fields are involved. Anyone know of an alternative that adheres closer to its charter?
Mod parent up. The polar regions are also more promising for finding water, and lacking an atmosphere, plants really don't need to have strong, perpendicular sunshine.
50m2 is not the size of ultra-efficiency apartments. A regular studio apartment can be a lot smaller and even that is not be ultra-efficiency - which I think is somewhere between around 16m2 and Bender's apartment. Does not change the validity of your point - indeed 50m2 sounds insufficient for oxygen alone, let alone harvesting and some backup capacity. If the author didn't know about microgravity plant growth, I wonder how he got this one.
> No one ever seriously thought a 2880x 1800 display was going to exist
Maybe it should be assumed that an N x M display will exist, where N and M are natural numbers. It'll be OK until the introduction of oval etc. displays.
The human brain itself is famous for its mosaic aneuploidy (http://en.wikipedia.org/wiki/Aneuploidy#Somatic_mosaicism_in_the_nervous_system), which is similar to having different genes in that the number of chromosome copies have a lot of gene expression significance (think of trisomy 21, for example). So as wonderful it sounds, it's nothing out of the ordinary. In biology, you can start research by going against something like the central dogma and finding counterexamples. Retrovirus, platypus, photosynthetizing animals ad nauseam. Also, as radiation causes mutation, presumably at the cell level, it would be a small wonder if genes were the same in a multibillion-cell organization.
Another must read is Vernor Vinge: Fast Times at Fairmont High.
*** SPOILER ALERT *** *** SPOILER ALERT *** *** SPOILER ALERT *** An interesting concept is that instead of decorating your wall and environments, you just augment reality. Also, depending on the level of intimacy, family members and some guests are granted the privilege of seeing through the wall (achieved by cameras dispersed all over and a view reconstructed from several of them from the viewer's position, overlaid on the wall).
How useful OO is interesting, because it is possibly one of the first uses of OO as applied to modeling wetware behavior, and there must be some lessons learned.
Calling it OO may be something to do with a superficial aspect of the realization, but at its core, it looks like a giant filter where the external signals to be processed are the time series of stimuli to the cell (chemical gradients near the cell etc.) and the results are probability distributions of the actions of the cell (both internal and external). The giant filter is itself composed of a large number of more elementary filters, or in other words, mathematical functions (probably stochastic differential equations) that take time series data and output time series data. So it's fundamentally a network of SDEs. Modeling it as such seems to be the way and I don't know what value OO adds, other than grouping SDEs, possibly in a hierarchical manner. Is there a reliance on polymorphism, inheritance, multiple inheritance, single method dispatch, multiple method dispatch, and objects potentially changing their class in run-time? Was there a modeling challenge due to a large number of interactions between "objects" relative to an ordinary OO design, because of the wide range of interactions and cross-talk that characterizes cellular biology? How were these solved, and are there lessons learned as far as OO modeling is concerned? Are there limitations caused by using OO?
I wonder how naturally an object oriented design worked out, given that molecular pathways are extremely complex and there are causal links between almost any pairs of phenomena. While OO is OK for CAD and man-made things, nature was much less restrained about high cohesion, low coupling, encapsulation and other heuristics. So the details would be interesting about inheritance, state representation, graph complexity, time-varying behavior etc.
"This intelligent co-pilot is starkly contrasted with Google's self-driving cars"
There is no stark contrast except in the minds of those who dramatize without much technical understanding. The technology behind both is largely similar. As part of the technology process, it is likely that the MIT type of application will be widely commercialized first, for these reasons:
- Today's people buy into most things that increase their safety, and the market is large (elderly folks, night drivers etc.) - It's easier to get societal acceptance to pose automatic driving as a life saving measure, unlike "taking the weels off my hand" - This is possible at an earlier stage of maturity (after all, its main risk is that it takes control when it shouldn't) - There is already an evolutionary trend from ABS through parking assist to lane detection to advance car brake detection to automated parking and
Excellent post, platypus and all. There are some ways of dealing with these effects. It's not a defense of object orientation, I'm more into functional programming and polymorphism, and feel uneasy when someone thinks "encapsulation" is such an integral concept to OO. So instead, here are a few things that _can_ be done about platypi (?) and real life ready modeling:
1. Some languages (e.g. Common Lisp) allow you to change the class of an object. The programmer can support such conversions by setter functions that get executed automatically (maybe lazily) when, for example, a new slot that is characteristic to the new class is read. 2. Multiple inheritance enables multiple roles for an object. 3. In Lisp, you can even automatically generate by code some of the above (at compile-time or at run-time), such as class changes or even the creation of a new class that inherit from other classes. Attention has to be paid so aspects are orthogonal (see next point). 4. Aspect-oriented programming 1. Identify aspects of what you model, and compose from them. For example, there is a class Person, and it has various aspects, for example as a physical person in the office, and as a holder of a job, and as a node in the organizational graph. If these concerns are kept separate, then aspects of behavior cause troubles less often. 5. Mixins. One way to do this is to define "abstract classes" that in themselves don't get instantiated, but they get mixed in into classes that do. For example, a dynamically generated subclass of a Person could have an Employee mixin or a Contractor mixin, or both! No loss of history when the class gets changed, and one mixin takes care of payroll related stuff (Employee) and the other takes care of an accounts payable account (Contractor). 6. Never delete an object! In almost all systems, deletion needs to be undoable; logs must be kept; the system must remain auditable. So it's easiest not to delete, conceptually speaking. Technically, to avoid running out of memory, an object could be archived: once its effects are properly aggregated everywhere, it can be archived to persistent storage such that it can be reloaded on request. 7. Identify what's intrinsic about an object, and never change those. Things like name, social security ID etc. are not intrinsic to a person. Often the best such "key" is the object identity itself (SQL equivalent: unique id) and nothing beyond it. 8. Everything that is not intrinsic is varying - usually as a function of time. Create those time-varying assignments (e.g. a name to a person) as a time series of separate objects. And the advice, "Never delete an object" still holds. Don't lose history of what happened to entities or their relationships. 9. As a corollary to 6,7 and 8: never change an object! Well, at least not at the conceptual level. If an object has a technical purpose (it serves a technical _aspect_ of the solution) such as maintaining a rolling time series aggregation or other caching so things don't have to be recalculated from scratch every time, those must change and you control how its time-varying behavior works (e.g. by saving daily and monthly aggregates). Which requires... 10. Aspect oriented programming 2. Now it's not in terms of modeled entity behavior, but the behaviors of your system. Spaghetti code (by extension, almost everyone's code) is characterized by a haphazard mixture of aspects, similarly to how the gut's content is a mixture of what went in, we want no sight of it. Often, a well-intentioned function starts by going through a series of assertions or other validations, then some precomputations happen, and some output (into a log, the console and as a function return value), and of course there are some other side effects that are made. Aspect oriented programming separates concerns. Make sure that you decompose your function into these: a pure (side effect free) function that just return a result purely based on its inputs and nothing else, and is understood by a literate domain expert. For example, a loan
Buying a used but well maintained lab microscope gives you solid optics, stability and motivation to use. If it's kept in a visible place, it'll trigger the want to use it.
He's been doing SAP since 1988, it destroys neurons after several years. He might be a millionaire so he can afford a non-traditional thrill-seeking lifestyle. Or he took even larger bribes from the competitors just to put SAP's name in the papers. Either way the guy showed initiative in Finance just as in Logistics:-)
For example, use analog circuitry for FP operations and do an ADC at the end only.Sometimes just a few transistors in analog mode can replace thousands of digital ones.
Before handing out sweeping compliments like that, it's better to clarify the purpose of the calculations. "Real financial companies" are a big group and their use of computing is diverse, and representing money as floating point numbers is doable for certain tasks in certain ways. It is sometimes worth the trade-off. One can not just mindlessly choose currency amount representations (whether including or excluding IEEE 754 floats), because in non-trivial financial problems you cannot usually ignore the functional and non-functional (e.g. speed) impact of whatever representation is chosen.
Such an inherently visual topic is not visualized in the article, shame. Who cares how exactly the projector glasses look like. What needs to be shown, is a pair of pictures: on the left, normal vision. On the right, how the same environment looks like with the new technique.
Don't spend millions on advertising; spend them to create a desktop experience of reasonable quality, and a decent office package. For office applications, the quality threshold is either the MS Office level with full compatibility (this is not given now), OR an office package that's way superior to the MS Office package (this latter seems to be easier and more meaningful, but OpenOffice/LibreOffice et al are POS uninspired, unconvincing copycats of decent but uninspired clones of 70's and 80's products). Also, stop the fragmentation; let there be one major Linux desktop. In general, do what Apple does.
The compass works (well, to the extent it does) when the phone is horizontal (and that way only, AFAIK); accelerometers etc. work all different ways, and AR software *could* take orientation into account. And btw. with augmented reality, all kinds of positions should be prepared for by the browser vendor. With a ducttaped baseball cap headgear, Layar's use case is invalid - you don't wander around in Rome searching for the nearest pizzeria (nothing wrong with the contraption but the baseball caps suck in general, esp. on tourists). In a headgear like that, you would probably crawl under a car, trying to repair it from overlaid CAD drawings, or go into a cave, an oil pipe or in general, anywhere dark (literally and figuratively) with no other people around. Just add more ducttape to fasten to the head and it becomes useful.
He could have reduced the CV value of the gear if he didn't use double mirroring - i.e. the phone could be horizontal, screen down. One fewer mirror is better quality. Software can mirror the screen contents (I tried an Iphone in a similar setup, using the car windshield as the mirror). As a next project, the camera could continuously monitor the user's eyeballs and determine where in the real life and on the screen he is looking at, including depth! Also, whenever an image is shown on the screen to augment reality, the phone uses not plain images but light field camera (Lytro; might go on the hat too) pictures so it can be refocused as the user's eyes indicate various depth. Stuff like this becomes almost practical: http://vimeo.com/timoarnall/light-painting-wifi and add CMU Johnny Chung Lee's techniques for depth simulation (http://www.youtube.com/watch?v=Jd3-eiid-Uw&feature=player_detailpage#t=165s) and motion tracking (Minority Report). Maybe for better precision, use some laser light to determine the focus depth and exact direction the user looks at. Then Apple should blow 10Bn on converting the entire gear into one fashionable eyepiece, that doubles as sunglasses, available with a black or - much later - white frame. _That_ will bring the CV value down.
The GP's question was something else - how did they initially tell it was _not_ regular C (as that obviously lacks the fingerprint of OO techniques of C++). Or if it didn't look like regular C or anything else, why didn't they just assume it was written in assembly, or some other rare machine code generating language like Common Lisp?
Slashdot Mirror
As apparently all of us are into learning, I hope you don't mind:
Incorrect name: Knan -> Khan
Missing verb: I them to be horrendous -> I find them to be horrendous (I guess)
Different word: shutter to think -> shudder to think
I just started my daughter, age 5, on Scratch (http://scratch.mit.edu/). The problem is that she is limited as much by some design choices as by her age. For example, icons and widgets are fairly small to click on; some functions can be accessed by right mouse click (or long left click) context menus; there is no full screen mode, i.e. a child can accidentally switch out of the program; and the worst offense, it requires numerical input. This last one would be easy to fix by sliders: very simple for continuous variables, and the number of dots could be used for small integers (such as number of loop iterations). Otherwise she enjoys it a lot, but I need to unnecessarily attend to any time numeric fields are involved. Anyone know of an alternative that adheres closer to its charter?
Mod parent up. The polar regions are also more promising for finding water, and lacking an atmosphere, plants really don't need to have strong, perpendicular sunshine.
50m2 is not the size of ultra-efficiency apartments. A regular studio apartment can be a lot smaller and even that is not be ultra-efficiency - which I think is somewhere between around 16m2 and Bender's apartment. Does not change the validity of your point - indeed 50m2 sounds insufficient for oxygen alone, let alone harvesting and some backup capacity. If the author didn't know about microgravity plant growth, I wonder how he got this one.
Go read books produced on matrix printers. Your limits may not apply to others.
> No one ever seriously thought a 2880x 1800 display was going to exist
Maybe it should be assumed that an N x M display will exist, where N and M are natural numbers. It'll be OK until the introduction of oval etc. displays.
The human brain itself is famous for its mosaic aneuploidy (http://en.wikipedia.org/wiki/Aneuploidy#Somatic_mosaicism_in_the_nervous_system), which is similar to having different genes in that the number of chromosome copies have a lot of gene expression significance (think of trisomy 21, for example). So as wonderful it sounds, it's nothing out of the ordinary. In biology, you can start research by going against something like the central dogma and finding counterexamples. Retrovirus, platypus, photosynthetizing animals ad nauseam. Also, as radiation causes mutation, presumably at the cell level, it would be a small wonder if genes were the same in a multibillion-cell organization.
Another must read is Vernor Vinge: Fast Times at Fairmont High.
*** SPOILER ALERT ***
*** SPOILER ALERT ***
*** SPOILER ALERT ***
An interesting concept is that instead of decorating your wall and environments, you just augment reality.
Also, depending on the level of intimacy, family members and some guests are granted the privilege of seeing through the wall (achieved by cameras dispersed all over and a view reconstructed from several of them from the viewer's position, overlaid on the wall).
Federal agents must be going through iranian IP addresses of the Cryptography course on Coursera.
Thank you for the answer! Not having access to the body of the article, it is informative.
I bumped into this cool video: http://www.youtube.com/watch?v=au4sl9CjKFU
How useful OO is interesting, because it is possibly one of the first uses of OO as applied to modeling wetware behavior, and there must be some lessons learned.
Calling it OO may be something to do with a superficial aspect of the realization, but at its core, it looks like a giant filter where the external signals to be processed are the time series of stimuli to the cell (chemical gradients near the cell etc.) and the results are probability distributions of the actions of the cell (both internal and external). The giant filter is itself composed of a large number of more elementary filters, or in other words, mathematical functions (probably stochastic differential equations) that take time series data and output time series data. So it's fundamentally a network of SDEs. Modeling it as such seems to be the way and I don't know what value OO adds, other than grouping SDEs, possibly in a hierarchical manner. Is there a reliance on polymorphism, inheritance, multiple inheritance, single method dispatch, multiple method dispatch, and objects potentially changing their class in run-time? Was there a modeling challenge due to a large number of interactions between "objects" relative to an ordinary OO design, because of the wide range of interactions and cross-talk that characterizes cellular biology? How were these solved, and are there lessons learned as far as OO modeling is concerned? Are there limitations caused by using OO?
I wonder how naturally an object oriented design worked out, given that molecular pathways are extremely complex and there are causal links between almost any pairs of phenomena. While OO is OK for CAD and man-made things, nature was much less restrained about high cohesion, low coupling, encapsulation and other heuristics. So the details would be interesting about inheritance, state representation, graph complexity, time-varying behavior etc.
"This intelligent co-pilot is starkly contrasted with Google's self-driving cars"
There is no stark contrast except in the minds of those who dramatize without much technical understanding. The technology behind both is largely similar. As part of the technology process, it is likely that the MIT type of application will be widely commercialized first, for these reasons:
- Today's people buy into most things that increase their safety, and the market is large (elderly folks, night drivers etc.)
- It's easier to get societal acceptance to pose automatic driving as a life saving measure, unlike "taking the weels off my hand"
- This is possible at an earlier stage of maturity (after all, its main risk is that it takes control when it shouldn't)
- There is already an evolutionary trend from ABS through parking assist to lane detection to advance car brake detection to automated parking and
Excellent post, platypus and all. There are some ways of dealing with these effects. It's not a defense of object orientation, I'm more into functional programming and polymorphism, and feel uneasy when someone thinks "encapsulation" is such an integral concept to OO. So instead, here are a few things that _can_ be done about platypi (?) and real life ready modeling:
1. Some languages (e.g. Common Lisp) allow you to change the class of an object. The programmer can support such conversions by setter functions that get executed automatically (maybe lazily) when, for example, a new slot that is characteristic to the new class is read.
2. Multiple inheritance enables multiple roles for an object.
3. In Lisp, you can even automatically generate by code some of the above (at compile-time or at run-time), such as class changes or even the creation of a new class that inherit from other classes. Attention has to be paid so aspects are orthogonal (see next point).
4. Aspect-oriented programming 1. Identify aspects of what you model, and compose from them. For example, there is a class Person, and it has various aspects, for example as a physical person in the office, and as a holder of a job, and as a node in the organizational graph. If these concerns are kept separate, then aspects of behavior cause troubles less often.
5. Mixins. One way to do this is to define "abstract classes" that in themselves don't get instantiated, but they get mixed in into classes that do. For example, a dynamically generated subclass of a Person could have an Employee mixin or a Contractor mixin, or both! No loss of history when the class gets changed, and one mixin takes care of payroll related stuff (Employee) and the other takes care of an accounts payable account (Contractor).
6. Never delete an object! In almost all systems, deletion needs to be undoable; logs must be kept; the system must remain auditable. So it's easiest not to delete, conceptually speaking. Technically, to avoid running out of memory, an object could be archived: once its effects are properly aggregated everywhere, it can be archived to persistent storage such that it can be reloaded on request.
7. Identify what's intrinsic about an object, and never change those. Things like name, social security ID etc. are not intrinsic to a person. Often the best such "key" is the object identity itself (SQL equivalent: unique id) and nothing beyond it.
8. Everything that is not intrinsic is varying - usually as a function of time. Create those time-varying assignments (e.g. a name to a person) as a time series of separate objects. And the advice, "Never delete an object" still holds. Don't lose history of what happened to entities or their relationships.
9. As a corollary to 6,7 and 8: never change an object! Well, at least not at the conceptual level. If an object has a technical purpose (it serves a technical _aspect_ of the solution) such as maintaining a rolling time series aggregation or other caching so things don't have to be recalculated from scratch every time, those must change and you control how its time-varying behavior works (e.g. by saving daily and monthly aggregates). Which requires...
10. Aspect oriented programming 2. Now it's not in terms of modeled entity behavior, but the behaviors of your system. Spaghetti code (by extension, almost everyone's code) is characterized by a haphazard mixture of aspects, similarly to how the gut's content is a mixture of what went in, we want no sight of it. Often, a well-intentioned function starts by going through a series of assertions or other validations, then some precomputations happen, and some output (into a log, the console and as a function return value), and of course there are some other side effects that are made. Aspect oriented programming separates concerns. Make sure that you decompose your function into these: a pure (side effect free) function that just return a result purely based on its inputs and nothing else, and is understood by a literate domain expert. For example, a loan
... or is it an attempt at some self-congratulatory celebration that just needs more spectactors?
(my question is a bit recursive...)
What a biased and egoistic worldview.
Buying a used but well maintained lab microscope gives you solid optics, stability and motivation to use. If it's kept in a visible place, it'll trigger the want to use it.
He's been doing SAP since 1988, it destroys neurons after several years. He might be a millionaire so he can afford a non-traditional thrill-seeking lifestyle. Or he took even larger bribes from the competitors just to put SAP's name in the papers. Either way the guy showed initiative in Finance just as in Logistics :-)
For example, use analog circuitry for FP operations and do an ADC at the end only.Sometimes just a few transistors in analog mode can replace thousands of digital ones.
Before handing out sweeping compliments like that, it's better to clarify the purpose of the calculations. "Real financial companies" are a big group and their use of computing is diverse, and representing money as floating point numbers is doable for certain tasks in certain ways. It is sometimes worth the trade-off. One can not just mindlessly choose currency amount representations (whether including or excluding IEEE 754 floats), because in non-trivial financial problems you cannot usually ignore the functional and non-functional (e.g. speed) impact of whatever representation is chosen.
and the root cause was the exposure of the ship to the aggressive metal-destroying properties of crystalline hidrogen-oxide.
Such an inherently visual topic is not visualized in the article, shame.
Who cares how exactly the projector glasses look like.
What needs to be shown, is a pair of pictures: on the left, normal vision. On the right, how the same environment looks like with the new technique.
Don't spend millions on advertising; spend them to create a desktop experience of reasonable quality, and a decent office package. For office applications, the quality threshold is either the MS Office level with full compatibility (this is not given now), OR an office package that's way superior to the MS Office package (this latter seems to be easier and more meaningful, but OpenOffice/LibreOffice et al are POS uninspired, unconvincing copycats of decent but uninspired clones of 70's and 80's products). Also, stop the fragmentation; let there be one major Linux desktop. In general, do what Apple does.
The compass works (well, to the extent it does) when the phone is horizontal (and that way only, AFAIK); accelerometers etc. work all different ways, and AR software *could* take orientation into account. And btw. with augmented reality, all kinds of positions should be prepared for by the browser vendor. With a ducttaped baseball cap headgear, Layar's use case is invalid - you don't wander around in Rome searching for the nearest pizzeria (nothing wrong with the contraption but the baseball caps suck in general, esp. on tourists). In a headgear like that, you would probably crawl under a car, trying to repair it from overlaid CAD drawings, or go into a cave, an oil pipe or in general, anywhere dark (literally and figuratively) with no other people around. Just add more ducttape to fasten to the head and it becomes useful.
He could have reduced the CV value of the gear if he didn't use double mirroring - i.e. the phone could be horizontal, screen down. One fewer mirror is better quality. Software can mirror the screen contents (I tried an Iphone in a similar setup, using the car windshield as the mirror). As a next project, the camera could continuously monitor the user's eyeballs and determine where in the real life and on the screen he is looking at, including depth! Also, whenever an image is shown on the screen to augment reality, the phone uses not plain images but light field camera (Lytro; might go on the hat too) pictures so it can be refocused as the user's eyes indicate various depth. Stuff like this becomes almost practical: http://vimeo.com/timoarnall/light-painting-wifi and add CMU Johnny Chung Lee's techniques for depth simulation (http://www.youtube.com/watch?v=Jd3-eiid-Uw&feature=player_detailpage#t=165s) and motion tracking (Minority Report). Maybe for better precision, use some laser light to determine the focus depth and exact direction the user looks at. Then Apple should blow 10Bn on converting the entire gear into one fashionable eyepiece, that doubles as sunglasses, available with a black or - much later - white frame. _That_ will bring the CV value down.
Haha what content???
The GP's question was something else - how did they initially tell it was _not_ regular C (as that obviously lacks the fingerprint of OO techniques of C++). Or if it didn't look like regular C or anything else, why didn't they just assume it was written in assembly, or some other rare machine code generating language like Common Lisp?