Linked by Thom Holwerda on Tue 12th May 2015 14:40 UTC
General Development

I work for a certain corporation which uses a certain product. This is its story. To put the quality of this product into perspective, let me say it's been in development for about 20 years and has pretty much no users (besides my corp and some "hey - let's make our own Linux crappy distro, which no one will ever use" fanatics) and no community. It was written by a C programmer who "doesn't like the notion of 'type' in programming". Let that be a prelude of what's to follow. Envy those who don't know it; pity those who use it.

The product is called Enlightenment Foundation Libraries and it's the absolutely worst piece of shit software you can imagine.

Poor Tizen.

Order by: Score:
Corporate backing
by kwan_e on Tue 12th May 2015 15:08 UTC
kwan_e
Member since:
2007-02-18

To be fair though, Qt has corporate backing for a lot longer.

To be also fair though, all the C widget libraries show C is a crappy language for GUI programming and ego stroking.

Reply Score: 7

RE: Corporate backing
by Kochise on Tue 12th May 2015 15:38 UTC in reply to "Corporate backing"
Kochise Member since:
2006-03-03

Corporate management at its best, it reminds me French bureaucracy ;)

C is far enough for GUI dev, how do you imagine it was done before Java and Go ?

Reply Score: 1

RE[2]: Corporate backing
by meme on Tue 12th May 2015 16:18 UTC in reply to "RE: Corporate backing"
meme Member since:
2006-04-03

Considering that Java has AWT and Swing, Go has no GUI framework to be worth mentioning, I think that C is a fine choice for GUI programming. Yes, Win32 API is a bit long in the tooth, but still usable. Gtk(3) is pretty much usable from C.

And before someone mentions Qt, have you tried to use it from language that's not called C++? There is a reason, why PyQt is paid for.

Reply Score: 2

RE[3]: Corporate backing
by kwan_e on Tue 12th May 2015 16:53 UTC in reply to "RE[2]: Corporate backing"
kwan_e Member since:
2007-02-18

I think that C is a fine choice for GUI programming. Yes, Win32 API is a bit long in the tooth, but still usable. Gtk(3) is pretty much usable from C.


No, those C libraries try to reinvent OO programming, which is like SVN trying to be CVS done right.

And before someone mentions Qt, have you tried to use it from language that's not called C++? There is a reason, why PyQt is paid for.


Before? You mean like me, the OP of the comment you're replying to? Or the article linked to which explicitly contrasted EFL with Qt?

Also, yes. Qt has QML, a scripting language. It also has Qtscript, which is an ECMAscript like language to write in it. Strangely enough, the article also mentions QML.

So if you hate C++ that much, Qt also provides a superb non-C++ programming interface for almost all of its functionality.

And using Qt from C++ is not difficult either.

Reply Score: 5

RE[4]: Corporate backing
by Kochise on Tue 12th May 2015 17:36 UTC in reply to "RE[3]: Corporate backing"
Kochise Member since:
2006-03-03

Imgui ? Well, I used to code on Atari St, the GEM interface was full event driven in C, NOT C++.

Reply Score: 2

RE[5]: Corporate backing
by kwan_e on Wed 13th May 2015 00:30 UTC in reply to "RE[4]: Corporate backing"
kwan_e Member since:
2007-02-18

Imgui ? Well, I used to code on Atari St, the GEM interface was full event driven in C, NOT C++.


So? I didn't say it doesn't happen. I'm saying it's not good for it.

Reply Score: 2

RE[4]: Corporate backing
by jgfenix on Wed 13th May 2015 00:45 UTC in reply to "RE[3]: Corporate backing"
jgfenix Member since:
2006-05-25

Well, EFL has Edje which predates QML and a scripting language called Embryo.
I have also read that the canvas library is very fast without hardware acceleration and the whole set of libraries seems to be designed (from what the author said) with perfomance and low overhead in mind so I suppose that it made sense for Tizen which were intended for low end phones.

Reply Score: 2

RE[2]: Corporate backing
by kwan_e on Tue 12th May 2015 16:47 UTC in reply to "RE: Corporate backing"
kwan_e Member since:
2007-02-18

Corporate management at its best, it reminds me French bureaucracy ;)


And what part of Qt's evolution has been bureaucratic?

C is far enough for GUI dev, how do you imagine it was done before Java and Go ?


The linked article contrasts EFL with Qt. I also mention Qt. Why do you miss the obvious answer in that there are GUI libraries that are not in Java or Go?

Or do you use Java or Go euphemistically to mean programmers who aren't as elite as you?

Reply Score: 4

RE[2]: Corporate backing
by moondevil on Tue 12th May 2015 17:35 UTC in reply to "RE: Corporate backing"
moondevil Member since:
2005-07-08

C is far enough for GUI dev, how do you imagine it was done before Java and Go ?


History lesson from my little corner of the world in GUI programming:

MS-DOS - Clipper, Turbo Pascal and Turbo C++ with Turbo Vision

Windows 16 bit - Visual Basic, Turbo Pascal and Turbo C++ with Object Windows Library, Delphi, Visual C++, Zortech C++, Metrowerks C++ with Microsoft Foundation Classes, CA Visual Objects, FoxPro

Windows 32 bit - Besides what was referred previously. C++ Builder, Visual Age Smalltalk, Allegro Common Lisp, Oracle Forms, ...


Mac - Hypercard, Object Pascal with Toolbox, C++ with PowerPlant, Macintosh Common Lisp

OS/2 - C++ Set with OS/2 C++ Class Library

UNIX - Progress 4GL, ABAP, Smalltalk, Allegro Common Lisp, C++ with Rogue Wave Views

Amiga - Mostly Assembly and AMOS


More examples can be provided.

Reply Score: 4

RE: Corporate backing
by Carewolf on Tue 12th May 2015 17:19 UTC in reply to "Corporate backing"
Carewolf Member since:
2005-09-08

To be fair though, Qt has corporate backing for a lot longer.

To be also fair though, all the C widget libraries show C is a crappy language for GUI programming and ego stroking.


I agree on C being a poor langugage for GUI programming, but it seems to do ego stroking quite well. I would guess egos are the main reasons people even try to use for things it is bad at.

Reply Score: 4

RE: Corporate backing
by grat on Tue 12th May 2015 17:34 UTC in reply to "Corporate backing"
grat Member since:
2006-02-02

C is a perfectly good language for GUI programming. However, writing "good" C code requires a lot of skill and discipline. It's very easy to write bad C code, because it doesn't enforce any form of good coding practice.

Likewise, writing a good GUI framework in C requires a great deal of planning and design work, and then you have to write the code in a very consistent manner. Well documented functions are an absolute requirement.

C++ (and other object oriented languages) make it much simpler to write complex code, but it hides much of what's actually happening.

Reply Score: 4

C as a language for GUI development
by rleigh on Tue 12th May 2015 19:43 UTC in reply to "RE: Corporate backing"
rleigh Member since:
2014-11-15

I really do have to disagree strongly here.

You stated that C requires "a lot of skill and discipline". This is certainly true. But another way of looking at it is that C exposes the programmer to unnecessary risk. If the programmer's discipline falters just once, they make a mistake and the most likely outcome is that the program will crash horribly (or corrupt its state). I say unnecessary risk because other languages eliminate entire classes of problems which plague C. A language like C++ would probably have caught the error at compile time, saving the programmer much time.

C++ is simpler in comparison to GTK+. GTK+ requires the programmer to reinvent the internals of the C++ compiler implementation in C, and then cast away all type and const information. It's a recipe for disaster. Too many eager programmers boldly state something like "that's OK, I have superior skills and I'll avoid problems by not making mistakes". But it's unrealistic--none of us are perfect and we all make mistakes. And constructing vtables and class structures by hand--it's a bad joke; imagine proposing this to your team in a company: We could use C++... or we could "do it the hard way" for no measurable benefit and a whole slew of quality problems. There's a good reason why you don't see much new GTK+ development and lots of projects migrating, or planning to migrate, to Qt--the cost/benefit just doesn't add up. You can do a better job in C++ with fewer people in less time, with a higher quality result. [And I say this as someome who was once a programmer working on a commercial GTK+ application and a GTK+/GNOME fanatic back in the early 2000s; how times change ;) ]

While EFL/Evas was rightfully criticised in the article, note that GTK+ suffers from almost all of the problems mentioned. While there's some type safety in the function prototypes as a hint, all the correct type information is cast away by the GTK_FOO macros--if you make a mistake with the type you cast, the compiler won't error out. This means you then have to check every function argument at runtime with g_type_check_instance_* taking a significant performance hit where a C++ compiler would have checked it all at compile time with zero runtime overhead. And worst of all, it can still crash horribly even with that extra checking overhead! Memory management including reference counting is inconsistent and manual where C++ can use smart pointers to do exactly the same thing but consistently and correctly--being automatic it avoids programmer error. And the GLib data structures like GList are also terrible compared with the STL; they require awkward memory management, are painful to manipulate and have terrible performance--many GList methods are O(n) where std::list is O(1), for example. C is the worst possible language here in all respects. Let's not even bother thinking about string handling. As for EFL, the manpower required to write (and maintain) a GTK+ codebase can be obscene--the amount of manpower wasted on boilerplate and hacking around the libraries deficiencies is huge. And once you get past a simple "Hello World" with GTK+ you start to hit the bugs, and there are certainly a lot of them to encounter... [I know from personal experience; I've converted codebases from C/GLib[/GTK] to C++/STL[/Qt] and the improvement is significant.]

While I started out using C, I've moved on via Perl to C++ and Python today. C receives much undeserved support in the free software world, and while historical precedent accounts for some of this, a lot is also due to hubris (and masochism). There are much better languages to use for almost every task imaginable, and it's time for us to move on for all but a few special case projects. Many big projects are slowly moving over e.g. GCC. With C++11 (now C++14), C++ is vastly simpler to use correctly than it once was, and toolkits like Qt are quite pleasant to use. When I run C++/Qt code under valgrind it's a rare event to see a memory leak; this was very much not the case with GTK+--it's too easy to mess up (did you need to "sink" a new ref for this type?). And unlike with GTK+, I don't break a sweat when it comes to doing any large scale refactoring since I can rely on the compiler to pick up any unintended breakage.

Reply Score: 10

Vanders Member since:
2005-07-06

You stated that C requires "a lot of skill and discipline". This is certainly true. But another way of looking at it is that C exposes the programmer to unnecessary risk. If the programmer's discipline falters just once, they make a mistake and the most likely outcome is that the program will crash horribly (or corrupt its state).


