Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!postnews.google.com!d17g2000vbv.googlegroups.com!not-for-mail From: micha Newsgroups: comp.lang.java.programmer Subject: Re: Single Class Object Model - new release Date: Mon, 11 Jun 2012 21:42:40 -0700 (PDT) Organization: http://groups.google.com Lines: 62 Message-ID: <169b14d7-e43d-482d-a195-bcd20965331a@d17g2000vbv.googlegroups.com> References: <9562a637-4191-42c2-a4b2-a2db589cd820@googlegroups.com> <787f166d-488f-49fe-aa1f-bd8e227ed30e@eh4g2000vbb.googlegroups.com> NNTP-Posting-Host: 78.245.44.15 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1339476508 31142 127.0.0.1 (12 Jun 2012 04:48:28 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 12 Jun 2012 04:48:28 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: d17g2000vbv.googlegroups.com; posting-host=78.245.44.15; posting-account=hm5crAoAAADluICY4BUEtpatfVdXh3wT User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.52 Safari/536.5,gzip(gfe) Xref: csiph.com comp.lang.java.programmer:15223 On 12 juin, 03:55, Leif Roar Moldskred wrote: > micha wrote: > > - moreover as a way to show that it(s not mandatory that the > > usefulness of an object model resideds in it's API (the default > > assumption), but instead in the semantic network of instances that you > > can build with it, that's the main idea within SCOM: it's instances > > are easily assembled in a semantic network by using triples as the > > semantic atom (Subject --predicayte--> Object, like RDF which is the > > foundation of Semantic Web) > > Wouldn't it be easier and more convenient to just program in Common > Lisp from the get go? (The above just strikes me as an example of > Greenspun's tenth rule in action.) > > -- > Leif Roar Moldskred Hello Leif Thanks for the Greenspun's tenth rule (thought I matbe heard about it long time ago but that's a nice piece of thinking to highlight for sure) Well, Lisp especially Common Lisp is pure in the intention not so much in the facts: there's a huge number of functions in Common Lisp, not all absolutely legitimate to be in the core of a language, then there was Scheme which seems to be a 'minimalist Scheme'. In fact all functional languages share this property to leverage the expressiveness, now we have functional (lambda calculus) in a wide variety of flavors even some on JVM (Scala, Groovy, Clojure) or CLR (Clojure, F#) BUT nevertheless Java has an unsurpassed firepower with tons of libraries, frameworks and dialects, so it could be useful if only for that reason (while Lisp developers have much more trouble to find software components for their needs so they may find themselves working hard to wrap a java component for Lisp instead of writing the business domain code) AND SCOM is not only about levererage of functional programming but also: - about Adaptative Object Model (which is also already native but more in Smalltalk than in Lisp as Common Lisp is not an Object language from the start but requires an extension layer (CLOS) to support Object paradigm) - and about Semantic Web paradigm, starting with semantic networks described as triples by RDF/Owl:SCOM provides a simple and straightforward mechanism (addfacet() method) to build such 'triple based' semantic networks at runtime (like DOM is the runtime data structure counterpart of an XML file) NOW there is Scala which is both functional and Object BUT not a purely interpreted metalanguage like Lisp (Lisp allows to define new Languages with it's bootstrapping/dynamic syntax capabilities) SO SCOM is not an attempt to do better than breakthrough languages like Scala, it's only an attempt to show that within Java microcosm, there's still ways to leverage expressiveness by adopting new paradigms namely Adaptative Object Model, Semantic Web inspired runtime data structures (not by extending Java with tons of new features which address implementation needs without really adding expressiveness or in the best case clearing out some inconsistencies, like int vs Integer, [] vs ArrayList etc...)