<< Previous TopicReturn to Index  

Higher-order functions

December 27 2017 at 12:57 AM
Anonymous  (Login goat314)

 
Procedures are, in effect, abstractions that describe compound operations on numbers independent of the particular numbers.

Often the same programming pattern will be used with a number of different procedures. To express such patterns as concepts, we will need to construct procedures that can accept procedures as arguments or return procedures as values. Procedures that manipulate procedures are called higher-order procedures.

QBASIC doesn't have them, Python does. Consider for example, a numeric integration function. In QBASIC, you would have to copy-paste the code for all the functions you want to integrate, write your own parser and pass the function as a string, or write the function you want to integrate in assembly, then pass the address and call it with CALL ABSOLUTE. (You could also use another representation instead of a string, like using an array to store a syntax tree using indices, or writing assembly for a virtual machine you made up). Same for summation with an index. In any case, this is much more complicated than Python where you could just pass the function you want to integrate.

In writing an interpreter you would also need a bunch of IF statements when trying to call a library procedure rather than just having an array of function pointers and calling the appropriate one.

Of course the downside is that some people think functions as arguments are hard to understand. You could of course just not use them, but if you go to FreeBASIC.net you can see that a lot of people write code that uses pointers when you could just as easily use array indices.
Do you think this feature makes it harder for beginners? Oh, and you can also pass functions as parameters in C Pascal, and FORTRAN.

But they aren't in Java so you have to wrap everything in an object. Which actually makes you code harder to understand.


 
 Respond to this message   
AuthorReply
easylangs
(Login easylangs)
R

advanced features vs easy features

December 27 2017, 2:25 AM 

im not against a language having advanced features. higher-order functions are an advanced feature. the only use of higher-order functions i know of is closures. the only use of closures i know of is capturing variables and simulating (or creating) objects or object-like features.

i currently have no use for that. i have never thought of a use for that. its a big deal to people who like closures. cool.

in general i prefer easy features, but im not against advanced features:

The eight design principles of BASIC were:

-> Be easy for beginners to use <-
Be a general-purpose language
-> Allow advanced features to be added for experts (while keeping the language simple for beginners) <-
Be interactive
Provide clear and friendly error messages
Respond fast for small programs
Not require an understanding of computer hardware
Shield the user from the operating system


i believe these are great principles, whether they are followed or abandoned, sort of like the way i think the constitution (with the amendments) is a good charter, even if people dont follow it.

"be easy for beginners to use" is the first design principle. i think thats a good one to start with. its the foundation.

and then just to be clear it says it again in #3, but with an additional note:

advanced features are ok, (so long as they dont turn the language into something obtuse, tedious and difficult.)


its not whether or not you have the features-- its what they do to the language.


i mostly think that depends largely on the community.


if the community believes in the benefit of commands that are easy for beginners, and they dont just think "we offer an easy language and then expect everyone to sort of use it as an advanced language later"

why? *why expect anyone to use basic as an advanced language?* why (for instance) deprecate the things that make it basic? why discourage such features?


there is merit in easy-to-use features and there is merit in advanced features.


basic can include both. but i personally think to make that work, you have to have a community that understands the merit of the easier, simpler commands.

not everyone wants advanced features, and not everyone uses basic because they want to become a language expert.

i think its very safe to say that some people use basic specfically because they do NOT want to become a language expert.

and i think thats fine. but i also think not everyone understands that.

there are lots of advanced languages. i dont think basic should ever cater too heavily to that-- so long as it balances out, advanced features are fine if the community understands why basic was written in the first place.

you add advanced features to basic with the understanding (hopefully) that not everyone is going to need or want them. freebasic spent a few years not quite entirely getting that very simple idea. but i also think they figured it out eventually. for a few years at least, it felt very bait-and-switchy and very ego-driven, not what i would call friendly. but again, i think its fine now.


i also think that qb64 showed fb how to do it "right." fvso of right, but i think qb64 had an unmistakable triumph in that regard, at the time.

i dont believe there will ever be a language truer to qbasic than qb64 was.

is? that depends (imo) on the things ive said here. in other peoples opinions? it will only get better. perhaps theyre right. "better" isnt very specific though.


i believe (and hope) this answers your question, but i think it answers what you were asking and also what you were getting at. hopefully, anyway.


    
This message has been edited by easylangs on Dec 27, 2017 2:29 AM


 
 Respond to this message   
 
  << Previous TopicReturn to Index  
 Copyright © 1999-2018 Network54. All rights reserved.   Terms of Use   Privacy Statement