Creeping Elegance

[doppler]

Creeping Elegance - Yes it's a thing.  It's a description of things which at the request of unqualified people (namely salesmen).  Want things for a project which takes away engineering time and costs money with no immediate return.

Backstory: I used to work for a company, which wrote from bottom up an Operating system which duplicated a major vendor in the field and did one better.  We were the first to do it in software.  Other guy did it in eproms, lots and lots of eproms.  The O/S was called Pick O/S.  It did all the things the fortune 500/100 companies wanted that IBM did not provide.  At the milestone of V2.0, a large number of features was requested in a short time frame and a want to be fixed all known and unknown bugs.  Unknown bugs ??? WTF ???.  Well that set in motion a whole new department dedicated to breaking the O/S.  As time pasted (including the first targeted deadline.)  Bugs, unknown bugs (fixed) and features were being created.  At record pace IMHO.  But an ending was no where in sight.  The department head of engineering could see what was happening "Creeping Elegance".  Fed up with missed deadlines all around.  A little meeting was done.  The outcome from the meeting, Sales was given the task of defining what was "REALLY NEEDED" to complete V2.  A few top level meets later with our largest users.  A shorten list of "needs" was created.  And a longer list of "wants".  V2 went out quicker and customers got a hint at V3.  Everyone was happy with V2.

Bottom line: There was a lot of wasted time trying to give Sales features that customers didn't want or would use.

Here is the question:
Are we getting diverted by Creeping Elegance with QB64pe ?
Should we survey which features to create ?

Don't get me wrong here, I think QB64pe, has a lot of good things and features.  Just my 3 cents here.

[SMcNeill]

To answer this, one has to ask, "What features are being developed in QB64pe? Are those features unwanted or something that won't be used?"

Let's look back at what we've added here recently:

A new build process, which allows the end user to choose which flags and optimizations they want to use with qb64pe. There's a dozen posts concerning this change, and it's one of the most interacted topics on the forums, so I'd say it's safe to say that people are interested and using the c++ optimization flags.

There's the new work which has been done on the image library front. We now load images faster, as well as support more image formats than before. The vast majority of users end up making use of images with their programs, so this isn't an unwanted or unused change.

Same thing with the sound library. We've gotten rid of the LGPL licensing requirements, which were a large concern to many people, as well as expanding and enhancing our sound routines. Back at last Christmas, I ran into an issue with loading multiple X-mas songs into my little game program, due to the time it required to load them all. 20 songs took almost a full minute to load... Now, those same 20 songs can be loaded and ready for use in around a second. That's a HUGE change -- and something which I sure as hell am appreciative of, even if no one else ever is.

We've redid the wiki - rebuilt it from scratch almost. Who doesn't use it?

Exactly what have we been pushing into the language that's unwanted or unused? All the changes I've seen in qb64pe are ones which people make use of. There's nothing which has been worked on that's been wasted effort, as far as I can tell.

---

As far as surveying what features to create, we simply don't work that way. Each developer we have is basically nothing more than a hobbyist who is willing to contribute to changes and adding features which they tend to need in particular with the language. The community could vote and say, "Add array use in UDTs next!!", and sadly -- but honestly -- the devs would just roll their eyes and shrug their shoulders at the suggestion. I wouldn't know where to start to do such a thing. I don't know if any of our other devs know how to tie in to the existing system and make such a change either -- or if they'd be willing to put off their own personal projects/enhancements to jump on such a request.

Truly, if the community started voting on what to develop next, I imagine the dev response would be, "We'd love to see this addressed as well. I wish you the best in luck in finding someone who can address the issue for you, as it's not something which we currently know how to correct."

At the end of the day, we make a lot of changes and correct a lot of glitches in the codebase, but when all is said and done, we're still just trying to maintain and improve somebody else's code -- and poorly documented code at that! For years now, I've been gnawing at the lack of full keyboard support and mismapped/multimapped keystrokes, and I still haven't sorted out how to correct the issue -- and I'm one of those guys who folks point to and say, "Steve's a dev on this project!"

Feel free to suggest anything in the world that you'd like to see us fix, add, or work into the language. Just do so while remembering we're just human, and we may not have any clue in the world to how to do whatever you'd like to see done. We're still learning as we go along everyday with the project.

[doppler]

Not being critical here. Just don't want you or the dev's. Being hit by whimsical requests. There has been a Herculean effort to recover from the ash'es. I think we are recovering better than any expectations.

[DSMan195276]

As a bit of a counter to Steve's point I think we largely do this already, the github tracks a long list of issues largely reported by users who don't work on QB64-PE, and I at least try to fix them if I can or keep them in mind. I think just about every user-facing feature has been added was due to a request from someone in the community: Compiler settings menu and command line options, Midi support, _ROL/_ROR, audio library replacement, many bug fixes...

I definitely agree with Steve's larger point though, this is just a hobby for all of us and functionally we just do not have the capacity to commit to any strict timelines for getting particular features done. I certainly like fixing issues for people, but that doesn't mean we always can, the best way to get something fixed is to try it yourself and submit a PR. And of course, the advantage of not having strict timelines for stuff is that we don't really stress over having too many things to do, we just focus on doing what we can and people are pretty understanding. We don't have a sales team breathing down our necks about finishing stuff 

[bplus]

I rue the day when elegance takes on a negative connotation.

Perhaps "bloat" is the more appropriate word? I remember the developer of BBC Basic use to really rail against bloat. But he was still remembering days when storage was very precious commodity. But the challenge to avoid bloat still is an excellent discipline for the spirit.

[doppler]

Perhaps "bloat" is the more appropriate word

Creeping Elegance morphed into Bloat.  People understand bloat, because it's 12" below there head.

[SMcNeill]

