Improved Wayland Application Redraws Coming To Enlightenment's EFL

[ssokolow]

LMAO - the 3yr old rant from a 'developer' that can't read docs? Too funny. We don't hire 'developers' like that guy, they are useless. Never had a problem using EFL, but then again I can read documentation and apply what I've learned lol.

I read the conversations on both TDWTF and OSNews between Rasterman/raster and everyone else... I am not impressed with raster's arguments, nor do I come away with the impression that raster is professional enough OR emotionally and socially mature enough to trust with maintainership of one of my dependencies.

[c117152]

Yes. C++ does. GTK+/Glib and EFL have a C API though, so void pointers appear more often for "generic handles to something"...

Since I have nothing to argue against I'll only add that (the specific) I AM a language bigot in the sense that I avoid C++ like the plague and would rather learn a few domain specific languages then actually work on someone else's C++.

[hansg]

I read the conversations on both TDWTF and OSNews between Rasterman/raster and everyone else... I am not impressed with raster's arguments, nor do I come away with the impression that raster is professional enough OR emotionally and socially mature enough to trust with maintainership of one of my dependencies.

That, plus the additional cognitive load of having to check every pointer yourself. In a type-safe system, you don't have to worry about it: the compiler will check your types for you, so you can focus on the task at hand. Of course C is seriously handicapped in this regard (lacking both inheritance and overloading), but still - there are better solutions than just casting everything to void* (or some unified base class pointer, which amounts to the same thing in terms of type safety).

Since I have nothing to argue against I'll only add that (the specific) I AM a language bigot in the sense that I avoid C++ like the plague and would rather learn a few domain specific languages then actually work on someone else's C++.

So you'd prefer a type-unsafe language which has the expressive power of a peanut, where even something as minor as string manipulation is a gigantic pain in the ass, over something that lets you just go ahead and solve the problem. Right.

[ssokolow]

That, plus the additional cognitive load of having to check every pointer yourself. In a type-safe system, you don't have to worry about it: the compiler will check your types for you, so you can focus on the task at hand. Of course C is seriously handicapped in this regard (lacking both inheritance and overloading), but still - there are better solutions than just casting everything to void* (or some unified base class pointer, which amounts to the same thing in terms of type safety).

I certainly agree, but then I'm a Python/JavaScript/PHP/Lua/bash programmer (who got started on DOS batch files, QBasic, Visual Basic, and then Perl) who is picking up Rust, not because I want to write code that Python is unsuited to, but because it gives me a stronger type system without Haskell's alienness. (And Pascal as a more typesafe way to develop for my DOS/Windows 3.1 retro-computing hobby PC.)

I didn't mention the cognitive load of C and C++ because I consider myself too inexperienced and biased to make an accurate judgment of C and C++ in the fields of endeavour they are best suited for.

[bleubugs]

I read the conversations on both TDWTF and OSNews between Rasterman/raster and everyone else... I am not impressed with raster's arguments, nor do I come away with the impression that raster is professional enough OR emotionally and socially mature enough to trust with maintainership of one of my dependencies.

I guess this is an argument to use software that their developers do not care about.

[bleubugs]

here are better solutions than just casting everything to void* (or some unified base class pointer, which amounts to the same thing in terms of type safety).

Please enlighten us here. This is a very common pattern in C for callback with user data. Not just EFL developpers will be interested to know you solution, but the GTK developer would to ( https://developer.gnome.org/gobject/...signal-connect ).

So you'd prefer a type-unsafe language which has the expressive power of a peanut, where even something as minor as string manipulation is a gigantic pain in the ass, over something that lets you just go ahead and solve the problem. Right.

Please recommend your solution for a language that would be used for a library that can be used by every single language possible on any Unix.

[ssokolow]

I guess this is an argument to use software that their developers do not care about.

I care very much about my own creations. That's why I try to be as professional as possible in my demeanour and documentation, despite IRL demands on my time conspiring to keep them on life support half the time.

[ssokolow]

Please recommend your solution for a language that would be used for a library that can be used by every single language possible on any Unix.

Well, the GNOME guys are quite interested in Rust for its ability to be typesafe internally, yet easily expose C-compatible APIs. They're currently working on code to further streamline things by automating the translation from Rust language constructs to GObject-convention-based C APIs with introspection metadata.

[Vistaus]

EFL is truly great on the technical side. Unfortunately, the licensing and the API (due to lack of personnel I think) are killing it..

Lack of personnel? Did Samsung shrink? 'Cause last time I checked Samsung was actively contributing to EFL...

[Vistaus]

Well, the GNOME guys are quite interested in Rust for its ability to be typesafe internally, yet easily expose C-compatible APIs. They're currently working on code to further streamline things by automating the translation from Rust language constructs to GObject-convention-based C APIs with introspection metadata.

So Rust got ported to all of the Unixes? 'Cause that's what he asked: "a library that can be used by every single language possible on any Unix."