Tux news - Linux ubuntu fedora gentoo gnome news

Etymon (20 unread)

So why can't google provide html for 40% of pdfs?

Posted: May 19th, 2008, 9:38pm CEST by Andrae Muys

p A google search for a href="http://www.google.com.au/search?hl=enclient=firefox-arls=org.mozilla%3Aen-US%3Aofficialhs=6bMas_qdr=allq=opensource+filetype%3ApdfbtnG=Searchmeta="opensource filetype:pdf/a returns the standard 10 results on the front page, but only 6 of them offer a "View as HTML" link. Is it just me, or has this become more prevalent recently? And what is the common property that results in this behaviour? /p p If anyone has any clues or ideas I would love to hear them. /p
Now this is how conference videos should be presented

Posted: January 15th, 2008, 11:40am CET by Andrae Muys

p A great collection of conference presentations and interviews (mostly on java topics) a href="http://www.parleys.com/display/PARLEYS/Home"Parleys/a - but of particular interest to me is the presentation, the best I have seen. /p
How to start thinking about RDF.

Posted: November 29th, 2007, 5:27pm CET by Andrae Muys

pWhile trying to understand RDF, its capabilities and its limitations I have done a lot of reading of earlier work on semi-structured data management. It occurs to me that I haven't blogged a paragraph from an 1995 paper on heterogeneous information sources that really crystalised for me the crucial difference between RDF and previous attempts at semi-structured data (especially XML and friends) - better late than never I suppose... /p blockquote We need note define in advance the structure of an object ... no notion of a fixed schema or object class. A label can play two roles: identifying an object (component) and identifying the meaning of an object (component). If an information source exports objects with a particular label, then we assume that the source can answer the question "What does this label mean?". It is particularly important to note that labels are relative to the source that exports them. That is, we do not expect labels to be drawn from an ontology shared by all information sources. /blockquote p Papakonstantinou, Y. et al. "Object Exchange Across Heterogeneous Information Sources", 11th Conference on Data Engineering, IEEE Computer Society, 251-260, 1995. /p p The actual framework presented in the paper is focused on intraorganisational integration and so doesn't have the property of anarchic scalability required if it is to be applied to the internet - however it does express clearly this need for source-defined semantics if semi-structured data is to be tractable.
Implementing a Resource Manger for the Java Transaction API.

Posted: October 17th, 2007, 5:03pm CEST by Andrae Muys

p One would hope that when an organisation like Sun specifies a standard as important as a transaction api they might take the time to ensure they do a reasonable effort -- unfortunately you would be wrong. The JTA specification is freely available a href="http://java.sun.com/products/jta/"from Sun/a, however the document is extremely vague and requires the reader to infer the underlying transaction state machine - with the unsurprising result that the corner cases are left completely unspecified. So having waded through this morass myself, I include here my advice on what you need to do to understand JTA, in the hope that anyone else coming to this standard won't have to waste as much time as I have understanding it. /p p Read the JTA spec span style="font-weight:bold;"last/span. JTA is a little more than a thin wrapper around the a href="http://www.omg.org/cgi-bin/doc?formal/00-06-28"Object Transaction Service 1.1/a published by the OMG. This is one of the CORBA standards published in the late 90's and early 2000's - and like most of the span style="font-style:italic;"early/span CORBA specs, it is well written; easy to read; and pretty complete. Unfortunately it too leaves the underlying state-machine and some of the corner-cases (especially those to do with recovery) underspecified. As a result I recommend printing this out and referring to it as an adjunct to the JTA spec. /p p Fortunately the CORBA-OTS is itself an object-oriented wrapper around another spec, the a href="http://www.opengroup.org/bookstore/catalog/c193.htm"Distributed Transaction Processing: The XA Specification/a spec' published by X/Open (now The Open Group). There in Chapter 2 you will find span style="font-style:italic;"most/span of the definitions missing from the other two specs; and in Chapter 6 the state-tables that provide definitive semantics for the various operations you will need to implement. You will also find a reference to another related X/Open specification - a href="http://www.opengroup.org/bookstore/catalog/g504.htm"Distributed Transaction Processing: Reference Model/a - which contains all the remaining definitions and assumptions missing from the the JTA/OTS specs. /p p So if you do need to implement a JTA interface I strongly recommend you start with the X/Open reference model; then read the X/Open XA Spec; and only then read the JTA specification alongside the OTS spec for elaboration. /p
Model-URI/URL Use-cases and Requirements and Proposal

Posted: September 20th, 2007, 12:01am CEST by Andrae Muys

