61–70 of 86 posts
I have been meaning to dig deeper into functional programming, specifically Clojure, but as a newbie to functional programming, I am finding it hard to find a detailed tutorial that I can start to get started with the concepts and programming used in Clojure. Would anyone have any recommendations for a guide?
Earlier quoted context omitted.
"[SQL] is way too simplistic for comparison with real world functional programs" Another way of interpreting that is that the ideas behind SQL are so powerful that it's able to be one of the most successful programming languages of all time without all the bells and whistles of a language like haskell. It's so successful that it can get by with horrid syntax, a ton of special cases built in, and the mess of SQL NULL…
"Sometimes it boggles my mind that more functional programmers don't get involved in databases, where all of their ideas are already proven to be useful." But some do. For example Rich Hickey used Clojure (which both users and encourages FP but still allows to bend the rules when needed) to create Datomic. It's a DB but it's CRA instead of CRUD. Making it just so much easier to reason about. The DB is ever-growing an…
That being said, I don't think CRA is a panacea. Databases will always have a "read, decide what to do, write" pattern (because that is what happens in the real world, and databases model the real world). If the read happens at time T, and the write happens at time T+100; then you could have a race condition if something happens at time T+50.
Postgres can detect such race conditions by using true serializability (based on a technique called Serializable Snapshot Isolation[1]). It gets tricky to apply the same technique for temporal databases, though I believe it's possible. Do you happen to know what techniques Datomic offers users to help avoid/detect/resolve race conditions?
Don't get me wrong. I think it's a very useful direction to go in. I've done a lot of work on temporal features in postgres. I'm also aware of some of the limitations, however. You still need some kind of coordination and something resembling locks or a conflict detector.
(By the way, please avoid derogatory comments about people who make different technology choices than you do. An argument could be made that postgres is CRA. And even if not, CRA versus CRUD is a small part of what is actually important to users; many of whom face a different set of trade-offs than you do.)
Earlier quoted context omitted.
Any reason why they ripped the original name for Javascript off? I totally thought you were joking until I went to the site and noticed it's a current project.
The name is a joke, the project is not. "LiveScript was one of the original names for JavaScript, so it seemed fitting. It's an inside joke for those who know JavaScript well." (from the site) LiveScript hasn't been used as a name for JavaScript in almost two decades.
Earlier quoted context omitted.
Concepts like your file state machine can be achieved using indexed monads and dependent types, though that's still fairly black magic. There's no doubt that the IO monad should have more structure, though, and ST is just one way to achieve that. There isn't a globally recognized standard for providing more structure, but there are a lot of fairly common practices (see IOSpec or free monads). The syntactic convenienc…
The syntactic convenience is unbeatable, of course. Exactly. I’m not in any way criticising all the research and ideas coming out of the functional programming community. Playing with Haskell is driving all sorts of interesting ideas. I’m just saying I don’t think the mainstream is going to give up a whole bunch of readily accessible and useful programming techniques any time soon, just to gain the benefits of a radi…
To clarify, I don't think Haskell is the ultimately useful embedding of many of these concepts. I just also don't think there's that much hand holding possible. You start to run up against the limits of inference and decidability in this space. Until Bob the programmer start to meaningfully think about the way to build the effects of his language around different contexts then there's a limit to how many guarantees a compiler is going to be able to make.
Earlier quoted context omitted.
To me, the future will most likely be languages that allows both functional and OO styles to interoperate. Programmers will pick the style or mix of styles most appropriate to the particular sub-problem they're solving. We already do this with some of our high-level languages like Ruby and JavaScript. With these, we have higher-order functions, map and friends, closures, etc.. But we also have our familiar OO constru…
For games and other reactive systems, you should check out functional reactive programming (FRP)[1]. The basic idea is to model time explicitly, working with time-varying values. So you would express your game logic as a network of event streams and signals. [1]: http://stackoverflow.com/questions/1028250/what-is-functiona... This is a radically different from the normal imperative approach, and I've found it to be m…
Quite off-topic, but the underscores for the variable names in the first code snippet are totally irritatingly useless and anachronistic in the most ugly looking way.
Earlier quoted context omitted.
To me, the future will most likely be languages that allows both functional and OO styles to interoperate. Programmers will pick the style or mix of styles most appropriate to the particular sub-problem they're solving. We already do this with some of our high-level languages like Ruby and JavaScript. With these, we have higher-order functions, map and friends, closures, etc.. But we also have our familiar OO constru…
If you mix FP and OO you'll often end up with terrible FP which simply reproduces the "old" approach: lots of mutable stuff everywhere. Many Clojure toy games are like that: they start with a lot of "variables" in mutable refs. But it doesn't need to be that bad: you can create a game that is fully deterministic. A game which is purely a function of its inputs. And it can of course be applied to more than games. The…
What I'm suggesting is that mutable state isn't inherently bad. It's entirely possible that we will someday enter a new age of mainstream, pure FP where we look back at mutable state and cringe. But that's pure speculation. Our current world is full of successful applications written in languages built on mutable state.
So I'm not saying that mutable state is inherently better than the alternatives. Just that the case against it--and for the alternatives--has to be pretty darn compelling to outweigh the tremendous real-world success of languages like Ruby, Python, JavaScript, and so on.
Earlier quoted context omitted.
To me, the future will most likely be languages that allows both functional and OO styles to interoperate. Programmers will pick the style or mix of styles most appropriate to the particular sub-problem they're solving. We already do this with some of our high-level languages like Ruby and JavaScript. With these, we have higher-order functions, map and friends, closures, etc.. But we also have our familiar OO constru…
For games and other reactive systems, you should check out functional reactive programming (FRP)[1]. The basic idea is to model time explicitly, working with time-varying values. So you would express your game logic as a network of event streams and signals. [1]: http://stackoverflow.com/questions/1028250/what-is-functiona... This is a radically different from the normal imperative approach, and I've found it to be m…
One question though: Does memory/storage become an issue if you're keeping track of values "over time?" If I understand it correctly, you'd have a constantly growing picture of your data as it has evolved, with a complete history of prior values. (Maybe I'm wrong about this part, though.) For applications that are long-running or handle a lot of data, could this be a fatal problem?
Earlier quoted context omitted.
For games and other reactive systems, you should check out functional reactive programming (FRP)[1]. The basic idea is to model time explicitly, working with time-varying values. So you would express your game logic as a network of event streams and signals. [1]: http://stackoverflow.com/questions/1028250/what-is-functiona... This is a radically different from the normal imperative approach, and I've found it to be m…
Now that is really cool. You've convinced me that this could be a viable and practical approach to handling highly stageful programs in an FP context. One question though: Does memory/storage become an issue if you're keeping track of values "over time?" If I understand it correctly, you'd have a constantly growing picture of your data as it has evolved, with a complete history of prior values. (Maybe I'm wrong about…
You have signals and events, but you never ask about the value right now; instead, you take these two abstractions and combine them in different ways to get a reactive network. In a way, it's similar to dataflow programming or circuit design: you connect up "wires" into a network that can constantly push through data. Depending on how you write this network, you will need to remember different amounts of past data at runtime.
If you write your event/signal network carefully, you do not need to keep a history of too many prior values at runtime. This is one of the things modern FRP libraries really try to help you with: writing networks that are efficient. At least the ones I've tried are good at this--I haven't had many space problems in my programs so far.
In summary, this is a potential issue, and you may have to be a little careful in how you write your FRP code. However, modern frameworks try to make it easy to avoid these pitfalls, and there is no fundamental reason you can't use memory efficiently with this model.
Why is functional programming on the rise? I have heard several times that the big payoff with function programming comes from parallel processing. Because functions typically have no side effects they can operate on a set of inputs in parallel without modification. This is important because future increases in processing power are expected to come primarily from more cores rather than higher clock speeds as in the p…
I've done a bunch of both 'classic' and functional programming, and for me the biggest difference is a switch in code-writing mindset. In imperative languages, generally, I tell the computer what and how it should do - no matter if it's assembly, C, Java or [most of] Ruby. In FP languages (Haskell or Scala, haven't worked with Lisps), I generally tell the computer what needs to be computed and expect it to figure out…