Author Topic: Graphical IDE. Should we all pitch in and make one?  (Read 30008 times)

0 Members and 1 Guest are viewing this topic.

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: Graphical IDE. Should we all pitch in and make one?
« Reply #15 on: September 19, 2018, 12:35:47 pm »
My personal wish list includes:
(...)
Better multi-assignment(it exists, but it's weak) e.g. a=b=4 where a=4 and b=4
Gyotdang += and -= operators, and ++/--(Which would give rise to the need for the == operator... I know, right?)

Just to clear it up: a = b = 4 isn't a multiassignment in BASIC. If b = 4 then a = -1 in this case.

It's like you're making a conditional check:

a = (is b equal to 4? if true, the result is -1; if false, the result is 0)

And about ++ and -- as operators, I wouldn't hold my breath.

Are you certain?   Don't we evaluate left to right in these cases?

A = B = 4 would be more (A = B) = 4 than A = (B = 4), wouldn't it?

(A = B) = 4 is *ALWAYS* going to be 0.
A = (B = 4) may be 0 or -1, depending on values of A and B.

Or am I wrong??  Either way, if one wants to write such code, they should *always* use parentheses to make certain it works as they're intending, and to improve readability.  :)
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

FellippeHeitor

  • Guest
Re: Graphical IDE. Should we all pitch in and make one?
« Reply #16 on: September 19, 2018, 12:43:39 pm »
I'm certain in that we're discussing assignments.

You can't type (A = B) = 4 in a line, as that's not an assignment. That's only valid if it's in an IF statement or equivalent, which is not our case here.

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: Graphical IDE. Should we all pitch in and make one?
« Reply #17 on: September 19, 2018, 12:54:38 pm »
I'm certain in that we're discussing assignments.

You can't type (A = B) = 4 in a line, as that's not an assignment. That's only valid if it's in an IF statement or equivalent, which is not our case here.

You're right, which is why I still stick by the theory that you should *always* use parentheses when dealing with multiple = signs.

A = B = 4 assigns a value to A just as you described.   PRINT A = B = 4 is a completely different case, as I was thinking above.

I still contend however, that A =(B =4) is easier to read and eliminates any confusion -- at least, for me, it definitely is.  :)
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline Bert22306

  • Forum Regular
  • Posts: 206
    • View Profile
Re: Graphical IDE. Should we all pitch in and make one?
« Reply #18 on: September 19, 2018, 04:30:01 pm »
As long as we're all giving our personal preferences for the IDE, I'm quite happy with the one we have now, including with the ability to scroll down to the subs more easily than in the MS QB days. But I would not be against an IDE that keeps the same look wrt the code itself, but in a more Windows-like presentation otherwise.

One caveat, though. It really helps me that QB64 makes no changes to the Windows registry. So for my own use, anything that involves registry changes would create problems, in the PC I use for my day job anyway. To me, no registry changes is a "feature."

FellippeHeitor

  • Guest
Re: Graphical IDE. Should we all pitch in and make one?
« Reply #19 on: September 19, 2018, 04:42:56 pm »
I agree that being portable is a great plus to QB64's account.

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: Graphical IDE. Should we all pitch in and make one?
« Reply #20 on: September 19, 2018, 06:13:23 pm »
Kids can easily write Hello World programs with modern devices:

 
Code: QB64: [Select]
  1. <html>
  2. <header><title>This is title</title></header>
  3. <body>
  4. Hello world
  5. </body>
  6. </html>

A new IDE won't make QB64 run better, faster, or be easier to learn.  How it compiles and what folks are using it for; that's what's important.  ;)
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline Omerta7486

  • Newbie
  • Posts: 33
  • √𝜋²
    • View Profile
Re: Graphical IDE. Should we all pitch in and make one?
« Reply #21 on: September 19, 2018, 07:51:01 pm »
I agree with Steve. If you needed a fast car, which would you buy? A) A 2018 Bugatti Chiron that someone managed to slap a 200HP V4 Honda engine in. B) A beat up, rusty but fully working 1976 Ford Mustang II hatchback that someone hooked up to a 1,500HP 16 cylinder supercharger. I know these scenarios are wildly improbable, but it mirrors this situation perfectly.

