Erlang and OpenFlow Together At Last

← Back to Stories (view on slashdot.org)

Erlang and OpenFlow Together At Last

Posted by timothy on Sunday June 17, 2012 @03:14PM 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."

93 comments

Min score:

Reason:

Sort:

Finally! by Anonymous Coward · 2012-06-17 15:20 · Score: 0

The anticipation has been growing, and I've been looking forward to this for so long.
Steady my fluttering heart.
1. Re:Finally! by Anonymous Coward · 2012-06-17 15:31 · Score: 0, Troll
  
  I used Erlang once before, in a previous job. What a fucking nightmare.
2. Re:Finally! by arth1 · 2012-06-17 16:06 · Score: 5, Interesting
  
  I used Erlang once before, in a previous job. What a fucking nightmare.
  It's certainly different from your average OO language, but it's no more "a fucking nightmare" than other functional languages like haskell and ocaml.
  I don't like either because I believe garbage collection is a bad idea - the programmer should have full control, and it's the job of the language to expose flaws, not hide them.
  I know I'm in the minority here, but still I look back to the days of (pre-turbo) pascal and (pre-95) Ada with fondness.
  But really, Erlang is one of the better functional languages, as they go. It may be tough to learn, but it has enough software written in it to prove its wirth.
3. Re:Finally! by Anonymous Coward · 2012-06-17 16:24 · Score: 1
  
  Hey, maybe he was referring to his previous job.
4. Re:Finally! by Psychotria · 2012-06-17 16:35 · Score: 4, Funny
  
  It may be tough to learn, but it has enough software written in it to prove its wirth.
  I'm not sure Wirth had much to do with Erlang.
5. Re:Finally! by Anonymous Coward · 2012-06-17 17:27 · Score: 0
  
  it's no more "a fucking nightmare" than other functional languages like haskell and ocaml.
  so it's a fucking nightmare, then?
6. Re:Finally! by Anonymous Coward · 2012-06-17 17:45 · Score: 1, Insightful
  
  Functional languages are only a nightmare if you are too dumb.
7. Re:Finally! by Pseudonym · 2012-06-17 17:46 · Score: 2
  
  I don't propse to start another to-GC-or-not-to-GC thread here. I'll just say my piece and that's it.
  GC is sometimes a bad idea, and sometimes a good idea. It depends entirely on precisely what the programmer is doing.
  Programs written in languages without some facility to enable automated or semi-automated memory management (be it full GC, reference-counted smart pointers or what have you) tend to be inherently non-modular. Somebody has to know when nobody else wants some object any more. There are essentially two solutions: either everyone is responsible for co-operative book-keeping (introducing boilerplate everywhere), or the program is structured around the lifetimes of data (potentially limiting what you can do algorithmically or making high-level reorganisation unnecessarily painful).
  Sometimes none of that matters, or other concerns dominate. That's okay. If you spend all of your career working in niches where memory management must be manual or else, and you enjoy it, then I'm glad you've found your calling.
  But for the majority of is, GC is another tool in our toolbox. It is part of my job to decide which tools are suitable for a given task and which ones are not. Hell, most of the time, semi-automated reference counting is more than enough. But sometimes, only GC will do the job.
  
  --
  sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
8. Re:Finally! by Vintermann · 2012-06-17 18:03 · Score: 4, Funny
  
  I know I'm in the minority here, but still I look back to the days of (pre-turbo) pascal and (pre-95) Ada with fondness.
  And you still hang out on slashdot, rather than reddit or Y combinator. Don't worry, you're probably not in a minority here.
  
  --
  xkcd is not in the sudoers file. This incident will be reported.
9. Re:Finally! by Vintermann · 2012-06-17 18:09 · Score: 5, Insightful
  
  And just like manual memory management is a clamp on the foot for modularity in a single-threaded environment, manual locking and mutexes is an additional clamp on the foot for modularity in the multithreaded realm.
  Erlang's actor model is an attempt to enable the production of modular concurrent communication software, just as Java's garbage collection model is an attempt to enable the production of modular business data software.
  
  --
  xkcd is not in the sudoers file. This incident will be reported.
