5 ms·

From my experience back when I was 12: once you get ambitious enough in QBasic, you start to wish for some way of organizing the code and making it easier to fo

From my experience back when I was 12: once you get ambitious enough in QBasic, you start to wish for some way of organizing the code and making it easier to follow. At that point, an intro to structured programming or OOP is natural. (Probably not functional programming, though, since functional's not very good for games, and what else do you think QBasic is going to be used for?)

bduerst 10y ago
I was in the same boat at that age. I was trying to build a text-based BassTour clone in QBasic, and the book my dad bought from Radioshack didn't get into OOP. It would have made it much easier to do than that static-state version I cobbled together.
- wj 10y ago
  I would love to see that if you did built it.
epsylon 10y ago
QBasic supports subroutines (called SUB for procedures and FUNCTION for functions). You can write very structured code with QBasic; pretty much the only thing it lacks is pointers, but it's a very capable language otherwise.
- pc2g4d 10y ago
  GOSUB got me pretty far!
- exDM69 10y ago
  > pretty much the only thing it lacks is pointers, but it's a very capable... You can PEEK and POKE arbitrary memory addresses and use CALL ABSOLUTE to call assembly shell code at any address. I remember typing out a mouse driver shell code in hexadecimal from a magazine. QBasic does not have built in mouse routines and the young me was baffled when you could make that happen with a long string of digits.
- exDM69 10y ago
  > pretty much the only thing it lacks is pointers, but it's a very capable... You can PEEK and POKE arbitrary memory addresses and use CALL ABSOLUTE to call assembly shell code at any address. I remember typing out a mouse driver shell code in hexadecimal from a magazine. QBasic does not have built in mouse routines and the young me was baffled when you could make that happen with a long string of digits.
ef4 10y ago
> you start to wish for some way of organizing the code Yes, this is a critical and valuable step in learning. You can't easily learn the solution until you've encountered the problem.
elijahparker 10y ago
I learned programming in QBasic when I was 12, wrote thousands of lines creating a Windows 3.1 style GUI complete with a help file reader that included hyperlinks. For me the limiting factor wasn't organization -- functions and subs worked well (and I loved the byref and byval parameter definitions). The real limit was speed, which drove me to learn C and was amazed that everything I wrote appeared to execute instantly compared to QBasic
jlg23 10y ago
> Probably not functional programming, though, since functional's not very good for games Can you elaborate on that? People have actually written games in FP languages ([1], [2]). [1] http://www.cliki.net/game http://www.cliki.net/game [2] https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
- rtpg 10y ago
  I think this isn't that FP languages themselves are not good for programming games, but that the languages don't really bring much more to the table. Even when writing games in C, you end up writing many things in a very functional way by default. You have some state variables, and on every tick you advance things around in a very defined fashion, and redraw the screen. The "default" pattern for making games is so close to functional languages already that the only thing moving to purely functional languages gives you is a tutorial on State monads. In a way, this is a way of saying that functional languages are good for games, though... meanwhile, OOP-style tools are extremely useful in games, because you often find yourself working with Entities with a lot of shared behaviour. The abstraction maps well to the concrete structure of a game. Going to an FP-language will often cause you to sacrifice many OOP-centric language niceties without bringing much to the table to replace those niceties. In game programming, I think the tradeoff is much harder to justify than in other domains.
  - eru 10y ago
    Once the Haskell people have figured out lenses properly, you can have all your OOP niceties (that anyone actually cares about).
    - deleted 10y ago
      [deleted]
    - clock_tower 10y ago
      We've already got those niceties (including the ones that you don't care about), and we get them without having to learn Haskell's enormous universe of exotic terminology. How do we get them? We don't use Haskell.

bduerst 10y ago

I was in the same boat at that age. I was trying to build a text-based BassTour clone in QBasic, and the book my dad bought from Radioshack didn't get into OOP. It would have made it much easier to do than that static-state version I cobbled together.

wj 10y ago
I would love to see that if you did built it.

epsylon 10y ago

QBasic supports subroutines (called SUB for procedures and FUNCTION for functions). You can write very structured code with QBasic; pretty much the only thing it lacks is pointers, but it's a very capable language otherwise.

pc2g4d 10y ago
GOSUB got me pretty far!
exDM69 10y ago
> pretty much the only thing it lacks is pointers, but it's a very capable... You can PEEK and POKE arbitrary memory addresses and use CALL ABSOLUTE to call assembly shell code at any address. I remember typing out a mouse driver shell code in hexadecimal from a magazine. QBasic does not have built in mouse routines and the young me was baffled when you could make that happen with a long string of digits.
exDM69 10y ago
> pretty much the only thing it lacks is pointers, but it's a very capable... You can PEEK and POKE arbitrary memory addresses and use CALL ABSOLUTE to call assembly shell code at any address. I remember typing out a mouse driver shell code in hexadecimal from a magazine. QBasic does not have built in mouse routines and the young me was baffled when you could make that happen with a long string of digits.

ef4 10y ago

> you start to wish for some way of organizing the code Yes, this is a critical and valuable step in learning. You can't easily learn the solution until you've encountered the problem.

elijahparker 10y ago

I learned programming in QBasic when I was 12, wrote thousands of lines creating a Windows 3.1 style GUI complete with a help file reader that included hyperlinks. For me the limiting factor wasn't organization -- functions and subs worked well (and I loved the byref and byval parameter definitions). The real limit was speed, which drove me to learn C and was amazed that everything I wrote appeared to execute instantly compared to QBasic

jlg23 10y ago

> Probably not functional programming, though, since functional's not very good for games Can you elaborate on that? People have actually written games in FP languages ([1], [2]). [1] http://www.cliki.net/game http://www.cliki.net/game [2] https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

rtpg 10y ago
I think this isn't that FP languages themselves are not good for programming games, but that the languages don't really bring much more to the table. Even when writing games in C, you end up writing many things in a very functional way by default. You have some state variables, and on every tick you advance things around in a very defined fashion, and redraw the screen. The "default" pattern for making games is so close to functional languages already that the only thing moving to purely functional languages gives you is a tutorial on State monads. In a way, this is a way of saying that functional languages are good for games, though... meanwhile, OOP-style tools are extremely useful in games, because you often find yourself working with Entities with a lot of shared behaviour. The abstraction maps well to the concrete structure of a game. Going to an FP-language will often cause you to sacrifice many OOP-centric language niceties without bringing much to the table to replace those niceties. In game programming, I think the tradeoff is much harder to justify than in other domains.
- eru 10y ago
  Once the Haskell people have figured out lenses properly, you can have all your OOP niceties (that anyone actually cares about).
  - deleted 10y ago
    [deleted]
  - clock_tower 10y ago
    We've already got those niceties (including the ones that you don't care about), and we get them without having to learn Haskell's enormous universe of exotic terminology. How do we get them? We don't use Haskell.