IDE support, Sponsorship, Boo

[roybatty]

I was curious if there were any near term plans for IDE support (VS, SharpDevelop)? Obviously in 2008 that's critical for adoption. What are others using right now to write Cobra in? Anybody got a VIM syntax file?

I thought I read that Cobra is sponsored by Novell. Is that true?

And I'm also curious to what the philosophical differences that differentiate Cobra from Boo are. Any plans for macros?

[tgoshinski]

I'm using UltraEdit32. I'll probably create a syntax file for Cobra sometime this weekend, unless someone beats me to it.

[Charles]

Re: IDE, I'll be pursuing the VS 2008 plugin in March. Others have expressed interest in SharpDevelop and I'm sure it's only a matter of time. I currently use TextMate on Mac and UltraEdit on Windows.

I'm sure my UltraEdit file is out of date, but I'll upload to this thread today.

Re: sponsorship, Cobra is not currently sponsored by anyone.

Re: Boo, I'll post that separately as I think it will turn into its own thread. We can use this one for further IDE planning, if necessary.

[Csaba]

Hi Chuck

Cobra is a wonderful language and I really hope it will succeed. Among many advantages with Cobra, I really like that Cobra is written in Cobra. Due to this, I think Cobra will develop and improve fast, if there is enough funding, my main concern.

I hope that methods will be first class objects in Cobra so that the Delegate/Event mess in C# and VB will be absent from Cobra. I’m not even able to count all the reserved words that are involved in the Delegate/Event mess. Not to mention all the confusing writing about delegates and events. Another wish, I haven’t seen if there is support for try-catch in Cobra, but I assume it will be implemented?

I certainly would switch to Cobra from VB if it were possible in practices; Cobra cleans up everything I think is bad with VB. But for that Cobra needs:

Support for Cobra in Visual Studio (or SharpDevelop?) for three reasons:
1: Intellisense - many users really depend on it especially to navigate through all the .NET classes.
2: The F1 help system – very convenient.
3: Many developers are using third party .NET extensions. For instance I use the Iocomp plot pack from to generate graphs and GemBox to create Excel files (without Excel). These third part developers only supply help files that work from Visual Studio (or maybe SharpDevelop). They don’t even supply a PDF manual!
This requires lot of clever work, and thus some funding.

Further to broaden the acceptance for Cobra, someone should have to port Cobra to the JVM. I might not be a giant issue since Cobra is written in Cobra and Scala, Jython and JRuby exist on the JVM. But nonetheless the porting will require lot of clever work, and thus some funding.

Then, for Cobra to succeed in the JVM world will require that someone develop IDE support for Cobra in NetBeans. Ruby has NetBeans support but Groovy still lacks it (as far as I know).

All these have been done before, but nonetheless it will require lot of work (by four? clever programmers) and thus some funding. Well, this work needed is modest compared with the investment already in .NET, CLR (&DLR), JVM and Java Beans!

I really would love if Cobra could replace VB and C# and even Java. But remember, C++ killed Ada and Java killed Modula-3, the world is not fair!

God Luck!
Csaba

[Charles]

Hi Chuck

Cobra is a wonderful language and I really hope it will succeed. Among many advantages with Cobra, I really like that Cobra is written in Cobra. Due to this, I think Cobra will develop and improve fast, if there is enough funding, my main concern.

I would certainly like to get funded, but regardless of whether that happens, Cobra is here to stay and I'll be pushing it forward on a regular basis. Keep in mind that Python was not funded for a long time, but still gained popularity.

I hope that methods will be first class objects in Cobra so that the Delegate/Event mess in C# and VB will be absent from Cobra. I’m not even able to count all the reserved words that are involved in the Delegate/Event mess. Not to mention all the confusing writing about delegates and events. Another wish, I haven’t seen if there is support for try-catch in Cobra, but I assume it will be implemented?

Try-catch is there. I'll post separately.

This comment about delegate/event surprised me. Given that Cobra runs on .NET, it seems that it must embrace delegates and events. I will say I also like some things I see in VB including the ability to declare an event with arguments without having to break out a separate delegate declaration. Also, I was planning that Cobra would let you narrow the type of "sender" in an event, but the VB guys beat me there. And I like being able to mark a method as handling an event.

Maybe you can tell me what's wrong with this approach to events?:

class X
    event onSomething(sender as X, args as EventArgs)

    def foo
        # ...
        raise onChange(this, EventArgs())

class Y
    def init
        # ...
        listen x.onChange, ref .handleChange

    def handleChange(x as X, args as EventArgs)
        # ...

# or

class Z
    var _x = X()
    def handleChange(x as X, args as EventArgs)
        handles _x.onChange
        # ...

Okay so there are some keywords: event, raise, listen, ref, handles. But the code is readable.