10. Re:Finally! by macraig · 2012-06-17 18:40 · Score: 1
  
  Damn, beat me to it....
11. Re:Finally! by Anonymous Coward · 2012-06-17 19:00 · Score: 1
  
  A monad is just a monoid in the category of endofunctors!
12. Re:Finally! by Anonymous Coward · 2012-06-17 19:04 · Score: 1
  
  If you think GC is only or even primarily for hiding programming errors, you aren't much of a programmer. Your programming language examples also suggest that you're very much a bondage-and-discipline programmer who doesn't mind having to be verbose unnecessarily.
  For allocating lots of small objects, a good garbage collecting allocator is both more time- and space efficient. Think of something like a programming language compiler. Try building an AST (or an intermediate representation of the program or similar) using a manual allocator versus a garbage collecting one. Now try freeing the entire tree at once.
  Manual memory management is good when your objects are large and long-lived, in which case you can handle them directly or by reference counting, but there are a lot of programming tasks where this doesn't even remotely apply. Maybe that isn't the type of programs you've written, but that's just your lack of experience.
13. Re:Finally! by Anonymous Coward · 2012-06-17 19:05 · Score: 0
  
  Yes! I like category theory. :)
14. Re:Finally! by Anonymous Coward · 2012-06-17 19:26 · Score: 0
  
  Yes! I like pretending to be smart. :)
15. Re:Finally! by Pseudonym · 2012-06-17 19:51 · Score: 3, Interesting
  
  Erlang's actor model is also just another tool in our toolbox.
  Threads with shared memory, manual locking, mutexes, condition variables, restartable transactions and so on are hard to use. But that can also be okay. Sometimes the problem you're solving is so simple that it doesn't really matter, and sometimes it's so hard that there's no better way.
  Having said that, of course, Erlang is closer to what Alan Kay meant when he coined the term "object oriented" than pretty much any other language has yet realised.
  
  --
  sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
16. Re:Finally! by TheRaven64 · 2012-06-17 20:22 · Score: 1
  
  Garbage collection is also important for concurrency. Explicitly managing the lifetime of objects goes from being hard to being almost impossible once you thrown in concurrency.
  
  --
  I am TheRaven on Soylent News
17. Re:Finally! by TheRaven64 · 2012-06-17 20:23 · Score: 2
  
  Erlang is closer to what Alan Kay meant when he coined the term "object oriented" than pretty much any other language has yet realised
  I'm not sure it's still there, but there used to be a thing on the Erlang web page that said that Erlang was 'not an object oriented language like...' and then listed a number of other languages that were all less object oriented than Erlang.
  
  --
  I am TheRaven on Soylent News
18. Re:Finally! by TheRaven64 · 2012-06-17 20:26 · Score: 1
  
  Your examples are somewhat flawed, because a lot of projects do exactly that. In Clang, for example, which I think gets better parsing performance than anything else around, small objects are allocated with a bump-the-pointer allocator with a per-AST scope, and then are freed by just freeing the whole allocation at once. This is entirely possible to do with manual memory management, because you have complete control over allocation policy. With automatic garbage collection, the collector has to infer lifetime, the developer can't explicitly state it.
  Automatic GC, however, deals a lot better with aliasing, cyclic data structures, and especially with concurrency.
  
  --
  I am TheRaven on Soylent News
19. Re:Finally! by Anonymous Coward · 2012-06-17 20:38 · Score: 1
  
  I agree totally. Why not use PHP instead of some dead, convoluted language? Some people may show a bit of interst in that switch then.
20. Re:Finally! by Anonymous Coward · 2012-06-17 23:13 · Score: 1
  
  Of course you can used specialized allocation schemes, and they are sometimes really convenient, but you can't use them for everything, and it's always extra work. Perhaps ASTs were a bad example (although for ASTs, you have a lot less code - much of it pointless boilerplate - to write if you're using an ML-style variant instead of a class hierarchy).
  For memory and time overhead, any data structure with a large number of nodes (a big std::map for instance) will have significant overhead, and you're not going to replace all of them with custom allocators (although I must admit I quite often do).
  BTW LLVM is a good example of some severe flaws in C++. It may be comparatively fast to run, but compiling it takes ridiculous amounts of time and memory. You really, really shouldn't need 1GB of RAM just to compile something (I could understand at link-time for a really big project, but I'm talking individual object files here).
