there are a lot of exceptions. reading data from a socket. getting data from a sensor like a camera. accessing the real time clock.
There are ways to deal with this in a functional language either with monads or with a world type. Conceptually the goals are the same, to isolate the side effects to a small well-defined portion of the system and remove the side effects from the general purpose functional language. Use generally carries some heavy constraints but it has been proven to work and isn't really all
Yes! That's why lots of programming types read The Daily (Way To Functionally program) each day. It describes how to create a true Functional program. And very often, people in the comments improve on it and point out some Real Way To Functionally program that is mentioned in passing in the main entry.
But seriously, true functional programs have no side effects, and side effects include basically all useful results, like modifying files or interacting with the user. So functional programs are almost by
Your example is exactly what side effect [slashdot.org] is defined to exclude. A side effect is changing something -- an existing variable's value, a byte on disk, a pixel on screen, which key is "next" in the input queue -- rather than simply returning a value. Side effects are what almost everyone expects their programs to have.
That has nothing to do with the programming paradigm though. Just because the function has no side effects doesn't mean you can't change anything. The runtime - for example - might be calling your state update function in a loop, then mirroring that state to - for example - your screen.
You get all the benefits of pure functions, and state changes to the running system are managed in one place in the runtime.
You just proposed what are effectively global variables, except that you have to pass them through your entire call stack so that they can be returned as part of the new state, and you have to jump through hoops to preserve a functional programming model for any sub-functions that need much of that state.
In the case of a GUI, you would also need to write code (which you attributed to the runtime) to describe how that state gets mirrored to the screen, so you still have some non-functional-programming wrappe
When you compile code, it is no longer functional or object oriented. It is procedural spaghetti assembler code. Whatever wrapper you may have is not relevant to how you code your app, whether that be in FP, OOP, or some other paradigm.
The language is mostly functional and aimed at people who know Excel, but want to do a little more. The language is better than Visual Basic, but not as good as . [zerobugsan...faster.net]
Ah, thankyou for explaining what "a new low-code language that will become the standard for writing logic customization across Microsoft's own low-code Power Platform" is, because I'm buggered if I can tell what it is they're introducing based on the article summary.
When I read the summary somehow I read that it was a "low-power language" like it wouldn't take much battery power.
I could not figure out what a low-power language would look like. Maybe event based with interrupts? Turns out it actually is event-based (from what I can see) but definitely not low-power. It looks like a power hog.
Indeed. The language for people that have a high pain-threshold with regards to barely usable simple mechanisms, but a very low one with regards to well-designed mechanisms that need some understanding of larger concepts to use them.
I've actually always wanted to program using spreadsheet-like formulas (it's called Functional Reactive Programming), and I'm going to take a look at this language.
I always wanted to program using Excel formula. (Score:5, Funny)
Looks like this is the language for me!
Re: (Score:1)
Why do you hate functional programming?
Technically, isn't anything you can build and run successfully functional programming? :-)
Re: (Score:3)
Technically, isn't anything you can build and run successfully functional programming? :-)
If a subroutine has hidden state, so it is not idempotent, then it is not functional programming.
if (foo(1.0) != foo(1.0)) {
printf("Not functional programming\n");
}
Re: (Score:2)
If a subroutine has hidden state, so it is not idempotent, then it is not functional programming.
True with one exception: When you interface the user, that one always has hidden state. Unless the user is dead. Hmmm ...
Re: (That was a joke, son) (Score:2)
there are a lot of exceptions. reading data from a socket. getting data from a sensor like a camera. accessing the real time clock.
There are ways to deal with this in a functional language either with monads or with a world type. Conceptually the goals are the same, to isolate the side effects to a small well-defined portion of the system and remove the side effects from the general purpose functional language. Use generally carries some heavy constraints but it has been proven to work and isn't really all
Re: (Score:3)
Yes! That's why lots of programming types read The Daily (Way To Functionally program) each day. It describes how to create a true Functional program. And very often, people in the comments improve on it and point out some Real Way To Functionally program that is mentioned in passing in the main entry.
But seriously, true functional programs have no side effects, and side effects include basically all useful results, like modifying files or interacting with the user. So functional programs are almost by
At last (Score:1)
So functional programs are almost by definition non-functioning! (Yes, yes, monads. It's a joke, laugh.)
See now, THAT was funny!
Re: (Score:2)
I'd like to give functional programming a good kick in the monads.
Re: (That was a joke, son) (Score:2)
You seem to misunderstand what no side effects means.
fn(state) => new_state
There. Updated state with pure functions.
Re: (Score:2)
Your example is exactly what side effect [slashdot.org] is defined to exclude. A side effect is changing something -- an existing variable's value, a byte on disk, a pixel on screen, which key is "next" in the input queue -- rather than simply returning a value. Side effects are what almost everyone expects their programs to have.
Re: (Score:2)
Intended link: https://en.wikipedia.org/wiki/... [wikipedia.org] . Phones try too hard to be helpful.
Re: (That was a joke, son) (Score:2)
That has nothing to do with the programming paradigm though. Just because the function has no side effects doesn't mean you can't change anything. The runtime - for example - might be calling your state update function in a loop, then mirroring that state to - for example - your screen.
You get all the benefits of pure functions, and state changes to the running system are managed in one place in the runtime.
Re: (Score:2)
You just proposed what are effectively global variables, except that you have to pass them through your entire call stack so that they can be returned as part of the new state, and you have to jump through hoops to preserve a functional programming model for any sub-functions that need much of that state.
In the case of a GUI, you would also need to write code (which you attributed to the runtime) to describe how that state gets mirrored to the screen, so you still have some non-functional-programming wrappe
Re: (That was a joke, son) (Score:2)
When you compile code, it is no longer functional or object oriented. It is procedural spaghetti assembler code. Whatever wrapper you may have is not relevant to how you code your app, whether that be in FP, OOP, or some other paradigm.
Re: (Score:3)
It's literally an advanced Excel-like platform [microsoft.com]. Scroll down to look at the screenshots.
The language is mostly functional and aimed at people who know Excel, but want to do a little more. The language is better than Visual Basic, but not as good as . [zerobugsan...faster.net]
Re: (Score:2)
Re: (Score:2)
When I read the summary somehow I read that it was a "low-power language" like it wouldn't take much battery power.
I could not figure out what a low-power language would look like. Maybe event based with interrupts? Turns out it actually is event-based (from what I can see) but definitely not low-power. It looks like a power hog.
Re: (Score:2)
Re: (Score:2)
Maybe the idea is to design FPGAs using, uh, excell macros .... yeah not likely lol
Re: (Score:2)
When I read the summary somehow I read that it was a "low-power language" like it wouldn't take much battery power.
More like "not much brain-power" needed.
Re: (Score:3)
Indeed. The language for people that have a high pain-threshold with regards to barely usable simple mechanisms, but a very low one with regards to well-designed mechanisms that need some understanding of larger concepts to use them.
Re: (Score:2)
I've actually always wanted to program using spreadsheet-like formulas (it's called Functional Reactive Programming), and I'm going to take a look at this language.