OSDev.org

Brendan wrote:

NickJohnson wrote:All you need for real functional programming is a) closures, b) garbage collection, and c) proper lexical scoping.

Various imperative programming languages have some or all of these things. They have nothing to do with functional programming.

But look at the Wikipedia page on functional programming: under concepts, the first thing that is listed is higher order functions, which is what I'm talking about. Pure functions (i.e. non-mutable state) is also listed, but any language can use pure functions, even if it doesn't restrict you to using them like a pure functional language does.

Edit: so yes: I'm saying that various imperative languages are capable of functional programming, although those imperative languages are almost all very high level scripting languages (like Python and Lua.) Functional programming is a way of thinking, just like OOP, and therefore can be done in any language with certain basic facilities. In addition, Rusky's code didn't use any real functional programming by my definition; only topical language features that often appear in functional languages. But that's because it wasn't a functional language sort of problem.

Not to mention lexical scoping and closures originated in the lambda calculus.

Hi,

NickJohnson wrote:But look at the Wikipedia page on functional programming: under concepts, the first thing that is listed is higher order functions, which is what I'm talking about. Pure functions (i.e. non-mutable state) is also listed, but any language can use pure functions, even if it doesn't restrict you to using them like a pure functional language does.

So you're saying that any language can use higher order functions, but pure functional languages restrict you to using higher order functions?

I'm confused now - I thought you were objecting to my "Functional programming is imperative programming with an additional set of restrictions (and work-arounds for the restrictions)" comment, rather than agreeing with it.

Rusky wrote:Programming uses text both for historical reasons (teletypes) and because of its relationship with math, which is very text-oriented, even if it does use a lot of symbols. Text does have its advantages.

Historical reasons definitely, but those reasons don't really apply anymore. Maths I'm not so sure about - there's no concept of control flow in maths, and it's the control flow in software where graphics would have the biggest benefits.


Cheers,

Brendan

Brendan wrote:Hi,

NickJohnson wrote:But look at the Wikipedia page on functional programming: under concepts, the first thing that is listed is higher order functions, which is what I'm talking about. Pure functions (i.e. non-mutable state) is also listed, but any language can use pure functions, even if it doesn't restrict you to using them like a pure functional language does.

So you're saying that any language can use higher order functions, but pure functional languages restrict you to using higher order functions?

I'm confused now - I thought you were objecting to my "Functional programming is imperative programming with an additional set of restrictions (and work-arounds for the restrictions)" comment, rather than agreeing with it.

The key is that "functional programming" != "pure functional language", in a similar way to "object-oriented programming" != "pure object-oriented language". In addition, "pure functional" and "functional" are different: "pure functional" here means pure as in no side effects, while "functional" by itself entails the use of higher-order and first-class functions. The terminology is a mess.

Brendan: Stop missing the point on purpose and "agreeing" with people. It's an irritating, scummy tactic that doesn't help anyone, let alone your position.

Hi,

Rusky wrote:Brendan: Stop missing the point on purpose and "agreeing" with people. It's an irritating, scummy tactic that doesn't help anyone, let alone your position.

I'm not missing the point on purpose. The problem is that nobody seems to be able to adequately explain the difference between imperative and functional programming in a way that doesn't make functional programming sound like "change for the sake of change" and marketing hype full of meaningless jargon. The best (and most understandable) explanation I've managed to extract so far is this:

Combuster wrote:Both paradigms are turing-complete and therefore theoretically identical. The only difference between imperative and functional languages is that imperative expresses the steps from start to end (do this, this and that to get this), whereas a functional language expresses all steps from back to front (we want this, which means we need this and this, and for that we need ...).

Which basically translates to "change for the sake of change", but not the normal change; it's the worst kind of change (changing how programmers think rather than just mere syntax) with no apparent benefit to justify it (excluding things that could just as easily be added to imperative programming, and things that are already done by imperative programming, which includes pure functions).

Maybe the reason I'm missing the point is because there really is no point.


Cheers,

Brendan

gerryg400 wrote:

Brendan wrote:Now try to explain why programming is the only "engineering like" profession that uses text.

I think the problem is that many people who program aren't engineers.

Imagine building a bridge by starting at one side of the river and just heading toward the other side by bolting on pieces as you go. Then imagine once you've reached the other side telling everyone that this is version 0.1 of your bridge, that THIS BRIDGE IS PROVIDED BY THE BRIDGE BUILDER "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES etc. etc.

It's not really engineering. It's not really even "engineering like".

Let's drop the "programming" term and let's use "software engineering", because I have yet to encounter a real-life company where the customer (or even the business analysts) are capable to come up with a specification that allows to "just program" the solution.

Hell yes there is engineering involved. (Craftsmanship and art play a role, too, but engineering is a major part of it.)

The problem with the bridge-building analogy: A bridge engineer has a very well-defined set of available building materials and -techniques. His workforce has very well-defined roles and skills. The art of bridge building has been established over centuries. It is very, very clear what could and what could not be done. No-one would try to second-guess the amounts of steel, concrete, and time that the bridge engineer says he needs to build the bridge. If they would, the bridge engineer would step down and refuse to build it, citing appropriate laws for the security of bridges, and no-one would think less of him while there would be outrage at the person second-guessing his professional estimates.

Compare: A software engineer has a wild array of third-party hard- and software, development techniques etc.etc. to choose from, to the point that no-one really knows them all. The workforce has a wildly differing experience and skill set. The art of software engineering has evolved helter-skelter over the last few decades, with many early lessons learned no longer being appropriate today. The limits of what could and could not be done are pushed every day. Every half-baked manager feels entitled to tell you which tools to use, how to go about your work and how long you are allowed to take for it, and if you speak up against it, you are fired and replaced by someone else, with the appropriate remarks in your references.