21. Re:Finally! by Anonymous Coward · 2012-06-17 23:13 · Score: 0
  
  Not so, the developers at ericsson had to use his leg to get to their offices.
22. Re:Finally! by arth1 · 2012-06-18 00:03 · Score: 1
  
  If you think GC is only or even primarily for hiding programming errors, you aren't much of a programmer.
  I hope you program better than you read. I don't think (and never said) it's for that, but I think it's an inherent side effect.
  
  Manual memory management is good when your objects are large and long-lived, in which case you can handle them directly or by reference counting, but there are a lot of programming tasks where this doesn't even remotely apply. Maybe that isn't the type of programs you've written, but that's just your lack of experience.
  You're making assumptions without any basis here, and then proceed to draw conclusions from them.
  And you're wrong too - small and short-lived objects are the prime example of when garbage collection is bad - they stick around when they shouldn't have to. This problem is elevated with concurrency and reentrance. If anything, manual memory management should always be the default for small short-lived objects where you can track the usage in your head, and know when to reap.
23. Re:Finally! by Anonymous Coward · 2012-06-18 00:26 · Score: 1
  
  For every 100 people doing their own memory management, I'm sure 101 of them are doing it right.
  While I'm sure that you can do a better job at memory management every time than all the compiler & OS experts of the past 50 years most people can't. Memory management and pointer errors have caused not just decades of security problems but it has destroyed property and even killed people. All that could have been avoided.
  Erlang routinely beats Java and C++ in large server benchmarks with lower latency and higher thoughput. It even beats Go at Google's own benchmarks. One of the secrets is soft threads avoid the overhead of OS context switches. In order to have a reliable soft threaded environment, you can't have any pointer mistakes.
  In the real world, under heavy use, the thing that really limits server performance is when the server runs out of RAM and has to page to disk. Running a single instance of a tight little benchmark and claiming Java is fast is laughable when benchmarks show that after years of being optimized by Java fans, some cases use thousands of times more RAM than Pascal does. That means for a multi-user server, you could service thousands of times more users in Pascal than you could in Java. The Pascal also compiles much faster and has a better historical completion and correctness rates than Java, C++ or C. For that matter COBOL has shorter development times and error rates then C++ and Java as well.
24. Re:Finally! by lars_stefan_axelsson · 2012-06-18 01:41 · Score: 1
  
  It's certainly different from your average OO language, but it's no more "a fucking nightmare" than other functional languages like haskell and ocaml
  Well, in the words of the guy behind Erlang, Joe Armstrong, "Erlang is a so-so functional language with excelent concurrency and distributed concurrency model" (paraphrase).
  As a pure functional language, it shows it's age IMHO - no Hindley mildner type system, uninspired syntax (based on Prolog), etc. etc. But as a systems language for distributed, soft real time, highly available systems, nothing else can currently touch it. (Yes, I used to work at Ericsson and build routers based on Erlang/C.)
  
  --
  Stefan Axelsson
25. Re:Finally! by Anonymous Coward · 2012-06-18 01:56 · Score: 0
  
  Back in the day, Americans would pronounce Wirth's name as "Nickles Worth" while Europeans would call him "Niklaus Virt".
  Europeans were calling him by name, Americans were calling him by value.
  Boom-tish. Try the veal. Etc.
26. Re:Finally! by phantomfive · 2012-06-18 02:36 · Score: 1
  
  Having said that, of course, Erlang is closer to what Alan Kay meant when he coined the term "object oriented" than pretty much any other language has yet realised.
  It's kind of hard to believe that considering Alan Kay himself wrote Smalltalk to show what object oriented is.
  
  --
  "First they came for the slanderers and i said nothing."