"Bloat" and "Creeping Elegance" and other such terms are all just elitest gobbledygook.  It's a way of saying, "Hey, I personally don't need X feature, so it's a waste to include it in the language!"

Ever since QB64 hit its first major milestone and was able to compile QB45 code on a modern OS, people have been complaining over how the language has "bloated" out of control ever since.    We don't *need* extra math commands!  We don't need extra image formats, or extra sound capabilities!  32-bit screens are overrated -- QB45 didn't have them, and they're just bloat added into the language!  MEM wasn't needed -- it's just bloat!  Bit shifting?  Bit rotating?  Bloat!  File compression?  Bloat!

I've heard it all in the last ten years of working on the project here.  People object to adding *anything* new, as it might add 0.02kb to the size of their compiled EXE -- and that's BLOAT!

A language without any new development is a dead language.  If all one needs is QB45 capability, then just use QB45 and Dosbox.  Personally, there's a zillion things I'd like to see added to the language -- but according to some people, it'd all be unnecessary bloat!

Personally, I'd like to see:
Video support -- it'd be nice to have a _VideoPlay command where avi, mp4 and mkv files could play and run in.
Unicode support.  It's currently a PITA to type and input foreign characters in a program.  I'd love to see utf8 support added.
Speech to text added.
Text to Speech added.
HTTPS support added.
OCR added.
JSDN support.
SQL support.
Along with a zillion other things...

But each time one of these things might be worked on or added, someone pops up and starts complaining over bloat.  "I don't need this and it's just adding to the complexity of the language and the size of the files we're creating!!"

Which seems rather selfish to me, as there's a dozen other people who would like to easily be able to just call a keyword and have such functionality at their beck and call.

What one guy calls "bloat", another calls an "essential tool".

---

The only real solution is to just strip everything out and make it all independent libraries which you then have to specify for use with your program.

Code: (Select All)

$USE: Screen
$USE: _NewImage
$USE: Print
$USE: Color
$USE: End

Screen _NewImage(640,480,32)
Color &HFFFF0000
Print "Hello World" 
End

With the above, we have the $USE command which we can make use of and only add those elements into our program that we actually make use of.  Bloat is now gone, but dang if the complexity of coding hasn't suddenly gotten a lot more complicated!!

[TerryRitchie]

"Bloat" and "Creeping Elegance" and other such terms are all just elitest gobbledygook.  It's a way of saying, "Hey, I personally don't need X feature, so it's a waste to include it in the language!"

Ever since QB64 hit its first major milestone and was able to compile QB45 code on a modern OS, people have been complaining over how the language has "bloated" out of control ever since.    We don't *need* extra math commands!  We don't need extra image formats, or extra sound capabilities!  32-bit screens are overrated -- QB45 didn't have them, and they're just bloat added into the language!  MEM wasn't needed -- it's just bloat!  Bit shifting?  Bit rotating?  Bloat!  File compression?  Bloat!

I've heard it all in the last ten years of working on the project here.  People object to adding *anything* new, as it might add 0.02kb to the size of their compiled EXE -- and that's BLOAT!

A language without any new development is a dead language.  If all one needs is QB45 capability, then just use QB45 and Dosbox.  Personally, there's a zillion things I'd like to see added to the language -- but according to some people, it'd all be unnecessary bloat!

Personally, I'd like to see:
Video support -- it'd be nice to have a _VideoPlay command where avi, mp4 and mkv files could play and run in.
Unicode support.  It's currently a PITA to type and input foreign characters in a program.  I'd love to see utf8 support added.
Speech to text added.
Text to Speech added.
HTTPS support added.
OCR added.
JSDN support.
SQL support.
Along with a zillion other things...

But each time one of these things might be worked on or added, someone pops up and starts complaining over bloat.  "I don't need this and it's just adding to the complexity of the language and the size of the files we're creating!!"

Which seems rather selfish to me, as there's a dozen other people who would like to easily be able to just call a keyword and have such functionality at their beck and call.

What one guy calls "bloat", another calls an "essential tool".

---

The only real solution is to just strip everything out and make it all independent libraries which you then have to specify for use with your program.

Code: (Select All)

$USE: Screen
$USE: _NewImage
$USE: Print
$USE: Color
$USE: End

Screen _NewImage(640,480,32)
Color &HFFFF0000
Print "Hello World" 
End

With the above, we have the $USE command which we can make use of and only add those elements into our program that we actually make use of.  Bloat is now gone, but dang if the complexity of coding hasn't suddenly gotten a lot more complicated!!

I'm all for new keywords and features added to the language. My main computer (which is 6 years old now) has plenty of power for anything added to the language. My point being that so what if the compiled size of the code gets a little bigger with each additional feature? Computers only get faster and new QB64 features can take advantage of that. If someone wants less "bloat" they can always fork the project and remove it. The use of a metacommand would be a terrible idea.

_VideoPlay - Hell yes!
HTTPS - Oh yeah!

[dbox]

"Bloat" and "Creeping Elegance" and other such terms are all just elitest gobbledygook.  It's a way of saying, "Hey, I personally don't need X feature, so it's a waste to include it in the language!"

That is a remarkable statement.

[SpriggsySpriggs]

Being able to play a video would be quite amazing. I think, however, it would require people installing codec packages. My Win32 video player required an installation of "K-Lite Codec Pack Full" in order to play all the different video types out there. You could possibly script out that install but I'm not sure if they have silent packages that could be ran by the setup batch file. As for HTTPS; I'm all for it. That's a fantastic idea and I love it. And having JSON would, of course, be epic. Especially since it would work hand-in-hand with HTTPS. Maybe even some sort of deserializer to turn JSON objects into TYPEs. But that would be difficult, I'm sure.