p span style="font-style:italic;"Just posted this to mulgara-general - posting here to provide readily accessible permanent reference./span span style="font-style:italic;"I would greatly appreciate any comments anyone may have - please also feel free to solicit comments from outside the mulgara community if there is interest. /span /p p span style="font-weight:bold;"The Use Cases and Requirements /spanbr/ The three key requirements of a model-URI proposal are: /p p 1. Protocol/Scheme independencebr/ 2. Model/Server mobilitybr/ 3. URI-standards compliance (ie. no fragment)br/ /pp Also desirable are /pp 4. Unique-namebr/ 5. Namespaced to allow a) potential resolution; b) predicable, human-readable URI's.br/ /pp The context of the most complex use-case involves 4 models and 4 machines (and assumes a Distributed or Federated Resolver) /pppre :modelA is on server1 on host1 and needs to reference :modelB and :modelC :modelB is on server2 on host2 :modelC is on server3 on host3 :modelD is on server4 on host4 run by an unrelated organisation /pre/pp The application needs to perform the query: /pppre select $id subquery( select $s $p $o where $s $p $o in $locn and $id lt;mulgara:locatedAtgt; $locn in lt;mulgara:modelURLResolvergt;) from host1:modelA where [ lt;:useModelgt; $identifier ] ; /pre/pp Which queries each model listed in :modelA after converting their identifier into a URL via a posited resolution mechanism. /pp Now host2 fails, and we restore server2 on host3 to run alongside server3. /pp We would like to be able to have the query run unmodified. /pp What this means is that :modelB cannot encode host2 in its URI. /pp The URI does need to encode some sort of server-id as servers are guaranteed to use the same model-names at least some of the time (consider all system-model's have the name ""). /pp Also because :modelD and :modelA-C are managed by unrelated organisations we must somehow encode the organisation in the model's URI-stem as they may well decide to use the same server-id ("server1" or "database" anyone?). /pp Also consider that any encoding of the organisation must also allow that organisation to maintain their own independent registry, or the proposal ceases to be scale-free (it's on this that the original UUID proposal floundered). /pp I have considered abandoning requirement 4, and just using URL's. However ultimately we require a canonical name for internal purposes (even if it isn't exposed externally), and so even using URL's we would have to pick a designated 'unique name' for the model - we can't escape that - so we might as well save ourselves the headache and make it unambiguous. /pp So a summary of my thinking on the use-cases/requirements for rdf model-names - we desire: /pp 1. Unambiguously an identifierbr/ 2. Encodes organisationbr/ 3. Encodes server-idbr/ 4. Doesn't encode hostnamebr/ 5. Potentially resolvable via a per-organisation registrybr/ /pp span style="font-weight:bold;"* Proposal/span /pp If we wish to be unambiguous then we should use our own URI-scheme. This has the added benefit that once we use our own scheme we have a lot more flexibility regarding how we structure the rest of the URI to meet our requirements. /pp I am proposing to use the scheme 'rdfdb' - as did the original UUID proposal. /pp I would prefer to avoid the use of opaque URI's; there is no reason why our URI can't be introspected if we structure it sanely - so the structure according to RFC2396 will be 'rdfdb://authority/path'. /pp Logically the model-name itself makes a good path so we arrive at 'rdfdb://authority/modelName'. Leaving the need to encode an organisation and a server-id in the authority in a fashion that will potentially permit resolution via a registry. /pp Now as the authority is not a hostname, RFC2396 identifies us as a "Registry-based Naming Authority". As such, the characters we have permitted to us are [ - _ . ! ~ * ' ( ) $ , ; : @ = + ] (excluding the []'s) - and the characters reserved are [ ? / ]. /pp I therefore propose to structure the authority 'server-id~organisation-id' (that is the server-id and org-id separated by a tilde). /pp At the moment we don't support hierarchical server-id's; but I would like to leave us the option of doing so once we start supporting more aggressive distribution. We also need to consider that it needs to remain a valid path-element for use in our existing model-URL's. So for now I would like to limit server-id to what we currently use, but ultimately I think we should consider some sort of delimited hierarchical form (probably dotted). /pp The organisation-id should be something that will eventually permit the identification of a registry. For now a dotted hierarchical form should suffice - although I will make sure the implementation leaves this as open as possible (the use of a tilde makes this possible). /pp It has also been suggested that to make it unambiguously clear we are *not* encoding a hostname as the organisation-id we should invert the traditional dns-style representation. /pp So putting all the pieces together: If I am running a mulgara server - /pppre host: pneuma.netymon.com organisation: netymon.com server-id: rdfDatabase model-name: addressBook /pre/pp The model URL for addressBook remains: rmi://pneuma.netymon.com/rdfDatabase#addressBookbr/ or: soap://pneuma.netymon.com/rdfDatabase#addressBook ...etc... /pp and the model URL for the model is: rdfdb://rdfDatabase~com.netymon/addressBook /p
Operational vs. Denotational Semantics

Posted: September 17th, 2007, 10:48pm CEST by Andrae Muys

p Spent a little time this afternoon discussing several topics with LB and SR. One topic we touched on was our continuing efforts to understand the distinction between denotational and operational semantics - I continue to be surprised at just how hard it's proving to nail down the precise distinction. /p p Looking at the various scrawls on my whiteboard that are the only physical remnants of what was a fascinating discussion, I gave some more thought to the distinction, and I believe it can be described thus: blockquote Operational : M ( P ) |= σ - σ' br/ Denotational : M ( P ) |= κ - P' br/ /blockquote ie. In Operational semantics the meaning of a program is a transition function on a virtual machine.br/ in Denotational semantics the meaning of a program is a mapping from an initial basis to a new (simplified) program. /p p Now this is confused by most operational semantics being "small-step", where the meaning is defined via structural recursion on the abstract grammar: blockquote M ( ρ ) |- σ - M (ρ') σ' { the meaning of an AST production is a transition function from an initial VM state to the meaning of a (simplified) production applied to a new VM state. } /blockquote Which end up looking very similar to denotational semantics as denotational semantics are normally defined via structural recursion. /pp But even for the similarity there remains the core distinction (as I understand it) - Denotational Semantics are defined in terms of a reduction-semantics from program+basis to a simplified program (although normally a program in a different, mathematically tractable language such as the lambda-calculus) whereas Operational Semantics are defined in terms of a transition-semantics from a program+initial-state to a new state (although normally a state extended with function-values defined in a mathematically tractable language such as the lambda-calculus). /pp Now of course Interpreter Semantics is a whole different kettle of fish, and of course leaves you facing the 'turtle problem' - you can try for 'turtles all the way down' if you like, but once you hit the metal you've pretty much lost the point of a semantics in the first place. I must admit admiring the way ECMAscript handled it - an interpreter semantics in SML, which has an operational semantics of its own avoiding the problem. /p
RDF, Document Repositories

Posted: August 30th, 2007, 7:23pm CEST by Andrae Muys

p I have recently had several discussions with people working on/with various document repository projects. One thing I hear is the increasing understanding of the importance of semantics in repository metadata management. I'm naturally pleased to see this because storage, query, and management of semantics is precisely where projects like a href="http://www.mulgara.org/"mulgara/a come in. /p p Now digital repositories are alot more than just a semantic store, there are also issues associated with the actual document storage, retrieval, and the QA, workflow, and various metadata extraction tasks. However these days most repository projects include some sort of semantic store to manage metadata, and the question is reasonably asked - why not just use that? /p p The reason I recommend considering using mulgara to augment a document repository is due to the additional flexibility gained by doing so. When a repository developer approaches the metadata problem they have a natural tendency to view adopt an 'instance-focused' view of metadata. This is where the focus is on the 'document', where each document is of a given 'document type', and each 'document type' implies corresponding 'attributes'. In contrast, RDF is 'property-focused' --- where the focus is on defining the 'meaning' of 'properties', and a 'document' having a given property 'classifies' the document as belonging to a given 'class of documents'. /p p While the two are duals they do influence design. If you are taking an instance-focused approach you will find yourself heading towards document-type hierarchies and defined attribute lists. If you take a property-focused approach you will find yourself defining lexicons and ontologies. The former tends towards relational approaches, the latter towards semantic approaches such as RDF. The reason why I believe the semantic approach to be superior is in its flexibility. Hierarchies are predicated on centralised control. Even if you can maintain central control over the document type definitions and their attributes, the very act of standardisation in this manner leaves your project with the unfortunate choice of 'scale' or 'responsive to change'. /p p RDF and its related standards allow the decentralisation of attribute/property definition, while providing the tools to manage the resulting 'mess'. With the combination of namespaces, RDFS, and assuming the provision of schema repositories, it becomes possible to allow global use and reuse of locally defined 'models'. This is especially relevant when you consider that 'local' should be considered in both temporal and spatial senses - keeping the system responsive both to the differing needs of independent organisations, and the changing requirements of a single entity. /p p The result is the need for two additional boxes in your architecture diagram. The first, a vocabulary server that allows users to define their own vocabulary extensions, and makes those definitions available to applications and critically capable of management and eventual rationalisation. The second is a metadata server that can store the resulting data and permit ad-hoc querying by applications, and the inferencing required by vocabulary rationalisation. One of the reasons a href="http://www.mulgara.org/"mulgara/a exists is to provide the storage and query engine required by these components - and so I do enjoy having the chance to talk to people about it. /p
The Effect of File Sharing on Record Sales: An Empirical Analysis