There are many more points where the analogy doesn't hold, this was just from the back of my head.

That's why a successful software engineer is one that cannot easily be replaced by anybody that has wrriten a few lines in basic and "know" Windows or Linux. Once you have some unique competence, you cannot easily be replaced, and can start putting demands on people in charge. If they want to replace you for standing up for your ideals, they would need to pay a lot of money to educate somebody else, and in the mean time have nobody do the work.

Brendan wrote:Maybe the reason I'm missing the point is because there really is no point.

An awful lot of people who use functional programming languages for real-world applications seem to disagree with you
The Haskell Wiki explains some of the benefits of functional programming languages
Joel Spolsky, a well-known imperative-language programmer, explains the benefits of functional programming techniques
Paul Graham, a Lisp advocate, describes the advantages of using Lisp, why some people dismiss functional programming, and why they shouldn't
There's also this book with a chapter on "why functional programming"
Here's the introductory chapter of another book, describing how functional programming contributes to productivity
c2 wiki has a few pages on why functional programming matters, including some directed at exactly your point of view (starting halfway down the first page at "Discussion:")
Here's a paper describing how functional programming helps create new abstractions

I found all these by googling "functional programming" and "why functional programming," though I'd encountered most of them before.

As I've said before:

Rusky wrote:Functional programming is different from imperative programming in the way C is different from assembly:

You can do all the same things in C as in assembly, and most of the time there's a direct translation, although not always if you stick to "pure C" without inline assembly (and the naive translation is probably inefficient), but C is more abstracted from the hardware so it's a better tool for some things.

You can do all the same things in functional programming as in imperative programming, and most of the time there's a direct translation, although not always if you stick to "pure functional programming" without IO or FRP (and the naive translation is probably inefficient), but functional programming is more abstracted from the hardware so it's a better tool for some things.

We all know how silly it is to use machine/assembly language for everything. Functional programming is just another "level" above C, et. al. The "blub paradox" described in the Paul Graham article above describes why you might not appreciate this without actually trying functional programming.

rdos wrote:That's why a successful software engineer is one that cannot easily be replaced by anybody that has wrriten a few lines in basic and "know" Windows or Linux. Once you have some unique competence, you cannot easily be replaced, and can start putting demands on people in charge. If they want to replace you for standing up for your ideals, they would need to pay a lot of money to educate somebody else, and in the mean time have nobody do the work.

However any good software engineer makes it easy for someone else to take over his work. Solar will know a nice anecdote about someone like that (you?) getting replaced because of such behaviour.

Combuster wrote:However any good software engineer makes it easy for someone else to take over his work.

Why? The only way somebody could easily take over my job is if I make net-applications, write html-scripts or something of similar complexity. My work being easy to take over only means that I work with unqualified tasks.

No, your work being easy to take over means you've structured it well enough for someone of similar skill level to understand.

Rusky wrote:No, your work being easy to take over means you've structured it well enough for someone of similar skill level to understand.

Only if a similar skill exist in enough people. That is the whole point of whom is easily replacable (net and html-programmers) and who isn't (embedded programmers that know a lot about hardware). For the first group there are ready-made education that teaches the basics, for the latter there aren't. The first group is also much larger.

@rdos:

Most employers (surprisingly, not all of them) are perfectly aware that:

• People take vacation and need to be replaced temporarily.
• People might become ill, or have an accident, and be unavailable for extended periods of time.
• People might leave for greener pastures.

Anyone who doesn't structure his work in a way that makes it as easy as possible to replace him is a danger to his employer. Again, most employers are aware of this, and take precautions against this eventuality. That is why the smarter companies insist on using a specific set of languages or technologies, employ 4-eyes principle, and require documentation to be done in a specific way, instead of leaving it up to the individual to "get it done".

Relying on the obscurity of your work to ensure your continued employment can - and hopefully will - backfire violently.

On the other hand there are the really good developers, who structure and document their work, at a quality that even someone with lesser skills can take over once the major part of the work is done. These people rely on the quality of their work giving them references that makes finding a new job child's play, instead of trying to cling to one software project forever. (The flaw in that idea should be pretty obvious.)

And believe me, that latter group does not have kind words for the former, because it's the former developer's approach of "I'm a real programmer, I don't have to follow the rules" that gives our profession a bad reputation, and usually results in someone having to clean up the mess they left behind.

Edit:

My work being easy to take over only means that I work with unqualified tasks.

Of course it takes someone with adequate experience to replace you. He still would need some introduction into the subject domain. But your job as a software engineer is to do your job in a way that:

1) someone with adequate experience is comparatively easy to find (i.e., write your source in C/C++, Java, Python etc. rather than INTERCAL or MyCoolLanguage) and

2) the domain introduction can be given by someone else if you are unavailable; i.e. it must not be "all in your head".

Bottom line, replacing you might not be easy if you are highly skilled, but you must not make it any harder.

It seems more like you are talking about "inhouse" empoyers vs consultant employers. Personally, I have nothing good to say about consultant employers that jumps from one project to the other, or people that change jobs every few years. Regardless of how good their documentation is, they always leave a mess behind, that some "inhouse" employer need to live with, or some new consultant employer is put on. IOW, I don't find your model a tiny bit efficient.

And yes, I've worked on the same company since 1995 (16 years), and during this time we have made it a successful business. I cannt see that it would have been if we have outsorced programming tasks.