3 ms·
Any BASIC which lacks user-defined named subroutines (i.e. real functions, not DEF FN) is a terrible language (compared to available alternatives), especially f
by teddyh 3y ago
Any BASIC which lacks user-defined named subroutines (i.e. real functions, not DEF FN) is a terrible language (compared to available alternatives), especially for beginners:
<https://news.ycombinator.com/item?id=35220605 https://news.ycombinator.com/item?id=35220605>
I wrote BASIC code in the 1980s; both games and utility software. It is precisely because I did those things that I object to any BASIC lacking functions. The BASIC I used lacked functions, and I remember it being very difficult to do what I can now call abstractions and subroutines. This would have been vastly more easy if the BASIC I used had had user-defined proper functions.
- lproven 3y agoA subroutine isn't the same as a function. Functions return a value, and can be used by name in an assignment operation. Subroutines are not interchangeable with them and are traditionally called by line number, and lack local variables. It sounds to me like what you are referring to are procedures: named blocks of code that can accept parameters, manipulate them in local variables, and thus can call themselves, enabling recursion. If that's what you meant, I agree. I owned a few (ZX Spectrum Beta BASIC, Sam Coupe SAM BASIC, and BBC BASIC V) and it makes much clearer code very easy.
- teddyh 3y agoIt doesn’t matter what you call them, since the BASIC people seem to have such fond memories of does not have any of them as a construct in the language. What I would like, no matter what they’re called, is anything which would allow easier methods of creating abstractions.
- lproven 3y agoIt does matter, very much. Firstly, because you are so lazy and inconsistent with your terminology, it's not possible to determine what your real meaning is. Secondly, because you are muddling up separate and different terms "function", "subroutine" and not using the correct term "procedure", you are missing the core point that even simple BASICs had subroutines. 0/10, try again. Learn the right words and use them correctly.
- ikari_pl 3y agoI agree, partially. It's a terrible language to solve complex problems with, because of the reasons you mentioned. In the article, I mentioned trying to do Advent of Code in it, and at some point the loops through strings, and GOSUBs started to obscure what I'm actually doing. But it also made it easy to learn. You got more done after learning a few keywords. With more evolved languages there's more to teach in order to make one aware what would be the preferred solution, so that they don't bang out unstructured code forever. The same lack of features makes it quick to grasp. Most of the keywords have a specific functionality, only a few actually "structure" the program and control the flow and the variables. It gives you the opportunity to jump straight into what you want to do. This, plus booting right into distraction-free BASIC environment within a second was a powerful combo. I believe that if someone keeps learning, they will outgrow that feature set, and prefer having functions and procedures, to hide away the complexity of some operations. But you could start learning even doing BASIC-level coding in, for example, Python, and use the more advanced constructs later on. It's one of the languages where a tutorial wouldn't have to start with a "let's ignore what public static class Main public static void main means for now".