• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Functional Style in the Real World

 
pie sneak
Posts: 4727
Mac VI Editor Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Marc Peabody
pie sneak
Posts: 4727
Mac VI Editor Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 782
Python Chrome Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 4727
Mac VI Editor Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
reply
    Bookmark Topic Watch Topic
  • New Topic