Learn you Func Prog on five minute quick! Functional Programming is the great paradigm shift that is sweeping through software development. The object-oriented era of coding is at last drawing to an inevitable and shameful close. We can – and we must! – all join hands and skip gaily into a brave new world, where sloppy state and careless side effects are excised …
This post has been deleted by its author
I have been reliably informed by someone who's good at reliably informing me of programming things in general that Prolog, like everything else in the computational universe, is just a subset/bastardization of LISP.
That said, I've used Prolog for a couple of live applications. Provided its the kind of logic (or list classification) problem that's suitable for this language and provided you don't go off the deep end trying out the latest fad in Theoretical Prolog its actually pretty neat -- you get quite a compact, fast, solution to your problem. I'd like to do more of it but unfortunately my work is in real time computing where even with the latest 'n greatest hardware we really can't afford the overhead and indeterminate nature of a lot of programming languages and techniques.
As for JavaScript -- someone mentioned it, didn't they? -- this is an example of a language that should have been strangled at birth. Its got just about everything wrong with it (and if you don't believe me try running a typical website with Firebug active -- its a rare website that doesn't have coding errors these days, its just that this language deals with this problem by not bothering to tell you)(and the programmers aren't motivated to look -- what was that about "firing concrete covered bricks at a wall to build it" again?)
Indeed, but I could show you lots of shit C++ code, does that mean that C++ is also crap? (ok, bad example, but true for any language!)
Javascript is strange, with a lot of unusual features and gotchas, but that doesn't mean you can't write elegant robust code in it that works without throwing errors.
It would help if the people writing the javascript were programmers and not designers....
"But in the new approach, as you know, the important thing is to understand what you're doing, not to get the right answer." - Tom Lehrer
In that spirit, the answer to Review Exercise 1 is surely that the amount of time spent in Tutu's as a London undergraduate is proportional to its nominative determinism.
This post has been deleted by its author
I'm sorry, but no CPU on the planet works internally with abstract objects, methods, or any other cobblers you want to invent. All OO did was to help revive the textbook printing industry, since everything you needed to know about procedural programming had already been written by the end of the 1980s.
So we should convert our abstractions of the world into machine code?
First of all there is no dichotomy between OO and procedural programming. OO is merely a different way to express the procedures. Functional programming shouldn't be excluded either. It's just another tool in the box.
Secondly, what's wrong with letting a compiler convert whatever high-level code into machine code? For a while now it's been known that compilers can produce better machine code than people can. They can also do it a lot faster, too. And CPU cycles are cheaper than people, too.
Sure, there are situations, especially where memory is extremely limited where you need to program as close to the machine as possible. But you know what's even better than writing machine code? Creating hardware that's optimised for your code. All hail FPGAs and hardware acceleration.
This post has been deleted by its author
Again, going back to Erlang, the original base concept of OO was message passing, something that Erlang does very well.
http://www.infoq.com/interviews/johnson-armstrong-oop
One of gripes of Alan Kay (Smalltalk man) is that the term 'Object Orientated' was 'stolen' by certain language promoters (C++, correctly, says its a multi-paradigm language) - Java! - got into this stupid 'Is-A' hierarchy game, rather than pick up the core concept - messages between objects.
OO is used for simple problems. Without messaging, OO does not scale that well.
*WITH* multiple-inheritance your risk having a complex fckup.
C++ naively supports multi-inheritance in the language. M-I should onyl be used carefully.
Java saw the problems and dodged it slightly.
One of gripes of Alan Kay (Smalltalk man) is that the term 'Object Orientated' was 'stolen' by certain language promoters
I think you'll find that Kay's gripe is actually the misuse of the term "object-oriented". "Object Orientated" is a similar term invented by people for whom there can never be too many capital letters or syllables.
Incidentally, I see this thread was a trolling exercise so successful the troll eventually reclaimed his bait and went home.1 Good show!
1I.E., back to the shelter of his bridge.
Yes, well. If you were to believe books about procedural programming then a program would represent a mouth that blurts out "hello, world!" to everyone who passes by.
Try something like this instead...
http://voices.canonical.com/jussi.pakkanen/2013/10/15/c-has-become-a-scripting-language/
"I'm sorry, but no CPU on the planet works internally with abstract objects, methods, or any other cobblers you want to invent."
Intel had a stab at it with the iAPX432, pretty sure there have been others too, I mentioned the oft-derided 432 because I vividly remember my incredulity turning to horror as I read the data book. :)
"Come to think of it, a floating point number is a pretty abstract object compared with mere binary digits.
They used to be defined in software, you know."
They still *are* 'defined' in software, and even 'implemented' in software too. ;)
I did wonder whether it would be worth binning hardware FP support - and supplying a bunch of super-quick bit-vector ops to replace it. The fact is that transistors are so cheap and the memory is so far away from the ALU/FPU now FP hardware costs virtually nothing and is a lot quicker.
Real programmers, (like me), write real procedural code. End of. And it's better than the OO tat that's written by people fresh out of uni with a piece of paper saying they can program.
Yes, but that's not because procedural code is better than OO code, that's because the people fresh out of "uni" (we used to call it university in my day but that was before the cuts) are wet behind the ears and full of themselves and terrified of their student loans ... whereas you are a 1980s_coder with (presumably) 30-ish years of experience and probably have a clue.
OO code is really just like procedural code, except that the procedures belong to objects that can parcel up some state that's shared between procedures ... you don't even have to do everything the OO way, but can mix it with procedural code and get the best of both worlds (unless you're writing in something like Java, which is so anally obsessive about being an OO language that it doesn't let you do anything else).
Wise programmers considers all the tools in their toolboxes before choosing one over another. Almost every tool is the best one for something (even perl and javascript, I'm told).
"Wise programmers considers all the tools in their toolboxes before choosing one over another."
Very often it is the case of: "to the person with a hammer - everything is a nail". Says one who wrote one-off system utilities in Fortran nearly 50 years ago because it was quicker than doing it all in the assembler language. There was a time when BASIC took over that function - then PASCAL - then VBA.
OO code is really just like procedural code, except that the procedures belong to objects that can parcel up some state that's shared between procedures ...
When I first encountered OO in a C++ class, I'd only written Fortran and BASIC. I started off thinking of Objects as structures with functions built in, and the rest was straightforward
"..When I first encountered OO in a C++ class, I'd only written Fortran and BASIC. I started off thinking of Objects as structures with functions built in, and the rest was straightforward.."
That is what I did for an embedded C program when I was pining for objects. Also C header files can be used as interfaces. OO is basically a set of rules applied to structs and function pointers.
> I started off thinking of Objects as structures with functions built in, and the rest was straightforward
That's true. But the way OO is taught in schools, you can end up swallowin too much Koolaid and get tied up in unproductive knots and arguments.
Suppose you have a function which acts on a Foo and a Bar. Should it be a method of Foo, or a method of Bar?
If you want to make an object Baz which makes use of the functionality of Foo, should it be a subclass of Foo or contain a reference to an instance of Foo?
Is a Square a restricted type of Rectangle, or is a Rectangle an enhancement to Square?
Polymorphism is one of those things which is apparently inherent to OO, but in practice rarely used. But it always makes it hard to follow the flow of code. e.g.
def foo(o):
o.bar()
Where in your source code is method 'bar' defined? Whereas:
def foo(o):
Mymodule.bar(o)
is completely unambiguous.
When you go back to simple procedures and data arguments, these problems go away.
It's probably been a decade since I last used/taught C++, but as I recall the *only* difference between a struct and a class (apart from spelling) is that the default visibility for class members is private and for struct members it's public.
C++, I don't miss it at all...
When I first encountered OO in a C++ class, I'd only written Fortran and BASIC. I started off thinking of Objects as structures with functions built in, and the rest was straightforward
Exactly. C++ as "C with RAII" works nicely for me (okay, I admit to having occasionally found templates to be more convenient/safe than macros too).
Wise programmers considers all the tools in their toolboxes before choosing one over another. Almost every tool is the best one for something (even perl and javascript, I'm told).
Whereas in most cases, the PHB gives you a box full of red hammers - being as how they're the "corporate standard" and then expects you to build a functional moon rocket. Out of cheese.
I speculate you program a lot in C. That's fine. You can use C++, which I guess you shouting is about, just as "better C". You get even better performance. The compiler can do and does _much_ more for you. Ignore the MBA style blatherings about "object oriented" and just sit down and learn.
And comparing yourself, a seasoned programmer, to "people fresh out of uni..." is quite unfair.
Just for perspective, I am speaking as a HPC person routinely producing code that should never be inflicted upon anybody under any circumstances.
You can use C++, which I guess you shouting is about, just as "better C".
No, you can't. C++, whatever its virtues,1 is not "better C".
For example, any C program that uses the standard allocator, if written well, is not valid C++. In C, the return value of malloc (or realloc or calloc2) should never be cast. Doing so hides the error - a fatal one in some C implementations - of failing to include a valid declaration of malloc via <stdlib.h>. In C++, on the other hand, the cast is required, if the lvalue receiving the result has any type other than void*.
You can write C-like code, with some differences, in C++, and produce well-written C++, though it would be using so little of the language there's little point. Yes, you may get better performance if your program is CPU-bound. Most are not; a large majority of software is in embedded, business, or consumer applications, most of which are I/O-bound.
1And I admit Stroustrop - with whom I have myself argued this point - has made good arguments for cases where C++ is better than C even for simple tasks.
2Though calloc has no justification appearing in any well-written C program.
"And not a moment too soon!!!"
The problems you complain about with OO stem from standard operating practice. Take an existing idea - in this case existing ideas about data structures, add something - in this case glue the procedural stuff onto it, wrap the whole thing up in new nomenclature to disguise what you've borrowed, add some over-the-top stuff - e.g. your example about wheels, and tell the world you've invented something completely new.
Between them the new nomenclature and OOT stuff is enough to put many of us off for years.
OK, I left out inheritance but the basic principle is "data structures on steroids" but calling it that wouldn't have brought the same kudos.
There's OO and OO.
The original Design Patterns book was the first book I read where the intent, and advantages of, proper object design came through. It requires a fair bit of attention to get it, but it sure doesn't talk down to you and it sounds very little like your critique.
Most OO books do not so much sin the way you claim, they sin by immediately focusing on inheritance, because... well, it is easy to explain. Never mind that inheritance is only one facet, and often the least useful, of OO. There's also often a tradeoff: some things like dynamically composing objects together at runtime are extremely powerful and hard to do procedurally, but also make debugging exponentially harder.
And most intro to Java books also sin by assuming that, since you don't know the One True Language (TM), then you don't know objects either so they must launch in an OO intro.
On the other hand, as an example of less than useful gratuitous object orientation, read this little nugget.
http://csis.pace.edu/~bergin/patterns/ppoop.html
Start out with a simple hack (on top) and go down to the author's brilliant suggestion at end. All other things remaining equal, which bit of code would you be rather looking at 2 AM with an angry customer on the line?
Notice the .edu in the above url, maybe that's where all those pants uni programmers come from ;-)
Except that to a mathematician programmers have completely corrupted the meaning of the word "variable"; the mere sight of a statement like
x = x + 1
is enough to make them go and lie down in a dark room.
Speaking as a mathematician, no - rather, programmers have completely corrupted the meaning of the "=" symbol (if standard keyboards had a "←" symbol* this problem would never have arisen...)
*Wait a minute, seems mine does, lets se oh, it didn't do what I expectede. Hey, it's got another on oh that diblimeydn't work out either. Wonder what
does? Or
Rationale: This makes it easier to reason about the code.
I've never seen that used as a justification, curried and tuple forms are essentially equivalent in terms of analysis, indeed it's easy enough to convert between them. Rather curried functions are one of the bits of scaffolding at the heart of true functional programming, i.e. functions as first class objects. Partial application of curried functions is one of the key methods of advancing code re-use by making a general function specific in a given context.
e.g. to add four to each of a list of numbers on SML:
fun curry f a b = f(a,b)
val input = [3, 6, 9, 12, 15]
val input_plus_4 = map (curry (op +) 4) input;
For the uninitiated:
"op +" converts the built in + operator into tuple form, i.e. a + b becomes +(a,b).
curry (op +) uses the curry function we supply to convert that into curried form: + a b.
(curry (op +) 4) creates a function which supplies an implied first parameter: + 4 b.
map (curry (op +) 4) supplies that new function as a parameter to the map function, which returns a function which applies it to each item in a list.
map (curry (op +) 4) input then applies that final function to the input and returns a new list.
I wouldn't have said that's any easier to analyse, but it certainly allows for complex ideas to be expressed quickly and succinctly.
This post has been deleted by its author
#! /usr/bin/env python3
from functools import partial
seq_7_10_13_16_19 = map(partial(int.__add__, 4), range(3,18,3))
If your only tool is a hammer, all tasks start to look like nails. Functional techniques are handy tools. Some languages provide a wide selection of tools without straining the syntax. Very often, you do not get a choice about the language. I think it is worth looking at how functional techniques are expressed in the language you are stuck with. If a task can be completed clearly and concisely with functional programming then you should not hammer the screws in.
-- Very often, you do not get a choice about the language. --
In particular, the choice of language is typically made by either a manager who read something nice about a particular language (or framework) in a magazine left in the seat-back pocket while returning from a junket, or by the founder who wrote pretty much all of V1.0 of the product. The one who has been nudged aside by the rest of the board after "explaining" difficulties in development by way of an interpretive dance on the boardroom table, naked.
If you are being paid to program, remember "He who pays the piper selects which tartan goes on the bag"
seq_7_10_13_16_19 = map(partial(int.__add__, 4), range(3,18,3))
Much too ugly*:
seq_7_10_13_16_19 = [ val + 4 for val in range(3,18,3) ]
* but you are obviously illustrating the FP aspect of it... list comprehensions are about as functional as I like to go ;)
I will meditate upon Functional Programming in Fortran
John Backus - who ran the team that invented FORTRAN - had some thoughts on the matter.
Not functional constructs in Fortran itself, mind you; he thought all the existing functional languages, to say nothing of the procedural ones, were too undisciplined. His '77 Turing Award lecture is well worth reading, even if you don't agree with it.
Programmers who have grown weary of everyday language paradigms may want to try J, a language that combines the power of APL with Backus' function-level programming and a few other goodies.
It was a CS exercise, to solve a puzzle in ML about lining up colours or something, I remember completing up to and including the 'mediochre*' parts of the exercise because at the time I only barely comprehended what was going on, and I'm sure that involved a struggle with recursion and Appleton Tower 8th floor had windows that looked easily big enough for a monitor to fly through...
I understand it now but the learning experience is always such a thing to cherish. The 'new keyboard' icon but for the repeated forehead impacts, not the coffeesplurt.
* mediochre = more of a beigey sort of shade whilst not actually reaching the holy tint of magnolia.
Same here at Uni. It was our first language taught so we could see the difference in paradigms, with Ada next. I remember some sadistic exercise in converting decimal to roman numerals via FP, using Miranda.
I've only recently stopped taking the medication for those flashbacks, 22 years later ...
Miranda memories - not at all nice
FTFY
It's like one of those dreams where you arrive naked at an exam hall for a class you forgot to attend. That's even without spending much time in Tutu's.
I was slightly surprised to see it missing from Ms Stob's language list - perhaps it isn't a practical language to use...
Isn't all abstraction from and, not and or a deviation from what cpu's understand?
And I usually get lost two chapters into any book on Functional programming* (or OO programming for that matter). My eyes usually start to glaze over then, the text starts to read as gibberish written by a lunatic (or a lengthy extract copied from Aleister Crowleys LIberX - yup, I've actually tried to read that).
* Hasn't stopped me putting together an overly complex Xmonad config together.
Sometimes I think if you want to learn something, the last thing your should do is read a book.
I'd already had a drink when I wrote that, no idea what I meant, still think it works though (just like every program I've written after a few).
I usually go looking for some vague example and run with that, only running to the manual if I run into a problem (if there is a manual, I've taken on projects where the manuals had been gathering dust un-updated for a decade or so).
"Sometimes I think if you want to learn something, the last thing your should do is read a book."
Get an example programme as a scaffold - cut&paste it to do what you want. By then you are ready to read the manual, or go on the course - and actually grasp what is being taught. However the lecturer doesn't usually appreciate the people who are potentially in step with them.
My first programming course was in System 4 Assembler in wooden Hut "K". Three of us sat on the back row and whipped through the exercises very quickly - tirelessly answered the lecturer's questions - and asked him awkward ones.
Came the day that our assignment programs came back from their first machine runs. The lecturer chortled as he gave us the print outs showing our programs had compiled cleanly - but had not worked as expected.
His smile faded when we pointed out the problem. He was so used to students' programs not compiling the first time - he had deliberately excluded the I/O macro libraries to save computing time and his departmental budget. On resubmission our programs worked faultlessly.
I can't remember the last time I laughed so much reading an article - simply inspired. Thank you :-)
$ scala -e 'println(Seq(5937258800786469487L,7454127455866286707L,
2333816157527044713L,8387145410718886944L,
7597045224257953900L,7020662622960182574L)
.flatMap(_.toHexString).grouped(2)
.map(a=>a.map(c=>Integer.parseInt(c.toString,16)))
.map(d=>(d(0)<<4)+d(1)).map(_.toChar).mkString)'
Real programmers can write Perl in any language.
$
But
I know this is bad practice but we had a program which mined a load of data from a database, reformatted and then stored it in a way useful for analysis. It was in Java and there was a lot of code of the form
stringBuffer.append(ident + ',' + a + ',' + b + ',' + c + '\n');
Now I know this is Bad Practice and a whole lot of other things but it worked, reliably and consistently. And it churned through millions of tuples in multiple tables in sensible time.
Then we acquired a new programmer who was asked to do something with this code. And we ended up with every occurrence changed to
stringBuffer.append(ident).append(',').
append(a).append(',').append(b) .append(',').append(c).append('\n');
[edit-the original single line version appears to have borked el reg formatting]
Because it was (a) more functional and (b) more correct and (c) more readable.
And...because if you asked it, Netbeans would carry out the conversion automatically.
Programming would be absolutely great if it wasn't for programmers.
At least in Haskell parlance, currying and uncurrying is conversion between a function that takes an argument of a product type (typically a tuple) and a function that takes multiple arguments of the types of elements of that product type
uncurried_func :: (Hight, Weight) -> HoleSize
curried_func :: Hight -> Weight -> HoleSize
The only connection to partial application is that you need a function with multiple arguments, so if your original function was uncurried, you will need to curry it before you can use it for partial application.
So many things in life run on the see-saw. Or the pendulum, if you prefer. Attitudes go one way and then back another. In so many areas of life. When I first learned programming, functional programming was all there was: input-process-output, complete with GOTOs and big runs of spaghetti (no sauce, alas). Then it was STRUCTURED programming, you dummies! Organize it so other people can read it (not to mention yourself six months later). Then it was OOD. And now we're trending back the other way? Really? Very interesting.
And, yes, Verity, it was past time to hear from you. We also need to hear from the BOFH and Lord Bong soon. Regular columnists are good.
Some years back I started sketching out syntax extensions to managed OO COBOL for functional constructs. (It's easier to do it with the managed version of the language because the frameworks do a lot of the work; I wasn't feeling the urge to create the Nth implementation of first-order-function support in the code generator.) Wandered away from that project, though.
In our current managed OO COBOL you do have support for anonymous delegate methods and closures, so you can do some functional stuff. At first glance I think I could implement monads using the existing language features.1 Hmm... COBOL with monads. "Think of them as END-PERFORMs with side effects!" Tempting, very tempting.
1Of course, by Kolmogorov's argument I can implement any programming language feature I want in OO COBOL, because it's Turing-complete, so all I need to do is implement an interpreter for a language having that feature. But that would be cheating.
Or, as my wife (the uber-goddess of literal) would say, I'm sorry dear but you just can't do math with letters. They're letters for God's sake. You might be able to do math with words like "six" and "two" but letters like "x" and "y"? No wonder you're confused all the time.
Her son says that she, having gone to a parochial school, balances her checkbook with "nun-math".
I just say, "Yes, dear."
Stobb forgot to discuss one important dogma of Functional Programming: No loops, ever. Use mapping, reduction or recursion instead. For the last part, I have never quite understood what makes recursion always superior over good old "while". In those cases where a loop would suffice, recursion is just a GOTO to the beginning of the function. On the other hand, in a pure FP language where variables can never be reassigned, a "while" would be pointless, so these go hand in hand.
"Stobb forgot to discuss one important dogma of Functional Programming: No loops, ever."
Not really, this is generally just a byproduct of maintaining pure functions. Often the compiler will optimize recursion into a GOTO, other times it builds a stack of function calls. , A while loop checks the state of some memory location, does some stuff updating at least one memory location and jumps into a goto. Using recursion or higher-order functions is a way to prove you aren't relying on state mutation, and thus certain types of reasoning about the code are guaranteed to be correct in a way you couldn't guarantee if there was a while loop capable on manipulating internal state.
That hits home. I've been working with FP fans for years now. Yes, they have a huge structure that contains the state of the whole program and gets passed as a parameter to everything. There's a tiny bit of it that's polymorphic, and because of that, now every function is polymorphic, usually on types that have nothing to do with what the function is doing. I still have to understand how that's better than OO.
I probably don't get it because I just do GUIs, which are supposed to be a trivial thing if you just consider user actions as rows in a database or something like that.
Respectfully to All—Eiffel
- General purpose OO
- Functional through Llamba functions as "Agents"
- Void safe (no null reference pointers—ever!)
- SCOOP (Simple Concurrent Object Oriented Programming)—multithreading with a single keyword
- Multiple Inheritance (implemented with sanity and a smart compiler)
- Design-by-Contract (i.e. "built-in" testing)
- C/C++ friendly (i.e. easily linked to C/C++ or in-lined as needed)
- Has its own code analysis tools (Eiffel Inspector)
- Generics (i.e. ARRAY [G] --> ARRAY [CAR], ARRAY [ANIMAL], etc.)
- Simple (i.e. only 59 keywords)
I have now taught more than a dozen people to effectively code in Eiffel. For an experienced programmer with a mentor, this process takes no more than a few days at about 10hrs/day. I have even taught one person who did not know how to program at all in about two weeks (crash course in Object Theory and Computer Science + Eiffel/through-Eiffel).
I know, I know—cue the whining about "no-one-uses-it" in 3 ... 2 ... 1 ...
I have been using it on an $multi-million / 900 KLOC project for nearly 6 years. One does not follow opportunity—one makes it!
Llamba functions
Which are like the lambda operator, but combined with llamas, so they have beaks for eating honey.
If you see a Llamba function in the source code, you should cry out "¡Peligro! ¡Hay llambas!".
(But your point is well taken, since Eiffel is the only programming language ever to have both OO and functional features.)
I've recently discovered Groovy. OO and Functional. Oh, and scripting. I learned a lot of Haskell at Uni and the beauty of it was staggering. Its type system sublime. Groovy is a great way to add functional (and tonnes of other great) stuff to Java code. I won't harp on about it here, but it's well worth a look.
Great article, BTW.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