For instance, I've known programmers who almost only use Notepad++ to code in C++. I've personally used Notepad++ for CSS and HTML pretty extensively. I think rather than focusing on what QB64 could do, or how it could look, we need to show as a community what it can do. Instead of just sharing stuff around the forum, our best work needs to hit the rest of the internet. I, for one, plan to release Omertris into the wilds of the web once I finish it. It's playable, it's clean, and everyone that's played the current version agrees that it's darn fun, and that's what matters.

QB64 is a pretty simple to pick up language, and while it's not too hot with 3D, it's great for small 2D apps. Card games, dice games, platformers, puzzlers, shoot 'em ups, RPGs. The IDE is good enough, as in it's not the BEST per se, but it doesn't hinder us all that much. What does hinder us some, however, is it's weak support for com ports and DLLs, somewhat broken bit level commands and Boolean variables, okay user defined types, and barely passable access to control over keyboards, mice, and devices(face it, we often have to jury rig complex control schemes).

If we could fix the com ports and DLLs, then the language could drastically grow with the user. Those that learn C could then help expand the community by providing more growth in the language. That's one thing I liked about DarkBASIC(RIP). There were a multitude of DLLs, and once the user got comfortable with the native command set, they could then download community created command sets to craft the language into what they needed.
The knowledge that's seeking the favor of another means the murder of self.

Latest version of my game, here  Omertris: Invasion

Offline TerryRitchie

  • Seasoned Forum Regular
  • Posts: 495
  • Semper Fidelis
    • View Profile
Re: Graphical IDE. Should we all pitch in and make one?
« Reply #22 on: September 19, 2018, 08:03:30 pm »
I believe the most popular languages have the simplest of IDEs. Look at Python's IDLE, acts pretty much the same way as QB64's IDE. Granted, it's written using a true OS graphics screen, but it's still basically text and nothing else.

The true strength of any language is what you can do with that language, not what the interface looks like in my opinion. The interface does need to be usable however, I agree with that, something I think the QB64 IDE does a great job of providing.

I've programmed in a great many languages over the years and the only one I truly disliked was Visual Basic. It wasn't because of the language but due to the interface. It was feature overload. Then came the abomination .NET, but that's another story.

The best way to get QB64 noticed is to start writing some great software with it and get it into the hands of people. There was a game written in QB64 some years back that garnered a LOT of press: https://www.pcworld.com/article/2033318/black-annex-is-the-best-qbasic-game-youve-ever-seen.html
Another popular game (in France I believe) written in QB64 was Papi Commando.

That momentum died out because no one followed up with more great software with QB64 (me included unfortunately).

Edit: I wrote this while Omerta was writing his reply and as you can see he's generally saying the same thing. I loved DarkBasic to the point where I even bought the full package back in 2005. That was a cool version of BASIC.
« Last Edit: September 19, 2018, 08:20:31 pm by TerryRitchie »
In order to understand recursion, one must first understand recursion.

Offline TerryRitchie

  • Seasoned Forum Regular
  • Posts: 495
  • Semper Fidelis
    • View Profile
Re: Graphical IDE. Should we all pitch in and make one?
« Reply #23 on: September 19, 2018, 08:31:33 pm »
If we could fix the com ports

This needs to be fixed, I agree! We could make a huge impact on the microcontroller (Arduino, Raspberry Pi, Beagle Bone, etc..) arena if QB64 could interface with these easily. Arduino uses a simplified version of C and with Raspberry Pi the best option right now is Python. Many people I introduce the Arduino to by showing them the cool things I do with them are beyond excited, until they see and start using the language.

MicroPython has been developed for the Arduino to help new comers with programming in an easier environment, but it's still a steep learning curve.

Parallax's Basic Stamp uses a flavor of basic called pBasic that is very easy to use. The problem is Basic Stamp is not open source hardware/software so it gains no traction.

Get QB64 working with microcontrollers and I believe the kick in the ASCII QB64 needs will happen.

If we want to band together on a project I believe USB and COM port development would be something to finally tackle and conquer.

I would be more than happy (ecstatic actually) for the opportunity to write libraries to interface with microcontroller circuits.
« Last Edit: September 19, 2018, 08:35:42 pm by TerryRitchie »
In order to understand recursion, one must first understand recursion.