Posted: February 14th, 2007, 2:22pm CET by Andrae Muys

p emFelix Oberholzer-Gee Harvard University and Koleman Strumpf University of Kansas/em /pp stronga href="http://www.journals.uchicago.edu/JPE/journal/issues/v115n1/31618/brief/31618.abstract.html"Abstract/a/strong /pp blockquote For industries ranging from software to pharmaceuticals and entertainment, there is an intense debate about the appropriate level of protection for intellectual property. The Internet provides a natural crucible to assess the implications of reduced protection because it drastically lowers the cost of copying information. In this paper, we analyze whether file sharing has reduced the legal sales of music. While this question is receiving considerable attention in academia, industry, and Congress, we are the first to study the phenomenon employing data on actual downloads of music files. We match an extensive sample of downloads to U.S. sales data for a large number of albums. To establish causality, we instrument for downloads using data on international school holidays. Downloads have an effect on sales that is statistically indistinguishable from zero. Our estimates are inconsistent with claims that file sharing is the primary reason for the decline in music sales during our study period. /blockquote /pp In the a href="http://www.journals.uchicago.edu/JPE/papers.html"Journal of Political Economy/a. /pp Available in a href="http://www.journals.uchicago.edu/JPE/journal/contents/v115n1.html"Volume 115, Number 1, February 2007/a /pp From a href="http://arstechnica.com/news.ars/post/20070212-8813.html"Ars Technica/a via a href="http://www.lessig.org/blog/"Lawrence Lessig/a /p
Java generics and the covariance and contravariance of arguments

Posted: February 13th, 2007, 10:08pm CET by Andrae Muys

p Well given we require 1.5 now for other reasons, and 1.5 does complain if you don't constrain generic classes I have finally bitten the bullet and started using generics. Unfortunately I just got bitten by what I suspect is going to be a very common mistake - in this case by failing to properly consider the type equivalence of parametrised method calls. /p p Consider the following code: /ppre public interface TestInterface { } public class TestClass implements TestInterface { } import java.util.ArrayList; import java.util.List; public class Test { private Listlt;testclassgt; list; public TestInterface test() { list = new ArrayListlt;testclassgt;(); list.add(new TestClass()); return covariant(list); } public TestInterface covariant(Listlt;testinterfacegt; ilist) { return ilist.remove(0); } } /pre Now there is absolutely no reason why this should not work. It is trivially inferable that the above code treats ilist as covariant in the list-type - and that therefore this code is statically correct. p/pp Of course Java's typing has never been particularly smart. Listlt;t1gt;.add(T1) is contra-variant in t1, and T2 Listlt;t2gt;.get(int) is co-variant in t2; so the Java compiler is correct to infer that in the general case Listlt;t1gt; and Listlt;t2gt; are substitutable iff t1 == t2. /pp If we can't declare a generic parameter to be covariant in its type parameter we have a serious problem - it means that any non-trivial algorithm involving collections is going to run afoul of this. You might consider trying to cast your way around it: /ppre public TestInterface test() { list = new ArrayListlt;testclassgt;(); list.add(new TestClass()); return covariant((Listlt;testinterfacegt;)list); } /pre but not surprisingly that didn't work. pre Test.java:11: inconvertible types found : java.util.Listlt;testclassgt; required: java.util.Listlt;testinterfacegt; return convariant((Listlt;testinterfacegt;)list); ^ 1 error /pre If you continue to hack at it you might try a double cast via a non-generic List. pre public TestInterface test() { list = new ArrayListlt;testclassgt;(); list.add(new TestClass()); return covariant((Listlt;testinterfacegt;)((List)list)); } /pre This works but leaves us with the unchecked/unsafe operation warning: pre Note: Test.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /pre Now this is a perfectly reasonable warning - it is unchecked; it is unsafe; and more importantly it emdoes violate encapsulation/em. The problem here is that the caller should not be defining the type invariants of the callee - that's the job of the method signature! p/pp The correct solution is to allow us to declare covariant() to be covariant in its argument; and fortunately Java does support this. /pp To declare an argument to be covariant in its type parameter you can use the extends keyword: /ppre public TestInterface covariant(Listlt;? extends TestInterfacegt; ilist) { return ilist.remove(0); } /pre To declare an argument to be contravariant in its type parameter you use the super keyword: pre public void contravariant(Listlt;? super TestClassgt; clist, TestClass c) { clist.add(c); } /pre Without these two facilities generics would be badly broken, so I am glad Sun had the presence of mind to include them - btw if you are using Java 1.5 I strongly recommend you read the a href="http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf"Java Generics Tutorial/a p/pp As an aside it is worth noting that as Java includes a Top type 'Object', List is a common covariant type - sufficiently common that Sun has included a syntactic sugar for it, List. Personally I'm not sure this was such a good idea, List would work anyway, and I think I would prefer to have kept the covariance explicit. /p p Update: Corrected capitalisation error in initial java example. /p
Five things to consider when writing a Mulgara Resolver

Posted: February 6th, 2007, 7:11pm CET by Andrae Muys

