51–60 of 86 posts
Highly recommend LiveScript if you like CoffeeScript or JavaScript or functional programming. http://livescript.net
Highly recommend LiveScript if you like CoffeeScript or JavaScript or functional programming. http://livescript.net
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…
My biggest takeaway, and an entirely legitimate criticism, is that if all your functions become instead State World (), your type signature no longer gives you much information about what the function does. In light of this I intend, when/if I get around to playing with a game in Haskell (or anything else that involves shipping around a huge wad of state), to look into splitting types of game state changes into multiple typeclasses, so as to see about preserving some more information about what various state transformations touch (both reading and writing)...
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…
> Well, every time you add a new type of entity (or a new data structure to index existing entities), you could add another parameter to the main game loop. But that gets crazy pretty fast. So then you have the clever idea to maintain one massive game state hash, and just pass that around. But wait, now you've lost something key to functional programming: You can no longer tell exactly what aspects of the game state…
frobnicateTurboencabulator :: GameState -> GameState
on :: (b -> b -> c) -> (a -> b) -> a -> a -> c
The state monad doesn't help with this problem:
frobnicateTurboencabulator :: State GameState ()
1) Split functionality into many typeclasses and hide the State monad, so you can see what functionality is accessed by a function (as mentioned in my other comment),
2) Have functions return a description of updates to the world-state instead of performing those updates themselves (so you know what kinds of things a particular function might do). This might have the benefit of letting you compose actions before applying them, which could in some cases be faster if the updates are likely to be large.
There are likely other options, as well.
Some ideas that are ubiquitous within functional programming are certainly on the rise, for example: - functions as first-class entities in programming languages, and consequences like higher-order functions and partial evaluation; - a common set of basic data structures (set, sequence, dictionary, tree, etc.) and generalised operations for manipulating and combining them (map, filter, reduce, intersection, union, zi…
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…
[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 much nicer. Admittedly, I haven't tried making games per se, but I have used it successfully for several other interactive UI programs.
FRP is a good approach for any system where you would normally use events and callbacks. This includes UIs and games as well as things like controllers or even music. So at least for that sort of IO-heavy and stateful domains, there is a very good declarative approach.
Earlier quoted context omitted.
Runtime constant values as IO is a long-standing concern. The existence of withArgs cements the issue (definitely allows for non referentially transparent code to be written with getArgs) but there's more to be said about why withArgs exist and why getArgs is in the IO monad. http://www.haskell.org/pipermail/haskell/2005-October/016574... The argument usually seems to play out as "their denotation is uncertain" and t…
IO's general status as the "Unsafe Pandora's Box" is a wart in Haskell. Isn’t that rather like saying mutable variables are a wart in C? :-)
Highly recommend LiveScript if you like CoffeeScript or JavaScript or functional programming. http://livescript.net
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.
LiveScript hasn't been used as a name for JavaScript in almost two decades.
Earlier quoted context omitted.
> Well, every time you add a new type of entity (or a new data structure to index existing entities), you could add another parameter to the main game loop. But that gets crazy pretty fast. So then you have the clever idea to maintain one massive game state hash, and just pass that around. But wait, now you've lost something key to functional programming: You can no longer tell exactly what aspects of the game state…
A state monad is a decoration of functions that take and return the state. It's certainly prettier, and there are respects in which the parent's complaints are overblown (certainly, it's no worse than imperative languages), but the parent is entirely accurate that a function like frobnicateTurboencabulator :: GameState -> GameState doesn't have a type that tells you anything about what it actually does. Compare that…
And as always in Haskell: more type trickery. Like lenses, which help with the splitting. Applicative functors might help with "Have functions return a description of updates to the world-state [...]" for free in a sense similar to http://gergo.erdi.hu/blog/2012-12-01-static_analysis_with_ap...
In fact, the only application I use that is built using functional programming is Xmonad.
Also, none of the top languages on the TIOBE survey are purely functional, although one in the top 20, 'lisp' with .9% and falling, does promote a functional style.
People expound the virtues of functional programming year after year, and then go off and get a bunch done with Python. Steve Yegge said it best: http://steve-yegge.blogspot.com/2010/12/haskell-researchers-...
http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
They are assuming that functional programming is on the rise. With the exception of Clojure (which is more popular by virtue of being new), I don't know of any functional language that are in any measurable way more popular (I assume that is what they mean by on the rise) than it has been in the last 10 years. In fact, the only application I use that is built using functional programming is Xmonad. Also, none of the…
Why on earth would you want to educated pointy-haired individuals when you can be another vapid supporter of the six-sigma model?