Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:I couldn't get past "how do you write a game"? (Score 1) 190

Functional reactive programming came out of the functional community. Assume you had an array of all the inputs the end user entered for a game that already happened. Then the engine can create an array of all the corresponding outputs. That's your engine. Now wrap the construction of those two arrays in a stateful monad (IO).

This book ( https://www.amazon.com/Haskell... ) is out of date but it will teach the ideas well. You'll create a video game and a music player.

In general though, no video games don't generally get written in functional languages they are too messy and stateful. Video game engines though can easily be written in functional languages.

Comment Re:Performance .... anyone? (Score 0) 190

The results are usually either trivial or dangerous.

To pick two examples. Perl has had a map for many years which is just syntactic sugar for the foreach construct. On the dangerous side we have the new optional monad (Java's name for the Maybe Monad). You can use it trivially like this

Optional person = personMap.get("Name");
if (person.isPresent()) {
    Optional address = person.getAddress();
    if (address.isPresent()) {
        Optiona city = address.getCity();
        if (city.isPresent()) {
            process(city)
        }
    }
}

On the other hand if you try and use it the way Maybe/Optional is really intended things blow up badly. The API aren't retrofitted to lift into the monad the way they should. So code will execute in sequence unless you catch exception in which case you are back to explicit exception catching. The primitives don't lift (there isn't optional int, optional char...), so methods don't lift smoothly ...

Essentially the less purity the less you can pull across non trivially. You can mix in some impurities (LISP) if you assume developers are very aware of theory.

So what ends up coming across are some nifty syntax from functional languages and a few minor features.

Comment Re:Scala (Score 0) 190

Haskell has a for loop. The thing is that there are really 2 types of for:

1) Go through an array and do something to each element (map)
2) Do a sequence of actions. for :: (Traversable t, Applicative f) => t a -> (a -> f b) -> f (t b) is just traverse with arguments flipped

Comment Its fantastic for principles (Score 0) 190

The functional languages are often about 2 decades ahead of the imperative languages in terms of features and ideas. Truly powerful type systems, purity, laziness, infinite data structures. They really do change the way you think about design. Engines (controllers for MVC) are excellent in those languages. They are also very good for protyping non-vonNeumann architectures (like Hadoop code) unlike the Algol based languages.

They have their own problems like a tendency for slightly less than optimal algorithms to be quadratic in memory.

Comment Re: They simply remember your UDID (Score 4, Funny) 88

= = = eah the NY times article was scaremongering and partially wrong but the 'bad' thing Uber did here was break the Apple TOS which say developers should not be fingerprinting users devices.= = =

Who would have ever thought that a company founded on the principle [sic] of breaking the law in multiple jurisdictions would ignore and circumvent the terms and conditions, to which they agreed, of an entity with which they do business. Whodathunkait.

Comment People have workflows. (Score 4, Informative) 369

They invest the time and the learning to master a workflow. They expect a payoff from this investment in their ability to use these workflows to achieve other ends. When you mess with a workflow, you negate that investment. They have to spend time learning and mastering a workflow all over again before they can apply it toward their actual goals.

Nobody uses software "to be using software" or "for a good experience." They use it to get things done. If they have to spend two weeks mastering a new workflow then your improvements had better deliver a multiple of that value in return, or they're going to come back with "that's cool, but it would trip me up for all of my muscle and click memory to be invalidated."

People aren't averse to improvements. They're averse to evolutionary improvements that cost more to the user in practice (time invested and mistakes avoided) than they deliver on the other end. "Small tweaks" often fall into this category. Some dev moves a button to a more "logical" placement and for the next two weeks, the users lose five or ten seconds every single time they need to use it because their absent minded clicking—absent-minded because they're focusing on what they're really trying to accomplish, not on 'using the software'—keeps ending up in the wrong place vs. what they're accustomed to.

Dev says "BUT IT'S BETTER." User experience is actually that of being irritated and not getting things done as efficiently as usual, so their response is "IN PRACTICE, IN THE CURRENT CONTEXT OF MY LIFE, NO IT'S NOT."

Slashdot Top Deals

On the Internet, nobody knows you're a dog. -- Cartoon caption

Working...