Forums

Cobra - a user experience

General discussion about Cobra. Releases and general news will also be posted here.
Feel free to ask questions or just say "Hello".

Cobra - a user experience

Postby ptokremin » 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
ptokremin
 
Posts: 9
Location: Ruhrgebiet - Germany

Re: Cobra - a user experience

Postby hopscc » Thu Jul 17, 2014 2:07 am

Fair enough - always good to see comments from someone approaching cobra fresh..

Re your points:

- Editors
What was the problem with notepad++ ?
The support file/doc for that editor was donated a while ago - it possibly needs refreshing.

install file option:
Good idea - I'm not sure of ( or if there was a rationale) for not allowing the installation program to modify the install dir from default
(personally I dont use it and havent taken much notice of its evolution)
Feel free to post an enhancement/bug request. (login then 'new ticket' in trac/wiki)

- IDE/monodevelop
Your impression of the IDE is correct - its (cobra support) still new and being improved/worked on
One issue may be just lack of contributors/helpers

- Doc
This is what it is - wiki based and (continually) under construction or subject to augmentation....
It is however freely editable/augmentable so if you find outages/missing items
feel free to either file a ticket or (better) just fix it in the wiki/doc pages...
There have been various suggestions to change the layout/format but they've so far foundered on the premise of actually doing the work :)


I'm not sure what you mean by the lowercasing of property names - cobra enforces that because thats a cobra paradigm/convention but the actual (C#) code gen does the usual C# thing - cobra is totally responsible for the case translation so local code AND .Net library access to properties (in cobra) should always be as per cobra conventions - It should be totally seamless (once you've internalised the naming rules :) )
Can you give me an example of the problem you were seeing ( or the missing realisation - i.e that .Net lib contents should be accessed as if they were using cobra nomenclature/case rules..) ?? - Mayhaps this just needs doccing/describing better..

multidimensional arrrays:
This is sort of an architectural decision - theres the belief that other constructs are 'better' ( List, multiList) so support for multidim arrays is limited to noexistant - just what fell out of the current implementation
- there are are patches to allow access to what C# provides but not in the baseline source (yet).
Arguably we need to do better here for those occasions/uses that need it.

Generating Doc content.
Yeah - I believe this is currently aimed at documenting all the code not necessarily support for reusable components
This area obviously needs expansion - allowing doc gen just for exported interfaces is a good enhancement.
(file an enhancement ticket or start beating on the compiler code :)

- print string text conversion
The string conversion output is more aimed at getting the 'right' (clear) thing for display debugging hence conversion to readable text formats..
writing binary formats is intended done via direct file access ( i.e differently) - as you've found there are workarounds..

- local variables masking class variables
We dont disallow/warn this cos its a common convention to use a similarly named local variable to copy from a class variable, reference/change it and maybe to eventually copy it back ( this is a small performance aid and helps keep class instance contents invariant and atomically static)
Under the cobra (enforced) naming convention ( leading dot or not) makes it immediately obvious whether its a local or class variable on read/scanning source so it's usually pretty clear if you get them wrong way round.....

I cant comment on forum response times - sometimes its rapid, sometimes not depending on whos watching and what else they have on...

Anyway thanks for the feedback, much appreciated..
hopscc
 
Posts: 631
Location: New Plymouth, Taranaki, New Zealand

Re: Cobra - a user experience

Postby nerdzero » Fri Jul 18, 2014 8:19 pm

Hi, ptokremin. It's really awesome that you took the time to give such detailed feedback. I'm the primary maintainer for the MD/XS add-in. It definitely has some ways to go to be on par with support for other languages, but I have less time now to work on it than before (just adopted a baby girl!). I'll probably get back to it in a few weeks when things settle down a bit for me.

As for the issues you found:

Go to Definition does not always work. Especially if you have syntax errors at the time you try to use it. Since the IDE add-in relies on the parser from the Cobra.Compiler.dll, there are some scenarios it can't handle. Same goes for code-completion. Addressing this is a major project that I started working on but haven't had much time lately to continue it.

Code folding should work. I believe it's an option under Tools > Options > Text Editor > General.

Syntax highlighting is controlled by this file: https://github.com/ramon-rocha/MonoDeve ... axMode.xml and the only documentation for the format is out of date and available here: http://monodevelop.com/developers/artic ... definition but I'll happily accept any fixes for syntax highlighting bugs.

As for the other issues, like unit test integration, task-list, etc. they just haven't been implemented for Cobra yet. As you found, sometimes the documentation for MonoDevelop is out of date or not available. If you are interested in adding support for these features, your best bet is too look and see how other language add-ins did it and then take a similar approach. The C# language binding has been my primary reference: https://github.com/mono/monodevelop/tre ... arpBinding

I'm looking forward to see how your project turns out.
nerdzero
 
Posts: 286
Location: Chicago, IL

Re: Cobra - a user experience

Postby ptokremin » Mon Jul 21, 2014 9:10 am

Thank you for your comments and ideas. Fortunately my summer holidays are approaching and it's getting more and more hectic every day. It will be 3 weeks before I'll have time again for Cobra. In departing just a few thougths in no particular order.

Xamarian Studio: Ok, I'll look into the options for code folding. The hint about syntax errors interfering with "go to definition" actually explains quite a few things.

Notepad++: I tried all the supplied xml-files but Notepad++ rejected them when I tried to load them. An older version of Notepad++ had the same problem.

array vs. Lists: I guess for me this is a matter of personal preference: I prefer a universal language construct (leading to rather portable code) to a class from the .NET standard libray (which I find profoundly confusing at times). There certainly are other sides to this question...

As soon as I return I'll try to tidy up a few things (documentation mostly).
ptokremin
 
Posts: 9
Location: Ruhrgebiet - Germany


Return to Discussion

Who is online

Users browsing this forum: No registered users and 10 guests

cron