Offline Cobalt

  • QB64 Developer
  • Forum Resident
  • Posts: 878
  • At 60 I become highly radioactive!
    • View Profile
Re: Graphical IDE. Should we all pitch in and make one?
« Reply #24 on: September 19, 2018, 09:25:55 pm »
whats wrong with the com port? I use it with my robotics interface all the time. input and output. serial cable or usb cable.
Granted after becoming radioactive I only have a half-life!

Offline TerryRitchie

  • Seasoned Forum Regular
  • Posts: 495
  • Semper Fidelis
    • View Profile
Re: Graphical IDE. Should we all pitch in and make one?
« Reply #25 on: September 19, 2018, 10:14:43 pm »
Which version of QB64? SDL?
In order to understand recursion, one must first understand recursion.

Offline cr0sh

  • Newbie
  • Posts: 10
    • View Profile
Re: Graphical IDE. Should we all pitch in and make one?
« Reply #26 on: September 20, 2018, 01:51:55 am »
Instead of just sharing stuff around the forum, our best work needs to hit the rest of the internet.

What could have been that example was called "Black Annex" - it was even greenlit for Steam, everyone was talking about it - and then...nothing. It seemed like the developer fell off the face of the planet.

That's not entirely true - he was still active on twitter, but never really seemed to answer anything in regards to that game. It seems crazy; he worked long and hard to develop that game, a single man effort over years. He got crazy press about it, and managed to get on Steam and greenlit to go. Then - poof. He stopped talking about it, working on it, I don't know what.

It's one of the strangest things I've ever witnessed on the internet...

Offline cr0sh

  • Newbie
  • Posts: 10
    • View Profile
Re: Graphical IDE. Should we all pitch in and make one?
« Reply #27 on: September 20, 2018, 02:00:05 am »
Arduino uses a simplified version of C

The Arduino uses C (and C++) - it's not simplified, it's straight C under the hood. You can ditch the entire Arduino ecosystem and code the ATMega in C/C++ to your heart's content if you wanted to. All the system does is introduce a simple "wrapper" in main() and includes the Arduino library of functions; in main it calls "setup()" then enters an endless loop calling loop() - and that's it. Everything else is regular ole C/C++.

Now - the "standard library" isn't going to be the same as the one on a desktop or whatnot (avr-libc); it's both scaled back and includes "embedded" or "microcontroller" specific implementations of certain functions and whatnot. But even there, some things are available on certain avr microcontrollers that aren't on others (which is why the Arduino library is such a dog in certain spots, because it has a ton of if-then and other logic to check for what microcontroller it is being compiled and/or running on, as well as other checks for boundary conditions and whatnot, which all makes the code it produces not as fast as it could be - but at the same time, it is highly portable across most of the platforms the Arduino IDE supports).

Offline TerryRitchie

  • Seasoned Forum Regular
  • Posts: 495
  • Semper Fidelis
    • View Profile
Re: Graphical IDE. Should we all pitch in and make one?
« Reply #28 on: September 20, 2018, 02:49:46 am »
I thought I read somewhere it was simplified. My mistake. Perhaps I was thinking this because it only uses two functions, setup and loop, as you point out. Either way, it's a tough sell to new programmers to get them to understand C/C++ programming right from the start. Heck, just setting up a for loop looks alien as heck:

/* for loop execution */
   for( a = 10; a < 20; a = a + 1 ){
      printf("value of a: %d\n", a);
   }

even stranger

/* for loop execution */
   for( a = 10; a < 20; a++ ){
      printf("value of a: %d\n", a);
   }
« Last Edit: September 20, 2018, 02:51:49 am by TerryRitchie »
In order to understand recursion, one must first understand recursion.

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: Graphical IDE. Should we all pitch in and make one?
« Reply #29 on: September 20, 2018, 07:24:25 am »
My honest question is:  What features does a new IDE need that isn't currently supported by the current one?  And, why can't the existing IDE simply be expanded to include those features?

What we have already is written in 100% QB64, so it helps highlight what we can do.  As I illustrate with the $AUTOSAVE and $REPLACE routines, it's not too difficult to add/alter usability/customizability. 

Why not simply keep improving what we have, instead of having to start over for something completely different?
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!