Forgot your password?
typodupeerror
Networking Open Source Programming

Erlang and OpenFlow Together At Last 93

Posted by timothy
from the from-this-day-forth-no-erlang dept.
New submitter SIGSTOP writes "The LINC [OpenFlow 1.2 software-based] switch has now been released as commercial friendly open source through the FlowForwarding.org community website, encouraging users and vendors to use LINC and contribute to its development. The initial LINC implementation focuses on correctness and feature compliance. Through an abstraction layer, specialized network hardware drivers can be easily interfaced to LINC. It has been implemented in Erlang, the concurrent soft-real time programming language invented by Ericsson to develop their next generation networks."
This discussion has been archived. No new comments can be posted.

Erlang and OpenFlow Together At Last

Comments Filter:
  • what OpenFlow is, and the OpenFlow link goes to a non-existent page.
  • by Anonymous Coward

    Haven't they ever played Beneath a Steel Sky [wikipedia.org]?

    LINC WANTS YOU, FOSTER.

  • Apache 2.0 licensed (Score:2, Informative)

    by gQuigs (913879)

    for those curious what they meant by "commercial friendly open source".

    http://www.apache.org/licenses/LICENSE-2.0.html [apache.org]

  • You know celebrity marriages never last. What are we going to call the bastard child offspring of this unholy union? Erla Flow? No... sounds like a personal problem. Lang Open? No... that won't do either.

    Screw it, let's just call it "Forever In Beta", since most parents name their children based on their hope for their future. -_-

  • by el_flynn (1279) on Monday June 18, 2012 @02:49AM (#40356965) Homepage

    Erlang Solutions will be providing the support structure for this, you can look at the packages offered here: http://www.erlang-solutions.com/section/84/support-plan-overview [erlang-solutions.com].

  • A pure functional language is one that just relies on recursion with only parameter variables to carry out loops. Sorry , but while that may have some kind of academic aesthetic to various hard core CS types, I really don't see why its that is any better than OO or even procedural style programming especially since both of those paradigms support recursion anyway. To me, pure functional just seems to be a very quick way to obfuscate even the simplest potential solutions to a problem.

    Or am I missing somethin

    • by wrook (134116)

      Or am I missing something profound?

      Probably. [wikipedia.org]

      Functional programming leads to a completely different set of coding idioms. These can be very convenient in many applications. Since it is not the kind of programming that most people are used to, it can be awkward at first. There are a lot of things that are much more elegant and obvious when done this way, but you have to get over the barrier of thinking procedurally first. I would say that it isn't simply that hard core CS types like the aesthetics of functional programming. I think it's

      • by alba7 (100502)

        Of course there is nothing really stopping you from writing functional code in any language. It's just that notationally, functional languages make it much easier. In the same way, you could write object oriented code in any language, but the verbosity would negate it's usefulness.

        By definition, functional languages require complex, structured return types. Typically implementations use nested lists (where items are referenced by position) or nested hashes (where items are referenced by name). It's not har

        • by rb12345 (1170423)
          Dynamic typing is common in functional programming languages but not essential; Haskell is statically typed and is one of the purer functional languages.
        • by Z8 (1602647)
          This seems to conflate dynamic vs static typing and functional vs procedural. The problem you discuss comes up in procedural languages all the time:

          if (TEST) return bar(); else return baz();

          That's more a "problem" with dynamic typing. Statically typed functional languages like Haskell or the ML family use type inferencing systems to detect these types of problems at compile-time. There's been a lot of progress made on type systems since C/C++ were developed. As the previous poster mentioned, Haskell

    • by BitZtream (692029)

      The profound thing your missing is that as a developer, if you feel the need to debate over the qualities of your language or style of programming (i.e. functional versus OO or whatever) then you have no right to actually be part of the debate.

      The language doesn't matter that much, and the people trying to convince you why one is better than the other aren't experienced enough to realize that yet. The more someone implies that one language is the way to go or one style is the way to go for a certain task,

      • by cduffy (652)

        The more someone implies that one language is the way to go or one style is the way to go for a certain task, the less likely it is that you should believe them.

        Obvious Troll is obvious. Or at least, I hope you're trolling, as opposed to trying to look wise by displaying intentional naivete. If you'd left out "for a certain task", I'd agree with you wholeheartedly -- there's no one right tool for every job -- but certainly some tools are better for some jobs than others.

        Case in point: At my last job (actual

    • by cduffy (652)

      A pure functional language is one that just relies on recursion with only parameter variables to carry out loops. [...] To me, pure functional just seems to be a very quick way to obfuscate even the simplest potential solutions to a problem.

      Or am I missing something profound?

      Yes, you're missing something profound.

      The big deal (and it's a Really Big Deal) in functional programming is isolation of side-effects. Pure functions transform inputs to outputs, and do nothing else: They don't mutate data, they don't

I cannot conceive that anybody will require multiplications at the rate of 40,000 or even 4,000 per hour ... -- F. H. Wales (1936)

Working...