27. Re:Finally! by skids · 2012-06-18 02:53 · Score: 0
  
  Functional languages are only a nightmare if you are too dumb.
  ...or want the language to be accessible to people who don't get their jollies golfing things into rpn notation and actually want to get some real work done.
  
  --
  Someone had to do it.
28. Re:Finally! by skids · 2012-06-18 02:58 · Score: 1
  
  For allocating lots of small objects, a good garbage collecting allocator is both more time- and space efficient.
  Do good garbage collecting allocators actually exist? I've heard of them, but have seen no droppings in the woods or other evidence. I'm pretty sure they are possible, but most of what I've dug into the guts of was a total amateur hour inside. Stuff like no sense of realization that GC shouldn't run constantly if the program isn't actually doing anything, and should cap itself in proportion to the program's core CPU usage.
  
  --
  Someone had to do it.
29. Re:Finally! by Anonymous Coward · 2012-06-18 06:45 · Score: 0
  
  Both Hindley and Milner[sic] can go fuck themselves. I will never forgive them for raping Indiana Jones.
30. Re:Finally! by arth1 · 2012-06-18 09:04 · Score: 2
  
  ...or want the language to be accessible to people who don't get their jollies golfing things into rpn notation and actually want to get some real work done.
  Go forth and get some real work done then!
31. Re:Finally! by Pseudonym · 2012-06-18 11:40 · Score: 1
  
  If it helps overcome your disbelief, consider that Haskell is closer to Peter Landin's vision of functional programming than ISWIM.
  
  --
  sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
32. Re:Finally! by phantomfive · 2012-06-18 16:42 · Score: 1
  
  It would be more interesting to have a citation to a quote, so we can dissect and understand what Alan Kay meant when he said that. The Pater Landin thing is interesting to know, though.
  
  --
  "First they came for the slanderers and i said nothing."
33. Re:Finally! by Pseudonym · 2012-06-18 19:54 · Score: 1
  
  It's a personal opinion my my part. Kay's notion of OO was inspired by a biological system of cells, which communicate via (chemical) messages. Erlang's actors seem to fit this pattern more closely than, say, Smalltalk.
  
  --
  sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