p Ended up writing a longer response than I had planned to a query about a href="http://mulgara.org/pipermail/mulgara-dev/2007-February/000323.html"writing a resolver/a in a href="http://www.mulgara.org/"Mulgara/a today. I'm putting it here to keep a handle to it as it does cover the basic structure of the resolve() method in reasonable detail. /pp First it is important to realise that resolvers *don't* return triples - they return Resolutions. These are Tuples that provide bindings for the variables in the Constraint passed to resolve(). So in the case of lt;http://www.example.com/path/subpathgt; $predicate $object the resulting Resolution should have two variables ($predicate $object). In the case of lt;../subpathgt; lt;http://www.schema.com#parentgt; $subpath it will have one ($subpath). /pp You should also be aware that a Resolution can be unevaluated! It is not uncommon for bindings, required to evaluate the constraint, come from other parts of the query. Consider the following where clause: pre $url $p $o in lt;rmi://localhost/server1#samplegt; and lt;myfilegt; lt;hasurlgt; $url /pre in this case your resolver will be asked to resolve ($url $p $o), return a Resolution that will later be passed the $url in the prefix argument to beforeFirst(). Evaluation would then occur either in beforeFirst() or in the calls to next() - we prefer it to happen in beforeFirst if the memory requirement isn't unreasonable, our algorithmic reasoning assumes a comparatively cheap next(). /pp If you require that a particular variable be bound prior to final evaluation then you need to provide a MandatoryBindingAnnotation - this indicates to the join logic that it must ensure a specific binding is satisfied by other constraints in the query before you are evaluated (in this case $url). /pp It is also worth noting that due to the support of intervals and the resulting interaction with query transformations, the XSDResolver is quite complicated as resolvers go. Without that a call to resolve consists of: ol liObtaining the model (constraint.getModel())./li liDo any preparatory work, especially any work that might be able to prove the result Empty (or a singleton)./li liIf you can't prove the result empty (or singleton), defer further evaluation to the returned Resolution./li /ol Then inside the Resolution you need to consider how you implement the following four key methods dl dtMandatoryBindingAnnotation/dt ddare there any variables that *must* be bound for the deferred evaluation to terminate./dd dtDefinablePrefixAnnotation/dt ddcan you cheaply reorder the variables in the result (log n or less)/dd dtReresolvableResolution/dt ddcan you cheaply reresolve the constraint if additional information becomes available (again log n or less) [note: this will become an Annotation like the other two in the Mulgara 1.2 dev-cycle]/dd dtbeforeFirst()/dt ddyou can ignore the suffixTruncation arg, but you can't ignore the prefix - these *are* the values of the first N variables of the resolution - if all the variables are passed as a prefix your only decision is 1 row or 0 - but most of the time you will be passed less than this./dd /dl At this point you have either performed the evaluation, or you have setup the evaluation and deferred the rest to be done incrementally on each call to next(). dl dtnext()/dt dddoes whatever is required to ensure that calls to getColumnValue()./dd /dl There is only one Tuple class that defers evaluation beyond this point (the implementation of count()). Naturally we don't want to go to the effort of evaluating an entire subquery until the user actually goes to use it - so we defer evaluation of the count() until the call to getColumnValue(). dl dtgetColumnValue()/dt ddnormally this is a matter of returning values calculated in either beforeFirst() or next() - occasionally this amounts to evaluating it but this is uncommon./dd /dl /pp The whole point of the Resolution/Tuples/beforeFirst/next bother is to implement lazy-evaluation in java. We only scale to bignum-levels when all query evaluation is done on a call-by-need basis. /p
Ok now this is too cool for words.

Posted: February 2nd, 2007, 11:07pm CET by Andrae Muys

pIf you are a fan of Pratchett you have to checkout a href="http://homepages.tesco.net/janefisk/discworld/discworld.htm"The Great A'Tuin as a wedding cake/a!/p
Umm, would you mind if we borrowed your DPP?

Posted: January 25th, 2007, 11:17am CET by Andrae Muys

pemfrom a href="http://www.boingboing.net/"boingboing/a/em/p pFinally a public official has the courage to a href="http://politics.guardian.co.uk/terrorism/story/0,,1997247,00.html"speak sense/a. blockquote "London is not a battlefield. Those innocents who were murdered on July 7 2005 were not victims of war. And the men who killed them were not, as in their vanity they claimed on their ludicrous videos, 'soldiers'. They were deluded, narcissistic inadequates. They were criminals. They were fantasists. We need to be very clear about this. On the streets of London, there is no such thing as a 'war on terror', just as there can be no such thing as a 'war on drugs'. "The fight against terrorism on the streets of Britain is not a war. It is the prevention of crime, the enforcement of our laws and the winning of justice for those damaged by their infringement." /blockquote If this was the only sentiment I would applaud, but to see his respect for the rule of law gives me hope our nations can come through this intact. blockquote "We wouldn't get far in promoting a civilising culture of respect for rights amongst and between citizens if we set about undermining fair trials in the simple pursuit of greater numbers of inevitably less safe convictions. On the contrary, it is obvious that the process of winning convictions ought to be in keeping with a consensual rule of law and not detached from it. Otherwise we sacrifice fundamental values critical to the maintenance of the rule of law - upon which everything else depends." /blockquote There is no right, no principle, no aspect of our 'way of life' that isn't completely dependent on the rule of law. Without rule of law every other guarantee, social contract, or bill of rights is moot - completely and absolutely unenforcable and thereby irrelevant. /pp Note to any political types who might read this: This is a vote swinger. The courage to respect and maintain rule of law in the face of fear is my definition of leadership, and what I am looking for above all when deciding my vote. /p
Erlang in 5 seconds.

Posted: September 13th, 2006, 8:08pm CEST by Andrae Muys

p There was recently a thread on erlang-questions that discussed how you would present Erlang in 5 seconds. In an unrelated thread it is possible Richard Carlsson managed to nail it: blockquote In most respects, Erlang _is_ a concurrent, nondestructive Lisp with a Prolog-inspired syntax that focuses on pattern matching and rules. /blockquote /p p For my own reference he original email: blockquote pre Nick Linker wrote: I wonder why Erlang is not Lisp? I mean why inventors of Erlang chose to create its own language instead of creating just ERTS-specific library for LISP (or at least Scheme)? Here are some reasons why Lisp might not be a perfect match to the problem they wanted to solve: - no built-in concurrency - destructive updates abound (in Scheme, too) - no pattern matching And if you're going to fix those things, you might as well use a syntax that feels more comfortable to you. In particular, pattern matching makes function definitions and selective receives much more readable, which I assume was an important goal for the kind of industrial applications that Erlang was created for. In most respects, Erlang _is_ a concurrent, nondestructive Lisp with a Prolog-inspired syntax that focuses on pattern matching and rules. /Richard /pre /blockquote /p
The Monad Laws

Posted: September 13th, 2006, 1:26pm CEST by Andrae Muys

