To me, more expressive power is always better. Being able to do something with less code not only producess less bugs (less code = less bugs), but also write code faster. Of course, balancing those features with making the language easy to learn is always tricky. In the case of default arguements though I wouldn't say it makes it harder to learn, considering 99% of popular programming languages out there implement those.
SFSW wrote: "(consider you have 9 elements with separate stop/start points all in a single line in your example)."
Funny, this is the first time I see someone argue against default attributes
May I ask what other languages besides AppGameKit do you use?
Anyways, I agree the list can get long, but:
a) A long argument list will suck be it with default arguments or not
b) The language already supports 9 elements argument lists
c) A function with so many arguments means there's something wrong with the program's design, meaning there's an object/type hiding in there, so you can refactor the arguments into one or more types and just pass that instead
SFSW wrote: "Using more dedicated lines with vertical alignment not only helps with faster visual cueing, but can also aid in error reporting when individual lines containing specific values/commands can be pinned down much more specifically. "
Also manually writing more code has a chance to introduce more bugs, and clutter the program with irrelevant, repetitive data, which ends up making it harder to read, especially when reading other person's code.
SFSW wrote: "Not quite sure yet what the benefits of an approach like that might be over others. There should currently be a couple of different ways to achieve the same thing, perhaps even easier in some regards. But I'll ponder what advantages that specific approach might have over other methods currently available in AppGameKit using its existing string search, type, and function capabilities with minimal layers and interdependencies."
Basically you get most benefits of
functional programming! You can write code which is easy to test, extend, reuse, and decoupled from the rest of the logic.
A classic example:
type person
name as string
age as integer
endtype
function greet(person)
Log("Hello, " + person.name)
endfunction
dim people[3] as person = ... // an array of person types
// Now, the previous example was able to just find by name. What if I want to find by age instead?
// I instead receive a filter function and call that to test each element in the array
function find(collection as person[], filter ref as function, callback ref as function) {
for i = 0 to collection.length
// here I just call the given function
if filter(collection[i]) then callback(collection[i])
next i
endfunction
// Now I can write as many filters as I want
function byName(name as string) // this function takes one argument, a name, and returns another function
function filter(person as person) // this other function takes a person, and compares the name, returning 1 if it maches, 0 otherwise
result = 0
if person.name = name then result = 1
endfunction
endfunction filter // here I return the filter function, so it's important to be able to take functions as arguments and return them from functions as well
function byAge(age as integer) // similar as above, comparing age instead
function filter(person as person)
result = 0
if person.age = age then result = 1
endfunction
endfunction filter
function olderThan(age as integer) // just one more example
function filter(person as person)
result = 0
if person.age > age then result = 1
endfunction
endfunction filter
// Now because my functions are so generic, I can make a lot of filters (on the fly!) and save up a lot of code
find(people, byName('Mike'), greet) // find by name
find(people, byAge(18), greet) // find by age
find(people, olderThan(21), greet) // older than
// alternative syntax
namedMike = byName('Mike')
find(people, namedMike, greet)
The benefit of that approach is that any filter function will work with any of my filters, so if your system is designed that way, you can reuse a lot of code. An example of this in real apps is JavaScript's
reduce,
map, and
filter, just to name a few.
Also, you can write callback-oriented code which is great for user interfaces, although it's known it can lead to
callback hell, that is just bad code and it can be easily managed with proper refactoring.
Now, I know there's no way this is comming to AppGameKit but just wanted to show you how functional programming can make some crazy generic things and reduce interdependencies in your code
SFSW wrote: "Another possibility for you might be to utilize Tier2 as that may align better with your objectives and methods."
Yeah, Tier 2 seems like the way to go for "advanced" usage, but I'm just not a C/C++ guy. Anyways, it's good to know there's that option if everything else fails