34. Re:Finally! by lars_stefan_axelsson · 2012-06-18 23:27 · Score: 1
  
  Sorry, that just wooshed straight over my head. (P.S. And thanks for correcting my bad spelling, it's of course Milner with a capical 'M' and no extra characters).
  
  --
  Stefan Axelsson
35. Re:Finally! by phantomfive · 2012-06-19 02:27 · Score: 1
  
  Maybe. I think Erlang and Smalltalk are trying to solve two different problems. Smalltalk is trying to solve the 'ease of coding' problem, whereas Erlang is trying to solve the 'high reliability' problem.
  
  --
  "First they came for the slanderers and i said nothing."
36. Re:Finally! by Anonymous Coward · 2012-06-19 04:48 · Score: 0
  
  http://www.southparkstudios.com/full-episodes/s12e08-the-china-probrem
37. Re:Finally! by mysidia · 2012-06-19 18:26 · Score: 1
  
  But really, Erlang is one of the better functional languages, as they go. It may be tough to learn, but it has enough software written in it to prove its wirth.
  It has a "killer feature" that other functional languages lack; distributed nodes.... a clustering capability built into the language.
Great how the summary fails to fails to describe by Anonymous Coward · 2012-06-17 15:20 · Score: 1

what OpenFlow is, and the OpenFlow link goes to a non-existent page.
Re:Great how the summary fails to fails to describ by Anonymous Coward · 2012-06-17 15:28 · Score: 0

worse than that wtf is homeimprovement.com? Tim Allen move to the interwebs?
Oh Christ, no! by Anonymous Coward · 2012-06-17 15:29 · Score: 1

Haven't they ever played Beneath a Steel Sky?
LINC WANTS YOU, FOSTER.
1. Re:Oh Christ, no! by Anonymous Coward · 2012-06-17 20:12 · Score: 0
  
  Be Vigilent!
Re:Great how the summary fails to fails to describ by Anonymous Coward · 2012-06-17 15:35 · Score: 5, Informative

what OpenFlow is, and the OpenFlow link goes to a non-existent page.
Link was missing a ":" - https://www.opennetworking.org/standards/intro-to-openflow
Here's wikipedia: http://en.wikipedia.org/wiki/OpenFlow
Re:It begins. by Anonymous Coward · 2012-06-17 15:44 · Score: 0

Wow! I hope you are /.'ed from the internets.
Re:Warning! I'm a big ol' bootynude! Warning! by tywjohn · 2012-06-17 16:07 · Score: 1

Sounds great! Where do I sign up?
"For Dummies" explaination. by Anonymous Coward · 2012-06-17 16:28 · Score: 0

OpenFlow is a standard driven by the Open Networking Foundation (ONF), a non-profit organization dedicated to promoting Software-Defined Networking (SDN), a revolutionary approach to networking that brings software-like programmability to networks
Cliff-notes version please for those of us not network engineers.
1. Re:"For Dummies" explaination. by Anonymous Coward · 2012-06-17 18:45 · Score: 1, Informative
  
  Even for Network Engineers, that is completely meaningless.
  Anyway, an Ethernet switch or Router has two engines - The low level ('fowarding pane') of which is high speed 'copy packet from port a to port b'. It's not very bright, as that's almost all it CAN do, but it's very fast at that task. Of course, to be useful, an ethernet switch has to have more smarts -- for example, learning which switch port has which MAC on it and things like that. In a normal switch, it can, when confronted with a packet ask a higher level processor "oy! What should I do with this packet?" (expecting that second processor to answer "copy it to port c" or "drop packet" or something very simple like that.)
  OpenFlow decouples these two - normally they're part of the same physical box, and normally completely propritory. With this approach, the second 'what should I do' can now be implemented on different hardware - even a general purpose PC. You can write your own programs to manage how packets are forwarded.
  Exactly what this gives other than a research test-bed, I have no idea.
2. Re:"For Dummies" explaination. by Sique · 2012-06-17 20:09 · Score: 2
  
  You can for instance implement Layer 3 routing by dynamically changing the switch matrix on Layer 2. Essentially, IP adresses then become fancy MACs, and you know which IP adresses are reachable behind which port, allowing you to handle routing on Layer 2. Similarly you could implement higher level protocols to change your switch matrix, handle TCP errors already in the switch, saving hops and packets etc.pp.. In the end you get a box which seems to run each layer at wire speed.
  In some way this runs contrary to the Layer model, because you use higher level layers to just remap the Layer 2, but if you implement it transparently (e.g. the box looks correctly at each layer), it is just very fast without disturbing the layering.
  
  --
  .sig: Sique *sigh*
3. Re:"For Dummies" explaination. by ThePhilips · 2012-06-17 22:28 · Score: 2
  
  In the end you get a box which seems to run each layer at wire speed.
  That, if data in the traffic do not change much. From the ONF site, the router has to consult with the software what to do with the unrecognized packet. That cannot be fast. What's more, unless they change order of packets, the router would have to stall the traffic on the port. If change of order is deemed acceptable, they can go on routing other packets, but in the mean time other packets requiring software introspection might come and they would have to be buffered. Buffering on router is bad, because later comes the problem of how to insert the now-cleared-for-delivery packets in the stream.
  All in all, I do not see how even theoretically it can be "at wire speed": either lots of out of order packets with selectively long latencies or long stalls. More flexible and complicated you want it to be, more exotic cases you want to catch - the more overhead that would introduce.
  N.B. considering potential amount of traffic going through a 16-port gigabit ethernet router, the forwarding of some share of the traffic to the remote software for introspection (and receiving responses from it) would potentially require duh 16 gigabit ethernet ports.
  I'll go read the white papers, but it all looks pretty funny to me.
  
  In some way this runs contrary to the Layer model, because you use higher level layers to just remap the Layer 2, but if you implement it transparently (e.g. the box looks correctly at each layer), it is just very fast without disturbing the layering.
  Man, real networks pretty much never followed Layer model. It makes sense only on the paper. The likes of ARP and ICMP and DHCP fit the layer model only in mind of the most delusional. Networks were always built around RFC 1925, (1). Layer model is more of RFC 1925, (6a).
  
  --
  All hope abandon ye who enter here.
4. Re:"For Dummies" explaination. by Sique · 2012-06-18 02:20 · Score: 1
  
  That, if data in the traffic do not change much. From the ONF site, the router has to consult with the software what to do with the unrecognized packet. That cannot be fast. What's more, unless they change order of packets, the router would have to stall the traffic on the port. If change of order is deemed acceptable, they can go on routing other packets, but in the mean time other packets requiring software introspection might come and they would have to be buffered. Buffering on router is bad, because later comes the problem of how to insert the now-cleared-for-delivery packets in the stream.
  All in all, I do not see how even theoretically it can be "at wire speed": either lots of out of order packets with selectively long latencies or long stalls. More flexible and complicated you want it to be, more exotic cases you want to catch - the more overhead that would introduce.
  So you have never seen a Juniper router in action?
  That's essentially what they do, they take their routing table, lookup the MACs of the respective gateways on their ports and then generate a switch matrix which the routing component writes through to the switch.
  
  --
  .sig: Sique *sigh*
5. Re:"For Dummies" explaination. by ThePhilips · 2012-06-18 03:34 · Score: 1
  
  So you have never seen a Juniper router in action?
  I did, but it was way too many years ago. The Juniper was huge and pretty dumb, but could route fiber gigabit in realtime. :)
  
  That's essentially what they do, they take their routing table, lookup the MACs of the respective gateways on their ports and then generate a switch matrix which the routing component writes through to the switch.
  Oh. So the SDN means: that above + standardized interface to install your own "plug-in" for the e.g. MAC resolution?
  I had the (short) experience in the telecom and many years ago (I was told) it worked pretty much like that for PSTNs/etc. Also there I heard the terms "control plane" and "data plane" first time. I had this short employment where among other things I had to implement part of the "customer activation on first call" functionality: replace MAC with MSISDN, and it was pretty much the same thing you describe. Data plane of the switch (mostly hardware) was failing to "route" the record (and there were relatively few of them) and was forwarding it to control plane (mostly software) where it was decided what to do with it: allow it to be processed further or block. Based on that, switch configuration was updated with the new phone number and the action, and the record would be sent to data plane for reprocessing or dropped right away.
  So it would seem that the old telecom paradigm has finally found a way into the corporate switches and routers.
  P.S. The most recent official white paper on SDN turned out to be mostly marketing pep talk barren of technical details...
  
  --
  All hope abandon ye who enter here.
