March 2009 Help Wanted

[Charles]

Cobra is an open source project under the MIT license. It runs on a variety of systems including Mac, Windows, Linux and Solaris.

Below I've highlighted some specific things that would help the Cobra project. I've place emphasis on items that can be worked on independently and therefore in parallel to the compiler, which I'm always busy on.

Feel free to discuss these here in the forums, but I recommend starting a fresh topic post to help separate out the conversations. Here we go:

-- NEW: Help with Trac administration. This is what drives our wiki, tickets and Subversion web browsing (checkins, diffs, etc.) We're currently having a problem with responsiveness.

-- Provide editor support for your favorite editor. See EditorSupport in the wiki for the current state of support

-- Integrate Cobra with Microsoft ASP.NET and/or Novell Mono xsp2.

-- Merge in the Mono C# compiler backend to improve Cobra compiler performance. Discussed here.

-- Create a SharpDevelop (aka #develop) plugin. See the CobraDevelop forum.

-- Create a Visual Studio plugin. See VSX Dev Center.

-- Create an .msi installer for Cobra for the next release. ticket:19

-- Benchmarks between IronPython (and also IronRuby) and Cobra would be interesting. How big is the gap? Are there places we could improve upon even further?

-- Some further Samples or How Tos that would be interesting:
Cobra WPF Sample or How To
Cobra DirectX 3D mini example
Cobra OpenGL mini example
Cobra XNA mini example
Regex How To
WPF Sample or How To

"Samples" do something useful or instructive, using whatever features and libraries they need. "How To"s focus on a particular feature or aspect of Cobra, contain instructional comments and don't generally do any useful work. If you create a Sample or How To, please try to use a clean, consistent coding style as seen in the existing ones.

-- And of course, hammer on Cobra and report your problems here so they can be fixed and we can get to 1.0.

-- Any Trac ticket not assigned to someone is open to the public for implementation. See also: HowToSubmitAPatch

-- Participate. Join the forums and the discussion. Use your forums handle to login to Trac so you can edit the wiki, work on tickets, etc.

-- If you think of anything else, feel free to discuss here.

[Caligari]

What are you looking for in a Regex HowTo?

I had occasion to use them in the simple Cobra app I put together just recently. All I did was make use of the .NET regex class. It is disturbingly easy to do.

Overall I'm finding at the moment that mostly Cobra is an easy way to use .NET/Mono. If anything, I'm under-utilizing the language's specific features, either because I want a special feature (like SortedDictionary, as opposed to an ordinary one), or because I don't know about a Cobra-specific way to do something. The bulk of the errors I had, I think, were related directly to getting types to agree, often because of nilable on one side or the other of an assignment.

-- Caligari

[Charles]

Something along these lines:

http://cobra-language.com/how-to/

It doesn't have to be fancy. Show some typical things that one might do with a regex. Maybe show that you can use them as objects. So for example, you can put them in a list and then loop through that list.

[Charles]

Regarding nilable types, check out UseNilAndNilableTypes.

I just updated the How To's and I don't recall if that one was there. I don't think it was.

[Charles]

Oh and regarding "Cobra is an easy way to use .NET/Mono", it's more than just that. With a combination of performance, high level syntax, unit tests, contracts and mixins, you're supposed to be able to write some totally bad ass software with it.

[Caligari]

I'll try to throw together a regex How To, then. I'll start another topic for it when I've put it together. I'll use this as an excuse to try to write some more "Cobra-esque" code.

My comment about Cobra being an easy way to use .NET and Mono wasn't meant to be a put down. I haven't written any managed code using these frameworks before, and I've been very happy that Cobra makes a natural platform that largely gets out of the way and lets me come to grips with the stuff I haven't seen. This is good! When throwing together something small and quick with Python, in the past, I've rarely used the language to its fullest, but I've been able to write things quickly. Cobra is working the same way for me, which is perfect, plus it is giving me access to a large set of cross-platform libraries that I hadn't explored (and perhaps had avoided).

I see the nilable and non-nilable types as an win for the language. Thinking explicitly about such details has obviously been one of the (low) hurdles I've had to overcome, but I think it is an aspect of programming that bears close consideration. So I suppose I feel I'm a better person for the attention the language draws to nils. I've definitely been guilty of lazy type usage in Python in ways that Cobra won't easily tolerate, and I've paid the price in the past for those lapses, at times. While I appreciate that Python lets me just get on with things, I'm basically a believer in dealing with types at compile time as much as possible.

I suppose I've been surprised that despite the amount of focus I've had on types and nilable/non-nilable types in my Cobra app, the exceptions I've had to field have almost entirely been Null Reference ones. The experience has served to underline the need to "get it right", and not rely on the language to warn me about everything, even if it helps to avoid a lot of nil problems by its design.

On another topic, I was going to suggest considering Roundup as an issue tracker (it is a Zope/python based tracker I've used in the past). But I see you are using Trac to handle more than Roundup will do for you. Well, it is worth a look if you decide to split the features up.

- Caligari

[Charles]

Thanks for the thoughts and insights into how Cobra is affecting you. For at least the benefit of the other readers, I wanted to emphasize that Cobra gives you the option of using dynamic typing / late binding like so:

def foo(x, y) as dynamic
    return x + y

This idea originally comes from Objective-C: support for static and dynamic binding. You use whichever is appropriate for your needs, so it does tolerate dynamic typing if that's what you want.

I'm surprised most of your exceptions are null ref exceptions. When moving from C# to Cobra, > 90% of my null ref exceptions have disappeared. I'm curious where things are breaking down for you, although that might be hard to figure out across a discussion board.

I know that in Cobra I favor non-nilable types a lot more:

# I'll use this:
var _name = ''

# rather than:
var _name as String?

...for example, and that seems to help. I might also require non-nil objects in the "cue init" so that the object vars can be non-nil.

Also, the Cobra compiler only enforces non-null on assignments, argument passing and return values. It does not do enforcement on "_obj.foo" where "_obj" is a nilable typed object var. I was concerned that this would become too annoying. In retrospect, perhaps it should at least be enforced on args and locals...

[Caligari]

I'd say that mostly the Null Reference exceptions I've encountered have been of my own doing, rather than any failing of the language.

I've been working with XML selects, for example, and while I've spent a lot of time making sure that various variables are nilable or not, it has been the results of those selects which have been nil when I wasn't expecting it. Perhaps it was the feeling of "nil safety" that allowed me to fail to take such return values into account, when normally I would have!

Initially I was making a lot of things nilable, in order to match the return type from various framework methods. But since the first few Null Reference exceptions I've gone back and threaded through as many non-nilable types as I can easily manage, as they help me to be certain of some values, at least, and highlight the ones which need special nil consideration. Much like using const in C++, in a way, to help highlight the methods which do change the contents of a class.

I very much appreciate that it is an extra step, at least conceptually, to make most things nilable (at least now that I'm thinking more clearly about nils); once I wasn't simply sprinkling ?s everywhere it really helped me to decide where it was necessary.

I think mainly we're looking here at the learning process I've been going through with the language. I find it fascinating that it is changing the way I'm considering my code, but I don't think I've encountered anything worrying in Cobra itself in this department. Quite the reverse, really.

- Caligari

[Charles]

Sounds good. Out of our conversation, I'm still liking the idea that for the dotted expression "foo.bar", Cobra should complain if "foo" is a nilable argument or local. (Note that it's not considered nilable if you guard with an "if foo" or assign it "foo = Foo()".)

Btw Cobra has a coalesce operator (as do C# and SQL) that you may find useful.

Thanks again for your comments.