Hi .. I have a lot of work on my plate just now with some refactoring in our Curl project. Working in the Curl IDE is really a pleasure. Now if the 'classic' IDE could only move into open source ![]()
I am also very excited about the prospects for a language that has constraint-resolution or other goal behavior to appear on the Curl NITRO platform ... and ICON/UNICON style string-scanning to complement REGEXP.
bis zum nächsten mal!
Friedger, didn't you write a book in German on Curl? I never got to see it, and don't know what topics you covered, but do you think there would be any value in republishing it in English for the US market? The existence of low-cost internet publishers such as BookSurge would make it pretty easy (ignoring the considerable trouble of having to translate it).
Regarding the Zuzu project, I only get to work on it in spurts so it might be a while before I get around to having an official release of anything. I have been working on test infrastructure first because I intend to use it as the basis for unit tests for later projects. ZUZU.TEST is already fairly usable in its current form, but I still want to do some refactoring and documentation before I make a release.
Christopher, the book needs more updating I guess as it was written while Curl 3.0 was the latest release. So, I am not sure whether I will find the time to update and translate it.
Re ZUZU.TEST, how does it relate to the CDU testing framework?
ZUZU.TEST and the CDU test framework aren't directly related. The CDU's CurlUnit framework is an adaption of the Java JUnit framework which in turn is an adaption of the Smalltalk SUnit framework. CurlUnit was developed by the Curl Solution's group and is used in the testing of code maintained by that group. The ZUZU.TEST framework is a reworking of test frameworks I wrote for internal RTE code. My philosophy of testing is that the test cases must be as easy as possible to write and did not like the need to explicitly create test classes to define test cases. Java is limited it does not let you write code outside of the scope of a class, so you are forced to write classes even when you just want procedures. So while CurlUnit is perfectly usable, it doesn't take full advantage of Curl's expressiveness.
In the RTE, most internal tests are written as curl scripts with assertions, and the test framework consists of mostly of a small number of assertion macros. In the ZUZU.TEST framework I wanted to support a visual testing framework as the CDU does but still allow the same tests to be run in batch mode scripts for automated builds. While my framework does define Test classes as CurlUnit does, test authors don't have to define classes explicitly but instead declare test cases using a 'define-test-case' macro. While I probably could have applied these concepts to the CDU, and may eventually do so, working on a separate framework gives me the freedom to refactor and rework the code until I am happy with it and not have to worry about backward compatibility. My eventual goal with the project is to create generic visual and batch test driver programs which can load and run arbitrary test files and packages and which will provide easy ways to run classes of tests. The current test macro lets you associate arbitrary tags with a test case, which eventually are intended to be used by the test drivers, so that you will able to mark some test cases as "smoketest" cases and be able to run them with one simple command through the test driver.
Robert, so are you actively working on macros to add constraint-resolution syntax to Curl? If so, perhaps you could start an open source project. I don't have all that much free time between work, the Zuzu project, and my family (including the real Zuzu), but I would be happy to help out in some way.
Regarding open sourcing the 'classic' IDE, it is something we have talked about, but we are so busy working on the next-generation Eclipse-based IDE that we have not fully thought through what we would need to do to allow it to be built and run externally. In the end, there might not be all that much utility to maintaining the old IDE, even as an open source project, since the new IDE will be so much better. It might turn out that opening up the old IDE sources will be useful primarily as a giant code example.
BTW, I have been using the Eclipse IDE for my own week the last couple of weeks, and I think that most will find it a huge improvement over the existing IDE, if for no other reason than that it means you will not have to switch to another IDE as you work on non-Curl portions of your projects.
For translation you could check with me .. I have usualy done French to English, but would be comfortable doing the German to English. We could always work backwards: old text to English; updates in English and then revert those to German. Like so many things, time permitting ...
btw, I liked how the Manning book handled Groovy: the code was generated (few errata) and the book has a Unit Test focus ( Groovy in Action? )
I have become very distracted by another strand of Icon, that being Laurie Tratt's Converge ( which implements Objvlisp )
It may be that CHR (constraint handling rules ) would better come from a DLL on the Windows side ...
On the macro side, my current inclination is to focus on SNOBOL-style string procedures as a first open-source project and then the goal-directed Curl ( there is a goal-directed Java project running called Godiva )
And Icon will be moving to 9.5 soon
Robert,
It will be great to see what you can do in terms of open source improvements to the Curl language - I've never met anyone with as much knowledge about program language design as you have. I'm looking forward to seeing your SNOBOL-style string procedures!
I should say: Converge implements classes and objects on the same level, as in Objvlisp ( Steph Ducasse has an Objvlisp running on top of Squeak Smalltalk )
Unicon has "additive" inheritance which is also quite cool ... you declare what you will inherit at the time of the inherit - which looks do-able in Curl as
{define-new-class public B {bequeathed {from OtherClassA, {members x, y, z}}, {inherits SuperC}}}
It seems like this is some form of delegation where x,y,z are delegated to another class instances, but doesn't that instance need to be specified somewhere? That is, x, y and z need to operate on an instance of type OtherClassA and have access to its state and other methods, so presumably you would have to stash a reference to an OtherClassA instance in B or otherwise provide a way to get such an instance.
I have sometimes wanted to write a delegating syntax that would let you implement a given interface by delegating methods to the same methods on a field of the class. This pattern is common when implementing proxy classes but has no direct support in the language currently.
Hi Friedger! Welcome to the Curl blogosphere! We are excited to have our first MVP posting his first of what is hopefully many more posts!