I'd suggest that's demonstrably untrue given that there are a huge number of systems and programs running billions (if not trillions) of lines of C without crashing, and that there are plenty of examples of non-C code which can and will crash horribly (unless we're declaring that "dump a stack trace and exit" is not "horrible")

People seem to think that C is difficult to learn, with lots of arcane rules. That's just not true; it's just that because C lets you do things wrong so easily, and as a result there's a whole bunch of people out there giving the wrong advice, it's very easy for someone learning C to learn it wrong. Then when someone tells them they're doing it wrong, they (quite rightly) throw their hands in the air and exclaim "That's how I was taught to do it and it works! What's the problem?" and then it descends into language lawyering.

Reply Score: 2

l3v1 Member since:
2005-07-06

But another way of looking at it is that C exposes the programmer to unnecessary risk.


Or, from another point of view, to necessary power. That a language gives freedom, doesn't mean it's bad. When someone uses that freedom without the necessary skill, now that really means bad, in every imaginable way.

Reply Score: 1

rleigh Member since:
2014-11-15

This isn't really true though, is it? I have exactly the same "power" with C++, but without the risk. The risks mentioned above with C are entirely avoidable by using a language which removes that risk. Most of the time, the C++ compiler does so with no runtime overhead and no reduction in power.

With C++, I can use std::unique_ptr and std::shared_ptr, and get guaranteed safe, robust and reliable memory management. unique_ptr has zero overhead; shared_ptr has the overhead of reference counting, but removes the chance for the programmer to screw up. Likewise with strings, the C (and glib) string APIs are dangerous and easy to use incorrectly; std::string gives equivalent (or better) performance without the risk.

The choice here isn't that C gives "more power". Both languages can do everything the other can, but the tradeoff here is whether the extra manual work and risk C imposes by requiring lots of manual make-work provides any benefit. In most cases, it just doesn't. If I have the choice between two tools, one of which is safer for no loss of performance, it's not exactly a difficult choice to make unless I'm a masochist. Manual refcounting is a problem waiting to happen, and if you look at the number of refcounting bugs in glib/gtk and client applications over the years, it's painfully obvious that it's an unresolvable problem in C, but one which C++ can elegantly and simply solve with smartpointers. Likewise with string handling, the regular stream of buffer overflow and other expolits and crashes is a clear indication that even experts can't use them correctly and consistently, but std::string eliminates the entire class of bugs, typically with either no performance impact or in many cases a performance gain (no need to run strlen() for every operation, and reallocations can be reduced).

Reply Score: 3

kwan_e Member since:
2007-02-18

With C++, I can use std::unique_ptr and std::shared_ptr, and get guaranteed safe, robust and reliable memory management. unique_ptr has zero overhead; shared_ptr has the overhead of reference counting, but removes the chance for the programmer to screw up.
.
.
.
Manual refcounting is a problem waiting to happen, and if you look at the number of refcounting bugs in glib/gtk and client applications over the years,



Not to mention the problems of manual refcounting in a threaded application. Smart pointers take care of refcounting in a threadsafe way.

Reply Score: 3

grat Member since:
2006-02-02

First, you seem to be switching back and forth between GTK+, a toolkit, and C, a programming language.

The vagaries of GTK+ should not be considered a pro or con against C, rather, they're a con against the people who designed and wrote GTK+.

Aside from that, I would say that far too many programs I've seen have shown warnings during compile-time. That's a hint that something untoward might be happening. It also means that cross-platform coding in C is rolling the dice.

I never claimed that C is a good language for general purpose programming-- many people who programmed in it (myself included) have bad habits that aren't conducive to good code (personally, I haven't done any C coding in the last 10 years, because it's not necessary, or preferable, for what I do now).

But you CAN produce reliable, solid code in C-- You just have to be careful about how you do it.

It needs to be remembered that C is not that far removed from Assembly language-- it's basically abstracting out assembly into a "common language", and as such, will give you not just the ability to shoot yourself in the foot-- but it gives you a machine-gun with unlimited ammunition. ;)

Reply Score: 2

kwan_e Member since:
2007-02-18

But you CAN produce reliable, solid code in C-- You just have to be careful about how you do it.


The issue is not that C can't produce reliable solid code. The issue is that it can't easily produce reliable solid code. Time is wasted being "careful" around the code. Time that should be spent on high level design and verification.

Reply Score: 3

Moochman Member since:
2005-07-06

Gtk+ is definitely not great with C, but with Vala it actually seems pretty appealing. Vala gives you C#-like syntax with everything you expect of a modern OO language, Automatic Reference Counting (had it way before Apple introduced it in Cocoa) and natural, invisible translation of classes to the GObject API behind the scenes. As far as I can tell there is no reason to ever write Gtk+ in plain old C ever again. The best example of what is possible using Vala with Gtk+ is elementary OS, they use it for everything and it has enabled a small team to put together an entire DE and suite of apps in just a couple years' time:

http://elementary.io

The main problem with Gtk+ today is that targeting the Linux desktop as the primary platform is no longer a very popular goal...

Reply Score: 3

Comment by hobgoblin
by hobgoblin on Tue 12th May 2015 15:43 UTC
hobgoblin
Member since:
2005-07-06

This would not be Emmanuele Bassi posting, would it?

Reply Score: 2

Samsung just doesn't know what to do
by moondevil on Tue 12th May 2015 17:38 UTC
moondevil
Member since:
2005-07-08

Tizen programming has been a clustf*ck since the beginning.

First it was to be only web based programming, then it inherited the C++ frameworks from BADA OS, which got rewritten to lose their Symbian C++ feel, which were again rewritten to straight C with Enlightenment.

Who knows if a fourth round is yet to come.

How can any serious developer ever think of writing a single code line for Tizen?

Reply Score: 6

Clearly missing the point about E
by cybergorf on Tue 12th May 2015 18:56 UTC
cybergorf
Member since:
2008-06-30

Compairing EFL to Qt or gtk must fail! Its like compairing wood and knive to Lego:
Lego is safe, easy, fast results and almost unlimited combinations ... But it will always look like lego. Ans so does qt or gtk.

EFL is the wood and knive approach: potentual dangerous, not so easy, but you can "carve" everything. You can even paint it and it will look marvellous. You can build everything from a small toy to a complete house.

EFL was never ment to be a Lego-like widget library (only the elementary part does that a little bit) - EFL shines at free-form animated interfaces and not at simple buttons.

Edited 2015-05-12 18:56 UTC

Reply Score: 1

Carewolf Member since:
2005-09-08

Compairing EFL to Qt or gtk must fail! Its like compairing wood and knive to Lego:
Lego is safe, easy, fast results and almost unlimited combinations ... But it will always look like lego. Ans so does qt or gtk.

EFL is the wood and knive approach: potentual dangerous, not so easy, but you can "carve" everything. You can even paint it and it will look marvellous. You can build everything from a small toy to a complete house.

EFL was never ment to be a Lego-like widget library (only the elementary part does that a little bit) - EFL shines at free-form animated interfaces and not at simple buttons.


I think you get thinks mixed around. EFL is playdough, you can shape into anything, but it will be always crap, the only thing that will make it work is everything else you structure it around. Qt is a professional powertool. It makes things simple, buy it can also do anything, by letting you replace any single component with specialized code.

Edited 2015-05-12 19:33 UTC

Reply Score: 8

cybergorf Member since:
2008-06-30

"Compairing EFL to Qt or gtk must fail! Its like compairing wood and knive to Lego:
Lego is safe, easy, fast results and almost unlimited combinations ... But it will always look like lego. Ans so does qt or gtk.

EFL is the wood and knive approach: potentual dangerous, not so easy, but you can "carve" everything. You can even paint it and it will look marvellous. You can build everything from a small toy to a complete house.

EFL was never ment to be a Lego-like widget library (only the elementary part does that a little bit) - EFL shines at free-form animated interfaces and not at simple buttons.


I think you get thinks mixed around. EFL is playdough, you can shape into anything, but it will be always crap, the only thing that will make it work is everything else you structure it around. Qt is a professional powertool. It makes things simple, buy it can also do anything, by letting you replace any single component with specialized code.
"

Well, lets say clay than ... And most houses are made of clay-bricks.
Don't get me wrong: I think Qt is great, and i never would use EFL if the same can be done much easier in Qt. Thats the wrong cometition!

But try to make something like "Terminology" in Qt and you will see, that it is not ment for such a thing:

https://m.youtube.com/watch?v=RxEbm4qGQHk

Edited 2015-05-12 19:54 UTC

Reply Score: 1

kwan_e Member since:
2007-02-18

But try to make something like "Terminology" in Qt and you will see, that it is not ment for such a thing:

https://m.youtube.com/watch?v=RxEbm4qGQHk



Seems pretty doable in Qt to me. If not in QML then in C++. What in "Terminology" is too difficult for Qt?

Reply Score: 4

cybergorf Member since:
2008-06-30

"But try to make something like "Terminology" in Qt and you will see, that it is not ment for such a thing:

https://m.youtube.com/watch?v=RxEbm4qGQHk



Seems pretty doable in Qt to me. If not in QML then in C++. What in "Terminology" is too difficult for Qt?
"

not that it is particularly useful:
https://www.youtube.com/watch?v=-8tZv4u8g6s

Exchanging the cursor prompt with a video! just by editing the theme file...
Sure, with enough code everything can be done in C++ und Qt too.

Reply Score: 1

kwan_e Member since:
2007-02-18

"[q]But try to make something like "Terminology" in Qt and you will see, that it is not ment for such a thing:

https://m.youtube.com/watch?v=RxEbm4qGQHk



Seems pretty doable in Qt to me. If not in QML then in C++. What in "Terminology" is too difficult for Qt?
"

not that it is particularly useful:
https://www.youtube.com/watch?v=-8tZv4u8g6s

Exchanging the cursor prompt with a video! just by editing the theme file...
Sure, with enough code everything can be done in C++ und Qt too. [/q]

But what about actual functionality that actually matters and people will find actually useful?

And no, it wouldn't be hard in Qt. It's just a playing video that is painted where the cursor would be.

Reply Score: 3

MrHood Member since:
2014-12-02

Compairing EFL to Qt or gtk must fail! Its like compairing wood and knive to Lego(...)


^This!

Enlightenment and its libraries have always looked like some sort of coding wizardry... At least to me.

Already a good amount of years ago - when E17 and EFL were just a thought - they already managed to pull out some kind of graphical performance levels with software-only rendering in E16 that the "mainstream" WMs and toolkits couldn't even achieve with hardware acceleration.

And then they realized that no toolkit had the flexibility and power they wanted, and so they underwent the creation of their very own libraries from scratch - how many WM developers can you count that achieved something similar?

And while I cannot fully speak about their ease of use (or lack thereof), I am sure EFL has very few comparable equals (if any) and certainly deserves *a lot* more respect than the thrash-talking that the linked blog post is spilling all around.

Either the guy under the spotlight of this OSNews "article" has some strained relationship with Rasterman, or simply he understands nothing about GUI development... :-D

Poor Tizen.


Not sure about what you precisely mean with this, but you are looking a lot like the guy I described just above... :-(

Reply Score: 2

leos Member since:
2005-09-21

Compairing EFL to Qt or gtk must fail! Its like compairing wood and knive to Lego:
Lego is safe, easy, fast results and almost unlimited combinations ... But it will always look like lego. Ans so does qt or gtk.


Wrong. Qt using QML (which is what you would use on mobile) you can have your UI look like anything you like. There isn't anything you can do in EFL that you can't do in Qt. EFL is likely a bit more performant because it is missing so many features from Qt, but that's about it.

Reply Score: 2

cybergorf Member since:
2008-06-30

[q] ... There isn't anything you can do in EFL that you can't do in Qt. EFL is likely a bit more performant because it is missing so many features from Qt, but that's about it.


As said before: you can code everything with every tool - it may just not be the best/shortest/fastest/savest way. (Pick one option)

Sure qml works fine on my Jolla Phone :-)

On EFL one would use Embryo to define your Interface. Spice it up with Lua or Python. Or do it on a graphical editor like Enventor:

https://m.youtube.com/watch?v=gwhsFjIhNaM

Or the theme editor:

https://m.youtube.com/watch?v=SYauwMAJhbg

Reply Score: 1

Interesting, remain sceptical
by ideasman42 on Tue 12th May 2015 19:01 UTC
ideasman42
Member since:
2007-07-20

Firstly, I never used EFL, but have maintained GUI-C-libs. And am often skeptical when devs post about how bad some code is.

Especially when they show simplistic side by side examples. Which often just show the difference between low/high level API's. Or show some boiler plate code compared against another API's wrapper function for similar code.

There are projects with key goals to have clean code, while I like it as a principle... at some point the bottom line is meeting user needs or not.

(BSD guys kicking Linux for having bad code springs to mind... )

Ultimately, the proof is in the pudding.

Reply Score: 3

Comment by oinet
by oinet on Tue 12th May 2015 20:08 UTC
oinet
Member since:
2010-03-23

From the page, quote:

Using Qt, one would write:

auto widget = new QWidget{parent};
widget->show();

End of quote. Correct me if I'm wrong (Since I do C, but not C++) but shouldn't it be:

new QWidget(parent);
and not
new QWidget{parent}; (note the curly brackets)
?

Edited 2015-05-12 20:15 UTC

Reply Score: 1

RE: Comment by oinet
by rleigh on Tue 12th May 2015 21:23 UTC in reply to "Comment by oinet"
rleigh Member since:
2014-11-15

Both would be correct. His syntax with the braces is the newer C++11 syntax using an initialiser list (std::initializer_list), and also using an auto type to save typing the class name twice.

Reply Score: 4

RE[2]: Comment by oinet
by oinet on Wed 13th May 2015 07:33 UTC in reply to "RE: Comment by oinet"
oinet Member since:
2010-03-23

Both would be correct. His syntax with the braces is the newer C++11 syntax using an initialiser list (std::initializer_list), and also using an auto type to save typing the class name twice.


Thanks for the infomation.

Reply Score: 1

Comment by oinet
by oinet on Tue 12th May 2015 20:40 UTC
oinet
Member since:
2010-03-23

OSNews dragged my edit (addition of input) to hell with it's 20 minutes edit limit. At least I could have received back my edited text, so I could copy ?

Anyway, quote: "Those knowledgeable in the horrible language of C know it’s a pointer to anything."

Those knowledgeable in the horrible C++ language know that:

* An operator could be anything, even Jabba the Hutt himself.
* Template syntax is yuck.
* ABI is one you don't mess with, much less trust.

That was my own 5 minutes of fame response, thanks for the ovations!

Edited 2015-05-12 20:41 UTC

Reply Score: 2

RE: Comment by oinet
by kwan_e on Wed 13th May 2015 00:58 UTC in reply to "Comment by oinet"
kwan_e Member since:
2007-02-18

* An operator could be anything, even Jabba the Hutt himself.


And so could a function be anything. Programmers deal with context in their minds all the time. It's not that hard to expand that mental ability to include operator (or function) overloading. Unless there is no mental ability there to expand.

* Template syntax is yuck.


Only when you have to write libraries. Using libraries that uses templates, though, can look way more cleaner than the comparable C code.

eg, this is code for using a state machine I've implemented:

machine
, state0 >> event0 >> [&state1](const State0&, auto&){return state1;} >> state1
, state0 >> event1 >> [&state2](const State0&, auto&){return state2;} >> state2
, state2 >> event3 >> [&state1](const State2&, auto&){return state1;} >> state1
, state1 >> event1 >> [&state3](const State1&, auto&){return state3;} >> state3
, state1 >> event4 >> [&state6](const State1&, auto&){return state6;} >> state6
, state6 >> event6 >> [&state4](const State6&, auto&){return state4;} >> state4
, state2 >> event2 >> [&state5](const State2&, auto&){return state5;} >> state5
, state4 >> event5 >> [&state5](const State4&, auto&){return state5;} >> state5
, state3 >> event2 >> [&state0](const State3&, auto&){return state0;} >> state0
, state5 >> event0 >> [&state0](const State5&, auto&){return state0;} >> state0
;

machine->switch_on(state0, state3, state4);

The state machine itself uses templates heavily, but the as you can see, code using the state machine hides it completely. In fact, if you change the return type of any of those lambdas to be different to the return state at the end, you get a compiler error. The point being the code is completely generic, but does not do any casts and thus is still compile time safe. And still not a template in sight.

Incidentally, this is a state machine I'm designing for GUI testing, among other things. And I've done just as complicated templated libraries for my own Qt projects. Qt works really well with C++11 and 14 and can be made even more cleaner with such.

Reply Score: 3

RE[2]: Comment by oinet
by oinet on Wed 13th May 2015 07:32 UTC in reply to "RE: Comment by oinet"
oinet Member since:
2010-03-23

And so could a function be anything. Programmers deal with context in their minds all the time. It's not that hard to expand that mental ability to include operator (or function) overloading. Unless there is no mental ability there to expand.


And that's just the problem. I was using that same argument against that same article. You seem to miss the point. Besides, I see no reason why operators need to be abused and hence add to un-readability for the outsider (very VERY important in (F)OSS), when the same thing can be performed by functions/templates. I even prefer macros to overloaded operators, as the latter are just super yuck.

Only when you have to write libraries. Using libraries that uses templates, though, can look way more cleaner than the comparable C code.


I know, but I wasn't referring to the user-end of said functionality.

eg, this is code for using a state machine I've implemented:

machine
, state0 >> event0 >> [&state1](const State0&, auto&){return state1;} >> state1
, state0 >> event1 >> [&state2](const State0&, auto&){return state2;} >> state2
, state2 >> event3 >> [&state1](const State2&, auto&){return state1;} >> state1
, state1 >> event1 >> [&state3](const State1&, auto&){return state3;} >> state3
, state1 >> event4 >> [&state6](const State1&, auto&){return state6;} >> state6
, state6 >> event6 >> [&state4](const State6&, auto&){return state4;} >> state4
, state2 >> event2 >> [&state5](const State2&, auto&){return state5;} >> state5
, state4 >> event5 >> [&state5](const State4&, auto&){return state5;} >> state5
, state3 >> event2 >> [&state0](const State3&, auto&){return state0;} >> state0
, state5 >> event0 >> [&state0](const State5&, auto&){return state0;} >> state0
;

machine->switch_on(state0, state3, state4);

The state machine itself uses templates heavily, but the as you can see, code using the state machine hides it completely. In fact, if you change the return type of any of those lambdas to be different to the return state at the end, you get a compiler error. The point being the code is completely generic, but does not do any casts and thus is still compile time safe. And still not a template in sight.

Incidentally, this is a state machine I'm designing for GUI testing, among other things. And I've done just as complicated templated libraries for my own Qt projects. Qt works really well with C++11 and 14 and can be made even more cleaner with such.


I realize the implementor vs user in this regard. And I DO realize some of C's shortcomings for certain usages. For me though, C is good enough. Not perfect by any measure, but good enough. I know that if some code is in C the chance is almost infinitly higher for me to understand than C++ code (which could be anything from a quiet and kind 8 year old kid to Jabba the Hutt as math prophet....ok ok jk).

Reply Score: 2

RE[3]: Comment by oinet
by Vanders on Wed 13th May 2015 09:03 UTC in reply to "RE[2]: Comment by oinet"
Vanders Member since:
2005-07-06

What is with people and "operating overloading is abuse"? I'm going to file that one alongside "threading is impossible" in my Hyberbolic Bullshit folder.

Why is the following

Bignum a(4^10), b(7^8);
Bignum c;

c = a + b;


such terrible, much abuse? Why is

c = a.add(b);


"better" when we already have a perfectly good addition operator we could be using? If you have an object where adding them (or subtracting, dividing, whatever) makes sense, how is it "abuse" to, you know, maybe support those operators for your object?

Reply Score: 5

RE[4]: Comment by oinet
by oinet on Wed 13th May 2015 10:57 UTC in reply to "RE[3]: Comment by oinet"
oinet Member since:
2010-03-23

What is with people and "operating overloading is abuse"? I'm going to file that one alongside "threading is impossible" in my Hyberbolic Bullshit folder.


You mean "operator", not "operating" ?

Why is the following

"Bignum a(4^10), b(7^8);
Bignum c;

c = a + b;


such terrible, much abuse? Why is

c = a.add(b);


"better" when we already have a perfectly good addition operator we could be using? If you have an object where adding them (or subtracting, dividing, whatever) makes sense, how is it "abuse" to, you know, maybe support those operators for your object?
"

That's why I wrote operator overloading _abuse_, not _use_. Addition and other arithmetic operators are implemented directly by generating assembly (> machine) code. It's a 1:1 correspondence, more or less (except for hardware that doesn't have FPU). I know perfectly well that if one was to write own programming langauge then one could assign different function to same operator based on it's syntactic or type surrounding: "hey, if I'm assigning addition to '+' when using numeric literals/types then I can assign string concatanation when using string literals/types". Similarly for vector and matrix math one can do just that, as it's done often in C++ (and other languages with subject functionality). I don't have a problem with that (although I prefer to implement my vector math stuff with functions myself, even if I was using C++ I would do that).

When one looks at "outsider" source code and sees "memory_handle += 100;" (which actually is easily guessed, and my intention is to avoid the scary examples) do you think this is the proper way to call memory API ? I'm being very general here. Don't ask me why one would do such a thing. The fact that it's possible opens for abuse.

Edited 2015-05-13 10:59 UTC

Reply Score: 2

RE[5]: Comment by oinet
by Vanders on Wed 13th May 2015 11:40 UTC in reply to "RE[4]: Comment by oinet"
Vanders Member since:
2005-07-06

You mean "operator", not "operating" ?

Yes, simple typo.

When one looks at "outsider" source code and sees "memory_handle += 100;" (which actually is easily guessed, and my intention is to avoid the scary examples) do you think this is the proper way to call memory API ?


I'm not sure what you're asking. It appears to add the constant integer to a variable called "memory_handle" but as I have no idea what type that variable is, I can't tell you if it's "proper" or not.

If I assume that memory_handle is an instance of an object that perhaps abstracts some sort of nonlinear memory model, perhaps memory_handle += 100; makes perfect sense?

Reply Score: 2

RE[6]: Comment by oinet
by oinet on Wed 13th May 2015 11:51 UTC in reply to "RE[5]: Comment by oinet"
oinet Member since:
2010-03-23

"When one looks at "outsider" source code and sees "memory_handle += 100;" (which actually is easily guessed, and my intention is to avoid the scary examples) do you think this is the proper way to call memory API ?


I'm not sure what you're asking. It appears to add the constant integer to a variable called "memory_handle" but as I have no idea what type that variable is, I can't tell you if it's "proper" or not.

If I assume that memory_handle is an instance of an object that perhaps abstracts some sort of nonlinear memory model, perhaps memory_handle += 100; makes perfect sense?
"

Your second paragraph is the correct assumption. I wrote "simple to guess" (when I of course included "_handle" as suffix). But my point is that it's abuse. I guess we agree to disagree.

EDIT:

Actually I read your answer too quickly. The line of code adds (allocates) further amount of bytes to "memory_handle". As you can see, the assumptions become a mess (even when I used "_handle" as suffix, since the variable is not a pointer to allocated memory).

Edited 2015-05-13 11:57 UTC

Reply Score: 2

RE[7]: Comment by oinet
by Vanders on Wed 13th May 2015 12:12 UTC in reply to "RE[6]: Comment by oinet"
Vanders Member since:
2005-07-06

I think we can both agree that stupid programmers will do stupid things. I don't see how giving non-stupid programmers useful tools makes that feature bad because a stupid programmer will use it incorrectly; I suspect there are examples of this problem (stupid people abusing perfectly good features) in every language.

Reply Score: 2

RE[5]: Comment by oinet
by kwan_e on Thu 14th May 2015 02:42 UTC in reply to "RE[4]: Comment by oinet"
kwan_e Member since:
2007-02-18

Addition and other arithmetic operators are implemented directly by generating assembly (> machine) code.


Which is completely irrelevant, since the '+' sign is a mathematical notion. There's no rule that there should be any correspondence between a symbolic notation and hardware implementation. Or, in other words, programming does not own the concept of mathematical operations.

Mathematicians and scientists have no trouble with dealing with operators that behave differently under different usages/contexts. So neither should you. If you do, blame your own lack of mathematical skill. Operator overloading should be no trouble to anyone who has progressed beyond basic algebra.

The fact that it's possible opens for abuse.


Do you know what is open for abuse? Turing machines and Church's lambda calculus. Function overloading is open to abuse. Everything is open to abuse. Even HTML and CSS is open to abuse. Hell, even abacuses are open to abuse.

Type casting is open to abuse, and is empirically more dangerous than operator overloading. It's 2015 and C programmers still can't stop preventing bad memory accesses. Which brings us back full circle to EFL and other C widget toolkits (like GTK+). They actually abuse the language to do what other languages do as a matter of course. Actual abuse is more real than potential abuse.

Godel-Escher-Bach is a good look at how any system powerful enough to be consistent cannot be complete, and vice versa. "Open to abuse" is therefore not a legitimate criticism.

Reply Score: 3

RE[6]: Comment by oinet
by oinet on Thu 14th May 2015 15:07 UTC in reply to "RE[5]: Comment by oinet"
oinet Member since:
2010-03-23

"Addition and other arithmetic operators are implemented directly by generating assembly (> machine) code.


Which is completely irrelevant, since the '+' sign is a mathematical notion. There's no rule that there should be any correspondence between a symbolic notation and hardware implementation. Or, in other words, programming does not own the concept of mathematical operations.

Mathematicians and scientists have no trouble with dealing with operators that behave differently under different usages/contexts. So neither should you. If you do, blame your own lack of mathematical skill. Operator overloading should be no trouble to anyone who has progressed beyond basic algebra.
"

So you jumped the gun without considering my comment. Read again my comment and let your pre-judices go. I even write that it would be logical to assign '+' to even string concatanation should one write an own language. I even mention vectors and matrices and the fact that I don't see any problem with that even if I prefer function-like approaches myself.

"Your (my) own lack of mathemtaical skill" ? Are you alright ?

"The fact that it's possible opens for abuse.


Do you know what is open for abuse? Turing machines and Church's lambda calculus. Function overloading is open to abuse. Everything is open to abuse. Even HTML and CSS is open to abuse. Hell, even abacuses are open to abuse.
"

CSS itself is abuse and voodoo magic AIO (ranty joke, but in some ways it really is true).

And that's my point, if C++ soldiers have their view that C memory access and type casting is abuse (regardless whether you use the word 'abuse' or not) then I have my views on C++, why so bothered ? What I wrote is perfectly true, operator overlaoding opens for (further) abuse. And need I drag some C++ un-ABI candy into this discussion ? "C++ is a horrible language", it's too large, too much, and that has nothing to do with math skills, algebra or not. I'm right, you're right, and we simply agree to disagree.

Type casting is open to abuse, and is empirically more dangerous than operator overloading. It's 2015 and C programmers still can't stop preventing bad memory accesses.


Yep, 2015, and C++ programmers can prevent resource leaks ? Considering my own experiences with only chromium-based browsers tells me otherwise ( I frequently need to restart them as both CPU and memory get eaten beyond bones). Neat.

Which brings us back full circle to EFL and other C widget toolkits (like GTK+). They actually abuse the language to do what other languages do as a matter of course. Actual abuse is more real than potential abuse.


If authors of an assembly programmed framework pass around addresses to subroutine address tables and dereference those table entries, are they abusing assembly to make it behave like function pointer structs, or C++ vtables ? Where they abusing assembly when there was only assembly (and nothing else besides machine code) when they wrote mnemonics to ADD and SUB ? Anyway, I have no problems with GTK+ use at all. I only dislike the class/widget definition process, and frankly I have a feeling that since that likely reflects the object system itself, and not the other way round, that is the reason for it's elaborate verboseness (including too many macros and what not). I'm not going to elaborate, perhaps they did do plenty of research, I have no idea.

Godel-Escher-Bach is a good look at how any system powerful enough to be consistent cannot be complete, and vice versa. "Open to abuse" is therefore not a legitimate criticism.


And neither is "C++ is a horrible language" while "C is a horrible language" is ?

Reply Score: 2

RE[7]: Comment by oinet
by kwan_e on Thu 14th May 2015 23:14 UTC in reply to "RE[6]: Comment by oinet"
kwan_e Member since:
2007-02-18

Thank you for basically arguing my point. "Open to abuse" is not a legitimate criticism for anything because anything worth using is always open to abuse. And anything can easily be said to be "open to abuse". A criticism that applies to everything applies to nothing.

So you need a better (a proper) argument against any language feature, not just operator overloading.

And if anyone needs to read, it's you. Because I didn't say C is a horrible language in general. I said it's a horrible language for writing GUI toolkits, as evidenced by every C (or mixed C/C++) GUI toolkit. And it's also evidenced by the fact that every major C project, no matter how complex, well designed or written, always re-implement OO features.

Reply Score: 1

RE[3]: Comment by oinet
by kwan_e on Thu 14th May 2015 02:56 UTC in reply to "RE[2]: Comment by oinet"
kwan_e Member since:
2007-02-18

"And so could a function be anything. Programmers deal with context in their minds all the time. It's not that hard to expand that mental ability to include operator (or function) overloading. Unless there is no mental ability there to expand.


And that's just the problem. I was using that same argument against that same article. You seem to miss the point. Besides, I see no reason why operators need to be abused and hence add to un-readability for the outsider (very VERY important in (F)OSS), when the same thing can be performed by functions/templates. I even prefer macros to overloaded operators, as the latter are just super yuck.


Sorry, but that's just an allergic reaction you've developed. Not an argument. You have no solid argument against operator (or function) overloading - yours is just a matter of taste. Bad taste, but still a matter of taste.

If you want to talk about readability to outsiders, macros are worse for outsiders than operator overloading. Macros have no type checking, whereas operator overloading has to work with strong static types.

[q][q]Only when you have to write libraries. Using libraries that uses templates, though, can look way more cleaner than the comparable C code.


I know, but I wasn't referring to the user-end of said functionality.
"

User-end functionality is important. Because most uses of library code is at the user end. Large projects are split into libraries. Internal use of those libraries is the bulk of the code. The "end-user" is still the people working on the project itself.

So if you want to talk about readability to outsiders, being able to hide complexity in libraries is much more readable than exposing that complexity to the library users. A large project is therefore expected to have uses of that library peppered all throughout it, and you do not want to export that complexity all over the project.

Reply Score: 3

RE[4]: Comment by oinet
by oinet on Thu 14th May 2015 15:09 UTC in reply to "RE[3]: Comment by oinet"
oinet Member since:
2010-03-23

That comment of yours is mess, if you fix it I might respond.

Reply Score: 2

RE[4]: Comment by oinet
by oinet on Fri 15th May 2015 11:25 UTC in reply to "RE[3]: Comment by oinet"
oinet Member since:
2010-03-23

You didn't fix that messy message, so I had to decode it myself.

Sorry, but that's just an allergic reaction you've developed. Not an argument. You have no solid argument against operator (or function) overloading - yours is just a matter of taste. Bad taste, but still a matter of taste.


And that is merely the opinon of one programmer among many (millions ?). Thanks for letting me know, but that is the reason I'm called individual. Some prefer footbal, others soccer. Some prefer muay-thai, others jiujutsu. Tell me now who has the bad taste!

If you want to talk about readability to outsiders, macros are worse for outsiders than operator overloading. Macros have no type checking, whereas operator overloading has to work with strong static types.


I know, I'm just expressing my personal "bad taste" regarding operator overloading.

So if you want to talk about readability to outsiders, being able to hide complexity in libraries is much more readable than exposing that complexity to the library users. A large project is therefore expected to have uses of that library peppered all throughout it, and you do not want to export that complexity all over the project.


This makes no sence. You think C programmers cannot "hide" nasty stuff in low layers ? Sure, it may not be C++ syntax sugar and what not, but I'm fine with it. If I ever get disgusted I'll join the C++ rebellion.

Edited 2015-05-15 11:32 UTC

Reply Score: 1

RE[5]: Comment by oinet
by kwan_e on Sat 16th May 2015 01:13 UTC in reply to "RE[4]: Comment by oinet"
kwan_e Member since:
2007-02-18

You didn't fix that messy message, so I had to decode it myself.


I didn't fix that message because this website has a time limit on edits, which expired by the time you replied.

And that is merely the opinon of one programmer among many (millions ?).


It's very telling how people like you keep saying "it's your opinion", but when it comes to your own opinion, it suddenly becomes fact.

"So if you want to talk about readability to outsiders, being able to hide complexity in libraries is much more readable than exposing that complexity to the library users. A large project is therefore expected to have uses of that library peppered all throughout it, and you do not want to export that complexity all over the project.


This makes no sence. You think C programmers cannot "hide" nasty stuff in low layers ? Sure, it may not be C++ syntax sugar and what not, but I'm fine with it. If I ever get disgusted I'll join the C++ rebellion.
"

If it involves too many casts and too many macros, then no, it is not hiding anything at all. You've just replaced one complexity with another kind and exposed that to the user. It's not a matter of syntactic sugar if you lose type safety and/or unclear ownership semantics.

Reply Score: 2

RE[6]: Comment by oinet
by oinet on Sat 16th May 2015 11:00 UTC in reply to "RE[5]: Comment by oinet"
oinet Member since:
2010-03-23

I didn't fix that message because this website has a time limit on edits, which expired by the time you replied.


You could have made a clean repost.

It's very telling how people like you keep saying "it's your opinion", but when it comes to your own opinion, it suddenly becomes fact.


Dude, I have mutiple times explained to you that what I wrote is my personal opinion. It's my "taste". I also wrote the same is true for every opinion giver. Did I not ?

If it involves too many casts and too many macros, then no, it is not hiding anything at all. You've just replaced one complexity with another kind and exposed that to the user. It's not a matter of syntactic sugar if you lose type safety and/or unclear ownership semantics.


(void *) casts are the way to do "generic" programming in C. Not as clean a C++, nor does that restrict the type of the passed "object". But that works for me, I have no problems. Never passed wrong type to a function this way, really.

Edited 2015-05-16 11:06 UTC

Reply Score: 1

Re:
by kurkosdr on Wed 13th May 2015 01:57 UTC
kurkosdr
Member since:
2011-04-11

Guys, nobody is blaming EFL for what it aims to be. What is being blamed are the creators of EFL, who are apparently to immature to produce libraries intended to be used in production environments.

-Not documenting anything? What is this a library you crufted up over the weekend, part of your dissertation?

-Having the compiler always finish with 0? Why?

-NAUGHTY PROGRAMMER! SPANK SPANK SPANK!!! and BITCH! I pity the foo who will have to write a book for this and intends to sell it for the usual 100 bucks.

-What's with the pointer thing? I lost the author there. My brain automatically recalled the fact INTERCAL performs AND and OR among the bits of a number and shut down some time afterwards.

Even if the aim of EFL is good, those guys ruined it. Have fun with your Qt legos. Any department basing anything on EFL will lose shipping dates and lag on features compared to competition (*cough* Tizen *cough*), and eventually be shut down.

And the "low memory usage because it runs on low-end phones" is silly. 6 months from now, every phone will have 1GB of RAM (if not already) which is enough even for Android to run.

Reply Score: 3

RE: Re:
by raster on Wed 13th May 2015 10:09 UTC in reply to "Re:"
raster Member since:
2005-07-07

You may want to look at the bit where most of what is claimed is debunked - by me. Scroll down.

The "bitch" thing is a matter of your origin. Where I grew up it means most commonly in that context "complaint" i.e. as "stop bitching" or "I'm bitching about your API usage". I didn't realize that the more hyper-sensitive or differently cultured may interpret it differently. I actually have never seen the error complaint in like maybe 5-10 years, so I forgot it was even there. But he mis-quoted it and I looked for what was quoted and didn't find it until I expanded my guess-work of what was being quoted and fixed it. I said so soon after. As for the facebook "like" icon - I know a lot of older people who see that symbol as meaning "up your bum" as a rude gesture. Growing up that is what I was actually originally taught. Some people can't possibly imagine a different cultural context. I forgot about it and admitted the problem once found.

As for the "naughty programmer", it tells you far more. Those outputs are meant to get the attention of the developer. It just wasn't quoted with the prior 2 or 3 lines of output that ALSO tell the details. For example: your input parameter is NULL, or object of the wrong type etc. The original post implies that all it does is say "naughty-spank" and leave it at that. It does not. This is the kind of output you get to get your attention:

[eina_iterator.c:163] eina_iterator_foreach() *** Eina Magic Check Failed !!!
Input handle pointer is NULL !
*** NAUGHTY PROGRAMMER!!!
*** SPANK SPANK SPANK!!!
*** Now go fix your code. Tut tut tut!


The compiler NEVER exited always with 0. Ever. Check src code + git history for a fact check. Whatever they see is not a result of the compiler always returning 0 - it never did. He may be using scratchbox with qemu emulating an ARM host system and executing an arm edje_cc on his x86 build box, and it is qemu that is itself returning with 0 rather than the exit code of edje_cc, or something else, but it sure isn't the compiler. We have relied on it having non-zero exit codes as we call it during builds in our own Makefiles. These would all be gloriously failing if it always returned 0.

As for documentation - I pointed to the docs on enlightenment.org. The very first getting started guide for elementary with the first hello world app would have solved his background issue by telling him to do it the easy way, not the hard way. It's documented all there. He chose not to read the docs and then complained things were hard.

His quote on our new object system only allowing 512 objects was also laughable. Provably wrong and clearly he didn't understand the presentation, didn't attend it and clearly didn't rub enough braincells together to realize that all the standard demos and tests in EFL easily exceed that object count and thus how could it be true if those tests and demos still work? Nor did he fact check by reading the code before making claims.

The typedefs to void * were also total fabrication. Proven wrong. Check the src and git history if you don't believe me.

He has some points to make, like no backtrace by default in such spank errors (this is due to backtrace() + backtrace_symbols() being largely useless and thus we relied on using gdb to trap them with aborts as i mentioned). It takes SIGNIFICANT effort to work around the limitations of glibc and get things like backtraces that can be useful, and so we instead relied on a different mechanism (gdb + aborts). But when you bury some points inside a landslide of basically "bullshit", it loses its luster.

Instead he chose to invent some "facts" out of thin air, selectively quote or twist facts to match a narrative he already had in mind. Provably he didn't bother even with the public docs as his first complaint is the very first thing solved in the getting started guide.

So just read on and do some research as above (the code and all changes are public so nothing is hidden) if you don't believe an author refuting those claims.

I'm all up for sensible, fact based discussion and criticism. In the end in some cases there might be an "agree to disagree". But the snide remarks about "redtube" (porn site FYI - I checked) making it a personal attack, with selective memory, quoting, lack of proof of claims, lack of research and actual basis in fact etc. makes this above original post a wonderful work of mostly fiction and slander. Act like a sensible and intelligent human being, and you get treated as such. I won't hide behind an anonymous identity. The OP apparently is happy to do so.

Reply Score: 3

RE[2]: Re:
by dpJudas on Wed 13th May 2015 12:46 UTC in reply to "RE: Re:"
dpJudas Member since:
2009-12-10

The "bitch" thing is a matter of your origin. Where I grew up it means most commonly in that context "complaint" i.e. as "stop bitching" or "I'm bitching about your API usage". I didn't realize that the more hyper-sensitive or differently cultured may interpret it differently.

...

The original post implies that all it does is say "naughty-spank" and leave it at that. It does not. This is the kind of output you get to get your attention:

[eina_iterator.c:163] eina_iterator_foreach() *** Eina Magic Check Failed !!!
Input handle pointer is NULL !
*** NAUGHTY PROGRAMMER!!!
*** SPANK SPANK SPANK!!!
*** Now go fix your code. Tut tut tut!


I think it might worth changing those kinds of error messages to be far more informal. For example, changing "Bitch!" to "Complaint!" still leaves too much ambiguity in the lines outputted. And the spank error message has two head-scratching lines and then accuses my code to be crap! I'll be the judge of whether my code is broken or not! Even if its 99.99% likely it is my code at fault.

Keep in mind that a frustrated newbie developer (like the OP clearly is) will have absolutely no clue why EFL writes those lines. The error messages makes it trivial to do an ad hominem attack on both EFL and you as a developer. The output could look like this instead:

[eina_iterator.c:163] eina_iterator_foreach() *** Eina Magic Check Failed !!!
Input handle pointer is NULL !
*** API MISUSE DETECTED! One of the function arguments are invalid!


In my opinion the slides posted in the comments suffer a bit from the same problem. Clearly you've heard one too many "if you switched to C++ or [insert other language here] then everything would be better" lines in your life. Personally as a C++ developer I've heard enough of it myself.

There are just some kinds of jokes and opinions you should keep out of public or you'll piss off people. No they won't get the joke. Developers are just too invested in their technological choices to not take it personal.

He has some points to make, like no backtrace by default in such spank errors (this is due to backtrace() + backtrace_symbols() being largely useless and thus we relied on using gdb to trap them with aborts as i mentioned).

Out of curiosity, why are those two functions largely useless? We use them in ClanLib ourselves and seem to capture stack traces fine. Admittedly I'm doing most of my development in Windows but haven't heard about anyone having problems with the Linux version of our two stack tracing functions:

https://github.com/sphair/ClanLib/blob/master/Sources/Core/System/sy...
https://github.com/sphair/ClanLib/blob/master/Sources/Core/System/sy...

Reply Score: 3

RE[3]: Re:
by raster on Thu 14th May 2015 00:17 UTC in reply to "RE[2]: Re:"
raster Member since:
2005-07-07

i just chanted bitch to complain and the errors are:

ERR("COMPLAIN! evas_object_stack_above(), %p not inside same smart as %p!", eo_obj, eo_above);

etc. it's just the first word telling you there is a complaint. it tells you exactly where and why already. i son't see what ambiguity there is there - complain -> here is why.

and the spank messages are accusing the calling code (which is the vast majority of the time something outside of the libraries) of passing in something invalid. it's a validity check failing. it is something that does need fixing. if you think it says your code is crap- you are adding that interpretation. it does say the programmer was naughty and needs a spanking and then to fix code. if you are converting the message to say your code is crap - then TBH any message saying something is wrong can be taken to say that. you're taking things awfully personally right out of the bat with the view that how dare anything even insinuate something could be wrong in your code. the message does it with some humor and tongue-in-cheek to try at least to get a laugh and some attention. i guess people with no sense of humor are always going to say this. the "why" was always printed there - right above.

as for the slides - they are from a presentation. they are not a document. if they were a document they'd be 50+ pages of dense text and examples. the point of a presentation is to be attended and listened to. slides just hilight key points or illustrate things easier done visually than in the spoken sense. so taking ANY slides without listening to the entire presentation too is going to be a pretty lossy way to evaluate something. and indeed i have heard the "well just switch to c++" line way too many times. in the presentation it is indeed a joke and it does elicit laughs from the audience. it is a way to keep their attention via humor. it works. works very well. if someone wants to be an a-hole, they'll find any excuse to do it, so there isn't much you can do.

as for the backtrace stuff - backtrace() has issues - it CAN call malloc inside of backtrace(). this is a problem if you are using it in a signal handler to catch an error .. and that happens to be in a malloc. deadlock. but that aside, backtrace_symbols will not give you function names and line numbers. at least not access shared library bounds. eg - it may work on the executable binary but not on the trace frames that are inside one of various shared libraries loaded. so you end up with no function name, just a filename for the library where the stack frame is. i've poked at this often enough over the years and given up on it as fairly useless.

Reply Score: 2

RE[2]: Re:
by somebody_close on Wed 13th May 2015 17:48 UTC in reply to "RE: Re:"
somebody_close Member since:
2015-05-13

The "bitch" thing is a matter of your origin. Where I grew up it means most commonly in that context "complaint" i.e. as "stop bitching" or "I'm bitching about your API usage".


Those are slang terms, which should never be present in a production-grade software. It's highly unprofessional, and could result in a harassment lawsuit, especially in the US. Errors should be descriptive - "bitch" isn't descriptive. It's rude.

As for the "naughty programmer", it tells you far more. Those outputs are meant to get the attention of the developer. It just wasn't quoted with the prior 2 or 3 lines of output that ALSO tell the details. For example: your input parameter is NULL, or object of the wrong type etc. The original post implies that all it does is say "naughty-spank" and leave it at that. It does not. This is the kind of output you get to get your attention:

[eina_iterator.c:163] eina_iterator_foreach() *** Eina Magic Check Failed !!!
Input handle pointer is NULL !
*** NAUGHTY PROGRAMMER!!!
*** SPANK SPANK SPANK!!!
*** Now go fix your code. Tut tut tut!


Any kind of log with "ERROR" in it also draws attention, but looks a lot more professional. You're complaining about a naughty joke about Redtube, yet you don't see anything wrong with your naughty logs, which can be seen by all your users. If you felt offended by the OP joke, image that yours is in the same line. So, you're either fine with it or not - but don't try to tell us it's fine when you make it, but utterly wrong when someone fires back at you. It just proves the point.

As for documentation - I pointed to the docs on enlightenment.org. The very first getting started guide for elementary with the first hello world app would have solved his background issue by telling him to do it the easy way, not the hard way. It's documented all there. He chose not to read the docs and then complained things were hard.


Make your API more obvious and the documentation problem goes away. Also note there are other sources of learning EFL, and not all can have that example. When searching through the bare API, you will also not find that example.

His quote on our new object system only allowing 512 objects was also laughable. Provably wrong and clearly he didn't understand the presentation, didn't attend it and clearly didn't rub enough braincells together to realize that all the standard demos and tests in EFL easily exceed that object count and thus how could it be true if those tests and demos still work? Nor did he fact check by reading the code before making claims.


In other words:
* the presentation was too vague
* "clearly didn't rub enough braincells together" - personal attack
* "Nor did he fact check by reading the code before making claims." - with well thought API with proper documentation, there is no need to look into the code, and that's the core problem. Your presentation failed to deliver a CLEAR and UNAMBIGUOUS message. Your argument now is to always fact check docs/presentation, which suggests the docs/presentations are wrong in the first place. In short - if someone needs to look into the implementation, you're doing something wrong as a library writer.

The typedefs to void * were also total fabrication. Proven wrong. Check the src and git history if you don't believe me.


Let's look at the docs for a callback used for pretty much everything: https://docs.enlightenment.org/auto/eio/Evas__Common_8h.html#a15e826...
I see 3 parameters: void *, Evas_Object (which can be anything) and another void *.

Now let's look at Evas_object: https://git.enlightenment.org/legacy/evas.git/diff/src?h=master&id=2...

A commit where void is changed to a struct. So for some time void * was true and now it's a generic struct, which also can represent anything. As in the OP - no type safety at all and that is the point.

So just read on and do some research as above (the code and all changes are public so nothing is hidden) if you don't believe an author refuting those claims.


Research done - OP proven true:
* poor API with bad docs
* no type safety
* unprofessional and harassing logs

One point refuted - unclear presentation led to one number falsely interpreted.

I'm all up for sensible, fact based discussion and criticism. In the end in some cases there might be an "agree to disagree". But the snide remarks about "redtube" (porn site FYI - I checked) making it a personal attack, with selective memory, quoting, lack of proof of claims, lack of research and actual basis in fact etc. makes this above original post a wonderful work of mostly fiction and slander. Act like a sensible and intelligent human being, and you get treated as such. I won't hide behind an anonymous identity. The OP apparently is happy to do so.


Your very first post is a barrage of personal attacks, which you continue later on. Suddenly you go quiet and now you're trying to spin it around. This smells of a classical lecture received from someone from the PR department.

Reply Score: 0

RE[3]: Re:
by raster on Thu 14th May 2015 01:11 UTC in reply to "RE[2]: Re:"
raster Member since:
2005-07-07

indeed i started off personally because my very first line... i said i'd respond in kind as the OP. he made it personal and adhominem almost of the bat. i was very clear about that. he obviously likes to speak this way, so use a language he understands.

as for slang - it's an open source project. most of it has been written in spare time. it just so happens the project is useful to companies and solves real problems. the linux kernel is full of swearing and slang in the src code. what's new? just someone wants to use that as a way of venting in what becomes a personal attack (the lines that make it really personal are the ones talking about redtube and in that context the whole thing becomes a personalize attack).

as such - i am not in the US. my point is that people only seem to see the world from their point of view. i have lived in the US before. the vast majority of people there think the world should conform to their standards and views. anything else is wrong. i totally accept that the word can be taken in that way, and addressed it, but you need to understand that not everyone in the world sees things from the angle of the US. the vast majority of the world does not, so thinking there is only one interpretation of a word or phrase is a very narrow view. "i'm pissed" where i come from means "i'm drunk", not "i'm angry". but if the only interpretation you have is "i'm angry" you'll misunderstand people again and again.

and the op was not joking about redtube. take the post as a whole - none of it was lighthearted or joking. it was a direct slander. look at the broader context. if it had a smiley or language that indicates it was lighthearted, that'd be otherwise.

as for api obviousness - he complained directly it was not documented. that is wrong. and the api is right there in the elm_win documentation for making a window. why did he not go look at it first when making a window and go "aaah a window WITH a background! use that!" as opposed to do it MANUALLY which required reading even more documentation (win docs + bg docs and then figuring out you can do the bg manually yourself). sorry but it'd documented as the first thing in getting started and the first port of call - win docs would have had it listed right there. it's documented. clearly. he said it's not documented and not obvious when he chose the most unobvious path by default - not even the thing first recommended or shown as an example. it's like someone using open of /dev/zero + mmap to allocate memory and going "my god linux sucks. this is so painful. why don't they just have a simple memory allocation function?" ... oh ... malloc?

as for presentation - if he attended and LISTENED it was clear. he obviously did not. the slides clearly say that it's a one in 512 chance of a false positive NOT a 512 max limit on objects. how you can convert that into a max 512 object limit beats me, other than if you have an agenda. slides are point form backing a spoken presentation. if you are going to make such claims based on slides, then at LEAST research your claim first by reading the src. he did not. as for the documentation - THIS API IS NOT PUBLIC AND FINAL YET. it's still undergoing minor revisions and to use it you have to enable a #define to use a beta api. otherwise the headers don't define the api. so no - it's not documented clearly. he isn't even using it. he's talking about future APIs. thus the code is in development. do you expect production level documentation at every stage of development of something? that's a waste of time as the code changes, you now add the cost of changing the docs to match. in fact there are some docs there and they are already mismatching the code due to changes in api. so if you're going to decide to evaluate a beta "need to specially access it" api based on some slides... you're standing on pretty weak ground especially if your claim is an outrageous "max # of objects - 512". you make an extraordinary claim - you'd better have extraordinary proof.

as for typedefs he says the evas object types were typedeffed to void. pretty clear about that. they never were. out objects always have been "strongly typed" (ie typed to definitive incomplete structs) ever since we released - he is using tizen 2.x and that has used efl 1.7. see that commit? 2003. that was about the same time that i actually wrote (or rewrite) the current evas code. efl 1.0 was released in 2010. how about someone accuse you of your code being "crap" because 5 years ago you had some structures public that should have been hidden? or you changed a typedef during early development phases before a release was ever made? sorry - he's complaining of the code he had that tizen forked back in 2012. not 2003. any actual releases of evas had this property typedeffed. it's like saying "linux sucks because back in 2003 it didn't have ipv6 support" or something (just as illustration not as actual statement of fact here). or like saying "your code sucks because you used a build script not a makefile 10 years ago in an early version of the src tree".

now as for the callbacks - yes, the first is a generic void *data because the code setting up the callback can have it point to anything and be passed into the callback as context. there is no sensible way to type this other than to force people to now go create context objects too and add a lot of overhead. same for the event_info - this entirely depends on event type. we'd have to have a typedef for every single possible event type and a different function to register every single callback. that'd be 1000's of functions just there. that's insanity. and it is not what the OP claimed. he claimed the Evas_Objects themselves are typedefed to void. they are not. have not been in any release of efl and certainly not in any code he would have worked with as he was on tizen and that used efl 1.7. as for a generic struct - it is a specific struct type. it must be that type. it can't be a char * or a struct tm * or a struct stat * or an int etc. - it has type safety. maybe it is a broader type in that an Evas_Object is any visible canvas object, but it's not a void. he's still totally wrong.

your research is not that great as a 2003 commit does not equal the 2012 code (which is post that commit and is probably in the first few weeks/months of me writing evas it its current form). he complained that he suffered from that problem - you clearly proved he did not as there is a 10 year gap between that commit and the 1.7 efl code in tizen he's using. thus you proved him wrong.

as for "poor api with bad docs" - how did you prove this at all? i clearly pointed at the docs on getting started which were ignored, thus leading to the problems. how have you countered this in any real way?

as for the logs - i said already that the bitch was an oversight and was changed. if he reported it properly it'd have been easy to find and fix. the rest i don't see as harassing at all. how is saying "naughty" and "spank" harassing? unprofessional? depends - if you mean "lack of sense of humor == professional" then sure. tbh there seems to be a fair bit of positive feedback on that too. people have made t-shirts with that message on it. and yes - wear them in public. we'll agree to disagree. but almost everything else which is the vast majority of his post, is wrong factually or a personal attack, or in the "naughty" case, a matter of taste/humor. there were more "wrongs" i didn't list here, like unable to find the error - set EINA_LOG_ABORT to 1 and use gdb + bt. presto.

yes - i made it personal because that is exactly how he communicates, as i made perfectly clear at the very start. i did not suddenly go quiet - i made my points (and acceded to the bitch thing), discovered that not a single one i refuted was supported by proof on the other side, just more spin of the same story, so i said it clearly that it's a waste of time.

Reply Score: 2

RE[4]: Re:
by somebody_close on Thu 14th May 2015 06:42 UTC in reply to "RE[3]: Re:"
somebody_close Member since:
2015-05-13

indeed i started off personally because my very first line... i said i'd respond in kind as the OP. he made it personal and adhominem almost of the bat. i was very clear about that. he obviously likes to speak this way, so use a language he understands.


As TDWTF is a well known humor site and the OP was humorous, that single line you use as an excuse (RT) was a joke. A joke based on your "naughty" jokes, which you claim are ok (they're not in a software package). The very first personal attacks stem from your response. That also proves the point of it all - "naughty" jokes are a gray area. You can use them in casual conversations or humor posts, but absolutely never in software development. Calling people "bitches" is not funny - it is an insult. "Spanking" people in logs can be treated as a joke, but it's still unprofessional in software. And now you're trying to justify your inappropriate behavior and personal attacks with one such joke in the OP. That's highly hypocritical, and frankly, a bad excuse. What you should do now is say "sorry, I stepped over the line" and continue with real arguments. Instead you're constantly justifying yourself and, even here, you're making additional personal attacks, which I pointed out earlier. That behavior should not be tolerated, so drop it.

as for slang - it's an open source project. most of it has been written in spare time. it just so happens the project is useful to companies and solves real problems. the linux kernel is full of swearing and slang in the src code. what's new?


That's another example of making excuses - "other's are doing it, so it's ok" and "it's open source, so it's ok". Neither of it is valid. If you want to be treated as a professional, behave like a professional and write good software. Don't write something you will be ashamed of, and you should be ashamed of those lines. Don't justify - fix it and forget about it. Don't write essays with bad excuses. Hell, your logs have become a meme on TDWTF, they're so bad.

as such - i am not in the US. my point is that people only seem to see the world from their point of view. i have lived in the US before. the vast majority of people there think the world should conform to their standards and views. anything else is wrong


You're saying that people not from US are free to insult other people and claim "cultural differences" as an excuse? That's absurd (and another lame excuse).

and the op was not joking about redtube. take the post as a whole - none of it was lighthearted or joking. it was a direct slander. look at the broader context. if it had a smiley or language that indicates it was lighthearted, that'd be otherwise.


As pretty much everything on TDWTF - it was written in a humorous tone (although with real arguments underneath), which everyone got, except you. The reason is simple - somebody criticized your work and you became defensive. That's quite common, unfortunately. Maybe your "cultural differences" prohibit you from accepting humor directed at you and the only valid jokes are the ones you make. No, it doesn't work that way and 500 comments there prove you wrong. You're trying to spin things around and derail the issue to form instead of content. Not going to happen.

as for api obviousness - he complained directly it was not documented. that is wrong. and the api is right there in the elm_win documentation for making a window.


Really? https://docs.enlightenment.org/stable/elementary/group__Win.html - no info about it anywhere, no examples anywhere. Let's look at adding a window: https://docs.enlightenment.org/stable/elementary/group__Win.html#gad... - still no info and no example. You have to know a priori what to look for to actually find what you're talking about. For you it's simple, since you already know that as the author. But a programmer looking at the API docs, doesn't know that and doesn't see that. He doesn't know, he should look instead for some util* function. The docs are bad in this regard.

as for presentation - if he attended and LISTENED it was clear. he obviously did not.


So what's the point of releasing a presentation, if you already know it's so misleading, you need to inspect the code or be there in person to actually understand what is being talked about? Make clearer presentations and those problems will be gone.

as for typedefs he says the evas object types were typedeffed to void. pretty clear about that. they never were.


I already gave a link to a commit which changes them from void to some generic struct, so don't lie they were never void. People on TDWTF already pointed you shouldn't lie about open source projects, since everyone can verify it. Also, changing from void to struct isn't enforcing type safety - you still have one generic type for everything, meaning you still don't what what it REALLY represents and what can be done with it. You need to have SEPARATE types for separate entities to enforce type safety, as in OO paradigm. Saying "I substituted X, which meant everything, to Y, which means everything" is enforcing type safety is absurd. And that is the point in the OP - no type safety at all. Furthermore, all callbacks etc. pass data as void *, as far as I can see, and de-const them, as in the OP. That's crashes waiting to happen.

we'd have to have a typedef for every single possible event type and a different function to register every single callback. that'd be 1000's of functions just there. that's insanity.


Other libraries use that approach and it's not insane. Qt has 31 subclasses of QEvent, which some have few subclasses further down. That's hardly "1000's" and you can do anything you want in Qt, and have type safety with it. Your argument is moot.
Same goes for other libs (in Java, C#...) - you just write a listener for given event and receive a proper event class as an argument. You chose the lazy way of erasing all types.

as for "poor api with bad docs" - how did you prove this at all? i clearly pointed at the docs on getting started which were ignored, thus leading to the problems. how have you countered this in any real way?


By showing you need to know upfront where to look and what to look for. As a programmer I found a function and looked it up and DIDN'T find what you're talking about. Same situation as in the OP.

as for the logs - i said already that the bitch was an oversight and was changed. if he reported it properly it'd have been easy to find and fix. the rest i don't see as harassing at all. how is saying "naughty" and "spank" harassing?


"Bitch" is harassing, other are simply unprofessional. I can ask you the same thing - how is making a joke about RT after reading such logs, harassing? Read between the lines and understand not all people appreciate your humor, as you don't appreciate the RT joke. But you are the one making a library for people to use, not making a humor post on a humor site.

yes - i made it personal because that is exactly how he communicates, as i made perfectly clear at the very start.


No, that is exactly how you CHOSE to communicate. Nobody attacked you personally and my previous arguments about your logs show what the issue here is.

i did not suddenly go quiet - i made my points (and acceded to the bitch thing), discovered that not a single one i refuted was supported by proof on the other side, just more spin of the same story, so i said it clearly that it's a waste of time.


From what I can see there, all your arguments were refuted, except the 512 one, which was clearly a misunderstanding of a presentation. There were refuted by multiple users there, and I also refuted them here and now.

Reply Score: 0

RE[5]: Re:
by raster on Thu 14th May 2015 10:32 UTC in reply to "RE[4]: Re:"
raster Member since:
2005-07-07

1. the OP was not humorous - it was far from that. he slandered his company as being totally incompetent. he made racist remarks about koreans and much more. sorry - but it was not humor in the slightest. it was a total dig with piles of missing fact and lack of even reading basic docs. the whole post was "all these things are bad and they have no idea what they are doing and i know better and they are so incompetent they can't even return a non-zero exit code from a compile etc.". that's not humor. that's outright slander. the post is so full of falsities it's almost entirely a work of fiction. but sure. pass it off as humor to excuse that. if it makes you feel better.

2. as for slang - i was EXPLAINING why it's there. not that it is meant to say "you are a bitch". didn't i say often enough "granted - it can be interpreted other ways and thus is now fixed" etc. but you fail to acknowledge that it was not INTENDED as an insult but it's a common turn of phrase, and that different cultures can interpret things differently. can this or can this not be the case? do you accept that it was not intended as it was interpreted? that is the point.

3. as for docs about win:

https://docs.enlightenment.org/stable/elementary/

the VERY first link "getting started":

https://docs.enlightenment.org/stable/elementary/

example right there with description. getting started. seemingly that document was never read. and here is the REFERENCE api for the func above that adds a window with a bg:

https://docs.enlightenment.org/stable/elementary/group__Win.html#gac...

all there. examples. the VERY FIRST THING in the documentation for elementary. the first thing you'd expect someone should look at - getting started. especially if they are having problems. UP FRONT the first thing to look at.

4. as for presentation - i don't release it. i present it. the conference organizers decide where/what to post. they should post videos not just ppt's. but that is not under my control.

5. as for the typedef voids - i'm not lying. they look at the date. that was long before any release. it's like saying "OMG! you didn't put out the glasses" when discussing a dinner because somewhere in the preparation stage of the table, glasses had not been put out yet. they never were typedefed to void in any release or anything that shipped - discussing what was done internally prior to that is like discussing transient bugs or typos in code just because it so happens the repository is public. but that doesn't change the fact the OP claimed HIS code HE worked with had them typedefed to void and thus they were stupid and had no type checking and you proved that to be wrong, as did i. and at no point would the OP even admit he was wrong nor provide proof of his claim despite me pointing to src to the contrary. of course you will sit here and do the same as the OP and ignore all of this. as we don't have one type for EVERYTHING. it's one type for visual objects, another for a canvas, another for an event, etc. etc. - they may not have the incredibly fine-grained types they want, but it still has type-safety, and is a far cry from the claim of "everything is typedeffed to void" which was in the OP. of course you happily change the topic without admitting this. as for the const/de-consting - it's far from asking for crashes. the const void * on the way IN says " i am not going to modify this during THIS FUNCTION CALL". you can't feasibly keep it const as you force a LOT of casting from const then inside the callbacks. this is something you end up having to do in C with generic callbacks and data ptrs. the only other sane solution is to not use const when adding the callback, thus de-consting then anyway (pthread_create de-consts at this point for example, so does gtk/glib - still de-consting), but losing information on what the callback_add func does (doesn't modify what is pointed to).

6. we have at least about 280 different event types across efl. that's not 31. not even close. think about it a bit in terms of maintenance of an extra 500+ function there (for add and then also for del). not to mention now all the extra entry points that now need testing. that's why it uses void *. gtk has done this ever since as well with the callback_data - it's necessary for sanity.

7. as for the arguments - the typedef void never was. the edje_cc return never was. the docs one (that it is documented first thing) never was, i can go on. i gave up. and you seem to be one of the same kind of people who happily ignore what they don't want to read can can't say "oh - i was wrong on that". i admitted fault on the bitch point - the rest - bzzt. but hey. despite pointing directly at the getting started docs above - the first first link, you'll ignore that and keep spinning, along with all the rest (you didn't check the tizen efl src he was complaining about with typedefs to void for objects - he was very clear on that, but hey - that won't change anything with you). so yet again... just like the dailywtf trolls. in fact it appears you joined osnews JUST to post on this article! funny that!

Reply Score: 2

RE[6]: Re:
by somebody_close on Thu 14th May 2015 12:42 UTC in reply to "RE[5]: Re:"
somebody_close Member since:
2015-05-13

the OP was not humorous - it was far from that. he slandered his company as being totally incompetent


That's your opinion. Other users found the story so good, it has become THE most liked story in the history of TDWTF. You don't like it, because it describes your product, that's all. You thought you were humorous by calling people "bitches". Guess what - you weren't.

the post is so full of falsities it's almost entirely a work of fiction.


As the comments there and my comments here show, the OP is right. You can continue to repeat "it's all lies", but the links shown there and here, prove you wrong. Ironically, you are the one suggesting taking a look at the code/docs.

as for slang - i was EXPLAINING why it's there.


Your explanations won't matter one bit when someone takes that to a court (and with right). You think it's fun? It's not. On the other hand, people found the OP to be the most liked story ever published there (can by verified by anyone, as the data is public), and you alone find it offensive. In fact, you are literally the only one offended, which can be checked by reading all the comments. Also, nobody took your side, but your coworker in the beginning. This is a clear indication where the truth lies.

but you fail to acknowledge that it was not INTENDED as an insult


The RT also wasn't an insult, but you constantly try to spin it like that. Not going to happen - it's just a try to derail the topic, but it won't work. Every time you try to spin it, I will be there to remind you it won't work. Discussions should be based on facts, while you just try to divert attention from them. You should really go there and apologize everyone for your behavior.

as for docs about win:

https://docs.enlightenment.org/stable/elementary/

the VERY first link "getting started":

https://docs.enlightenment.org/stable/elementary/

example right there with description. getting started. seemingly that document was never read. and here is the REFERENCE api for the func above that adds a window with a bg:

https://docs.enlightenment.org/stable/elementary/group__Win.html#gac.....

all there. examples. the VERY FIRST THING in the documentation for elementary. the first thing you'd expect someone should look at - getting started. especially if they are having problems. UP FRONT the first thing to look at.


Now take a look at the links you pasted and the links I have. As a programmer, I searched for docs about a function adding a window and came nowhere near the things you link. On the other hand, you already know what to look for and you keep saying "it's all there". It doesn't matter if it's there, if it's unreachable. A programmer won't know to look in a totally different place, when reading about a function, which he's interested in (especially if the other function is named so badly, there's no hint what is does exactly). When I search for X, I don't write Y in the search bar. That is the point.
AS Qt is being used as a counter example, read their docs. Every class has a wall of text with description, examples and references. Every function is well described, to the point of saying how thread safety is implemented. How about EFL docs? Which functions are thread safe? Which are reentrant? No information on that. But I guess there's one page somewhere which has some details about this issue, but since it's also unreachable, finding it will be next to impossible, unless you already know where to look.

as for presentation - i don't release it. i present it. the conference organizers decide where/what to post. they should post videos not just ppt's. but that is not under my control.


If there was a possibility of it getting public, you should have anticipated different people with different knowledge about EFL will read it. That's why it should be either extremely specific, hinting it's only for those already invested, or broad enough, so there's no room for misinterpretation about the details. Don't give numbers when nobody will understand them without also listening or inspecting the code, as you suggested yourself.

as for the typedef voids - i'm not lying. they look at the date.


You said they were never there, while also saying "look at when they stopped being there". That doesn't inspire confidence in your words. Going further - for what I've seen all callbacks still take void *. Data structures still have a lot of fields being simply void * without explanation what it is, AND Evas_object is still a generic type for everything defeating type safety.

they may not have the incredibly fine-grained types they want, but it still has type-safety


If they don't have types representing what they really are - there is no type safety. None. I can use Evas_object of type X with a function expecting Y and it will compile, thus no type safety. The effect will be an error or a crash during runtime. Crashing in runtime is not type safety - it's the exact opposite. Type safe means the compiler won't let me do it in the first place.

the const void * on the way IN says " i am not going to modify this during THIS FUNCTION CALL". you can't feasibly keep it const as you force a LOT of casting from const then inside the callbacks. this is something you end up having to do in C with generic callbacks and data ptrs.


Wrong - because you don't know where that ptr is passed and what is it's lifetime (for example in callbacks), you can't restrain constness to a function call. You either pass it as const and treat is as const everywhere, everytime, or pass it as non-const. Removing const can lead you to memory corruption, example being passing data from read-only memory (literals being the textbook example, also mentioned there). Also, const in the modern world means "safe to be used in multiple threads". Const variables can be read in parallel and nothing wrong will happen. (Properly written) const function is safe to be called from many threads and nothing wrong will happen. In case of EFL, you can't know if that const whatever is safe to be read, because it could be de-const'd somewhere and someone might write to it. That's the problem your API introduces. A problem which was not there in the beginning.

we have at least about 280 different event types across efl. that's not 31. not even close. think about it a bit in terms of maintenance of an extra 500+ function there (for add and then also for del). not to mention now all the extra entry points that now need testing. that's why it uses void *. gtk has done this ever since as well with the callback_data - it's necessary for sanity.


So it all comes down to you being too lazy to do it properly. Having type safe callbacks is a standard everywhere, except EFL and GTK. Saying "but this one other guy does it this way" is not an excuse. If others could do it so it works, so could you. Now we have perfectly type safe C++, C# and Java gui libraries and you don't.

7...


Given how people on TDWTF pointed out flaws in your arguments and given how I manage to do it here, it seems you are the one trying to spin this around. You can either improve, what was said to be bad, or you try pretend everyone is wrong but you - your choice. Quick research shown, that EFL is pretty much non-existent in the professional world, despite it's age. That is a clear indication, who is right in this dispute. If it really was so good, as you try to spin it, it would have at least gained some traction.

Reply Score: 1

RE[7]: Re:
by cybergorf on Thu 14th May 2015 15:28 UTC in reply to "RE[6]: Re:"
cybergorf Member since:
2008-06-30

[
That's your opinion. Other users found the story so good, it has become THE most liked story in the history of TDWTF. You don't like it, because it describes your product, that's all. You thought you were humorous by calling people "bitches". Guess what - you weren't.


It is only the SECOND most liked story at TDWTF !
Be careful, when you accuse others of spinning things around...

Reply Score: 2

nej_simon
Member since:
2011-02-11
@ Raster: Better documentation
by cybergorf on Thu 14th May 2015 17:38 UTC
cybergorf
Member since:
2008-06-30

Hi Raster,

Can we agree, that something needs to be done for a better documentation an a lot more comprehensive tutorials?

Reply Score: 1

raster Member since:
2005-07-07

Hi Raster,

Can we agree, that something needs to be done for a better documentation an a lot more comprehensive tutorials?


I don't disagree that more tutorials and docs would be great and are always needed. What I do take exception to is people claiming there are precisely no docs or are so bad that they struggled with even the most basic things when THOSE are clearly documented in the getting started guide, and that was not read or followed, thus leading to the trouble.

Along with a whole bunch of other "bleh - they can't even return an error code from a compiler" when that is totally bunk. I don't know how clearer i could have been there that it does return error codes, the code is littered with "exit(-1)" functions on error, so making such extraordinary claims and simply repeating them again and again with no proof, the typedeffing to void etc. just makes the whole post nothing more than a huge trollfest that involves dragging other peoples names and work through the dirty based on fiction.

Reply Score: 2

C, thoughts thereon
by Gullible Jones on Thu 14th May 2015 17:42 UTC
Gullible Jones
Member since:
2006-05-23

As far as C, NB: I am not an experienced C programmer. And I know only the vaguest stuff about GUI programming. But based on what I do know of C, and what I have done with it, I have the following opinions:

1. For some jobs, there is just no substitute for C, flawed though it may be.

2. This does not mean that C should be used for everything.

3. Cleverness in most programming languages is bad. In C, it's lethal.

And elaborating on (3), the programming style espoused in the K&R text is stupid to use in this day and age. Don't get me wrong, the White Bible is an excellent book (and one of the few programming texts that I would actually call such). But the programming style is obsolete and dumb, because it is clever. It is premature optimization incarnate, and you know what they say about premature optimization.

...

But please take the above with several grains of salt. I mean, I didn't even know that typedef could be used with function pointers that way until I looked it up on Wikipedia.

Edited 2015-05-14 17:43 UTC

Reply Score: 3