p Every now and then I come across a post that explains a concept so clearly it is inspiring. I'd like to thank Albert Lai for just such a post. a href="http://haskell.org/haskellwiki/Monad_Laws"Re: [Haskell-cafe] Monad laws/a blockquote pre Deokhwan Kim dk@xxxxx.xxx.ac.kr writes: What is the practical meaning of monad laws? 1. (return x) = f == f x 2. m = return == m 3. (m = f) = g == m = (\x - f x = g) I offer to re-write the laws in do-notation. (Please view with a fixed-width (non-proportional) font.) 1. do { x' - return x do { f x ; f x' == } } 2. do { x - m == do { m ; return x } } 3. do { y - do { x - m do { x - m ; f x ; do { y - f x } == ; g y ; g y } } } do { x - m using 3.14 ; y - f x == ; g y } I think in this notation everyone sees the laws as plain common sense. If you do write a monad that doesn't follow some common sense, the dire consequence (practical or theoretical) is obvious. Just in case it is still not obvious to somebody... When we see a program written in a form on the LHS, we expect it to do the same thing as the corresponding RHS; and vice versa. And in practice, people do write like the lengthier LHS once in a while. First example: beginners tend to write skip_and_get = do { unused - getLine ; line - getLine ; return line } and it would really throw off both beginners and veterans if that did not act like (by law #2) skip_and_get = do { unused - getLine ; getLine } Second example: Next, you go ahead to use skip_and_get: main = do { answer - skip_and_get ; putStrLn answer } The most popular way of comprehending this program is by inlining (whether the compiler does or not is an orthogonal issue): main = do { answer - do { unused - getLine ; getLine } ; putStrLn answer } and applying law #3 so you can pretend it is main = do { unused - getLine ; answer - getLine ; putStrLn answer } Law #3 is amazingly pervasive: you have always assumed it, and you have never noticed it. (To put it into perspective, you hardly notice yourself breathing, but this only makes the practical meaning of breathing more profound, not less.) Whether compilers exploit the laws or not, you still want the laws for your own sake, just so you can avoid pulling your hair for counter-intuitive program behaviour that brittlely depends on how many redundant "return"s you insert or how you nest your do-blocks. /pre /blockquote /p p It is also worth reading apfelmus' followup for further elaboration on the intuition behind the monad laws. blockquote pre Deokhwan Kim wrote: But what practical problems can unsatisfying them cause? In other words, I wonder if declaring a instance of the Monad class but not checking it for monad laws may cause any problems, except for not being qualified as a theoretical monad? This question is likely to be a result of an unlucky introduction to monads where they are introduced top down: "Hear ye, a monad, this is some mystic thing obeying the spiritual laws 1.,2. and 3.", isn't it? It is this way that monads get the attribute "theoretical". Asking what the practical meaning of the monad laws might be is like asking what the practical meaning of the laws for natural number addition could be: what does i) a + (b+c) == (a+b) + c mean? How can i understand ii) a + 0 == a ? What does iii) a + b == b + a signify? These question are unlikely to arise because you have an intuition of what a natural number is: a number of bullets in sack, coins in your pocket, people in the mailing-list etc. With this knowledge, you will most likely not have any problems explaining the laws i),ii),iii) to somebody else and most likely you will have not doubt about *why* they must be true. For monads, my intuition is as following: a value of type (M a) is an action, something producing a value of type a and (or by) executing a side-effect like drawing on the screen or screwing up the hard drive. With the operator =, I can execute such actions in a specific sequence. For the sequence, it is of course unimportant how i group my actions: i can group actions act1 and act2 first and then postpend act3, or i can group act2 and act3 first and then prepend it with act1. To simplify writing down a formular corresponding to this fact, we introduce the operator defined by act1 act2 = act1 = \x - act2 which sequences actions but for simplicity discards the computed value x of type a. It is only the side-effect of act1 we are interested in. Now, the thought about grouping written does as formular is just (act1 act2) act3 == act1 (act2 act3) and this is the simplified version of law 3. Of course, we know that this is coined "associativity". The actual law 3 is just a formulation for = that takes proper care of the intermediate calculation result x. With return x , we can create an action which computes the value x but has absolutely no side-effects. This can also be stated in formulas, as Mr "return" explains: 1. "if i am prepended to guys doing side-effects, i give them the value x but do not take any responsibility for side-effects happening" (return x) = (\y - f y) == f x 2. "if i am postponed to an action which computes a value x, i don't do any additional side-effects but just return the value i have been given" m = (\x - return x) == m which is of course equivalent to m = return == m So to answer your question: In other words, I wonder if declaring a instance of the Monad class but not checking it for monad laws may cause any problems, except for not being qualified as a theoretical monad? A thing you declare to be an instance of the Monad class, but one that does not fulfill the three laws above, simply does not match the intuition behind a monad. I.e. your definitions of (=) and (return) are most likely to be void of the intended meaning. /pre /blockquote /p
Why I prefer LALR parsers

Posted: September 1st, 2006, 3:34am CEST by Andrae Muys

p I was asked on a mailing list why I prefer LALR to LL based parser generators. I ended up spending enough time on it to justify posting it here. Summary: em"Reduced complexity in the semantic analyser is well worth the 'cost' of thinking bottom-up in the parser."/em /p blockquote How come you prefer LALR? What about LR(k)? /blockquote p I haven't really found the need for the added expressiveness of LR(k); this combined with the dearth of good GLR and LR(k) generators for many languages means that I haven't ended up using one for a project yet. When people write production generators (as opposed to experimental), they seem to be either LL(k) or yacc+. /pp I'm not surprised at the popularity of LL, as you say, if you're going to write your parser by hand you're going to use top-down, recursive decent - ie LL. Consequently for people coming to the problem of parsing for the first time, they are much easier to visualise, and as you point-out consequently to debug. I recently had to assist a colleague with a couple of sablecc[0] bugs that were a direct result of visualising the parse top-down, while using a bottom-up parser. /pp However once you've written a handful of parsers, the expressive limitations of LL(k), and the software engineering challenges top-down imposes on semantic analysis quickly teach you to appreciate LALR. Consequently I do not voluntarily use LL parsers in new projects. /p blockquote I prefer LL(k) as it generates code similar to that you'd write yourself (top down parser) and that's useful when you are debugging. LL(k) is quicker :). /blockquote p You're right, debugging of the parser is simpler with LL(k). That of course is beside the point, as I mentioned in my original email, the parser is the easy stage - the hard part is the semantic analysis, and LL makes this tougher. Simplifying the parser at the expense of the SA is false economy. /pp The added complexity derives from two places. The first derives from the additional information available with non-terminal productions in bottom-up parsers. Because bottom-up parsers reduce non-terminals after their children are fully parsed. This additional information makes using S or L-attribute grammars feasible for the first stage of SA. When working with LL I have come across three ways of dealing with this: ol liDon't use attribute grammars, and use gradually (ie. most of the time, partially) initialised parser-global mutable state./li liUse nested parsers as accumulators./li liUse a eulers walk to convert top-down into bottom-up by attaching the SA to the post-order events./li /ol In my experience the general approach is a combination of 1 and 2 - and they both cause serious structural problems in the resulting code, which all manner of coupling and structural aliasing between the parser and the SA that complicate ongoing maintenance. 3 wastes alot of memory (although admittably that is less of a problem now), but more importantly you have thrown away the very reason you went LL(k) in the first-place - top-down parsing. /p p The second source of complexity is the consequence of losing access to left-recursive grammars - which has two key impacts. ol liElimination of left-recursion replaces one simple rule with two coupled rules./li liThis elimination is achieved by converting left-recursion to right-recursion; which will always[4] convert an S-attribute grammar into an L-attribute grammar; and seriously complicate any L-attribute grammar./li /ol /pp This causes problems analogous to the interaction of non-associative operators with foldr. br/ Consider the following grammar (where coden/code is a terminal matching code{digit}+/code ) pre E - E - n | n /pre converted[1] becomes pre E - nT* T - - n /pre "10 - 5 - 3" is then parsed: ul liL-recursive : code(((10) - 5) - 3)/code/li liR-recusive : code(10 (- 5 (- 3)))/code/li /ul Now of course SA can evaluate the R-form correctly, it just takes more work[2]; less intuitive code[3]; greater coupling; greater complexity. /pp LL parsers can't handle the L-recursive grammar, LR parsers can. /pp strongReduced complexity in the SA is well worth the 'cost' of thinking bottom-up; seriously, it's not that difficult to do./strong /pp [1] The kleene star simplifies this a bit, using e for the empty match the classic conversion ispre E - nE' E' - - nE' | e/pre See Aho et al for details. /p p [2] The L-recursive SA is a trivial S-attribute grammar defined as pre E - E' - n { E.val := E'.val - n.val } E - n { E.val := n.val } /pre /pp [3] In this case the L-recursive form is so trivial that the resulting R-form produces a trivial accumulator based SA. However note that even at this basic level, we have converted a simple declarative form into a recursive form that is fundamentally more complex. In cases where the L-form is naturally recursive, the resulting R-form invariably introduces mutable shared state, with it's attendant complications. /pp [4] I'm reasonably certain this is the case, I don't however have time to double check this. Presumably someone will correct me if I'm mistaken here. /p
Open Recursion: a definition.

Posted: April 21st, 2006, 10:56am CEST by Andrae Muys

p I've been asked a couple of times now about my use of "open recursion". It's covered in some detail by Pierce in "Types and Programming Languages"; I've included the one paragraph definition he gives below. blockquote p strongOpen recursion./strong Another handy feature offered by most languages with objects and classes is the ability for one method body to invoke another method of the same object via a special variable called codeself/code or, in some langauges, codethis/code. The special behavior of codeself/code is that it is emlate-bound/em, allowing a method defined in one class to invoke another method that is defined later, in some subclass of the first. /p p emTypes and Programming Lanauges, Benjamin C. Pierce, 2002, MIT Press, pg 227./em /p /blockquote /p
What is Object-Oriented Programming

Posted: April 20th, 2006, 12:31pm CEST by Andrae Muys

p Ok, so I've spent the past few days ragging on various applications of object-oriented programming. So what do I consider OOP good for? Well the answer naturally depends on what you consider OOP to be. So before I attempt to ask "What is it good for?", I will prepare the way by looking at "What is Object Oriented Programming"? /p p The biggest problem with giving a definition for object-oriented programming is that there are so many to choose from. Worse, the vast majority consist of little more than vague handwaving giving little or no thought to the existence of non-OO techniques. Consider the a href="http://www.paulgraham.com/reesoo.html"list of features/a listed by Johnathan Rees on Paul Graham's site. /p p Consider the first example. Encapsulation is not a distinguishing feature of OOP. Not only is it common in numerous non-OO languages, but it is not supported by many OO languages including both Smalltalk and Python! Moreover encapsulation is a friendly name given to existentially quantified types, which are the underlying theory used to understand emModules/em. Ie. when you see a feature offering encapsulation, what you are really seeing is a module/package system (possibly in disguise). Yes that does mean that Java/C#/C++ classes are doing double duty as both a type definition AND a module system. Yes that is the cause of several problems you are probably experiencing. No it doesn't have to be that way, there are languages that successfully seperate the two orthoginal concepts. /p p I make use of theory here because it allows me to avoid handwaving. Specifically it allows me to avoid the trap of promoting specific language features to the status of paradigm definition just because they are favoured, or even common in OOP languages. Using this approach I can quickly eliminate Encapsulation, Protection, Ad hoc Polymorphism, Parametric Polymorphism, and Sum-of-Product-of-Function from Ree's list. This leaves us with only "Everything is an object", "All you can do is send a message", Specification Inheritance, and Implementation Inheritance to consider. So lets map these to theory and see what we have left: dl dtEverything is an object/dt ddThis is literally a meaningless phrase as either it is strictly a matter of syntax (2.add(3) vs. 2 + 3); or it is a matter of purity, at which point it begs the question./dd dtAll You can do is send a message/dt ddMessage Passing. You can take your pick of various algebras and calculi to model this. a href="http://citeseer.ist.psu.edu/context/552/0"CSP/a was popular for a while; a href="http://www.amazon.com/gp/product/354066579X/sr=8-1/qid=1145513870/ref=pd_bbs_1/102-8567709-1780100?%5Fencoding=UTF8"Process Algebra/a has its admirers; but my favourate is the a href="http://www.amazon.com/gp/product/0521658691/sr=8-2/qid=1145501749/ref=pd_bbs_2/102-8567709-1780100?%5Fencoding=UTF8"pi-calculus/a. /dd dtSpecification Inheritance/dt ddThis is subtype-polymorphism using subsumption./dd dtImplementation Inheritance/dt ddOpen Recursion. Not alot of use if you don't have subtype-polymorphism as well, and proves difficult to model when you do. The simplest treatments use a least-fixed-type operator applied to a 'self' abstraction./dd /dl /p p Ultimately the above three concepts coalese into two conceptualisations of OOP. /p p The first focuses on the 'object', considering them as identifiable, autonomous, finite automatons communicating via message-passing. Conceptually we are talking about highly concurrent actor based models. This approach is the once taken by Simula, Erlang, Pick, and friends. However while it corresponds closest to the original conception of OOP, it is barely recognisable in modern mainstream OOP languages. In fact these languages are more likely to be described as concurrency-oriented than object-oriented. /p p The second focuses on the 'class', considering OOP in terms inheritance and subtyping. Conceptually we are talking about languages that provide records containing function typed attributes that are parametised by a recursive 'self' parameter that provides for 'late-binding'. The conventional way to model this theoretically is via Abardi and Cardelli's a href="http://www.amazon.com/gp/product/0387947752/102-8567709-1780100?n=283155"Object Calculus/a (or you could try one of the papers available online ie a href="http://citeseer.ist.psu.edu/304252.html"A Theory of Primitive Objects (second order systems)/a or a href="http://citeseer.ist.psu.edu/abadi96imperative.html"An Imperative Object Calculus/a). Representitive languages include all the usual suspects: Java, C++, C#, Smalltalk, etc. /p p While concurrent agents with message passing might be the original definition of OO, as mentioned above most programmers who consider themselves OO wouldn't recognise this as OO; certainly almost none of the languages traditionally considered OO would fit this definition. So it is pointless to pursue it further. That leaves us with a single definition. /p p strongObject Oriented Programming is any programming based on a combination of subtype polymorphism and open recursion/strong /p p Translated back into more common terms - programming based on a combination of ol liPolymorphic functions that accept as actual parameters values of any subtype of their formal parameters, and/li liLate binding, based on a distinguished 'self' parameter to functions that provides access to attributes of a record/object based on its runtime type./li /ol Which is consise, precise, and coincides with our intuition --- even if it does leave out a few 'traditional' aspects commonly included in definitions of OOP. Now to produce an object oriented language you need to add emat least/em the idea of functions and function application without which you are not turing complete and you will need records, without which you can't define subtyping. These don't belong to any paradigm rather they are what it means to be a programming language. You probably want to add a store and references, but again these do not belong to OO rather they belong to the super-paradigm Iterative Programming. There are all sorts of features you can add to your language but only two, subtype-polymorphism and open recursion, make you Object Oriented. /p
Interpreter Pattern and Structural Recursion

Posted: April 19th, 2006, 11:49am CEST by Andrae Muys

p I have previously discussed the flaws and limitations of the Visitor Pattern; criticised the Singleton Patterm as a global variable in disguise; and dismissed all but one of the rest as kludges to work around the GoF's languages-of-choice. That leaves the Interpreter. /p p This is a critically important pattern, if you only learn one pattern, make it this one! It is so fundamental to what we do to be different in kind from the other patterns in the book. In fact it is so critical that Gamma et al would probably have been better off ignoring the other patterns and writing their book exclusively on the Interpreter. In a very real sense this is exactly what Daniel Friedman did in "Essentials of Programming Languages" (EoPL). /p p If nothing else, the fact that you can comfortably write an entire book emintroducing the basics/em of the Interpreter Pattern is a good sign we're dealing with a different beast here to the rest of the GoF. Can you imagine writing a 300 page book introducing the basics of the factory-method? /p p The reason why the interpreter pattern is so important is that it amounts to designing a language, and language is our primary tool as programmers. We solve problems with computers, ultimately we do so with sequences of opcodes passed to the execution unit of our cpus; but the number of concepts we can express in a single sentence in machine code is limited, and the amount of detail we can choose to ignore when it is irrelevant to our solution is minimal. The act of climbing the language stack, (machine code - symbolic assembly - macro assembly - C - libc - [java, Scheme, ML, etc]) is an exercise in increasing these two measures. Note I included libc in that list. I did that because language is the core abstraction being invoked in library, module, and macro systems as Kernighan and Pike discuss in "The Practice of Programming". /p p Now for the bad news. Yes the interpreter pattern is all goodness and light, but the unfortunately the sample implementation provided by GoF is crap. It's crap for exactly the same reason the visitor pattern is an inappropriate approach for parse-tree manipulation. This is a symbolic transformation, and as a problem is decidedly non-object-oriented. I'll go into exactly what an object-oriented emproblem/em looks like another time, but suffice to say that there is a good reason why LISP has survived 50 years, and the applicability of functional programming techniques to symbolic programming is a major part of it. /p p The solution offered in Design Patterns is an excelent piece of OO design. The problem: You have an AST you wish to execute. The solution: encapsulate the knowledge of how each different node-type should be evaluated in an 'evaluate' method on each node-type's associated class. Below is an example calculator implemented in Java using this exact design: pre $cat test/*.java /** * test/Add.java */ package test; public class Add implements Expression { private Expression lhs; private Expression rhs; public Add(Expression lhs, Expression rhs) { this.lhs = lhs; this.rhs = rhs; } public int calc() { return this.lhs.calc() + this.rhs.calc(); } } /** * test/Div.java */ package test; public class Div implements Expression { private Expression lhs; private Expression rhs; public Div(Expression lhs, Expression rhs) { this.lhs = lhs; this.rhs = rhs; } public int calc() { return this.lhs.calc() / this.rhs.calc(); } } /** * test/Expression.java */ package test; public interface Expression { public int calc(); } /** * test/Main.java */ package test; public class Main { public static void main(String[] args) { System.out.println(Integer.toString( new Mul( new Sub(new Num(6), new Num(2)), new Add(new Num(2), new Num(3))).calc())); } } /** * test/Mul.java */ package test; public class Mul implements Expression { private Expression lhs; private Expression rhs; public Mul(Expression lhs, Expression rhs) { this.lhs = lhs; this.rhs = rhs; } public int calc() { return this.lhs.calc() * this.rhs.calc(); } } /** * test/Num.java */ package test; public class Num implements Expression { private int num; public Num(int num) { this.num = num; } public int calc() { return this.num; } } /** * test/Sub.java */ package test; public class Sub implements Expression { private Expression lhs; private Expression rhs; public Sub(Expression lhs, Expression rhs) { this.lhs = lhs; this.rhs = rhs; } public int calc() { return this.lhs.calc() - this.rhs.calc(); } } /pre and indeed this does print '20' as expected. /p p Compare this with the ML code below, or the far more complex interpreter on page 74 of EoPL, and the problem is immedately clear. With symbolic transformation we are invariably performing 'structual recursion'. We have a data-structure, that is indeed a emstructure/em, defined recursively that is then processed by following the structure of the data, possibly performing an operation at each step. Consequently it is the structure that is important in comprehending the code, and ensuring a perfect match between data-structure and code-structure that is required to get it right. By scattering the code across multiple files, it makes it much more difficult to understand the emstructure/em of the code, and impossible to verify that this matches the structure of the data without signifigant effort. pre $cat calc.ml (* Calculator *) type expression = | Num of int | Add of expression * expression | Sub of expression * expression | Mul of expression * expression | Div of expression * expression ;; let rec calc expr = match expr with | Num n - n | Add (e1, e2) - calc e1 + calc e2 | Sub (e1, e2) - calc e1 - calc e2 | Mul (e1, e2) - calc e1 * calc e2 | Div (e1, e2) - calc e1 / calc e2 let main () = print_int(calc(Mul(Sub(Num 6, Num 2), Add(Num 2, Num 3)))); print_newline(); exit 0 ;; main() ;; /pre and it is now trivial to inspect the code and the data and verify that the structures are identical. In fact it is so trivial the compiler will warn us of our mistake. pre $ diff calc.ml calc-broken.ml 15c15 | Mul (e1, e2) - calc e1 * calc e2 --- (* | Mul (e1, e2) - calc e1 * calc e2 *) $ ocamlc -o calc-broken calc-broken.ml File "calc-broken.ml", line 11, characters 2-199: Warning P: this pattern-matching is not exhaustive. Here is an example of a value that is not matched: Mul (_, _) $ ./calc-broken Fatal error: exception Match_failure("calc-broken.ml", 11, 2) /pre Now if you are stuck in an OO-world then the closest you can get to the above is to use either the visitor pattern or dynamic double dispatch. Not as neat, and a scary amount of boilerplate, but it works, and it is definately preferable to the example given in GoF; and when the time comes that you are not compelled to consign yourself to the OOP-only gulag you now know that there is something worth escaping to. /p
Back working on Kowari.

Posted: April 18th, 2006, 6:00pm CEST by Andrae Muys

p I am very grateful that I have been able to obtain another contract to work full-time on Kowari, so we should be seeing several fixes, changes, and enhancements flow into kowari over the next 3 months. The first installment is an enhancement to iTql to permit the convenient expression of compound constraints and existentials within the query. pre { s p1 o1 : p2 o1,o2 in m} is expanded to s p1 o1 in m and s p2 o1 in m and s p2 o2 in m and [ p1 o1 : p2 o1,o2 in m ] is expanded to $av__X p1 o1 in m and $av__X p2 o1 in m and $av__X p2 o2 in m ; for some value of X /pre This syntax is derived directly from N3/SPARQL, with the only exception being that we use colons instead of semicolons to separate predicates because kowari uses ';' as a query seperator. /p p Anyone doing large conjunctions on custom resolvers will be particularly pleased to see this, and this is my first step towards better custom resolver support in general. /p p In other news I feel I should point people at the Netymon Public Repository which is currently home to any kowari improvements made by Netymon until such a time as the future of the sourceforge project is determined. /p
The perils of avoiding heresy (or "What are Design Patterns")

Posted: April 18th, 2006, 1:29pm CEST by Andrae Muys

p My last two posts have been rather critical of the Visitor Pattern as described in "Design Patterns" more commonly known as GoF (Gang of Four). So the question is reasonably asked, do I consider the other patterns similarly flawed? If anyone is interested in the answer, it's yes. In fact rather than being subtitled "Elements of Reusable Object-Oriented Software", it should have been em"21 reasons C++ sucks; 1 embarassment; and an Abstract Syntax Tree"/em. /p p First the embarassment: Singleton.br/ This is a global variable. It should be treated in your design as a global variable; a useful hack sometimes, but always undesirable. Singleton is more honestly described as "Abusing your languages class system to provide namespacing for global variables". Just say no. /p p Regarding the 21 other patterns, let me just add that most of them apply to Java equally to C++, but Java simply wasn't a serious contender when the book was written; and of course the examples are mostly C++ (all of them except a few in smalltalk). Ponder this question: Why isn't 'Constructor' a creational pattern? Then ask yourself, why are the OO-community the only programming community to name the Factory Method, or Command patterns? The answers are simple, but the ramifications profound. /p p In a language with first-class constructors, the Factory Method Pattern consists of pre factory = MyClass.constructor /pre In a language with closures the Command Pattern consists of pre menuItem.clicked = lambda : ...do stuff... /pre In a langauge with constructors, the Constructor Pattern consists of pre obj = new MyClass() /pre /p p The final pattern is the OO version of the fundamental 'design pattern', elsewhere known as 'language'. The Interpreter Pattern was first applied, in it's non-OO form, during the 1950's, most famously in the development of symbolic assembly language, FORTRAN and Lisp. Since then it has found wide application being used in such diverse domains as database-querying, and printf format strings. The pattern is simultaneously both the most signifigant, cross-language, powerful pattern in Computer Science, and the biggest 'DUH' in the GoF's book. Of course, as with Visitor, the pattern in GoF is a near perfect example of the results of trying to shoehorn a non-OO problem into an OO-design; however I'll leave analysis of that for another time. /p p So if the book is predominately a catalogue of unfortunately necessary kludges around the semantic weaknesses of mainstream OO-languages, why do I still highly recommend it to new programmers? /p p Well for starters, precisely because it is a catalogue of emnecessary/em kludges. The book does capture (with the exception of Singleton) good work arounds for the weaknesses a programmer is going to face when working with C++/Java/C# (and to a lesser extent Python/Ruby/Smalltalk/etc). We all find ourselves needing to work in these languages from time to time, and it is well worth knowing cleaner kludges. /p p Secondly, along with "Refactoring" by Martin Fowler, GoF provides the reader with a solid introduction to good OO design. Combined, these two books will guide the new programmer into a solid understanding of classic object orientation. Given OO is the dominant paradigm behind all the current mainstream languages (unless you consider VB mainstream), this is worthwhile. That there are far better, cleaner, and safer alternative designs available outside the mainstream is beside the point when a new programmer is going to face Java or C# (or heaven forbid C++). Where a skilled programmer will translate these alternatives into a clean non-OO implementation within a mainstream language (see previous discussion regarding Visitor pattern and parser generators); this is simply not a reasonable expectation of a new programmer who is still mastering their first or second language. /p p Read them, learn them, even use them. Still you should always remember, these are kludges, and there are generally better alternatives available - the proof of you skill as a programmer is you understanding of what they are. /p

← Tony's Diary LawFont.com » kim →

Feeds

Etymon (20 unread)

Posted: May 19th, 2008, 9:38pm CEST by Andrae Muys

Posted: January 15th, 2008, 11:40am CET by Andrae Muys

Posted: November 29th, 2007, 5:27pm CET by Andrae Muys

Posted: October 17th, 2007, 5:03pm CEST by Andrae Muys

Posted: September 20th, 2007, 12:01am CEST by Andrae Muys

Posted: September 17th, 2007, 10:48pm CEST by Andrae Muys

Posted: August 30th, 2007, 7:23pm CEST by Andrae Muys

Posted: February 14th, 2007, 2:22pm CET by Andrae Muys

Posted: February 13th, 2007, 10:08pm CET by Andrae Muys

Posted: February 6th, 2007, 7:11pm CET by Andrae Muys

Posted: February 2nd, 2007, 11:07pm CET by Andrae Muys

Posted: January 25th, 2007, 11:17am CET by Andrae Muys

Posted: September 13th, 2006, 8:08pm CEST by Andrae Muys

Posted: September 13th, 2006, 1:26pm CEST by Andrae Muys

Posted: September 1st, 2006, 3:34am CEST by Andrae Muys

Posted: April 21st, 2006, 10:56am CEST by Andrae Muys

Posted: April 20th, 2006, 12:31pm CEST by Andrae Muys

Posted: April 19th, 2006, 11:49am CEST by Andrae Muys

Posted: April 18th, 2006, 6:00pm CEST by Andrae Muys

Posted: April 18th, 2006, 1:29pm CEST by Andrae Muys