I certainly would switch to Cobra from VB if it were possible in practices; Cobra cleans up everything I think is bad with VB. But for that Cobra needs: Support for Cobra in Visual Studio (or SharpDevelop?) for three reasons:

I agree. I hope to start the Visual Studio edition in March.

Further to broaden the acceptance for Cobra, someone should have to port Cobra to the JVM. I might not be a giant issue since Cobra is written in Cobra and Scala, Jython and JRuby exist on the JVM. But nonetheless the porting will require lot of clever work, and thus some funding.

I agree than a JVM backend is desirable. Whether that comes from a funded effort or open source volunteers, only time will tell.

I really would love if Cobra could replace VB and C# and even Java. But remember, C++ killed Ada and Java killed Modula-3, the world is not fair!

There's no killing Cobra after it goes open source this month. There's no killing my long term commitment to it. And unlike previous efforts such as Ada and Modula-3, Cobra is coming online at a time when we can leverage and interoperate through .NET and JVM. You no longer have to "beat" your competitors at the popularity game to survive.

God Luck!
Csaba

Thank you for your comments,
Chuck

[keess]

Hi, I'm using jEdit http://www.jedit.org with a slightly modified python mode, but without a list of reserved words, operators, builtins etc. it will never be complete.
The Reference manual needs a lot of work, but then Chuck has to do that all by himself at the moment I guess...

Regards,

Kees

[Charles]

My latest thought on the reference manual is that it should move to the wiki when I put up Trac this month. Then anyone can work on it.

I'll do a separate post on syntax highlighting for editors.

[Csaba]

Hi Chuck

The delegate and event concepts are important and have to be implemented in Cobra. I will try to describe what I mean with the delegate an event mess in VB. This description is a black box perspective on delegates and events. I have never looked at any dissembled code and will probably never do it. Neither am I an expert on these issues, just confused, so I have probably misunderstood many of the issues here In VB you can’t assign directly a method to a variable like this:

Code: Select all

aSub =anotherSub

You have to first declare a delegate:

Code: Select all

Public Delegate Sub AnyParameterLessSub()

Then:

Code: Select all

Dim aSubDelegate As AnyParameterLessSub = New AnyParameterLessSub             (AddressOf anotherSub)

An ignorat question, why is AddressOf needed here? It seems that Cobra is using the Ref keyword in similar situations. Is it a problem here to understand that it should be the reference? The delegate class methods like Remove, RemoveAll and Combine do not require the AddressOf a delegate. In VB2005, it is also little tedious to do all the type casting when Remove, RemoveAll and Combine are used. Hopefully, Cobra can simply that.

Then comes the event concept with reserved words:

Code: Select all

Event, WithEvent, Handles, AddHandler, RemoveHandler, AddressOf, RaiseEvent

The Event object has to be declared as

Code: Select all

Public Event BehaviourEvent()

The object with an event is usually declared something like:

Code: Select all

Dim WithEvents aButton As New System.Windows.Forms.Button

But it is also possible to declare a button object without the WithEvents keyword as. The difference seems to be that for a aButton object declared with the WithEvent keyword, the compiler adds all methods marked with the Handles keyword to the list belonging to the appropriate aButton Event object:

Code: Select all

Sub SomeBehaviour Handles aButton.Click

I don’t know why it should be possible to inhibit this by declaring an object without the WithEvent keyword. So I think the WithEvent keyword is not necessary.

The AddHandler, RemoveHandler used with the AddressOf keyword seems syntactic sugar for the delegate methods. I believe that normal collection methods are easier understood and used (but not the present ,NET delegate methods).

The keyword RaiseEvent that executes the methods in the method list connected to the Click event in VB:

Code: Select all

RaiseEvent Click

And RaiseEvent can only be used IN THE SAME method or class that has the event declaration! Why? Delegates don’t have this restriction, and why isn’t the delegate invoke method used instead? This limitation has also given the convention in some places that the method added to the event list should be named On<EventName>.

From a black box perspective, the Event class seems to be a wrapper around the Delegate class. The main advantage with the event concept seems to be that it extends the delegate concept with Handles, so that methods are added automatically to the delegate list by the compiler at compile time. But the restriction with RaiseEvent limits the events usability compared with delegates.

I would like that functions in Cobra by default have some delegate functionality so it would be possible to write straight forwardly:

Code: Select all

anObject.Behaviour = modifiedBehaviour

It should used anywhere just like present VB delegates:

Code: Select all

anObject.Behaviour

For this, the Cobra delegate should have a subset of the present .NET delegate functionality since each Cobra delegate should have just one method connected to it, not a list of methods. Hopefully, Raise in the Cobra event concept doesn’t have the VB RaiseEvent limitations.

Hopefully, this clarifies what I dislike about delegates and events in VB.
Regards
Csaba

[Charles]

Hi Chuck