6. Re:"For Dummies" explaination. by BitZtream · 2012-06-18 05:30 · Score: 1
  
  Yes, but they don't look up that data by asking another computer over the wire and THAT is the difference that makes his statement.
  'Switched IP' or 'layer 2 routing' or 'layer 3 switching' is not even a little new or unique to this or Juniper layer 3 switches.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Apache 2.0 licensed by gQuigs · 2012-06-17 16:28 · Score: 1, Informative

for those curious what they meant by "commercial friendly open source".
http://www.apache.org/licenses/LICENSE-2.0.html
First link is wrong by rrohbeck · 2012-06-17 16:41 · Score: 2

Should be https://www.opennetworking.org/standards/intro-to-openflow

--
thegodmovie.com - watch it
Re:It begins. by Anonymous Coward · 2012-06-17 17:08 · Score: 0

Can we just ban the 'TheUltimateSmashAss' from the /. ?
yea, I know, he/she will create new acct in a heartbeat...
How about banning any post that refers to MCPC instead?
This is RIDICULOUS !!! ... I don't even feel like login in on /. anymore because of this ... moderators, PLS wake up !!!!
Celebrity marriages by girlintraining · 2012-06-17 17:18 · Score: 1

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. -_-

--
#fuckbeta #iamslashdot #dicemustdie
1. Re:Celebrity marriages by Anonymous Coward · 2012-06-17 19:27 · Score: 0
  
  I prefer "Forever Young" just because I like the melody
