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.
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.
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 ?
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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).
Not to mention the problems of manual refcounting in a threaded application. Smart pointers take care of refcounting in a threadsafe way.
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.
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.
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…
This would not be Emmanuele Bassi posting, would it?
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?
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
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
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
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.
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.
Not sure about what you precisely mean with this, but you are looking a lot like the guy I described just above… 🙁
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.
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
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.
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
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.
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
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.
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).
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
“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
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
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.
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.
And neither is “C++ is a horrible language” while “C is a horrible language” is ?
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.
We agree to disagree. Some poeple like to settle in the border between CPU (asm) and abstract wonderland (C++ and so on). C GUI-toolkit devs and users are among them. It’s just personal preference. We like to keep in touch with dear hardware.
Edited 2015-05-15 12:42 UTC
The article writer didn’t say the C was a bad language in general either. You have trouble reading. Learn to read.
Wow man, you just add a “in general” and my “claim” magically becomes false ? Neat. Here’s what he wrote: “Those knowledgeable in the horrible language of C know it’s a pointer to anything”. Neat.
On a side note, that site stole my CTRL+F keycombo for own purpose. Neat++.
Edited 2015-05-15 18:15 UTC
Yes. Do you understand the difference between a claim about something in general and a claim about a very specific thing, you fucking idiot? I made a claim about GUI widget toolkits. I did not talk about other programming contexts. So you trying to twist my words into saying that C is a terrible language for absolutely everything DOES magically become false. Learn to read, and learn basic logic.
Also, one line does not an argument make. It was a line written in passing. It does not then turn his entire article into meaning C is a horrible language for everything.
I have to cleanly “fork away” from the quotation tree, since you lack any capability to stop creating mess.
Sorry man, that’s exactly what it was. If he had written “..those in agreement with the insanity of C regarding GUI toolkits..” or somehting similar (referencing the actual context), I would still disagree, but I would understand and respect his opinion. But that’s not what he wrote at all. He plain and simple wrote that C is a horrible language. See, YOU are the one trying to TWIST HIS words to benefit your own arguments.
Edited 2015-05-16 10:39 UTC
No, I call you a fucking idiot after too many times you twist words I say. Considering the rest of your comment consists of nothing but twisted versions of my words, I don’t have any more time to untwist them.
I call http://rationalwiki.org/wiki/Gish_Gallop on your bullshit.
I even hacked OSNews to twist your words in-place !
Edited 2015-05-16 11:37 UTC
To which I responded with “bad taste”.
Do you understand English, you illiterate cunt?
I was calling your preference to macros OVER overloaded operators bad taste.
Do you see how there’s ABSOLUTELY NO IMPLICATION that one must use operator overloading exclusively?
This is proof you twisted my words.
The context of my paragraph was function-like approaches (functions/templates) vs overloaded operators. I also added macros to intesify my personal dislike for overloaded operators.
When you quote the whole paragraph and reply without narrowing the context (to macros) then I have no choice but to interpret the context as “function-like approach vs overloaded operators”.
Edit: You mention macros in another paragraph, I can see now. But your mess created mess. You should have reposted your mess cleanly as I asked you to.
Edited 2015-05-17 11:48 UTC
I did narrow the context to macro. You yourself just admitted I said macros in another paragraph. Not just any paragraph, but precisely the one after the “bad taste” one. It was a continuation of the reply to the same quote, therefore, narrowing.
Edited 2015-05-17 12:09 UTC
It’s far easier to read C casts and macros than your crappy mess. Learn to edit properly. If not able, then learn to repost cleanly. I’m not responsible for your mistakes, only for mine.
Which is why I didn’t want to reply to your mess, and asked you to fix it (repost). I learned from my mistake: not to mess with mess.
Edited 2015-05-17 12:24 UTC
You were completely free to not reply. Yet you chose to. So you only have yourself to blame for not reading properly.
Edited 2015-05-17 12:24 UTC
I wrote that if you fixed your mess, I “might” reply. You wrote in your former post that you didn’t bother to fix it becasue you didn’t think I would reply. But I had already asked you to fix it because I wanted to reply. I even made that clear in this very paragraph. Twist and turn all you like.
Edited 2015-05-17 12:44 UTC
If you wanted to reply, and was going to any way, then why demand that I repost at all? Why should I do anything for you just because you say so?
Edited 2015-05-17 12:52 UTC
Really ? explain what straightforward comment I had trouble reading before that one ? Put up or shut up, troll.
Edited 2015-05-17 13:03 UTC
And you’re a c*nt who twists people’s words because you have no actual argument. c*nt.
This was your reply to me before the messy one.
Whoever said operators need to be abused? See? You make shit up right from the get-go.
Edited 2015-05-17 13:11 UTC
Hahahahahahahahaha ! You’re an amazing troll.
It’s my opinion that it’s abuse (even though I don’t have MAJOR PROBLEMS with mathematcial operator overloading, I certainly dislike them). I wrote my opinion. Just like you wrote your damn opinion. I didn’t claim you stated that operators MUST BE ABUSED until police arrives. It’s your head that is troubled, not mine.
Edited 2015-05-17 13:25 UTC
You implied it. In very much the same way you accuse me of implying things that I didn’t based on your attempt to twist people’s words.
“things” is like x, y, z, and all the rest. “things” will not help you.
Edited 2015-05-17 13:45 UTC
It’s called a reference. It’s pretty simple. Just go back to all the comments that you accuse me of “implying” something I did not say.
The bit I quoted off you would be considered “implying” by you if I wrote it in that same manner. Or maybe you apply your rules differently to other people than to yourself. Which is to be expected of someone like you.
Or maybe you think I hacked OSNews and twisted your words in-place.
Edited 2015-05-17 14:00 UTC
No, I think you refused to fix your very messy post.
Edited 2015-05-17 16:01 UTC
So, due to your perception of my trolling you, you decided to troll back. Seems like in all of this, the person actually with the intent to troll was you.
Using your logic, it’s your fault you got “trolled”. You “trolled” yourself by imagining some grand scheme on my part. You may be schizophrenic, thinking every slightest thing may be an attempt to troll you.
My “continuous insults” aside, numerous times I’ve told you that you were twisting my words, but you never bothered to double check. And now that you got exposed like a chump you’re grasping at straws to try to pass of your failure.
Get help. We don’t want you turning into another Elliot Rodger.
Edited 2015-05-17 16:39 UTC
It’s not only my fault that I misread. I asked you to fix, and you refused. I call that trolling. It’s simple, either don’t post mess, or when you do and refuse to fix, then prepare for further mess.
Edited 2015-05-17 16:45 UTC
It’s simple. Don’t be a c*nt. Don’t be an Elliot Rodger.
Edited 2015-05-17 16:45 UTC
See, you’re a troll.
I don’t think you understand what a troll is. A troll is someone whose only goal is to try to get a rise out of someone but they don’t believe in what they say.
I truly believe you are a c*nt, and I don’t say that to get a rise out of you.
You, however, admit you are trolling, based on your misperceptions that you never bother to question.
Edited 2015-05-17 16:49 UTC
You have described yourself prefectly. Thank you. And hey, in addition to learning how to post/edit/quote, also learn to watch your tongue. The chance is that you’ll do a big mistake if you use that thing IRL.
Luckily, IRL, I am not surrounded by f–king idiots who blame others for their own carelessness. So I don’t have the urge to call them c*nts.
Also, learn to not get “carried away”. IRL, learn to not demand absolute perfection. Because you will make a mistake and people will hound you for it and you will have deserved it.
Edited 2015-05-17 16:58 UTC
Of course not, since they’re surrounded by the likes of you. Take my advice and learn to post/edit/quote properly. That’s what you need to do. Learn.
Edited 2015-05-17 16:58 UTC
If you want my comeback, you’ll have to scrape it off your mother’s teeth.
Quoted you for the purpose of evidence. I’m sure your post history is still accessible to admins anyway, should you modify.
Edited 2015-05-17 17:03 UTC
Aww poor baby can’t handle getting his arse whooped. Not even your “I know you are but what am I” defence that your mommy and daddy taught you worked. Poor baby.
Sounds like I whooped _your_ ass. The only things you have are insults. IRL against me, the only thing you’d have would be broken body. Any plans to visit sweden ? I would love to mistreat you, little fellow
Edited 2015-05-17 17:17 UTC
I think I whooped your arse, because you’re stooping to threats of physical violence. Wouldn’t have expected any better from someone like you who can’t read carefully or use logic.
Edited 2015-05-17 23:19 UTC
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.
That comment of yours is mess, if you fix it I might respond.
You didn’t fix that messy message, so I had to decode it myself.
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
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
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.
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.
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…
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.
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.
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.
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.
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!
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.
It is only the SECOND most liked story at TDWTF !
Be careful, when you accuse others of spinning things around…
To be pedantic, just in case: the first one was a ironic topic about likes, designed to gain likes. I wouldn’t count that as real topic with an IT perversion story.
Now you are wrong again!
Under “Side bar WTF” the top liked artikel is about car traffic. Enlightend is second.
In total of all articles enlightend is only at place 8. With only 2.2K likes compared to 1.1M likes for the top article!
Youself told us this would be easy to proof, because it is in the internet. So why don’t you have a look by yourself, instead of stating untrue things?
Edited 2015-05-14 16:49 UTC
Ahh, you’re talking about total topic likes? You should look at first-post likes: http://what.thedailywtf.com/badges/20/great-topic
Total likes include likes for individual comments, in addition to topic itself.
Now you do the exact same thing, you did not like in Rasters replay:
‘ It’s all there, you just have to look in the right place. And when I said no 1, I meant no 2, but it should be no 1, because bla bla… ‘
True that – I should have been more obvious. Yet I wish to point a certain thing. We were talking about a counting system on a forum, while in case of EFL, the issue was with the official documentation of a software library. Software is much more demanding in terms of good specification. You can casually say “look at the number of likes on that topic” and just clear things out later, if the need arises. But when you are about to use a product, potentially for commercial applications, you should have all the documentation already available and clear enough to use the software. When you want to use a function X, but the “real” documentation of usage in not at the docs for X, but at the docs for Y, things get unpleasant. Time gets wasted, software gets made with potential errors. I think you are comparing two different worlds here. But it’s good that you noticed the problem. Raster still claims the problem doesn’t exist and attack his opponents (currently me).
Note to Raster – take a look at how I responded to this misunderstanding. Notice how I avoided being offensive; notice how I avoided any personal attacks and arrogance. I cleared things up in a quick and calm way. That’s how you should behave – professional. Calmly admit mistakes and correct them, so the world gets a bit better for everyone. Don’t go all out raging like you did there and like you do here.
Thanks for your replay.
Yes, you are right and missunderstandings can not always be avoided. It is the aftermatch that counts.
Enlightenment and EFL was (other than Qt) not backed by any company until resently by samsung. It had no means of providing professional support. It is open source and most core parts are BSD licened, so we don’t even know who else uses it.
It was literally some code you could take or leave.
Quite a lot of people used E16, before complete desktop environments become “in”, it was the first wm in the gnome project und its sound deamon esd was part of gnome for a very long time.
Qml is inspired by Embryo..
And I am sure a lot of the fast pixel conversion routines of E can be found in many other projects or games.
So Enlightenment is beeing widely used, but mostly as spare parts store and not as a whole framework.
With Samsung picking up EFL as basis for Tizen, they are the ones changing the rules. Now some people are “forced” to use it. So things like better documentation and more tuorials become necessary and it is Samsung that needs to hire smart people providing that.
Edited 2015-05-14 18:36 UTC
Better docs will surely benefit everyone involved. I would add to that a change of attitude from the author.
As for the libraries – the more I look at the docs, the more it looks like an awful mess. Personally, I would never touch it for any of my projects. I also agree with previous comments that C is not a language programmers should use in 2015. It’s so error-prone, I don’t see how a reliable software can be made with it. Manual memory management? Please, that’s asking for trouble. Erasing types everywhere? More trouble. But removing const as EFL seems to do – it’s a recipe for disaster. Have fun debugging those undefined behaviors.
But everyone is free to make their own choices and mistakes. Just be prepared for the consequences.
Well, there is lua-scripting for EFL. With Eolian bindings to many more languages are under way (some already working). It’s not in the stable branch yet.
But to be clear: E always was a project from C programmers for other C programmers. Originating in a time, when everything on linux, bsd or X11 was in C.
2015 … why should someone use something other than Swift? 😉
(Besides the obvious reasons…)
Edited 2015-05-14 19:50 UTC
On “liking” something in the internet:
I did “like” the article here on Osnews, but not because Thoms two words were so well written or because I agree with the original post. I did like it because i wanted to draw attention to the matter.
So the “likes” on TDWTF don’t say much about agreeing or disagreeing with certain points.
The comments do, but most of them are written by people, that never tried to use EFL, or (like here on osnews) dislike C in general – maybe for good reasons, but of topic anyway.
Its a little bit like judging a bike to be unstable and it should better have 4 wheels. Which is completely true by the way 😉
Edited 2015-05-14 20:33 UTC
the linux kernel does manual memory management. someone it works. xorg server? same. libc? same. 1000’s of projects do this and are not disasters. i think the difference is they are more disciplined programmers who pay attention to what they are doing.
So listing projects where it works is an argument for manual memory management? Really? It’s like saying “soldiers successfully throw grenades, so it perfectly safe”. No, it’s not. Take a look a recent security vulnerabilities. How many of them are related to memory corruption? Use after free, buffer overflow, etc. These are all related to the tool no providing the means to do it properly.
That’s the problem – you have to spend more resources to carefully manage everything manually. As people always make mistakes, that is a guarantee of errors. The question is – why would anyone want to do it manually, when modern tools do it automatically? I can’t imagine a memory related bug in modern C++. I don’t even count GC languages, as the point there is obvious. In C you have no automation anywhere. When you see a pointer, let’s say “Foo *foo”, what can you say about it? Is it a valid pointer, or was it freed? Are you the owner of the memory or someone else? Or maybe it’s a shared ownership? What about threading?
In C++ when you see a std::unique_ptr or std::shared_ptr, you know what is means. You know how to check for validity. You know it will be freed when it needs to be, not a moment too early or late. You know it will support sharing between threads on its own. And you simply don’t care about the memory, because you know the tool you use will do everything automatically and it will always work.
When you use a std::string, you will never get a buffer overflow, since it will grow, if needed. You can do all you want on it and you don’t need to strlen() everything, as stated previously. You are free to implement your business logic and not worry about secondary stuff, as it is done for you. The lifetime of every object is well defined, the ownership of memory is well defined, while in C you don’t have any of these.
You literally said “I don’t see how reliable software can be made with it”. I pointed out counter examples. It is possible. has been done. Unless you wish to claim glibc is unreliable. The Linux kernel is unreliable (despite large chunks of the worlds financial infra depending on it, some of the biggest scientific and commercial concerns basing their entire infrastructure on it etc. – if you disagree, then there are a lot of people who would beg to differ and are “betting the bank” on the fact they are right). In fact most of the core of a Linux system is raw pure C. From kernel through to libc, apache, xorg, etc. And yet you don’t see how reliable software could be made with C? You are neither objective, nor perceptive in even seeing the world that exists as I pointed out, as you are ignoring all of these major counter-examples to your point. You seem to have blinkers on with “only C++ can make reliable software and using C is impossible” despite the wealth of counter-examples.
As someone who does a lot of C, it doesn’t take much effort at all to keep manual memory management in mind. It’s like walking. you don’t THINK of how to move every muscle and put one foot in front of the other. You just “move” to where you want to go. The rest is instinct. I spend the vast majority of my time thinking of “business logic”. At the back of my mind something keeps track of who owns what, where in memory it may be,might it be on the same cacheline or not, likely in l1 cache or not, how many indirect lookups it may take etc. – but it’s a tiny bit of thought vs the actual business logic.
One of these days, you should perhaps learn about tools like coverity, that ACTUALLY can tell you all those “use after free” things you claim are not possible to know in C. Clang/llvm will do it for you too for free with reports. These tools also can tell you much more. You claim you can’t know. I claim you can, and I actually do know this all the time via coverity, valgrind etc. etc. I’m regularly using tools that give me such information you that you claim you just don’t have in C? I beg to differ – static analysis and runtime tools do know this and tell me.
As I said. I just think it’s a matter of being disciplined. You use tools, are experienced and keep things in mind. It doesn’t have to take over your brain activity just like walking doesn’t tax your brain whilst you do it.
Yes, it is. But it’s a waste of resources, when you can have automation do it for you. Also, even the most disciplined people make mistakes, so you need to use external tool to actually verify everything works fine and even that fails sometimes, especially for large projects.
In the end, I would really say that you both have your points. It (almost) all boils down to personal mindset and programming style – even if for certain aspects one toolset is designed to behave more comfortably to the average developer, he/she might be much more accustomed to / productive with a more rudimentary and lower-level toolset.
Perhaps you might want to give a more concrete and directly-comparable proof of your points about C++ by trying your hand at writing some bindings for EFL… 😛
I’ll agree with you, up to a certain point. A developer will be more efficient with languages and tools they are intimately familiar with. But not all languages and tools are created equal. And a programmer working at maximum efficiency with their language of choice can still be far less effective than a programmer working at moderate efficiency with a superior language.
Over the years I’ve created libraries, tools, applications with several different languages and libraries, for example in approximate chronological order of first use:
– C89 + libc
– C99 + libc + glib [ + gtk ]
– perl5
– C++98 + libstdc++
– C++98 + glibmm [ + gtkmm ]
– python2
– python2 + pygtk
– C++11 + libstdc++/libc++ + Boost [ + Qt5 ]
– java
– python3 [ + PyQt ]
I’ve written and contributed to simple low-level stuff in C to higher-level stuff in C++ and python over an 18 year period. I started with ISO C and worked my way up through Perl, C++, Python and then C++11/14 and Python3 (omitting a bunch of other languages not so relevant here). While I would hesitate to call myself an expert, I do have in depth experience and skill in all these languages. I’d have to say after using them all, I really do hate to do much in C nowadays, it’s just so rudimentary and limiting after seeing and experiencing how much better things are elsewhere, but most of all simply too time-inefficient. What are the concrete rational reasons to continuing to use it in 2015? Die-hards might be more productive with it right now, but if they are unwilling to look at other languages “Over or dead stinking corpses” ( http://download.tizen.org/misc/media/conference2014/slides/tdc2014-… ) then that does indicate that there might be a little bit of unwillingness to consider other options, even if superior.
The problem I have here isn’t so much C, the language, as it is developers who are so single-minded and fanatical that they push it well past what is reasonable. Or maybe more having been indocrinated to use such horrors back when I still thought it was a good idea and getting a harsh dose of reality! Once you need object orientation and polymorphism, the answer is not to invent (yet another) type and object system in C when every last one of them is awful and inherently unsafe. It is, of course, to use a language which implements such things properly in the first place.
While these practices do have their staunch defenders, these people do tend to ignore some fairly damning realities. The GTK+ developers created a new language, Vala, to wrap the C API by use of a C code generator (in addition to all the other existing wrappers). If this act alone doesn’t highlight how fragile and unusable the C API was in practice, I don’t know what does. And while it has its supporters, I’ve also read horror stories about debugging the generated code. EFL with its .eo files looks just as bad.
The other damning reality is that for paid programmers (e.g. commercial, academic) the bottom line is delivering functional code to specifications, on time. Many were seriously burned by this with C and C++ in the 90s and hence the move to managed languages like Java and C#. No one wants projects to drag on years after the deadline and/or be segfaulting wonders. While you can argue about the languages’ merits and the competence of the programmers using them, the fact is they were appropriate solutions to the problems which plagued C and C++ back then. Now we have C++11/14 with sane memory management built into the core language (rather than TR1 or Boost) there’s some renewed interest in it. Except for specialist stuff like embedded, C is not on the radar for the most part (and even there, it’s declining). For free software and hobbyist projects, these pressures and constraints and the historical background to the projects have meant that C use has declined at a far lower rate. But even here, reality is eventually setting in. Even for a hobbyist, their goal is to work on a project and Get Stuff Done, and doing everything by hand the hard way gets in the way of those goals. That’s the primary reason I reached the tipping point in 2005 where I ported all my current C projects’ code to C++ over the course of a month. And didn’t look back; they all benefitted greatly from the move both in maintainability and code quality. Removing all those GObject type casts exposed latent bugs which GCC had kindly kept hidden for years… Back in 2005-6 when I was doing commerical GTK+ development there were developers from one or two other companies on the lists struggling to use it for real work; I’m unaware of anyone doing that in the last decade–we all got too badly burned by the crappiness of it and the bad attitude of the upstream developers. EFL seems to be on a par in both respects.
You can successfully wrap the C API; GTKmm/GLibmm did a decent job of providing sane RAII and memory management, signals etc. over the C API. (Shame GTK3 was trashed though.) A similar wrapping could possibly work for EFL, though the slides in the presentation above don’t really inspire confidence in the maturity or understanding of the developers.
Just as an aside with respect to efficiency. A few months ago I needed to store a list of objects which needed to be indexed by their insertion order and also ordered by value, and these needed to be kept synchronised, ideally zero duplication of information. And this was needed in a whole set of classes for many different types. After an hour or two of research and half an hour to implement and test, this was the result (minus osnews mangling):
——–
/**
* Multi-index container for efficient ordered insertion and
* deletion of model object references.
*/
template<typename T, template <typename ElementType> class Ptr>
struct indexed_container
{
/// Multi-index container type.
typedef boost::multi_index_container<
Ptr<T>, // value type
boost::multi_index::indexed_by<
boost::multi_index::random_access<>, // insertion order
boost::multi_index::ordered_unique<boost::multi_index::identity< Ptr<T> >, std::owner_less<Ptr<T> > > // sorted order
>
> type;
};
——–
This is a templated container which stores the items with two indexes, both by insertion order and sorted by value. Use is simple: e.g. indexed_container<Foo, std::shared_ptr>::type
Imagine how many hundreds (thousands?) of lines of code an equivalent implementation would take in C, without type safety, and how long it would take to implement and test. And note the memory management is again implicit and reliable, and in fact configurable in the template.
Edited 2015-05-16 23:45 UTC
This isn’t a great argument. There are indeed projects which aren’t “disasters”, but that’s not to say that making them that way didn’t involve significant time and effort, or that this was the most suitable approach. How much time is spent with valgrind and gdb to make them robust (and keep them that way)? What is the burden on the maintainers to achieve this state? Is the burden strictly necessary?
How do you validate that a program doing manual memory management in C is correct? With extreme difficulty. How much time does the programmer have to spend making sure it’s correct? Lots, especially when you have to check the documentation to see how every function behaves, and this is worse when the docs are incorrect, misleading or missing entirely and you have to dig into the source. How easy is it for a bug to be introduced inadvertently, particularly by outside contributors or other team members, not least of which yourself when you forget your own cleverness? Very easy.
In comparison if I use std::unique_ptr and/or std::shared_ptr, the burden is moved from the programmer onto the compiler. If it fails to compile, it’s incorrect and if it compiles it’s almost certainly correct unless I took deliberate action to break it. And checking with valgrind shows that it is indeed working correctly. I’ve not had a memory leak in my C++ code in the last decade as a result of this simple discipline (and RAII). Rather than wasting many man hours proving my “eliteness” by doing it the hard way in C against all common sense, I’ve solved the problem, and moved on to the higher-level interesting problems that are the meat of my application or library. Why would I want to continually bang my head against the wall solving and re-solving what are fundamentally quite boring and mundane details? My time is limited, so why waste it on trivia?
When I was programming heavily with GObject and GTK+ in C, I estimated that I was spending well over 50% of my time dealing with GObject boilerplate, refcounting and closure madness, and bugs silently introduced but not warned about by the compiler since I’d cast away type information. Not productive or helpful in the slightest–it’s time-wasting bullshit for zero gain. If there was something concrete to be gained, I’d be more understanding, but it gains nothing except for satisfying “studly” programmers who want to feel superior because they can do everything in C despite it being entirely pointless. I was once one of these people. I learned better.
As an example, consider this trivial [C++14] code. Build with e.g. “g++ -std=c++14 -o test test.cpp”
——–
#include <iostream>
#include <memory>
#include <string>
#include <vector>
struct base{ virtual std::string name() const = 0; };
struct a : public base { inline std::string name() const override { return “a”; } };
struct b : public base { inline std::string name() const override { return “b”; } };
int main()
{
std::vector<std::unique_ptr<base>> l;
l.push_back(std::make_unique<a>()); l.push_back(std::make_unique[b]());
for (const auto& i : l)
std::cout << i->name() << ‘\n’;
}
——–
This combines a few things in just a few lines of code:
– automatic memory management; zero bare pointers, no calls to malloc() or new.
– storing allocated objects in a list; these are all automatically freed when the function exits
– use of interitance and virtual method calls
– automatic string handling
– iteration over the list using iterators and virtual method calls
This took just a few minutes to write and test. It’s utterly trivial. But consider writing this exact logic with GObject/GTK+. The GObject/GType work to create base/a/b would be many lines of non-trivial boilerplate; the memory management and list management would be manual and painful. Iterating over the list would be manual and painful. Storing and freeing the string returned by the method call would be manual and painful. While I’ve not used EFL, it looks even more painful than GObject.
It’s not that a “perfect” programmer couldn’t do all these things with C. It’s that each of these things is a potential point of failure, and moving to another language eliminates all these failure points at a stroke. It removes unnecessary risk. While programmers do need to focus on nitty-gritty details, constantly tackling unnecessary problems which have been solved decades ago serves little purpose. It’s like walking a tightrope across a chasm when you can walk over a bridge with side rails. Both get you to the other side, but to continually run the tightrope years after the bridge has been built is masochistic.
To rationalise this a bit more, we can consider some important factors for a software project:
– code size
– code complexity
– code quality
– code performance
– programmer time and effort
– ease of testing and validation
– ease of refactoring and ongoing maintenance
For these “non-disastrous” projects, were they each implemented by superhuman programmers, or did it involve a significant cost in terms of time and effort. How much time was spent with gdb, valgrind, coverity, etc. to eliminate errors? Are all codepaths covered by unit and integration tests, and are the tests comprehensive? Just for reference, I’ve experienced segfaults due to memory management bugs in every once of the projects you’ve mentioned. Yes, even glibc on more than occasion. Could the development time and implementation quality for these projects have been improved by using another language?
For the code sample in the parent post, consider how the above factors would fare if we implemented it in C rather than C++ (or Python):
– Would the code size be reduced? No. Reinventing OO in C (again) and doing everything by hand makes the code significantly larger, and hence significantly more likely to contain bgs.
– Would the code be less complex? No. Doing unnecessary extra make-work makes the code more complex and less readable, and again more likely to contain bugs.
– Would the code quality be improved? No. The chance for bugs creeping in is much higher.
– Would the code performance be improved? No. The C++ code might be using constructors, destructors to allocate and free things for me, but it’s simply automating what would need doing in C anyway. And when you look at the gross hacks to implement OO in both GObject and EFL, it’s quite clear that these are vastly less efficient than what the C++ compiler would generate as a matter of course.
– Would be programmer time and effort be reduced? No. The above example took around two minutes to write and test. How long would this take if written with GObject. For an expert, hours; for a non-expert several days–this is not documented well at all and it is very complex.
– Would testing and validation be simpler and quicker? No. There are many more things which could go wrong, and consequently more to test.
– Is it easier to refactor and maintain? No. It’s far more work, and far easier to mess up if the compiler doesn’t warn you about mistakes.
It’s not that this couldn’t be implemented in C, it certainly could. It’s more a question of whether implementing it in C has any concrete benefit, other than being able to boast of being able to implement it in C against all common sense. C is now 43 years old and over the course of those 43 years, we’ve discovered better ways of doing things, often several times over. Doing things “the hard way” is great if your main goal is to prove to others how elite you are, but if your goal is efficiently producing good quality code which performs well and isn’t riddled with bugs, there are better options. Doing things by hand the hard way is sometimes appropriate. When that work can be automated by the compiler, it’s kind of silly not to take advantage of it. In the above program, if the memory management was buggy, the program would fail to compile. I’ve eliminated several classes of failure which are endemic in C at a stroke, and I haven’t lost anything of value by doing so. In fact, by having the compiler be responsible for this burden, it leaves me with more time to focus on higher-level design and algorithms. It’s not that I can’t handle doing manual memory management, I can. It’s more that I don’t have to worry about messing up because it’s no longer possible to mess it up.
I’m not particularly advocating C++ here; Python or other languages would also be just as good, particularly for GUIs. PyQt is particularly nice in my experience. The high-level UI doesn’t need to be in a compiled language, though performance-critical widgets might.
Regarding C++, there are several comments about how large and complex it is. They are mostly correct. But consider this:
– you can use just traditional C plus the minimal subset of the features you need
– maybe you just want to use OO, in which case you don’t even need libstdc++; just use the class keyword
– maybe you just want better string handling, in which case just use std::string
– maybe you just want better memory management, in which case just use std::unique_ptr or std::shared_ptr
C++ was already so complex prior to standardisation that many people’s code was a buggy mess which leaked memory and crashed all the time. This is because in the mid-’90s even experts hadn’t yet fully appreciated all the subtleties with the interaction of memory management, exceptions, templates etc. It was easy to write buggy code. But we discovered and now use RAII to avoid these problems, and have done so for well over 15 years now. Once you’ve read e.g. Effective C++ (Meyers), you’ll know what you need to write good quality robust code. It’s a different set of considerations to writing in C, but many C programmers are quick to criticise C++ yet haven’t actually bothered investing any time to find out why the features it offers are useful, and how to make effective use of them. If they had, they might appreciate how it might improve their code. And if you’re a professional programmer, being wilfully ignorant and dismissive of the wider ecosystem around you isn’t a good thing (as we see in the original article comments).
note that your original posts didn’t start making snide comments and remarks basically saying “you watch porn all day and that explains your code”? or “your tools suck because they do X” which they clearly in code do not? If someone said that you molest children and that explains your work .. would you respond nicely? I sure don’t. and i don’t much care if people think i should “respond nicely”. when someone does something like that, it’s game on.
you, on the other hand have not “stepped over that line”. you have not of course addressed the fact that the typedef to void’s were a falsity in the OP (remember using an actual code release not some initial code commits being built), and edje_cc does nto “always return 0” on error – the code literally never does, unless you have found some incredibly odd codepath in it and it’s some rare case we have yet to find. ie just a grep of all the exit(-1)’s is enough to make that case, but you conveniently ignored this one.
You ignored all the comments on TDWTF about this + other proving you wrong. But I conveniently summarized that in this one for you.
1. the watching redtube comment in OP. seriously. you choose to forget that right now. you are a waste of time to talk with. very troll-like behavior.
2. spinning the exit code 0 edje_cc thing now to excuse the op because they decided to go to town saying how dumb the devs are that they can’t return an error code, when they couldn’t even BOTHER filing a bug report, or asking for support FROM THE PEOPLE WHO PROVIDED THEIR SDK, which was not the enlightenment project. yet you defend that behavior? don’t go to your software provider, but instead just bad-mouth the upstream developers because it’s more fun? you are the kind of person who thinks it’s fine to blame the farmer for a bad apple even when the store selling it wrapped it up in moldy banana peels? yup. that’s precisely what you are saying. “well how do you expect them to blame the store they bought the apple from? it’s just fine they say the farmer is incompetent for wrapping apples in moldy banana peels!”.
that’s enough – i’m not bothering with the rest. you are just as much of a troll as the OP. right from the same batch.
You don’t know what the situation was, so you can’t assume it was so simple as telling someone “fix it”. As this is the easiest thing to do, rather than working around bugs, it is safe to assume an attempt was made. I look at it from a user perspective and understand the situation. You look at it from the author perspective and you defend your product at all costs. Let me repeat that – you don’t know that and you can’t know what was done with the problem, before describing it. What you’re trying to do is implying a situation in your favor. You are showing an eristic argument style, which won’t work – I will point that out each time.
Going further – you deviate more and more from the real points of the OP:
* no type safety (proven there and here – you can find void * and Eve_Object everywhere instead of real types)
* bad docs (proven there and here)
* unprofessional logs (proven there and here – fun thing is you claiming the “bitch” comment is a lie and removing it later from code)
* bad API design (just read the API docs to see what a mess this is)
* unsafe callback system (proven by reading that smart callback thing in the docs)
* unsafe and badly designed event system (as above; the key event is really absurd, but it’s true – https://docs.enlightenment.org/auto/eet/struct__Evas__Event__Key__Do… )
* bad layout design (proven by reading the docs)
* unsafe memory handling (proven by the language of choice – C)
* strange hack for working around the lack of type safety (ironically, proven by you)
this seams to be another cultural thing …
What is the matter with watching porn? Is it a considered as a bad thing? Is porn a bad thing per se?
Not where I come from….
Of course it makes no sense, to assume watching porn leads to bad code. Its like saying “eating apples leads to bad code” or “doing sports leads to bad code”.
Simply no relation.
I really can’t understand his obsession about it. He made logs about spanking programmers, called them bitches and even named one widget type SWALLOW. And now he’s surprised about a joke about it all and uses it as an excuse for personal attacks. Unbelievable.
Edited 2015-05-16 13:17 UTC
well, if the only thing that Swollow reminds you of, is porn, than you might be watching to much in deed 😛
No, I can see the context and while I have no problem with all these log entries, I also have to admit its not very professional. More information on the error and suggestions how to solve the problem, would be more helpful.
Well Mr. Somebody: you said Raster should calmly admit his mistakes and solve things out. He did by removing the “Bitches”.
So we should not bring this one up again and again.
Also you have to admit that any code here on earth may give no return on error, if you wrap it up or modify it somehow…
True, but if a user doesn’t know a tool is wrapped, he is safe to assume the tool works wrong. The issue seems to be clarified now, at least a bit. It’s always good to position yourself as a user, if you’re a developer.
I found this while browsing their sources
https://git.enlightenment.org/core/efl.git/commit/?id=ed58165b501d24…
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.
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