Sponsored Link •
Introducing the CEDSimply project and some thoughts on a clean way to assign pointers using safe multiple dereferences of possibly nil pointers: CurrentLogger = gRS.runner.UI.LogTo unless nil
I often see code like (slightly ugly contrived example):
if (gRS.runner!=0 && gRS.runner.UI!=0 && gRS.runner.UI.LogTo!=0) CurrentLogger = gRS.runner.UI.LogTo
or, taking advantage of the c treatment of nil pointers as false:
if (gRS.runner && gRS.runner.UI && gRS.runner.UI.LogTo) CurrentLogger = gRS.runner.UI.LogTo
In an abstract syntax form, this can be expressed as:
(if-no-pointers-nil (CurrentLogger = gRS.runner.UI.LogTo) )
This is the kind of assumption, like having zeroed memory by default, that could be built into a language. Indeed, it might be nice to only be allowed to assign a nil pointer explicitly:
CurrentLogger = gRS.runner.UI.LogTo
CurrentLogger = Nil
However, I keep being really really uncomfortable when a language does things that are going to subvert the instincts of a good c++ or Java programmer.
I find myself rather liking the simple form:
CurrentLogger = gRS.runner.UI.LogTo unless nil
I miss the Object Pascal with statement, dreadfully so when I first moved to C++.
Trying to write a nil-safe with leads to:
with gRS.runner.UI unless nil: CurrentLogger = LogTo
Which doesn't really work for me:
I'm not sure there's a readable alternative, maybe some of these meet your fancy:
with unless nil gRS.runner.UI: CurrentLogger = LogTo with nil-safe gRS.runner.UI: CurrentLogger = LogTo with guaranteed gRS.runner.UI: CurrentLogger = LogTo safely with gRS.runner.UI: CurrentLogger = LogTo
I will probably blog again on this topic because it's dear to my heart and deserves more detail.
People avoid errors of tired misinterpretation when code is easy to read.
As you can see from the above examples, this means trying things in nit-picking detail.
I came to Christopher Diggins' blog and Heron project because for a few years I've been dissatisfied with existing programming languages and how well they allow me and many others to communicate to a computer and other programmers.
CEDSimply is currently a theoretical project in establishing a clear vision for a language, it may end up as:
I have realised it might be a tiny bit ambitious to aim at developing the entire language and environment alone so it is going to have to be an open source project. Maybe I'll at least establish a BDFL-like reputation, rather than getting rich :-)
I've spent a lot of time in the Macintosh world working in the code generation space: writing code generators that target c++ frameworks such as Think Class Library (for Prototyper) and enhancing AppMaker from Bowers Development.
From publishing a Windows code generator and PowerPlant framework portability kit for AppMaker, I've now moved on to acquiring the product (Spec Bowers has retired to run cabins).
AppMaker has a JSP-like template environment for code generation, using its own OO language. This, Python and years of trying to write highly-usable C++ API's (OOFILE) were the seeds of my thinking in CEDSimply, watered with dabblings in Forth and Scheme.
CEDSimply is pronounced "said simply"
yes it's a kind of pun on Smalltalk
it's also a pun/jibe at another famous old language - you can't say it clearly with a lisp.
CED started out as an acronym for Connecting Events and Data, then it became Contexts, Events and Data
or maybe it now means many other things, some of which start with Community.
Anyway, I think it's a great pun!
|Andy is a free-lance developer in C++, REALbasic, Python, AJAX and other XML technologies. He works out of Perth, Western Australia for a local and international clients on cross-platform projects with a focus on usability for naive and infrequent users. Included in his range of interests are generative solutions, software usability and small-team software processes. He still bleeds six colors, even though Apple stopped, and uses migration projects from legacy Mac OS to justify the hardware collection.|