Re:Great how the summary fails to fails to describ by phantomfive · 2012-06-17 17:44 · Score: 4, Informative

Openflow is a protocol to let various routers communicate and coordinate how they route packets. That's my understanding of it. Google says they've gotten substantial efficiency improvements using it.

Erlang, of course, is a language designed to be as reliable and fault-tolerant as possible. I didn't know they used it in routers, but apparently some people want to.

--
"First they came for the slanderers and i said nothing."
Support structure by el_flynn · 2012-06-17 18:49 · Score: 2

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.

--
The Wknd Sessions - Malaysian and South East Asia independent music
You forgot about smalltalk by Viol8 · 2012-06-17 22:44 · Score: 2

Erlang is a functional language first , OO second. Smalltalk was designed to be OO from the ground up. In smalltalk even first class objects such as integers have methods and can be passed messages. Thats taking it too far IMO , but you can't get any more OO than that.
1. Re:You forgot about smalltalk by Pseudonym · 2012-06-18 11:38 · Score: 1
  
  I didn't forget about Smalltalk. When Alan Kay coined the term "object oriented", he didn't intend that everything should be an object. Erlang is closer to Kay's vision than Smalltalk is.
  
  --
  sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
2. Re:You forgot about smalltalk by Anonymous Coward · 2012-06-18 13:00 · Score: 0
  
  Dr. Alan Kay on the Meaning of Object-Oriented Programming
  http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
  "
  OOP to me means only messaging, local retention and protection and
  hiding of state-process, and extreme late-binding of all things. It
  can be done in Smalltalk and in LISP. There are possibly other
  systems in which this is possible, but I'm not aware of them.
  Cheers,
  Alan
  "
  take what you will from it - think erlang qualifies
Functional languages - whats the point? by Viol8 · 2012-06-17 22:50 · Score: 1

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 something profound?
1. Re:Functional languages - whats the point? by Anonymous Coward · 2012-06-17 23:38 · Score: 0
  
  Or am I missing something profound?
  You are missing something profound.
2. Re:Functional languages - whats the point? by Anonymous Coward · 2012-06-17 23:45 · Score: 0
  
  They tend to scale well across CPUs/cores.
  http://www.drdobbs.com/tools/212201710?pgno=1
  Oh, and you can get used to anything, once you use one of these for a while the light bulb will come on and it becomes less painful.
3. Re:Functional languages - whats the point? by Viol8 · 2012-06-17 23:48 · Score: 1
  
  Wow, did you think up that amazingly insghtful response all on your own or did you get help?
4. Re:Functional languages - whats the point? by wrook · 2012-06-17 23:59 · Score: 2
  
  Or am I missing something profound?
  Probably.
  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 more that, being hard core CS types, they are exposed to functional programming and once the get immersed find it easier to express what they want to say.
  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.
  Personally, I don't think a programmer's education is complete without achieving some level of fluency in functional programming. Personally, I sadly lack any competence at all and I really should spend more time practicing.
5. Re:Functional languages - whats the point? by alba7 · 2012-06-18 01:16 · Score: 2
  
  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 hard to implement these data structures in simple languages like C, but as you said, the verbosity would negate it's usefulness.
  But anyway, the problems with functional ideoms only start at this point. To take a made-up example in Perl syntax:
  sub foo($) { return $_[0] == 1 ? { key => +1, value => bar() } : { key => -1, value => baz() }; }
  What is the return type of foo? Without looking at the implementation of bar and baz you cannot tell. Functional languages make it very hard to separate interface and implementation. It takes a lot of support by the run-time systems and development tools to make up for it.
  
  --
  Post tenebras lux. Post fenestras tux.
6. Re:Functional languages - whats the point? by Anonymous Coward · 2012-06-18 02:04 · Score: 0
  
  The rest of the comment is written in haskell, and we are still waiting for it to terminate.
7. Re:Functional languages - whats the point? by Anonymous Coward · 2012-06-18 02:30 · Score: 0
  
  Hooray for contrived examples that are false 90% of the time!
8. Re:Functional languages - whats the point? by rb12345 · 2012-06-18 03:30 · Score: 1
  
  Dynamic typing is common in functional programming languages but not essential; Haskell is statically typed and is one of the purer functional languages.
