Comparison of Cobra to Python. | Hacker News Reader

Comparison of Cobra to Python.

cobra-language.com

43 pointskaens20 comments

Seems like an interesting cross between Python and C#. Any multi-line lambdas?

edit: Read into it a bit more. I may wrong, but it doesn't seem to have nested functions and their lambdas are just basically anonymous delegates, not real .NET lambda expressions. Wasn't clear how or if they tackled the multiline lambda problem that occurs in CPython. As it stands, it's pretty similar to C#/VB.NET--only slightly more readable at the expense of being way less mature. Definitely keeping an eye on this one though.

No, the anonymous functions do capture the current context. See here: http://cobra-language.com/trac/cobra/browser/cobra/trunk/Tes...

Search for the test that increments the "count" variable.

I don't really like the syntax for these anonymous methods. Boo is more readable in this regard: http://boo.codehaus.org/Closures

Getting rid of the colons (e.g. "if foo:" vs "if foo") does not appear to enhance readability.

This is nice on some levels, and they document their goals well (basically, to have features in one language that would otherwise require several). But I think they should have started by investing in Python itself.

While they wouldn't have their desired features "today", they'd have been working with a much larger audience. This would have led to more contributions in terms of PEP comments and feasibility testing, and ultimately more programmers benefiting from the new features.

All they need is a bit of syntax sugar and debugger integration on calls to Python, and they could at least benefit from many of the libraries. For all I know, the CLI already provides this.

I would love to have feedback about this page :

http://cobra-language.com/docs/why/

Cobra brands itself as the best of all worlds. What do you think about it?

Where's the catch?

(Or have we just uncovered the Graal of programming languages?!)

I am not fluent enough in all these languages to be able to tell.

In the meantime I'll stick to python.

I definitely agree that there is a missing spot to take in the language design space: python-like clear code and static typing without bulk. Cobra, Nimrod have other interesting features but really, the point is: Python is cool to read. When it comes to writing/rewriting though, I prefer having my computer helping and assisting me: with Haskell e.g. I have this "lego" feeling that I know everything fits together and it will be all right.

>> I have this "lego" feeling that I know everything fits together and it will be all right.

EXACTLY. I wish there were an imperative language with haskell's type system.

You can do imperative in Haskell if you really want to (or OCaml).

Having built in contracts and unit tests seems like a progressive feature.

Is there a similar comparison to boo?

http://boo.codehaus.org/

For a language like this to overtake Python, several things would have to happen:

1) It would have to offer something a lot more than slight improvements in syntax. What improvements it offers already are definitely nice, but I'm not going "OMG I have to have that!"

2) Lots of documentation would be needed (link points this out). As PG mentioned in an essay, an O'Reilly book too (or equivalent).

3) Having a large pre-existing code base, and project base you can build off of is key (i.e., Python has Django, tons of useful modules, etc...). This comes in time.

4) Community of users to ask questions (needs to be built up over time - publishing articles like this is a good way to start one).

I think to overtake Python it'll also have to offer something much different, substantially different^, from Python. Maybe build upon being easier to debug more. Or perhaps look at the most confusing aspects of Python and make them simpler (OOP can be very complicated for a newbie learning how to code - it was for me).

^By substantially different, I mean it doesn't have to try and be "black" to Python's "white". But it has to save programmers something (time, frustration, reduced learning curve, etc) that Python, or some other language, doesn't meet.

This language offers contracts, and built-in unit tests - both of which could probably be done in python (contracts could be done as decorators, I would think), but are far from being built-in to the language.

Eiffel is the only language I've heard of that uses contracts (I'm sure there's more though). They seem like they could make some aspects of OOP in a dynamically-typed language much easier.

Maybe I'm reading you wrong, but it sounds like you think this is a set of changes to python. It's not, it's a different language with some syntax inspired by python.

Either way, I don't think their goal is to overtake python - besides, the language is still really young.

http://docs.plt-scheme.org/guide/contracts.html IANACS I'm not sure if these are the same as (or even similar to) contracts in eiffel, but they are very useful and prevalent in the standard library.

I didn't know of some of these limitations. For example - this decimal one is nasty:

    >>> from __future__ import division
    >>> 4 / 5  # normal division
    0.80000000000000004  # <-- there is an extra '4' at the end
    >>> 4 // 5  # integer division
    0

Are any of these things fixed in python 3?

That's just how floating point math works in every language. Python intro: http://docs.python.org/tutorial/floatingpoint.html

Comprehensive paper going into depth about many other issues: http://docs.sun.com/source/806-3568/ncg_goldberg.html

If you don't understand the above, your missiles may kill you and your rockets may explode: http://www.ima.umn.edu/~arnold/455.f96/disasters.html

However if you don't care about performance but want precision, you can use e.g. the Decimal module (which is a little annoying with syntax help from the compiler) or perhaps various wrappers for arbitrary precision libraries that are around.

What about this: http://docs.python.org/dev/py3k/whatsnew/3.1.html#other-lang... (the fifth bullet)

It seems to make things more reasonable. After all, Python has showed that saying "that just how it works" can be avoided, as in the case of / defaulting to floating-point division.

I'm not a programmer, but IIRC normal division, as shown (4/5), used to do integer division, but now in python 3 it follows the behavior you show. Notice the "from __future__ ..."line implies that the following lines all follow the python 3 behavior, I assume from 2.6.

They aren't really problems. As was pointed out, this is the way floating point works. It trades (decimal) precision for speed. Personally, I do wish that Python would default to a fixed precision decimal style instead of defaulting to floating point.

But, you can make Python use the decimal style if you use the Decimal (or similar) library. Also, you can use certain wrappers for Python such as Sage to do something similar. I am a great fan of Sage for certain tasks personally.

Looks interesting, but I'm not sure if I see the need for a Python-syntaxed C# (that is essentially what it is). If I want to use the features of C#, I'll just use C#. For me, the appeal of Python is not as much the syntax as it is that it is a dynamic typed, interpreted language with some great libraries and frameworks available.

A new language that does not even make a minimal attempt at dealing with concurrency? Why bother?

Reply on news.ycombinator.com