The delegate and event concepts are important and have to be implemented in Cobra. I will try to describe what I mean with the delegate an event mess in VB. This description is a black box perspective on delegates and events. I have never looked at any dissembled code and will probably never do it. Neither am I an expert on these issues, just confused, so I have probably misunderstood many of the issues here In VB you can’t assign directly a method to a variable like this:

Code: Select all

aSub =anotherSub

You have to first declare a delegate:

Code: Select all

Public Delegate Sub AnyParameterLessSub()

.NET, and therefore C# and VB, have strongly typed delegates. Knowing the number and type of arguments and the return type are required. We can explore the idea of Cobra automating this, but we'll have to see if that really works out. For example, if Cobra automates the delegate generation, is .NET going to allow it to be passed where an explicitly declared, but type-signature-compatible delegate is expected? I doubt it.

Then:

Code: Select all

Dim aSubDelegate As AnyParameterLessSub = New AnyParameterLessSub             (AddressOf anotherSub)

An ignorat question, why is AddressOf needed here? It seems that Cobra is using the Ref keyword in similar situations. Is it a problem here to understand that it should be the reference? The delegate class methods like Remove, RemoveAll and Combine do not require the AddressOf a delegate. In VB2005, it is also little tedious to do all the type casting when Remove, RemoveAll and Combine are used. Hopefully, Cobra can simply that.

Both VB and Cobra do not require empty parens to invoke a method. Therefore the AddressOf/ref informs the compiler not to invoke. I'm curious about this not being needed elsewhere like someDel.remove. I'll have to look into that. I've coded plenty of C#, but I only read up on VB.

Btw I also like "ref" because it immediately informs someone reading the code what's going on. It's pretty short and sweet and stands for "reference".

Then comes the event concept with reserved words:

Code: Select all

Event, WithEvent, Handles, AddHandler, RemoveHandler, AddressOf, RaiseEvent

...
I don’t know why it should be possible to inhibit this by declaring an object without the WithEvent keyword. So I think the WithEvent keyword is not necessary.

I agree and hope to avoid this when adding "handles" to Cobra.

The AddHandler, RemoveHandler used with the AddressOf keyword seems syntactic sugar for the delegate methods. I believe that normal collection methods are easier understood and used (but not the present ,NET delegate methods).

Well it is possible to ditch "listen" and "ignore" and go with "button.onClick.add(ref .myHandler)" but I thought the keyword approach went well with the declaration "event" and raising with "raise".

The keyword RaiseEvent that executes the methods in the method list connected to the Click event in VB:

Code: Select all

RaiseEvent Click

And RaiseEvent can only be used IN THE SAME method or class that has the event declaration! Why? Delegates don’t have this restriction, and why isn’t the delegate invoke method used instead? This limitation has also given the convention in some places that the method added to the event list should be named On<EventName>.
From a black box perspective, the Event class seems to be a wrapper around the Delegate class. The main advantage with the event concept seems to be that it extends the delegate concept with Handles, so that methods are added automatically to the delegate list by the compiler at compile time. But the restriction with RaiseEvent limits the events usability compared with delegates.

I'm sure this is intentional and I think I can infer the reasons. While delegates are general purpose method pointers, events are intended as a higher-level feature for object-oriented or component-oriented programming. The philosophy is that objects announce their events and others listen for them. Events aren't about offering control to outsiders (that's what methods are for), they are about informing outsiders. I have to say I agree.

I would like that functions in Cobra by default have some delegate functionality so it would be possible to write straight forwardly:

Code: Select all

anObject.Behaviour = modifiedBehaviour

It should used anywhere just like present VB delegates:

Code: Select all

anObject.Behaviour

For assignment, the "ref" will still be there, but I'll see what we can do about inferring the type. C# is at least good at inferring the type in the context of passing the delegate as an argument. I'm sure Cobra will be too.

You will certainly be able to easily call the delegate.

For this, the Cobra delegate should have a subset of the present .NET delegate functionality since each Cobra delegate should have just one method connected to it, not a list of methods. Hopefully, Raise in the Cobra event concept doesn’t have the VB RaiseEvent limitations.

MulticastDelegate is a .NET library feature so that will still be there. Cobra's raise will have the same limitations as VB and C# because events are for "object announcements", not general purpose use.

Hopefully, this clarifies what I dislike about delegates and events in VB.
Regards
Csaba

It does, but I think you're going to have to drink the kool-aid. Cobra will only be able to help syntactically. The semantics of delegates and events are system level. I agree they can be confusing at first because there is much overlap. I think VB does a better job than C# in making them more distinct. C# seems to really try to fold them together, making us scratch our heads even more as to when we should use which.

My recommendation when writing .NET software is to ask yourself if you're notifying outsiders what has happened to your object. If so, an event is the way to go and you will have a better OO structure to build on. If on the other hand you are delegating a computation, meaning you need some other unknown method to implement behavior, or you are offering outside control of your object, then use a delegate.

HTH,
-Chuck