It's not a secret anymore!*
The moose likes Scala and the fly likes Functional Style in the Real World Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Languages » Scala
Bookmark "Functional Style in the Real World" Watch "Functional Style in the Real World" New topic
Author

Functional Style in the Real World

Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

I've been reading up on Erlang a little more. I've been curious how a completely functional language deals with things that need to be persisted. Basically, anything persisted is a kind of mutable state and I was curious how in the world Erlang copes with race conditions.

It turns out you can mark the DB code to run in a transactional context. In Erlang this does more than just rollback everything if something fails - it actually puts a pessimistic lock on the rows or table and will even run away like a smart chicken when it sees potential for deadlock.

I would suppose that in Scala you would have to handle all this yourself. Another possibility would be to let Hibernate handle its optimistic locking mechanism... but then your domain objects wouldn't work as well if your Scala code started passing them around in multiple processes. I mean, a lot of their value is in being able to alter their state.

So this leads me to think that Scala in a basic CRUD application isn't such a great idea... or at least utilizing a functional style of programming in Scala for a basic CRUD app isn't optimal. You could still use Scala imperatively.

I've been thinking through a lot of past projects, wondering where functional style programming could have saved some headache.

There've been times where an asynchronous call was needed and for some reason most people immediately jump to the conclusion that MDBs are the best solution for anything asynchronous rather than bother to multithread.

There have also been plenty of times where multithreading some utility processes would have sped up the response (incredibly more so now with multicore processors) but the riskiness of creating a potential maintenance nightmare usually outweighed the benefits of pursuing it.

If I were to introduce a functional style of programming into an enterprise application, where would be the ideal place for it?


A good workman is known by his tools.
Garrett Rowe
Ranch Hand

Joined: Jan 17, 2006
Posts: 1296
I've been waiting for someone to answer this post for a while because I am

a.) Interested in what others opinions are, and
b.) wholly unqualified to answer the question as it was posed myself

Therefore hopefully without sounding too ignorant, I'll give my 2 cents.

MP: Basically, anything persisted is a kind of mutable state and I was curious how in the world Erlang copes with race conditions.

Dealing with race conditions is definitely out of the scope of my knowledge, but as to dealing with persistence in a functional language, from what I've seen from Haskell DBC libraries (which are *purely* functional) deal with database CRUD interactions the same way all IO is modeled in the language, with monads. In Haskell it's the IO Monad that is usually used, but I suppose a user defined monad would work.

I haven't worked with lift yet but have you checked out how the lift framework
handles CRUD applications?


Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. - Laurence J. Peter
Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

Originally posted by Garrett Rowe:
I haven't worked with lift yet but have you checked out how the lift framework
handles CRUD applications?

Oo - new toy! I'll mess with that over the weekend some. Thanks, Garrett!

A web framework might actually be a great way for Scala to get into the enterprise. I'll bet it has an Actor as a Front Controller. Shoot, even individual Servlet/Action/Command objects could be Actors.

I suppose my questions about race conditions probably aren't that big a deal. We have to deal with them in web applications (which are multithreaded) all the time in Java.
Pho Tek
Ranch Hand

Joined: Nov 05, 2000
Posts: 761

Have you also looked at Erlang mnesia.

mnesia transaction

A Mnesia transaction is a mechanism by which a series of database operations can be executed as one functional block. The functional block which is run as a transaction is called a Functional Object (Fun), and this code can read, write, or delete Mnesia records. The Fun is evaluated as a transaction which either commits, or aborts. If a transaction succeeds in executing Fun it will replicate the action on all nodes involved, or abort if an error occurs.
Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

Originally posted by Pho Tek:
Have you also looked at Erlang mnesia.


Yeah, my comment of: "It turns out you can mark the DB code to run in a transactional context. In Erlang this does more than just rollback everything if something fails - it actually puts a pessimistic lock on the rows or table and will even run away like a smart chicken when it sees potential for deadlock."

actually was talking about Erlang's Mnesia transactions.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Functional Style in the Real World
 
Similar Threads
General Erlang questions to book authors
Seven Languages in Seven Weeks
what is scala ?
How are you using Clojure?
Scala vs erlang