whining about collections: road blocks to adoption

[Raoul Duke]

hi,

from what i've experienced so far, the idea of "collections" in the
world of Haxe is sadly less than what i suspect most programmers
coming from other languages would expect:

* hash literal syntax is missing, and work-arounds are hacks that lack
features and/or type safety.
* there's no haxe.ObjectHash.
* missing other things like a standard Set class (yes it took a while
for Java to get that, too ;-)
* giving up on haxe.* and trying polygonal.ds doesn't help me much
since it doesn't work on neko.

that people are apparently basically required to (a) use nothing but
arrays or (b) create their own collections classes from scratch seems
pretty darned sad vs. any other main-stream language.

sincerely.

[Juraj Kirchheim]

On Tue, Jun 19, 2012 at 1:01 AM, Raoul Duke <rao...@gmail.com> wrote:
> hi,
>
> from what i've experienced so far, the idea of "collections" in the
> world of Haxe is sadly less than what i suspect most programmers
> coming from other languages would expect:
>
> * hash literal syntax is missing, and work-arounds are hacks that lack
> features and/or type safety.

Workarounds yes, but through macro they can be typesafe and have any
features you want.
I'd be very careful with more literal syntax. I already find the
ambiguity between an empty block and an empty object very disturbing.
How should an empty hash literal look like?

> * there's no haxe.ObjectHash.

AFAIK Simon is working to implement this across all platforms. I am in
no position to give reliable information, but I suspect it will be
available no later than Haxe 3.
Until then I suggest using this:
https://github.com/back2dos/tinkerbell/wiki/tink_collections

> * missing other things like a standard Set class (yes it took a while
> for Java to get that, too ;-)

Sets are easily created from maps. Sometimes using an array is cheaper though.

> * giving up on haxe.* and trying polygonal.ds doesn't help me much
> since it doesn't work on neko.

There's a whole number of collection libraries out there. Granted,
polygonal is probably the most comprehensive one, but if it doesn't
work for you, then it doesn't mean you can't find something else ;)

[Cauê Waneck]

Hi, just a heads up, it seems to me that this message should be at haxedev or haxelang. Haxenext is not to talk about code, but about how to promote Haxe. :)

Cheers!

Cauê

2012/6/18 Raoul Duke <rao...@gmail.com>

[Raoul Duke]

hi,

On Tue, Jun 19, 2012 at 8:36 AM, Cauê Waneck <wan...@gmail.com> wrote:
> Haxenext is not to talk about code, but about how to promote
> Haxe. :)

i thought haxenext was also about listing barriers to adoption, so
they could be (some day) addressed.

i very seriously see, when compared to Java, C#, Python, Ruby, et.
al., [but not when compared to Haskell, Erlang, and I dunno about
Ocaml :-] that Haxe's "answers" to "collections" are weird enough that
they can and do turn people off of Haxe.

doubly so for the angle of "Haxe is for web server development".

sincerely.

[Raoul Duke]

On Tue, Jun 19, 2012 at 1:56 AM, Juraj Kirchheim
<back...@googlemail.com> wrote:
> Workarounds yes, but through macro they can be typesafe and have any
> features you want.
> I'd be very careful with more literal syntax. I already find the
> ambiguity between an empty block and an empty object very disturbing.
> How should an empty hash literal look like?

that is a good point, that is the kind of thing that is important to
seek out and work through.

overall however i would suggest that given the existence of hash
literals in other languages, haxe has to have them, even if they can
lead to some confusions in places. hopefully such confusions would be
eliminated by manually specifying the type of the receiving variable?
(better than nothing.)

>> * there's no haxe.ObjectHash.
>
> AFAIK Simon is working to implement this across all platforms. I am in
> no position to give reliable information, but I suspect it will be
> available no later than Haxe 3.

yeah, from the mailing lists it sounded like it was in progress
somewhere, but i never saw any other clear evidence / dates. it is ok
to say "we'll get there!" but it is bad to say (1st) haxe is great!
leave your ruby/python/java for us! (2) the new adopter gets burned by
no decent collections (3) the response is not "sorry yes we should be
more careful about (1)" but is instead to brush off the problem by
saying (4) "oh somewhere sometime maybe in the future it will all be
better".

> Until then I suggest using this:
> https://github.com/back2dos/tinkerbell/wiki/tink_collections

i will certainly try it, thanks. somehow i had missed that particular
ObjectMap when googling. i did see polygonal and actuate's. :-)

>> * missing other things like a standard Set class (yes it took a while
>> for Java to get that, too ;-)
> Sets are easily created from maps. Sometimes using an array is cheaper though.

