Calling all programmers for IntyBASIC SDK contributions!

[+DZ-Jay]

I'm preparing a new version of the IntyBASIC SDK to be released next month and I am looking for samples and contributions to include in the next distribution.

 

As before, the IntyBASIC SDK will include the latest version the IntyBASIC compiler, as1600 assembler, and jzIntv emulator; along with the same set of samples and contributions included with the base IntyBASIC distribution from nanochess. On top of that, any programmers out there who wish to donate sample code, full games, or utility libraries are welcomed to submit their IntyBASIC source for inclusion as well.

 

I also aim to complete and release the IntyBASIC SDK for Macintosh, which has been in the works for a long, long time.

 

Finally, if anybody has any ideas for improvements or enhancements, or anything else they wish the SDK to provide or do, just post it here.

 

The IntyBASIC SDK is by - and for - the Intellivision programming community; I just do the dirty job of putting it together.

 

-dZ.

Edited August 12, 2018 by DZ-Jay

[+DZ-Jay]

Quick question: Should the SDK default to enabling "Option Explicit" on new projects to force all variables to be defined with "Dim"?

[+nanochess]

Quick question: Should the SDK default to enabling "Option Explicit" on new projects to force all variables to be defined with "Dim"?

As a professional programmer that doesn't want bugs in his programs, I would say: Yes.

 

But thinking in novice programmers that want to make everything work fast and never used C or Pascal, I would say: No.

[+DZ-Jay]

As a professional programmer that doesn't want bugs in his programs, I would say: Yes.

 

But thinking in novice programmers that want to make everything work fast and never used C or Pascal, I would say: No.

 

Well, I personally was thinking that "Option Explicit" helps the newbie more than the professional programmer, because it forces them to do things the right way. The professional programmer supposedly knows what he is doing and is free to remove restrictions at his own risk.

 

In my mind, it's not only important to help the programmer get up and running as quickly as possible, but also to help him follow correct conventions and patterns.

 

Now, the question is: Is the requirement of variable declarations something we consider the "proper and correct way" for IntyBASIC? That's a question for both you (as the language designer) and the community in general (as the promoters and beneficiaries of the IntyBASIC culture).

 

-dZ.

[+nanochess]

Now, the question is: Is the requirement of variable declarations something we consider the "proper and correct way" for IntyBASIC? That's a question for both you (as the language designer) and the community in general (as the promoters and beneficiaries of the IntyBASIC culture).

 

-dZ.

Nothing in IntyBASIC is the "proper and correct way", I leave free the style of development because I think every rule (or complication) simply move away beginners.

 

I would say more like "suggested" with a list of known advantages:

 

* All variables listed.

* A reminder of variables that could be uninitialized.

* A way to see what variables could be optimized out.

* Putting all DIM together manually allows to separate visually the variables used in each module.

[JosueCom]

I am working on a new game right now. I am trying new things that I didn't do in my first game, such as music, physics vector and more complex animation. I am going to try to post it before the end of the month and it would be great if it is in the next sdk.

[fsuinnc]

if it's not already included. I suggest the acceleration example from Intvnut found here: http://atariage.com/forums/topic/275183-intybasic-accelerationvelocity-demo/

 

