Cobra - a user experience
Posted: Thu Jul 17, 2014 1:05 am
Hi,
it's been a week since I started on the Cobra journey. Perhaps you might be interested in the things I found.
Background: Many years ago I wrote a number of python scripts (scientific numerical calculations). Some years ago I rewrote the code in Boo (3 modules) and Component Pascal (1 module). Last week I've ported some of the Boo code to Cobra.
Some things I really like
The syntax is quite clean, short but not cryptic (class declaration are one example). Nice.
The iterated for loop is a bit too brief for my tastes (no range-function), but I could get used to that.
Docstrings gave me some trouble in Boo, in Cobra they just work.
A really nice way to state what a method is supposed to do without hiding then information in comments.
My old code already contained quite some tests. Moving them from commented code into unit tests (for classes or methods) felt quite natural.
You get all the benefits of a statically typed language.
Cobra even caught an error at compile time which boo didn't: assigning object(sub class) to object(base class) without a cast.
Compiler messages really help you to find and fix the problems.
You may confuse it though with superflous ":" (e.g. from old python/boo code).
There's a compiler option to embed Cobra.Core so you don't have to copy it with a finished component (dll).
Language documenation is accessible on the web page.
After some struggle I compiled Cobra from the latest sources.
Couldn't say this about Boo (although Component Pascal set pretty high standards in this regard).
Finally I expect runtime performance to be in the same league as C#. This is not iron python, after all.
things to come to terms with
Setting up a text editor proved to be somewhat difficult. Especially Notepad++ gave me a hard time. I finally wound up using Xamarin Studio. What confused me was that the the download link for MonoDevelop gives you XS.
There is no option for the install program (if you compile from source) to change the target directory. You can change the source file though.
Overall the IDE does not seem that mature. You can debug in XS, but source navigation (go to definition) does not work. Neither does code folding, displaying nested comments or the task-list (TODO). There isn't even a list of methods as in CpIde. Syntax highlighting is confused by string constants like "[ ", you have to circumvent this by a trailing comment. Having a namespace declared in the source file and the project settings gave me classes with nested names at one time (haven't been able to recreate the problem for a bug report though). Opening a referenced assembly gives you detailed c#-code instead of a brief interface description. Code completion worked sporadically.
The integration of unit tests with the IDE was not that obvious and the documentation for it hard to find and rather confusing. The latter really bugged me. In the end I ran the tests for a library project from the command line.
My point of reference for these complaints are the Boo integration in SharpDevelop and CPIde for Component Pascal.
Documentation is good but not really complete. For instance I found the exponential operator "**" by trial an error.
Being forced to start names for properties with a lower case letter affects not only your own code but also the .NET library.
Although the compiler messages were helpful in these cases.
Multidimensional arrays (as a type, not a literal constant) and abstract classes gave me problems. Call me old fashioned, but I expected better from a high level language.
There is no obvious way to generate a documented interface for a component, because -document exports private and internal methods as well.
You can redirect output to a string, but print statements do an implicit conversion to string before. This is a bit annoying if you want to output float values using the invariant culture. It's still possible to do it with method calls to the StringWriter though.
Having local variables inside a method with the same name as class variables did not give me a warning. Forgetting the "." could possibly lead to problems.
Perhaps it's the holiday season, but responses here in the forum have been somewhat slow.
conclusion
Well that was quite a long post.
So, can I work with Cobra? Sure.
Does it occasionally annoy me? Absolutely, just as every other language/environment I have used so far.
I'm looking forward to completed my little project and see, where that leaves me.
Your comments and tips and pointers are appreciated.
kind regards
ptokremin
it's been a week since I started on the Cobra journey. Perhaps you might be interested in the things I found.
Background: Many years ago I wrote a number of python scripts (scientific numerical calculations). Some years ago I rewrote the code in Boo (3 modules) and Component Pascal (1 module). Last week I've ported some of the Boo code to Cobra.
Some things I really like
The syntax is quite clean, short but not cryptic (class declaration are one example). Nice.
The iterated for loop is a bit too brief for my tastes (no range-function), but I could get used to that.
Docstrings gave me some trouble in Boo, in Cobra they just work.
A really nice way to state what a method is supposed to do without hiding then information in comments.
My old code already contained quite some tests. Moving them from commented code into unit tests (for classes or methods) felt quite natural.
You get all the benefits of a statically typed language.
Cobra even caught an error at compile time which boo didn't: assigning object(sub class) to object(base class) without a cast.
Compiler messages really help you to find and fix the problems.
You may confuse it though with superflous ":" (e.g. from old python/boo code).
There's a compiler option to embed Cobra.Core so you don't have to copy it with a finished component (dll).
Language documenation is accessible on the web page.
After some struggle I compiled Cobra from the latest sources.
Couldn't say this about Boo (although Component Pascal set pretty high standards in this regard).
Finally I expect runtime performance to be in the same league as C#. This is not iron python, after all.
things to come to terms with
Setting up a text editor proved to be somewhat difficult. Especially Notepad++ gave me a hard time. I finally wound up using Xamarin Studio. What confused me was that the the download link for MonoDevelop gives you XS.
There is no option for the install program (if you compile from source) to change the target directory. You can change the source file though.
Overall the IDE does not seem that mature. You can debug in XS, but source navigation (go to definition) does not work. Neither does code folding, displaying nested comments or the task-list (TODO). There isn't even a list of methods as in CpIde. Syntax highlighting is confused by string constants like "[ ", you have to circumvent this by a trailing comment. Having a namespace declared in the source file and the project settings gave me classes with nested names at one time (haven't been able to recreate the problem for a bug report though). Opening a referenced assembly gives you detailed c#-code instead of a brief interface description. Code completion worked sporadically.
The integration of unit tests with the IDE was not that obvious and the documentation for it hard to find and rather confusing. The latter really bugged me. In the end I ran the tests for a library project from the command line.
My point of reference for these complaints are the Boo integration in SharpDevelop and CPIde for Component Pascal.
Documentation is good but not really complete. For instance I found the exponential operator "**" by trial an error.
Being forced to start names for properties with a lower case letter affects not only your own code but also the .NET library.
Although the compiler messages were helpful in these cases.
Multidimensional arrays (as a type, not a literal constant) and abstract classes gave me problems. Call me old fashioned, but I expected better from a high level language.
There is no obvious way to generate a documented interface for a component, because -document exports private and internal methods as well.
You can redirect output to a string, but print statements do an implicit conversion to string before. This is a bit annoying if you want to output float values using the invariant culture. It's still possible to do it with method calls to the StringWriter though.
Having local variables inside a method with the same name as class variables did not give me a warning. Forgetting the "." could possibly lead to problems.
Perhaps it's the holiday season, but responses here in the forum have been somewhat slow.
conclusion
Well that was quite a long post.
So, can I work with Cobra? Sure.
Does it occasionally annoy me? Absolutely, just as every other language/environment I have used so far.
I'm looking forward to completed my little project and see, where that leaves me.
Your comments and tips and pointers are appreciated.
kind regards
ptokremin