argh! this is the kind of thing that kills me. :-)

there is a range of what is easy to create from something else. we are
not all using assembly code. if "haxenext" is asking "why don't people
adopt haxe" and then say "oh we don't need apis, we'll just let
everybody *roll their own every single expletive time* they first come
to haxe" then gosh duh i wonder gee why people aren't adopting haxe...

(just because *you* (or me! or whomever!) apparently loves to write
and maintain things from scratch...)

> There's a whole number of collection libraries out there. Granted,
> polygonal is probably the most comprehensive one, but if it doesn't
> work for you, then it doesn't mean you can't find something else ;)

the problem is that i think this kind of thing should not be an
external library at this point. look at current versions of Java,
Python, Ruby. [now there is room for debate, of course, about the
details of those not-in-a-library but-in-the-core collections. java
collections are not very functional and groups like apache and google
put out huge bandaid wrappers around them to offer more fp style. but
no matter what, i think the state of core haxe collections vs. core
java, python, etc. collections doesn't stand up.]

no i don't have the code to commit to fix this.

no i don't expect anybody to snap their fingers and have it done yesterday.

what i would like is for people who are running the show to at least
clearly acknowledge where things are not good, where things are behind
vs. other languages, where things are causing people to drop haxe.

i'm still trying to use haxe. i'm still trying to make something real
with haxe to show off haxe and to get people in the contract house to
adopt it themselves as well. i want haxe to grow well, not either die
or be the good-but-more-rough-than-i-like thing it is today.

sincerely.

[Cauê Waneck]

i thought haxenext was also about listing barriers to adoption, so
they could be (some day) addressed.

The goal is more general than those specific cases. It's got more to do with action than with language features. You can read more about it here:  

https://groups.google.com/group/haxenext/about?hl=en

i very seriously see, when compared to Java, C#, Python, Ruby, et.
al., [but not when compared to Haskell, Erlang, and I dunno about
Ocaml :-] that Haxe's "answers" to "collections" are weird enough that
they can and do turn people off of Haxe.

doubly so for the angle of "Haxe is for web server development".

But anyway, it's a nice suggestion, Just a heads up to add it to the right place ;)

Cheers!

Cauê

[Raoul Duke]

On Tue, Jun 19, 2012 at 11:54 AM, Cauê Waneck <wan...@gmail.com> wrote:
> The goal is more general than those specific cases. It's got more to do with
> action than with language features. You can read more about it here:
> https://groups.google.com/group/haxenext/about?hl=en

if the rule is no technical talk, then:
(a) i will stop :-)
(b) you have lost a majorly important thread about what prevents /
would actually further haxe adoption cf. "about best ways to ...
increase its adoption rate."

python and ruby etc. didn't win because they were whitewashed or had a
fancy logo. they won because things were easier. because they didn't
lead you on with promise and then just let you down as a developer. i
suspect. (well actually i think python does fail, i can't say i like
that language in any way, even though i have broken down and used it
for personal and work projects at times.)

haxe starts off sounding like it will make cross-platform easier, and
then one of the first most basic things you can expect a developer to
do is to reach for a hashmap (gosh that's technical), and that is when
it all suddenly is obviously not really smooth.

sincerely.
yes i'm really stopping now. :-)

[Plop]

I agree a lot with raoul. Collection are commons, needed everywhere and to push haxe to a top level we need haxe to give guaranty.

Industry (i talk about little company too) need standards like collections because don't want to rely on external library that are not ensured to be maintained in long term. 

A standard ensure effort for stability, maintainability, enhancement, and long life. (and in case of haxe crossplatform)

As an exemple Juraj, your work on libs tinker and macros are amazing but who can assure that you are going to maintain enhance bug fix some part for the rest of your life ? I was happy when official macro reification was released, (but sad for you, for the time you have invested) because official given me guaranty.

Rely on independant lib, is a risk. Someone don't want to take this risk. (Freelance and indepedant guys could take more risk because have less constraint, team work, long term products...). But haxe has the potencial to address lot of more segments in futur (big backend, real time, glue between large disparate multilangual codebase...). Collections like targets are things that open usages and potenciallity.

Think about an internal framework in a company that rely on a library and the only one lead developper take the black and go in mountains for the rest of his life.

A little company can't invest time in maintaining an open source project in place of the initial programmer.

Be open and think about people that have lot of separate codebase, frameworks, and several workers at the same time.

After that, if some want to specialize a collection, for perf or something. This time it's an investisment, not a constraint.