SFML community forums
General => General discussions => Topic started by: BHXSpecter on July 15, 2012, 04:28:46 am
-
SFML isn't any less ugly. I've been programming for 16 years and have never seen an API that isn't ugly. Qt, Allegro, SDL, SFML, enet, Box 2d, etc all have ugly APIs and could be improved upon in one way or another. To be honest I write wrappers for every library I use so the ugliness isn't an issue.
What exactly is ugly in SFML? It's a real question, because I'm interested in your criterions, as I personally have only seen very few C++ libraries with such a clean API as SFML. For me, "clean" includes points like:
- Well-structured functionality
- Intuitive usage
- Consistency
- Modern C++ style
And I understand eXpl0it3r. It is already more cumbersome to program with SDL/Allegro because they are written in C, with all the corresponding drawbacks. For example, there is neither automatic memory management, nor function/operator overloading, nor default parameters.
Your clean list alone shows SFML isn't clean. If SFML has "intuitive usage" then there would be no posts on this forum as everyone would just instinctively know how to use SFML without a document or tutorials. Resident Biscuit's misuse of the three functions again show it isn't intuitive otherwise he would not have posted this thread.
"It is already more cumbersome to program with SDL/Allegro because they are written in C, with all the corresponding drawbacks." That has to be the oddest sentence I've ever read. Don't mean that in a bad way, just I looked at the Pong code for SFML and I've coded Pong games in SDL and Allegro 5, and all three have similar function names and structure for doing it (ie clear, draw, display). Only big difference I've noticed is SFML abstracts the process more than the other two libraries.
As for consistency, that is a good thing, but wouldn't take it at face value. That could just mean they don't care to change the API or only tweak the function body to optimize the library while adding new functions here and there. I know a programmer that does just that, I've told him he needs to make more creative names in his library he made for his team a few years back, but he has been consistent there because he doesn't want to make more creative and memorable names for the functions. While others, like Allegro 5, got the API renamed to reflect that A5 was a new library and not like the A3 or A4 libraries before it.
Can't really comment on modern C++ style as modern C++ style is still in flux too (I mean they just released C++11 so that will change modern C++ style some, but don't know how much).
Bare in mind these are just my opinions, just like it is my opinion that SFML API is ugly. Even if I set here and listed every thing I thought was ugly, I already know that the SFML devs would just say something like, "Well it is how we like it and it is staying that way." I've pointed out ugliness of libraries before and I'm used to nothing being fixed in it so I've just learned to keep it to myself (unless it is a company I'm working for then I'd list everything).
I'm sure SFML's dev team is a great team and I'm not trying to put them down. Just stating my opinion, but the wonderful thing about opinions is that no one has to agree with them :).
It implies that you choose your tools according to your feelings, instead of the usual technical details (design of the API, documentation/tutorials, features, ...)
So which would DirectX fall under? That is the ugliest API I can even think of.
-
Your clean list alone shows SFML isn't clean. If SFML has "intuitive usage" then there would be no posts on this forum as everyone would just instinctively know how to use SFML without a document or tutorials.
It is just not possible to use a library that covers this functionality without knowing anything. Rather than argumenting by taking "intuitive" literally, you should show how -- on a technical level -- SFML could be improved towards being more intuitive and user-friendly.
"It is already more cumbersome to program with SDL/Allegro because they are written in C, with all the corresponding drawbacks." That has to be the oddest sentence I've ever read.
You shouldn't have omitted the following sentence, I especially listed some examples to clarify it. What I mean is that C forces you sometimes to write unnecessary boilerplate code (e.g. explicit allocation and deallocation).
Only big difference I've noticed is SFML abstracts the process more than the other two libraries.
Which is an advantage in my opinion. Note that with the low-level vertex API and OpenGL, you still have the possibility to not use those abstractions.
Can't really comment on modern C++ style as modern C++ style is still in flux too (I mean they just released C++11 so that will change modern C++ style some, but don't know how much).
I meant modern C++98, as SFML doesn't use the new standard. And here, I refer to style shown in books such as Effective C++ or Exceptional C++. You don't find that in many libraries.
Bare in mind these are just my opinions, just like it is my opinion that SFML API is ugly.
The problem with your opinion is that you actually say, "SFML is ugly, but it can't be more beautiful". If you don't see much room for improvement, you can consider it already pretty optimal. If you see it, please be more specific. Opinions are good, but arguments are better ;)
-
Your clean list alone shows SFML isn't clean. If SFML has "intuitive usage" then there would be no posts on this forum as everyone would just instinctively know how to use SFML without a document or tutorials. Resident Biscuit's misuse of the three functions again show it isn't intuitive otherwise he would not have posted this thread.
This is not fair. No library can be 100% intuitive, and live without forum, documentation and tutorials. But libraries can be more or less intuitive; and what Nexus said is that, in his opinion, SFML is more intuitive than other libraries.
Bare in mind these are just my opinions, just like it is my opinion that SFML API is ugly. Even if I set here and listed every thing I thought was ugly, I already know that the SFML devs would just say something like, "Well it is how we like it and it is staying that way." I've pointed out ugliness of libraries before and I'm used to nothing being fixed in it so I've just learned to keep it to myself
You can't imagine how curious I am to see your list. I'm not saying that I would answer "alright, I'll change everything", but discussions about design are too rare and can really help SFML to become better and better.
The "team" is not huge, it's just me and Hiura for the OS X port. So design issues can be discussed very easily, and I can decide to make any modification whenever I want -- there's not a whole team to convince, nor plans/roadmaps to break.
-
Your clean list alone shows SFML isn't clean. If SFML has "intuitive usage" then there would be no posts on this forum as everyone would just instinctively know how to use SFML without a document or tutorials. Resident Biscuit's misuse of the three functions again show it isn't intuitive otherwise he would not have posted this thread.
You got a very wrong definition of 'intuitive' in your mind. Intuitive doesn't mean everything works for everyone with no learning curve. It only means the if you know part A it will be very easy to get to part B.
Take the touch mechanisms as example. I think mostly everyone would agree that touch movments are intuitive. Now if you give a device capabale of those inputs to a person not familiar with them at all, you'll notice that only some will automatically understand that pitching with two fingers will zoom, or swiping will get you to another screen/state. So intuitive in a technical sense is not just to know blindly how to do things, but more like an easy way to understand and discover new things, when a few certain rules are set.
And everything can be misuse in some way, it doesn't matter if it's intuitive or not, e.g. I have a computer mouse, throw it against the wall and it breaks, is that now the fault of the vendor or creator of that mouse?
Only big difference I've noticed is SFML abstracts the process more than the other two libraries.
As Nexus said abstraction is a good thing, or why do you think nobody is programming in ASM anymore? A computer is a product full of abstraction, physical interactions -> electronic stuff (transistor) -> logic gates -> processor -> bit code -> assembler -> higher programming langues like C++.
Also the name API means Application Programming Interface and interface is what connects diffrent abstraction levels.
So from my point of view this statement says that SFML is better than SDL or Allegro sind it uses a better abstraction. ;)
As for consistency, that is a good thing, but wouldn't take it at face value. That could just mean they don't care to change the API or only tweak the function body to optimize the library while adding new functions here and there. I know a programmer that does just that, I've told him he needs to make more creative names in his library he made for his team a few years back, but he has been consistent there because he doesn't want to make more creative and memorable names for the functions. While others, like Allegro 5, got the API renamed to reflect that A5 was a new library and not like the A3 or A4 libraries before it.
Have you looked at the difference between SFML 1.6 and SFML 2.0?
I'd say SFML 2 is a completly new library with sooo much changes. Take the function change Laurent made from CamelCase to camelCase which still confuses people and so even hate the change, but you can't say SFML is limiting itself.
Also do you think SDL doesn't care for consistancy at all? Wrong! Because if they wouldn't be consistence the library wouldn't be available on nearly all linux distros by default. With that you can be certain that you're program will just run under linux and don't have to worry about compability etc...
It implies that you choose your tools according to your feelings, instead of the usual technical details (design of the API, documentation/tutorials, features, ...)
So which would DirectX fall under? That is the ugliest API I can even think of.
I don't really get the connection between the quote and your answer, but if you wanted to say you don't use DirectX because it has an ugly API then this falls again into the same category as Nexus as pointed out.
I don't choose DirectX because I can decide between OpenGL and DirectX and only OpenGL is crossplatform so the choice is really easy. If I wanted to make a fullsized AAA game just for Windows I might use DirectX regardless the ugly API, but because it may give me more power to the OS supported functions.
As I said, it is just my opinion. Any ugliness I think there is I just remedy by wrapping them in a function of my own. I don't stress over it, lot easier just to wrap them and keep going than to worry about the developers possibly fixing them. Since the developers and other users don't think the API is ugly then I will just continue to wrap it and use it that way. No need to rock the boat over interpretations of clean and ugly API as the API works fine even though it isn't to my tastes. After 16 years I have just become accustom to doing wrappers anyways :).
Do you really go down the path to: "This API is ugly but I won't tell you why."
We're all eager to know what your opinion is and what you think should be made better. So the worst thing that can happen is that your suggestions just get rejected, so you got nothing to lose at all.
If you for some strange reason really don't want to tell use what in your opinion is ugly, then you could maybe enlight us on how you'd create a wrapper for SFML. You know there's nothing wrong in having it's on engine/code laid out to use a certain interface for a renderer and then write a 'wrapper' that connects the wanted interface with the selected renderer, but that doesn't mean the other API is ugly, it just means that you match your ideas with the one of the library.
Since you like to point out your 16 years of experienc I'm curious to see some of your work to maybe learn a few new tricks. And are those 16 years from the first time you've read something about programming or from the time you got hired as programmer or contributed to a bigger open source project?
So please tell us your opinion! :)
-
As I said, it is just my opinion. Any ugliness I think there is I just remedy by wrapping them in a function of my own. I don't stress over it, lot easier just to wrap them and keep going than to worry about the developers possibly fixing them. Since the developers and other users don't think the API is ugly then I will just continue to wrap it and use it that way. No need to rock the boat over interpretations of clean and ugly API as the API works fine even though it isn't to my tastes. After 16 years I have just become accustom to doing wrappers anyways :).
Why so defensive all of a sudden? You made a claim, now back it up or shut up. With your (claimed) 16 years of experience I believe you should be pretty good at designing a good API if you like to write your own "better" wrappers around the API in question. Thus far, you haven't mentioned a single flaw in SFML API, instead you've emphasized it's your own opinion and doesn't really matter, while boasting your experience as a developer.
-
You have 4 messages, and all they say is: SFML is ugly. You never showed on this forum for posting questions or answers, so why are you here? Did you just want to say "SFML is ugly" and then goodbye? You started this discussion, so where did you want to go with it?
And someone with so much experience shouldn't be afraid to share its opinion about the design of an API. I'm sure it is more than relevant, and could help a lot. So why don't you tell us?
-
Lets not instigate more war.. And be productive instead..
This thread is not really about improving anything anymore... Programmers tend to be a little less than flexible, and a lot of them really believe there is only one way to do things right, even when those beliefs are just a matter of philosophy.. We see that in teachers, co workers and everywhere else. We have apple, windows and linux defenders, among many others, and fans for about anything who aren't likely to ever agree on one single opinion..
I just don't think we are building something good from this thread.. If good constructive comments were to appear, that would have already appeared...
-
I think there are two kinds of ugliness:
1. you don't like the naming convention, or how classes are organized: this is your own taste and, unless the majority of users share it, discussing it won't make the library better
2. you don't like some design choices, and think that some parts of the library could be more intuitive, cleaner, etc.: it could clearly improve the library and definitely deserves a discussion (even if it's only your personal opinion)
I deduce from what you say that you are talking about number 1.
The fact that SFML is known, used and appreciated only proves that the API is not completely wrong. But it doesn't mean that it can't be improved. Most people just use it and are happy with the way it is written, only a few experienced users take the time to question the design of the API and share their ideas or comments with the team. So any feedback of this kind is precious to me.
-
I followed this thread and expected some suggestions or notes from BHXSpecter. But nothing. :(
As a noob i would be very interested what's so ugly in SFML. :)
-
BHXSpecter, can you tell us how you write your wrappers?
-
And someone with so much experience shouldn't be afraid to share its opinion about the design of an API. I'm sure it is more than relevant, and could help a lot. So why don't you tell us?
It concerns me that you are so hung up on my opinion of it.
People are "hung up" about it because you created a thread about it...
If you don't want to discuss it, there's no need to create a thread. Creating a thread titled "SFML API ugliness" means you want to discuss SFML API ugliness, no?
[edit]
Sorry, I thought BHXSpecter forked and created this thread to avoid hijacking the other thread. I missed Laurent's post saying he created the fork.
-
Laurent started this thread to have a proper place to discuss it.
Anyway, quit the discussion, an opinion is always good, but it is not necessary to force him to give his.
Lets just quit this and make good software instead :)
-
Laurent started this thread to have a proper place to discuss it.
Ah, I see. Thanks for pointing that out.
-
I followed this thread and expected some suggestions or notes from BHXSpecter. But nothing. :(
As a noob i would be very interested what's so ugly in SFML. :)
I second this notion. I can't speak for others, but I myself probably would learn a thing or two if BHXSpecter shared not only their opinion but also arguments backing up that opinion.
I also can't quite understand why hold back on it. What anyone has to lose here?
-
Yeah, I mean I can think of a few things I'd of done differently with SFML, but all in all I like the API.
Things I'd of done differently, largely design choices and reasons not to can be easily justified:
- All platform specific calls would be hidden behind interfaces to aid in porting (e.g from OpenGL to DirectX or OpenAL to DirectSound or whatever)
- Unit Test, Integration tests and Acceptance Tests to act as promises and safe-guard against breaking things too badly whilst refactoring (which would be difficult without the previous interfaces).
-
I don't really understand the point of the hate. If you have criticisms, then state them, and explain how you would change them, or better yet, write your own library. I personally think SFML is definitely one of the best OpenSource APIs, and I think that Laurent has done a fantastic job. Obviously one can't be perfect, but on a realistic level, I think SFML is a great example of a fantastic OpenSource API. Look at something like Direct X. It is gaudy and limited as well as worked on by a LOT of paid people. Despite all of that though the general ease of use and quality of Direct X is horrible.
-
Obviously there were no arguments, rather a personal style preference, which is correspondingly useful for an objective discussion. There is not much benefit from resurrecting the thread ;)
-
I know everyone has already stated that it is just BHXSpecter's opinion is just an opinion, but I find this situation strange. SFML is open source, so if BHXSpecter finds SFML so ugly, then why doesn't he create his own version? You can't critisize something if, a) You don't know how hard it is to create something so epic in the first place and b) If you don't have any evidence. BHXSpecter seems to not have a very good argument, which I suspect he/she has realised at which point they started being defensive by saying things like this:
As I said, it is just my opinion. Any ugliness I think there is I just remedy by wrapping them in a function of my own. I don't stress over it, lot easier just to wrap them and keep going than to worry about the developers possibly fixing them.
I strongly disagree with the above quote anyway, because if you can see an improvement, then point it out.
Also, when you say something is good or bad, you are just comparing it to something else. For example, a banana is good because it is better than some chocolate. Here, BHXSpecter is not comparing SFML to other APIs, but rather to his own version of the perfect library, which is completely unjustified. You have to compare things to something similar, which actually exists, not something which you would like to exist. This is like saying, a banana is bad because it is not as exotic as Martian Red Monkey Grape. See what I mean?
Sorry about this, but I feel that SFML is an excellent library, and you just can't say it's bad without having any strong reason.
P.S. If you think SFML is so ugly, then why do you use it anyway? Maybe it's the best library out there? Or maybe you are just not bothered to write your own library?
-
(http://www.lotustalk.com/forums/attachments/f93/127134d1247491680-lotus-dealers-sell-their-stuff-msrp-including-new-evora-dont-feed-troll.jpg)
-
this ^
-
As Nexus already said:
Obviously there were no arguments, rather a personal style preference, which is correspondingly useful for an objective discussion. There is not much benefit from resurrecting the thread ;)
So please stop writing/ranting/trolling in here, unless it's really related to the topic (ranting about BHXSpecter isn't related to the topic). Als kaB00m & noobie, writing such useless things is imho considered spamming.
Since BHXSpecter doesn't care to answer anymore, this thread should be closed to prevent further ranting/spamming.