Luna – Visual and textual functional programming language with a focus on productivity, collaboration and development ergonomics.

Take a look at what these folks are doing.   Very cool stuff!!!

Software design always starts with a whiteboard. We sketch all necessary components and connect them to visualize dependencies. Such component diagram is an exceptionally efficient foundation for collaboration, while providing clear view over the system architecture and effectively bridging the gap between technical and non-technical team members.


Unfortunately, it is impossible to execute the diagram itself, therefore the logic has to be implemented as a code.

Now that’s the part I disagree with, in the sense that, once the code-behind is written, and written in a modular and semantic way, you should be able to visually build the workflows, reduce/map/filter operations from “primitive” blocks, which then become bigger blocks from which you build from, etc.

Function Composition, Function Chaining, Currying, and Partial Functions / Application in F# and Ruby

A while ago I wrote an article comparing / contrasting language elements in Ruby with C# with regards to classes: constructors, destructors, fields, properties, initializers, events, methods, etc.  Ruby however also has a foot in the functional language paradigm, though it requires a certain discipline to ensure that you’re adhering to qualities of a functional programming language such as statelessness and immutability.  However, for purposes of this article, what I am more interested in is exploring how Ruby handles certain concepts that seem to be core to most functional programming languages:

  • function composition
  • function pipelining (chaining)
  • continuation functions
  • currying
  • partial functions
  • partial application

These concepts are all intertwined with each other, and as we’ll see, you can certainly implement these behaviors in Ruby, though not as elegantly as with F# (or other FP languages.)  Incidentally, one of the reasons Ruby gets away with being called an FP language is its support for lambda expressions and the ease in which code blocks yielded to for iteration, application specific handling (like IoC), and so forth.  Again, those are not areas that I’m interested in pursuing in this article because at this point they are part of most imperative languages as well, such as C#, further blurring the lines between imperative, declarative, and functional programming.

Continue reading this article on The Code Project!