Does complexity matter (in general and in GUI)

SDL Development
1

I ask it because, i compare the complexity of my GUI widget toolkit to the complexity of other widget toolkits, and all these toolkits including mine are generic. Like my widget toolkit is 10 to 60 times less complex than many other widget toolkits, the complexity of the other toolkits also varies. And i get answers like, complexity doesn’t matter at all.

I say that complexity does matter. First complexity can never be completely hidden. But second, when a toolkit has to be easily changeable, so that one can easily change completely everything in the code, then the length of the code matters. And the learning curve also depends on it, in several ways, being able to read the code because it’s shorter, helps to understand how it works. And being able to immediately control everything what it does, also helps to understand it more.

So who says complexity doesn’t matter, what do they say then matters? Short learning curve? But some say that it’s the better the more features the widget toolkit has, and learning these features makes the learning curve longer, so learning curve also then doesn’t matter. How well does it work matters? But when it works worse, then it may just need a longer learning curve to learn all its deficiencies, so how well it works doesn’t then also always matter.

The only reason why i wrote my widget toolkit was that it had to be small and everything there has to be easily changeable, also that the user has to be able to immediately code what it does. Besides having to be completely faultless. If that all didn’t matter, then by that my widget toolkit were completely useless. Is it true?

Some say try this GUI toolkit and try that GUI toolkit. But as i see it, what concerns GUI toolkits, it is not a matter of trying. Because all generic GUI toolkits, even if they are made as simple as ever possible, need some learning. Which means that the user has to decide what GUI toolkit to use before trying it. I dare to say that my toolkit is easy enough to learn, so that when it really happens that it’s not good enough, then one can afford to forget it and learn another one, i doubt that this will happen, but this is not always the case.

I think when one needs a generic widget toolkit that is not complex, then this should be immediate GUI, because it is more direct and thus less complex. The original immediate GUI is imgui https://github.com/AdrienHerubel/imgui , this is the most classical but this is for OpenGL. Immediate GUI, or i call it principal GUI as it goes further, is my GUI toolkit for SDL2 https://github.com/actsl/kiss_sdl , this is not only for SDL2, but written in SDL2, that is more than just having a backend for SDL2.

I hope that there is a use of talking about such theoretical issues, though there has not been much of such theoretical talk.

2
  1. Lines of code is NOT a measure of complexity and you are still using your library’s LOC metric as a measure of its complexity.
  2. Complexity of a library is of minor importance; what is of major importance is the complexity of programs that use that library: using a library should not egregiously affect the complexity of the library user’s code.
  3. If a library is too “simple” or has too few features it probably means that the user has to do more work adding complexity to his own programs to mitigate the deficiencies of that library.

/Flibble

1 Like
3

Not this crap again. Look, we get it; you think your toolkit is the
hottest thing since sliced bread. But TBH, I’m sick of opening my
email every morning, and more often than not, seeing you spamming the
SDL mailing list as an advertisement page for your warez.

If you have a question to ask (or answer), then fine, do it. Otherwise,
why don’t one of the mods just ban this user. In case it wasn’t clear:

WE DON"T WANT TO HEAR, YET AGAIN, ABOUT YOUR TOOLKIT
4

I think extremes are not important targets for any library. Simple is not always better and more is not always better.

Two things that are actually important: Comprehensiveness and filling a niche/need. Do one of those and be satisfied with your work. If it’s a niche (I.e. you don’t expect most devs to want to use your tool), be happy with any users. If it’s the best tool across the board, hands down, then you won’t even have to try. If you have few users (fewer than 1000), you have trouble marketing, and you work mostly alone on it, you are probably in a niche.

5

Being niche is not a bad thing, just to clarify. You just have to have realistic expectations if that’s where you end up.

6

I think JonnyD has some good points - there are uses for simple things and for more complex things and for example both Dear Imgui and Qt are very useful for different purposes.

For personal projects I’d suggest to do whatever is useful or interesting to you.
It’s great to release that kind of projects as Open Source Software; maybe it’s useful for someone else and that’s cool, but if not that’s also ok - at least it was useful to yourself, or you had fun doing it and you probably learned something.

(And, TBH, the more people use it the more time you’ll spend on support, debugging their problems, fixing bugs they found etc, and that’s not always as much fun as writing the software in the first place :wink: )

7

Yes this is of course the answer. I never disputed that simple and complex are both important, they are for different needs. Comprehensive i think means a set that includes everything. There is also generic, which is a minimal general set, my toolkit and imgui are generic, they are meant to be extended for anything outside the generic set. While Qt aims to provide a comprehensive set where one can get everything for any need. I don’t say neither is bad, and neither is always better, and there is a need for both, these are just different approaches.