I found/find it a great example of movement and acceleration and also I like the way it decodes the controller directions (even though I don't think I understand it completly.

 

I think this was the last version posted:accel.zip

 

If possible, I would like it if the SDK could make it easier to install new versions of IntyBASIC and jzintv. (It might just seem a bit difficult because I'm not too smart. )

[+DZ-Jay]

if it's not already included. I suggest the acceleration example from Intvnut found here: http://atariage.com/forums/topic/275183-intybasic-accelerationvelocity-demo/

 

I found/find it a great example of movement and acceleration and also I like the way it decodes the controller directions (even though I don't think I understand it completly.

 

I think this was the last version posted:accel.zip

 

If possible, I would like it if the SDK could make it easier to install new versions of IntyBASIC and jzintv. (It might just seem a bit difficult because I'm not too smart. )

 

Well, ideally, the SDK would be updated after every major release...

[+DZ-Jay]

Nothing in IntyBASIC is the "proper and correct way", I leave free the style of development because I think every rule (or complication) simply move away beginners.

 

With all due respect, in my opinion, what scares away beginners is the so-called "tyranny of choice" and the arcane and inscrutable way of accessing the tools.

 

It's why people clamour for an IDE and an SDK.

 

Just because you want to program games does not mean you are comfortable using the command line and figuring out everything yourself from first principles.

 

I would say more like "suggested" with a list of known advantages:

 

* All variables listed.

* A reminder of variables that could be uninitialized.

* A way to see what variables could be optimized out.

* Putting all DIM together manually allows to separate visually the variables used in each module.

 

I agree with all that, and in my opinion, we have an opportunity with the SDK to guide burgeoning programmers in the right direction and help them find their way. It's not a matter of style so much as it's a matter of giving them the tools to succeed. Style comes with experience and personal preference, but it is more productive to start with some foundation -- any foundation -- on which to build your own experience. (It is typical to copy your teacher until you figure out what works best for yourself.)

 

Personally, I would recommend that the SDK defaulted to including "Option Explicit," with an option to avoid it (sort of like it defaults to include a Mattel-style title screen but allows you to disable it). I also propose to include a short document on helpful tips on writing code. This could include not only recommendations of putting all DIM variable definitions together, but also promote the use of modular libraries with "INCLUDE," and the use of GOSUB over GOTO, etc.

 

I'm trying to do what's best for the community and to attract more programmers. Veterans can ignore all that and do whatever they please -- that has been, and will always be, the case.

 

What do you think?

 

-dZ.

Edited August 21, 2018 by DZ-Jay

[+DZ-Jay]

I am working on a new game right now. I am trying new things that I didn't do in my first game, such as music, physics vector and more complex animation. I am going to try to post it before the end of the month and it would be great if it is in the next sdk.

 

Sure! Any contributions from the community are welcomed. Also if you have ideas for improvement of the tools (or new tools), please provide them and I'll see if I can include them as well.

 

Thanks!

-dZ.

[+nanochess]

With all due respect, in my opinion, what scares away beginners is the so-called "tyranny of choice" and the arcane and inscrutable way of accessing the tools.

 

It's why people clamour for an IDE and an SDK.

 

Just because you want to program games does not mean you are comfortable using the command line and figuring out everything yourself from first principles.

Mostly people doesn't want to mess with command-line and I don't believe in the Tiranny of Choice. Although I'm surprised today with children in school age feeded with a little info start saying "my head is going to explode".

 

I agree with all that, and in my opinion, we have an opportunity with the SDK to guide burgeoning programmers in the right direction and help them find their way. It's not a matter of style so much as it's a matter of giving them the tools to succeed. Style comes with experience and personal preference, but it is more productive to start with some foundation -- any foundation -- on which to build your own experience. (It is typical to copy your teacher until you figure out what works best for yourself.)

 

Personally, I would recommend that the SDK defaulted to including "Option Explicit," with an option to avoid it (sort of like it defaults to include a Mattel-style title screen but allows you to disable it). I also propose to include a short document on helpful tips on writing code. This could include not only recommendations of putting all DIM variable definitions together, but also promote the use of modular libraries with "INCLUDE," and the use of GOSUB over GOTO, etc.

My recommendation is to NOT default to include "Option Explicit"

 

I'm trying to do what's best for the community and to attract more programmers. Veterans can ignore all that and do whatever they please -- that has been, and will always be, the case.

 

What do you think?

 

-dZ.

Why I say this if both you and me know that's a good programming practice?

 

Because beginners should be able to code very fast without worrying about if declaring a variable. It isn't a "normal" thing, you don't come to the school with a previous declaration "I'm going to study", you don't enter a restaurant announcing you're going to eat.

 

It's normal only for programmers that have worked with C and Pascal. So my decision is no, no default OPTION EXPLICIT.

[+DZ-Jay]

Mostly people doesn't want to mess with command-line and I don't believe in the Tiranny of Choice. Although I'm surprised today with children in school age feeded with a little info start saying "my head is going to explode".

 

 

My recommendation is to NOT default to include "Option Explicit"

 

 

Why I say this if both you and me know that's a good programming practice?

 

Because beginners should be able to code very fast without worrying about if declaring a variable. It isn't a "normal" thing, you don't come to the school with a previous declaration "I'm going to study", you don't enter a restaurant announcing you're going to eat.

 

It's normal only for programmers that have worked with C and Pascal. So my decision is no, no default OPTION EXPLICIT.

Your decision? I think you mean your recommendation.

 

I also would like to hear what others have to say, especially novices.

 

dZ.

[+nanochess]

Your decision? I think you mean your recommendation.

 

I also would like to hear what others have to say, especially novices.

 

dZ.

Hehe, it's because I've been asked two times, the first time is a recommendation, the second time is a decision

[+DZ-Jay]

Hehe, it's because I've been asked two times, the first time is a recommendation, the second time is a decision

OK. Your feedback is noted, thanks. Anybody else?

[intvnut]

It's normal only for programmers that have worked with C and Pascal. So my decision is no, no default OPTION EXPLICIT.

 

I'd strongly recommend OPTION EXPLICIT to anyone writing a serious game, in the same way I'd recommend use warnings; use strict; to someone writing a Perl script that's more than a few dozen lines. It's good software engineering, and will help you scale up from quick demo to big game. It just gets in the way, though, for anything short and quick. (Perl is like IntyBASIC here: By default, you can just start using a variable. With strict turned on, you need to declare everything before use.)

 

We're not training software engineers. There's something to be said for the shallow on-ramp, and a short throw from opening an editor to getting stuff up on the screen. OPTION EXPLICIT is available when you're ready for it, if you want it, when it's time to scale up.

 

This is BASIC, not Pascal, after all. You know, the language that Edsger Dijkstra once complained about: "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." Unsurprisingly, Dijkstra was a much bigger fan of Pascal. ;)

[+DZ-Jay]

 

I'd strongly recommend OPTION EXPLICIT to anyone writing a serious game, in the same way I'd recommend use warnings; use strict; to someone writing a Perl script that's more than a few dozen lines. It's good software engineering, and will help you scale up from quick demo to big game. It just gets in the way, though, for anything short and quick. (Perl is like IntyBASIC here: By default, you can just start using a variable. With strict turned on, you need to declare everything before use.)

 

We're not training software engineers. There's something to be said for the shallow on-ramp, and a short throw from opening an editor to getting stuff up on the screen. OPTION EXPLICIT is available when you're ready for it, if you want it, when it's time to scale up.

 

This is BASIC, not Pascal, after all. You know, the language that Edsger Dijkstra once complained about: "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." Unsurprisingly, Dijkstra was a much bigger fan of Pascal. ;)

So... TL;DR: You vote for not/i] setting it as default in the SDK "new project" file..?

[intvnut]

 

So... TL;DR: You vote for not/i] setting it as default in the SDK "new project" file..?

 