9. Re:Functional languages - whats the point? by Anonymous Coward · 2012-06-18 03:42 · Score: 0
  
  You're missing a brain.
10. Re:Functional languages - whats the point? by Anonymous Coward · 2012-06-18 04:39 · Score: 0
  
  > Hooray for contrived examples that are false 90% of the time!
  Please show a concrete example where it is false. Clojure's OOP a la carte is made to address the necessary, complex, return types. Perhaps you're just trolling the wrong site.
11. Re:Functional languages - whats the point? by Z8 · 2012-06-18 04:40 · Score: 1
  
  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 has a particularly nice type system that can catch at compile-time issues that would generate run-time errors in C-like languages.
12. Re:Functional languages - whats the point? by BitZtream · 2012-06-18 05:40 · Score: 1
  
  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, the less likely it is that you should believe them.
  The people who know what they are doing have no need to tell others about why what they are doing is the right way on slashdot.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
13. Re:Functional languages - whats the point? by cduffy · 2012-06-18 06:01 · Score: 1
  
  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 grab locks, they don't interact with I/O subsystems, they don't... well, do anything that isn't interacting with that function's inputs and outputs, and their results are always 100% reproducible (same inputs -> same outputs).
  This means that huge sets of problems simply can't exist in parts of your codebase written to be purely functional, and that the parts of your codebase that do IO or similar things are isolated in well-defined locations, nice and far away from the highly testable business logic. It means that pure functions can always be executed in parallel, no locking required. It means that compilers can do all kinds of optimizations which would be utterly unthinkable in less-constrained languages (Example: Calling a pure function twice with the same arguments? It can't have side effects or return a different value for the second call, so the compiler can always just cache the return value from the first call and use it twice).
  Recursion isn't really what it's about at all -- the tendency to use tail-call optimization for loops is a minor side effect of the use of immutable data, and it's that decision to use immutable data that makes the huge difference.
14. Re:Functional languages - whats the point? by Anonymous Coward · 2012-06-18 08:46 · Score: 0
  
  To add to this: functional languages aspire to be mathematical. 2+2 is always 4, so the function ADD_2(2) would always return 4. As abstraction levels grow, you can then use the language to do things like prove software does X, or vet a proof in pure math. This is a goal of Haskell.
15. Re:Functional languages - whats the point? by cduffy · 2012-06-19 00:51 · Score: 1
  
  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 (actually, N-2), a stream processing system that needed to be massively parallel was first developed in Python. It scaled poorly to highly parallel architectures (where it was intended to be deployed), was rewritten in Clojure using the native concurrency primitives, and thereafter scaled linearly to the workload.
  Python really was a bad tool for that job -- the primary (CPython) runtime having a big lock everywhere meant that trying to scale cleanly required using a less-common runtime or eating the overhead of the multiprocessing module, and its native types being mutable meant that sharing references to them between threads was dangerous. Clojure really was an exceptionally good tool for that job -- its transactional memory system meant that you could have a large number of threads working in parallel on a problem, and still be able to get a consistent snapshot of the world without needing to freeze any of them by grabbing a lock.
  Would other tools have worked well for that task also? Certainly -- Scala would have many of the same benefits, to pick the first example that comes to mind -- but the claim that every language is of about equal utility towards every task fails even to a first approximation.
Intercal's COME FROM statement by Anonymous Coward · 2012-06-18 01:09 · Score: 0

I looked at Erlang once, and noticed it is the only serious language which implements Intercal's COME FROM statement. Erlang does not use that keyword, but control mysteriously transfers to somewhere else in an Erlang program without any indication of where it came from. Mentally yucky to get a grasp of.
Re:Great how the summary fails to fails to describ by lars_stefan_axelsson · 2012-06-18 01:45 · Score: 1

Erlang, of course, is a language designed to be as reliable and fault-tolerant as possible. I didn't know they used it in routers, but apparently some people want to.
Well, it's been used in "routers" for some time. :-)

--
Stefan Axelsson