Thanks for the feedback, it motivates me to clarify some things (IMHO propoganda about OOP) which I feel are very important and widely misunderstood. Any way, it will be useful to hear what others know and think about these matters.
You were replying to this post of mine: http://lists.motion-twin.com/pipermail/neko/2010-January/002703.html >> Haskel's OOP model is >> mathematically preferable. > > > Haskell doesn't have an OOP model. [snip] Type classes are not classes in the > OOP sense. Type classes are interfaces, which is the most OOP one can get: http://www.haskell.org/haskellwiki/?title=Why_Haskell_matters&oldid=24286#Haskell_vs_OOP http://www.haskell.org/~pairwise/intro/section2.html#part3 Virtual/prototype/base classes break "Liskov Substition Principle" and thus break large-scale interoperability and composeability. I explained that in the post you are replying to. If you read the links I provided in my prior post, you see the example where one codes a reference to a CSet interface as seen with the eyeballs in the code, but gets a CBag semantics at runtime. It becomes impossible to reason about interoperability and composeability over infinite scale of mashups, when one can't declare the interfaces one will be operating on. In short, breakage and deadlocks on interoperability, i.e. bugs and failure to scale. Not OOP. Note this can devolve into a very religious discussion, but I urge you to go wikipedia the fundamental theorems of computer science that I enumerated and reflect deeply on how they impact on OOP, interoperability, and composeability: http://www.haskell.org/pipermail/haskell-cafe/2009-November/068432.html What works "elegantly" for a monolithic project, does not mean it will scale out to unsynchronized efforts (developers) at WWW-scale of networking: http://lists.parrot.org/pipermail/parrot-dev/2010-January/003679.html So we may have a personal preference for "elegant" dynamic languages to improve our workflow for our inward looking projects, but if we start thinking about how we can all "code once" and reuse and mashup every where, then the models have to change. We have to study fundamental theorems that impact such ability to scale. >> Seems to me that the interoperability of at the common data type layer >> of >> NekoVM could be modified seamlessly to reach into binary compatibility >> with native C, with 20% effort. But that needs more study. >> > > This presupposes that compatibility with the C virus is a desirable trait, > doesn't it? If you are referring the potential for breaking out of the security sandbox, then I want to refer to my discussions about the "security" oxymoron in my very first post: http://lists.motion-twin.com/pipermail/neko/2010-January/002691.html I think our systems will be more secure if we get rid of the sandbox (e.g. the browser sandbox), and we proliferate more diverity of code and interfaces. For example, people will then be motivated to encrypt all their files on local media, i.e. adopt network-interoperable media strategies, and someone will learn how to produce keyboard drivers and OSes that can prevent keyboard sniffing during the time someone is typing into a password field. I think the current sandbox approaches erect walls in the wrong places, akin to cutting off our nose to remove a bad smell. But it will not be an easy transistion, especially as long as huge monolithic platforms are entrenched, e.g. Windows, LAMP, etc. But at some point, the floodgates open (Berlin wall falls) and there is technology eruption to greater levels of interoperability. I see this happening for example new standard for being able to manipulate local files in the browser without trigger the sandbox. All barriers to entropy must fall (decay) eventually. The hard part is being in sync with the timing in nature. The Water Lily doubles it's coverage of a pond every day and on the 29th day, it covers the remaining half of the pond. The catches the human's linear mind off guard. I think this same human inability to comprehend exponential scale, is what drives the local preferences for some "elegant" paradigms that can't scale. -- Neko : One VM to run them all (http://nekovm.org)