I can see both sides of the argument, and think it's fine to not default to OPTION EXPLICIT.

 

If you auto-populate an empty BASIC project, maybe add a bunch of items in comments at the top saying "Uncomment these when you're ready for them." For example, ASM CFG_VAR lines to set title, author, etc.

 

BTW, a quick question for nanochess: Will IntyBASIC 1.4 finally allow you to set your game title from within the BAS file, or will it remain solely a command-line option?

[+DZ-Jay]

I can see both sides of the argument, and think it's fine to not default to OPTION EXPLICIT.

 

I'm good either way, I just think that adding it automatically in the "new project" file will lead new programmers in the right direction. It will not have any effect on veterans since they can disable it from the command line.

 

I can see why it could get in the way of a "quick-and-dirty" program, but is that the actual common use case of the IntyBASIC SDK?

 

If it is, perhaps it's worth separating a "New Project" from a new "toy" quick and dirty program. I don't know.

 

If you auto-populate an empty BASIC project, maybe add a bunch of items in comments at the top saying "Uncomment these when you're ready for them." For example, ASM CFG_VAR lines to set title, author, etc.

 

The "New Project" file comes with an include to the Constants.bas library, and another to a default Mattel-style title screen, auto-generated with the name of the program, author, and copyright year.

 

The "include" for the constants is expected to be used, so it stays. The one for the title screen, is preceded by a comment stating to remove it if the programmer has his own title sequence.

 

I was planning of including the "Option Explicit" at the top with a comment saying to comment the line to avoid strict variable declaration requirement (worded better, of course). Also add a command line option to the "INTYNEW" command that suppresses the "Option Explicit" for those power users.

 

I guess I could add the "Option Explicit" commented by default, with a comment as you suggest. I'll think about it.

 

dZ.

[+DZ-Jay]

Oh, and forgot to say that it does include the CFG_VARS as well.