Notes for June 11, 2012 meeting: Actors, legacy code, testing, code coverage, static analysis, Kotlin, pronunciation, etc
31 views
Skip to first unread message
Igal Koshevoy
Jun 13, 2012, 6:22:42 PM6/13/12
to pdxfunc
We had another great meeting last night. As usual, when interesting
people get together, even without an agenda, an interesting
conversation gets going.
Below are notes about some of the things we discussed. Feel free to
post comments, improvements and corrections:
* ACTORS
Lyle Kopnicky talked about actors and using them in the Oz programming
language. My best attempt to explain actors in a single sentence is
that they're concurrently executing units of logic similar to threads
(and are often built on threads), but have no shared state and instead
communicate through messages.
Actors seem appropriate for those situations where you'd typically use
threads: low-overhead concurrent in-process computation. Because
actors isolate state within themselves and the rest of the world can
only interact with them through well-formed messages, this eliminates
many problems associated with coordinating multiple threads that are
collectively manipulate shared state.
Oz made using actors easy and succinct because it offers easy access
to threads and blocks execution on unbound variables, e.g. pass a
message to an actor with an unbound variable as a kind of placeholder
and assign it later, so the actor can continue to run until it tries
to use the variable and blocks until its set to something.
However, the downside of actors is that they're less well supported or
understood by most programmers than threads, which are already
considered tricky, and add more indirection to the code. A bigger
issue is whether actors or threads are an appropriate solution for a
given task, because many of the examples discussed later seemed like a
better fit for message-oriented middleware (MOM) where a one process
enqueues a job with the middleware process, and then another process
gets a job from the middleware and works on it. Unlike most
implementations of actors or threads, middleware typically provides
natural ways to scale the worker pool, limit the numbers of workers
running at once, can be easily made durable enough to preserve
messages through crashes, and often allows workers to be written in
different programming languages. Lastly Oz's clever features and
specialized syntax for dealing with concurrency made code so succinct
that it surprised and confused many us unfamiliar with the language.
If someone or a group would be interested in presenting more about
concurrency and dealing with state in functional way, we'd love to
hear it.
Learn more about:
- Actors and libraries for many programming languages:
http://en.wikipedia.org/wiki/Actor_model
- Actors and their ilk from a Ruby perspective:
http://www.slideshare.net/mperham/actors-and-threads
- Scala offers threaded and event-based actors:
http://www.scala-lang.org/node/242
- Oz programming language: http://www.mozart-oz.org
* LEGACY HASKELL CODE, TESTING AND CODE COVERAGE
Someone asked how to cope with inheriting a large legacy Haskell
codebase that needed new features added, lots of unused code removed,
and much code that needed refactoring.
Suggestions were to add tests and code coverage ASAP. Tests make it
easier and safer to add functionality, remove unused code, and
refactor. Code coverage identifies what code is used, which is helpful
in figuring out what code is useful but needs tests or is irrelevant
and should be removed. Learn about various Haskell tools, techniques
and issues at <http://stackoverflow.com/questions/3120796/haskell-testing-workflow>.
* STATIC ANALYSIS OF HASKELL
Someone asked how to perform static analysis on Haskell code.
Suggestions included using Haskell Source
<http://hackage.haskell.org/package/haskell-src> and Source Extensions
<http://hackage.haskell.org/package/haskell-src-exts>. Also suggested
was compiling to Core and analyzing the output
<http://stackoverflow.com/questions/6121146/reading-ghc-core>.
* KOTLIN
Kotlin is a new JVM language written by the clever people at
JetBrains. It can use Java libraries, compiles as quickly as Java, is
safer and more concise than Java, and avoids various pitfalls in
Scala. Apparently some feel it's stable enough now that it's worth
using for new projects instead of Scala. Although Kotlin has many
features we'd expect in a functional language, it's primarily intended
for OOP. Learn more about Kotlin at <www.jetbrains.com/kotlin/>.
* PRONUNCIATION
A brief debate broke out over the correct pronunciation of "Haskell".
Opinions seemed to range from "feh" to "Those pronouncing 'Haskell'
like 'Pascal' will be the first against the wall when the revolution
comes." You may be interested in hearing some guy named Simon
pronounce "Hasekll" at
<http://www.youtube.com/watch?v=iSmkqocn0oQ#t=197s> and amused by this
somewhat helpful 4chan thread which contains naughty words
<http://dis.4chan.org/read/prog/1212717072>. Meanwhile, no consensus
was reached on the correct way to pronounce "tuple".
* NEXT MEETING
We'll hopefully have presentations next month on:
* Parser combinators in Haskell, what are and why may want to implement your own
* Writing a JSON validator DSL in functional-style Ruby
-igal
people get together, even without an agenda, an interesting
conversation gets going.
Below are notes about some of the things we discussed. Feel free to
post comments, improvements and corrections:
* ACTORS
Lyle Kopnicky talked about actors and using them in the Oz programming
language. My best attempt to explain actors in a single sentence is
that they're concurrently executing units of logic similar to threads
(and are often built on threads), but have no shared state and instead
communicate through messages.
Actors seem appropriate for those situations where you'd typically use
threads: low-overhead concurrent in-process computation. Because
actors isolate state within themselves and the rest of the world can
only interact with them through well-formed messages, this eliminates
many problems associated with coordinating multiple threads that are
collectively manipulate shared state.
Oz made using actors easy and succinct because it offers easy access
to threads and blocks execution on unbound variables, e.g. pass a
message to an actor with an unbound variable as a kind of placeholder
and assign it later, so the actor can continue to run until it tries
to use the variable and blocks until its set to something.
However, the downside of actors is that they're less well supported or
understood by most programmers than threads, which are already
considered tricky, and add more indirection to the code. A bigger
issue is whether actors or threads are an appropriate solution for a
given task, because many of the examples discussed later seemed like a
better fit for message-oriented middleware (MOM) where a one process
enqueues a job with the middleware process, and then another process
gets a job from the middleware and works on it. Unlike most
implementations of actors or threads, middleware typically provides
natural ways to scale the worker pool, limit the numbers of workers
running at once, can be easily made durable enough to preserve
messages through crashes, and often allows workers to be written in
different programming languages. Lastly Oz's clever features and
specialized syntax for dealing with concurrency made code so succinct
that it surprised and confused many us unfamiliar with the language.
If someone or a group would be interested in presenting more about
concurrency and dealing with state in functional way, we'd love to
hear it.
Learn more about:
- Actors and libraries for many programming languages:
http://en.wikipedia.org/wiki/Actor_model
- Actors and their ilk from a Ruby perspective:
http://www.slideshare.net/mperham/actors-and-threads
- Scala offers threaded and event-based actors:
http://www.scala-lang.org/node/242
- Oz programming language: http://www.mozart-oz.org
* LEGACY HASKELL CODE, TESTING AND CODE COVERAGE
Someone asked how to cope with inheriting a large legacy Haskell
codebase that needed new features added, lots of unused code removed,
and much code that needed refactoring.
Suggestions were to add tests and code coverage ASAP. Tests make it
easier and safer to add functionality, remove unused code, and
refactor. Code coverage identifies what code is used, which is helpful
in figuring out what code is useful but needs tests or is irrelevant
and should be removed. Learn about various Haskell tools, techniques
and issues at <http://stackoverflow.com/questions/3120796/haskell-testing-workflow>.
* STATIC ANALYSIS OF HASKELL
Someone asked how to perform static analysis on Haskell code.
Suggestions included using Haskell Source
<http://hackage.haskell.org/package/haskell-src> and Source Extensions
<http://hackage.haskell.org/package/haskell-src-exts>. Also suggested
was compiling to Core and analyzing the output
<http://stackoverflow.com/questions/6121146/reading-ghc-core>.
* KOTLIN
Kotlin is a new JVM language written by the clever people at
JetBrains. It can use Java libraries, compiles as quickly as Java, is
safer and more concise than Java, and avoids various pitfalls in
Scala. Apparently some feel it's stable enough now that it's worth
using for new projects instead of Scala. Although Kotlin has many
features we'd expect in a functional language, it's primarily intended
for OOP. Learn more about Kotlin at <www.jetbrains.com/kotlin/>.
* PRONUNCIATION
A brief debate broke out over the correct pronunciation of "Haskell".
Opinions seemed to range from "feh" to "Those pronouncing 'Haskell'
like 'Pascal' will be the first against the wall when the revolution
comes." You may be interested in hearing some guy named Simon
pronounce "Hasekll" at
<http://www.youtube.com/watch?v=iSmkqocn0oQ#t=197s> and amused by this
somewhat helpful 4chan thread which contains naughty words
<http://dis.4chan.org/read/prog/1212717072>. Meanwhile, no consensus
was reached on the correct way to pronounce "tuple".
* NEXT MEETING
We'll hopefully have presentations next month on:
* Parser combinators in Haskell, what are and why may want to implement your own
* Writing a JSON validator DSL in functional-style Ruby
-igal
Nathan Hunter
Jun 13, 2012, 6:29:16 PM6/13/12
to pdx...@googlegroups.com
Everyone should watch that whole video. It's awesome.
-igal
--
You received this message because you are subscribed to the Google Groups "pdxfunc" group.
To post to this group, send email to pdx...@googlegroups.com.
To unsubscribe from this group, send email to pdxfunc+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pdxfunc?hl=en.
Jesse Cooke
Jun 13, 2012, 6:37:03 PM6/13/12
to pdx...@googlegroups.com
I've been watching "The Actor Model (everything you wanted to know, but were afraid to ask)[1] and it's proven very insightful & helpful.
[1] http://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask
--------------------------------------------
Jesse Cooke :: N-tier Engineer
jc00ke.com / @jc00ke
--------------------------------------------
Jesse Cooke :: N-tier Engineer
jc00ke.com / @jc00ke
On Wed, Jun 13, 2012 at 3:22 PM, Igal Koshevoy <ig...@pragmaticraft.com> wrote:
-igal
gregory benison
Jun 13, 2012, 10:18:12 PM6/13/12
to pdx...@googlegroups.com
On Wed, Jun 13, 2012 at 3:22 PM, Igal Koshevoy <ig...@pragmaticraft.com> wrote:
> We had another great meeting last night. As usual, when interesting
> people get together, even without an agenda, an interesting
> conversation gets going.
>
There was also some interesting discussion of memory resource usage in
> people get together, even without an agenda, an interesting
> conversation gets going.
>
Ruby. Partly because everything is an object, Ruby processes tend to
have a large footprint - when Rails is running, it can be 100 MB per
Ruby process. Once upon a time, there was an effort to create a
"forking Ruby" in which a parent Ruby process would start, load all
the libraries, and then fork to run worker programs; due to the
copy-on-write behavior of memory in child processes, the workers would
have a very small (physical) memory footprint because most of that 100
MB Ruby address space is library code that does not change. This
method has not become mainstream in Ruby deployment.
I happened upon the following interesting SO thread that describes a
way to get copy-on-write behavior for duplicated data structures in a
C program (i.e. two copies of the same data, in the same process, but
sharing physical memory with copy-on-write behavior):
http://stackoverflow.com/questions/1565177/can-i-do-a-copy-on-write-memcpy-in-linux
--
Greg Benison <gben...@gmail.com>
[blog] http://gcbenison.wordpress.com
[twitter] @gcbenison
Thomas Lockney
Jun 13, 2012, 10:55:24 PM6/13/12
to pdx...@googlegroups.com
On Wed, Jun 13, 2012 at 3:22 PM, Igal Koshevoy <ig...@pragmaticraft.com> wrote:
> If someone or a group would be interested in presenting more about
> concurrency and dealing with state in functional way, we'd love to
> hear it.
If anyone wants to hear yet more about actors, I'd be happy to try and
> concurrency and dealing with state in functional way, we'd love to
> hear it.
put something together on using actors in Scala via Akka. In my
opinion actors are a very elegant model and while they are not
strictly functional in the core definition, they meld very well with
the functional model. In particular, I'd love to talk about scenarios
where actors can fit the problem appropriately and show how Akka's
approach to actors allows it to fit into many of the situations where
a MOM (yes, I'm bringing out *that* old term - let all you enterprise
architects be warned!) style approach can be replaced with an
actor-based approach (at least, by way of Akka).
~thomas
Lyle Kopnicky
Jun 13, 2012, 11:10:02 PM6/13/12
to pdx...@googlegroups.com
Sounds good to me!
Thomas Lockney
Jun 15, 2012, 12:59:00 PM6/15/12
to pdx...@googlegroups.com
I'd be curious to know if others are interested in this before I start
committing time to work on it (though, I'll likely give a very similar
talk at pdxscala at some point). If most of you are already bored with
actors, I'll spare you. ;~)
http://about.me/tlockney
committing time to work on it (though, I'll likely give a very similar
talk at pdxscala at some point). If most of you are already bored with
actors, I'll spare you. ;~)
> --
> You received this message because you are subscribed to the Google Groups
> "pdxfunc" group.
> To post to this group, send email to pdx...@googlegroups.com.
> To unsubscribe from this group, send email to
> pdxfunc+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pdxfunc?hl=en.
--
> You received this message because you are subscribed to the Google Groups
> "pdxfunc" group.
> To post to this group, send email to pdx...@googlegroups.com.
> To unsubscribe from this group, send email to
> pdxfunc+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pdxfunc?hl=en.
http://about.me/tlockney
Jesse Cooke
Jun 15, 2012, 1:06:02 PM6/15/12
to pdx...@googlegroups.com
I'd like to hear about it.
gregory benison
Jun 15, 2012, 8:29:08 PM6/15/12
to pdx...@googlegroups.com
On Fri, Jun 15, 2012 at 10:06 AM, Jesse Cooke <je...@jc00ke.com> wrote:
> I'd like to hear about it.
>
+1
> I'd like to hear about it.
>
Andrew Sackville-West
Jun 15, 2012, 11:07:55 PM6/15/12
to pdx...@googlegroups.com
On Fri, Jun 15, 2012 at 05:29:08PM -0700, gregory benison wrote:
> On Fri, Jun 15, 2012 at 10:06 AM, Jesse Cooke <je...@jc00ke.com> wrote:
> > I'd like to hear about it.
> >
>
> +1
+1. might be just the thing to finally get me out to a meeting...
> On Fri, Jun 15, 2012 at 10:06 AM, Jesse Cooke <je...@jc00ke.com> wrote:
> > I'd like to hear about it.
> >
>
> +1
A
Thomas Lockney
Jun 16, 2012, 1:14:18 AM6/16/12
to pdx...@googlegroups.com
On Fri, Jun 15, 2012 at 8:07 PM, Andrew Sackville-West
<and...@swclan.homelinux.org> wrote:
> +1. might be just the thing to finally get me out to a meeting...
At least some small part of my motivation for proposing the talk was
<and...@swclan.homelinux.org> wrote:
> +1. might be just the thing to finally get me out to a meeting...
to force myself to get back out to another pdxfunc meeting. ;~)
--
http://about.me/tlockney
Thomas Lockney
Jun 16, 2012, 3:57:43 PM6/16/12
to pdx...@googlegroups.com
As it turns out, the soonest I could give this talk would be at the
August meeting. My wife and I already have plans that conflict with
the July meeting day. Since there seems to be at least a handful of
folks interested, I'll go ahead and plan on presenting it then. If no
one objects, of course. ;~)
--
http://about.me/tlockney
August meeting. My wife and I already have plans that conflict with
the July meeting day. Since there seems to be at least a handful of
folks interested, I'll go ahead and plan on presenting it then. If no
one objects, of course. ;~)
http://about.me/tlockney
Reply all
Reply to author
Forward
0 new messages