Thus when choosing a widget toolkit, one has to proceed from what is ones need, and then choose one that is good for that need. What i don’t like when they write about widget toolkits, are some general statements like, it is good this way and it is good that way, sometimes this is all you can read in the summary, so you never get to know what it really is. This i think is advertisement, aiming to make one to make decision without even knowing enough. This i think is bad, because widget toolkits need too much learning to try, and it is that information based on which one should make a decision.

Stephen_Anthony, this thread is about theory, at least this is what i intended it to be. JonnyD and Daniel_Gibson, your answers were constructive, i always wanted such discussion.

8

I’m going to side with MrFlibble on this, lines of code is a metric, but not a sign of complexity

Take this case for instance:

There are two software packages, where each feature for either package is about 100 lines of code. The first package has three features, and the second four features. Is the second software package more complex? Honestly, we can’t tell, because we don’t know the relationship between the features.

I think a huge problem in understanding complex code is that we don’t even have a definition that we’re all agreeing on. If it’s just the length of code, that is not really covering a lot of what makes complex code. I’d say complex code has the following characteristics:

  • It is hard to read.
  • It is hard to maintain.
  • It is hard to add a new feature.
  • It has little to no feature isolation.
  • It is hard to test a given feature.
  • It has inconsistent coding practices (ie style guides and general coding rules).

Lines of code as a sign of complexity is really only reasonable for small pieces of code. For a javascript example:

// Low complexity
function foo (someArray) {
  return someArray.map(transformItem)
}

// Higher complexity 
function foo (someArray) {
  var someArrayResult = [] 
  for(var idx = 0; idx < someArray.length; idx++) {
    someArrayResult.push(transformItem(someArray[idx]))
  }
  return someArrayResult
}

Both of these things do the exact same thing, but the low line count is roughly the same as the low complexity. But it reality, it’s not really the line count, it’s that the first function has less moving parts. There are more variables to keep track of, a manual loop, and code that doesn’t self-document well.

So on a micro-scale, line count is maybe meaningful to demonstrate complexity. On a macro scale, especially with various features interacting, it’s less meaningful because there is code to deal with each feature, plus code to deal with the relationship between each feature.

In terms of finding a programming library or tool and judging it’s complexity, you really just have to try it out. If someone builds a tool with the intent that other people will use it, it’s in the best of the developer to say it is simple/easy/etc., and maybe it is, maybe it isn’t. It also difficult, because what another developer sees as complexity may just be unfamiliarity to how the original developer envisioned the implementation of the tool.

Think about SDL. How many lines of code are in the project? I don’t know that I’d consider SDL complex, since given my definition of complex code, SDL isn’t hard to read, it doesn’t seem to be hard to maintain and have features added (people are creating patches for it all the time), features are appropriately isolated and easily testable, and follows a coding styling guide with pretty consistent code rules throughout.

That’s all to say that I don’t believe that lines of code, on it’s own, is a reasonable complexity metric.

9

I think what you say is, lines of code is a measure of complexity, only when the code is well written.

Side note, widget toolkits are quite difficult to understand, as they have to do many things, this is why i think that the learning curve matters there more than with other things.

Btw, SDL2 version 2.0.5 has [corrected 247 912] lines of code, the way i count it with find and wc, this is relatively simple for a major framework.

10

Not at all. On a small scale (ie a single file, or a single or group of functions), lines of code is maybe a sign of complexity. On a large scale (full app or library), lines of code becomes considerably less relevant.

11

Thank you for clarifying what you mean.

My gui toolkit last version has 2446 lines of code, so is it entirely what is considered small scale?

Btw, SDL2 version 2.0.5 has 247 912 lines of code, when counted with find and wc -l, again small for a major framework. I’m sorry, don’t know what is wrong with me, i forgot -l.

12

Not to sound like a dick, but is this thread really about having some other person validate that your library isn’t complex?

1 Like
13

No, sorry that i asked that question, this thread is not about that.

14

I have to agree with Stephen_Anthony on this one. I don’t think I’ve ever seen a post made by you that doesn’t include something about your toolkit or some kind of advertisement about it. Frankly, I’m starting to get very sick of it.

I know this post doesn’t add anything of value to this thread but I just feel I have to say it.
If you want people here to like/start liking you, you need to stop with the advertisement of your toolkit and start asking/answering questions (that doesn’t evolve around your toolkit) and become a nice part of the community, which, in my opinion, is the purpose of the forum.

You can either ignore what I’ve just written or you can take it as a friendly advice. If I were you, I would take it as a friendly advice since you’ll then have a much more pleasant experience on this forum.
Whenever I post something on a forum, the last thing I want people to feel whenever they see my post is: “oh no, not this user again”, but that’s just how I feel about it.

2 Likes
15

I’m open source programmer, i will say no more. I will post no more.