The Artima Developer Community
Sponsored Link

Weblogs Forum
The Myth of Paradigms and TMTOWTDI

62 replies on 5 pages. Most recent reply: Jan 16, 2019 7:57 PM by Henna Smith

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 62 replies on 5 pages [ « | 1 2 3 4 5 | » ]
Alex Herz

Posts: 9
Nickname: softcore
Registered: Aug, 2005

Re: The Myth of Paradigms and TMTOWTDI Posted: Sep 13, 2006 3:33 PM
Reply to this message Reply
Advertisement
I think that TMTOWTDI is the great thing about most programming languages (as long there is a clear correleation of each possible way and the outcome). This is what allows us to construct software and allows for step wise refactoring.

Image programming was like maths. Most analytical problems have only a small set of possible solutions and some are very hard to find. So instead of constructing solutions we'd spend most of our time to find the one/two right combination of rules and axioms that work...horrible :)

I think the more freedom your language gives you the nicer the design/solution you can possibly create. Best practices and coding standarts guide you when solving standard problems.

So I don't think TMTOWTDI stops a language from being adapted widely.

Alex

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: functional/procedural schism Posted: Sep 13, 2006 11:42 PM
Reply to this message Reply
James Watson wrote
As I read it, what he is saying is not that you cannot do this in a functional language but that the procedural paradigm is a more natural fit for that particular problem. The reference you gave before said that it could be done in a functional language as 'efficiently' as it could be done in a procedural language. That says nothing about how naturally the functional solution fits the task.
And that reference continued "Besides this, the possibility of reasoning about algorithms, in order to prove that the programs are correct, gives Clean and Haskell a clear advantage over languages like C and Oberon."

nes wrote
In other words: if you have to put a sequence number beside each expression to define the execution order or if your Haskell program consists 95% of I/O monads you might as well just use a procedural language (and you will probably get more meaningful error messages too ;-))
I think that just begs the question. I've seen the claim that it's easier to reason about such programs when state is explicit rather than implicit, I haven't seen a convincing demonstration.

(It also seems that extending a program that explicitly maintains state would be more awkward than changing an imperative program with implicit state - but if we're mainly dealing with I/O that doesn't seem to be an issue.)

Max Lybbert wrote
The guys who program these robots think sequentially...
Well maybe that's more to do with the robot's capabilities than the guys who program them :-)

I think you can easily make the point that imperative languages suitable for programming assembly robots exist, and as-far-as-we-know functional languages suitable for programming assembly robots don't exist yet. (It seems like Hume may demonstrate how practical functional programming is for hard real-time embedded systems.)

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

true multi-paradigm language Posted: Sep 13, 2006 11:49 PM
Reply to this message Reply
nes wrote ...there is really no true multi-paradigm language out there.
Not even Oz? ;-)

Christopher Diggins wrote Perhaps some unwritten language could unify everything elegantly.
Is Oz a candidate?

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Paradigm or Style? Posted: Sep 14, 2006 2:43 AM
Reply to this message Reply
> Terje Slettebø wrote
> > I'm not sure about that paradigms. even in the Kuhnian
> > sense, are mutually exclusive.
> >
> > To take the list given here
> > (http://en.wikipedia.org/wiki/Paradigm_shift), one
> example
> > is the shift from Newtonian physics to relativistic,
> and
> > quantum mechanics. However, surprise - surprise,
> Newtonian
> > physics is still alive and well. For situations not
> > involving speeds approaching the light speed, or
> enourmous
> > masses, Newtonian physics give perfectly good answers
> (and
> > much simpler calculations).
> -snip-
>
> Seems like your ignoring the description of Kuhnian
> paradigm shifts given on that wikipedia page - the point
> is not that the old paradigm is wrong in every aspect but
> that it's wrong in too many aspects.

Maybe it wasn't clear from the above, but my point was that the earlier "paradigm" wasn't completely _replaced_ by the new one - we still learn Newtonian physics, today. However, in the Wikipedia article, it says:

"Kuhn [...] states that when a scientific paradigm is _replaced_ by a new one, albeit through a complex social process, the new one is always better, not just different." (my emphasis)

The point was not whether the earlier "paradigm" was considered completely wrong, or not (like you said, it wasn't necessarily that).

> > However, with "paradigms" in the realm of computer
> > science, it's not at all clear that one paradigm is
> > "better" or "more accurate" than another, although
> > different "paradigms" (or computational models)
> typically
> > work better for different things (as Christopher
> mentions
> > in the blog).
>
> It's not at all clear to me that describing these things
> as paradigms was more than another example of our talent
> for hype and promotion of the new new thing ;-)

Right. "paradigm" may not be the best word for this, in computer science, but a word like "style" is a little too ambiguous, I think (it could refer to anything from the placement of curly braces, to... :) ). The term used in "Concepts, Techniques, and Models of Computer Programming" is "computational model".

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: functional/procedural schism Posted: Sep 14, 2006 5:39 AM
Reply to this message Reply
> James Watson wrote
> As I read it, what he is saying is not that you cannot
> do this in a functional language but that the procedural
> paradigm is a more natural fit for that particular
> problem. The reference you gave before said that it could
> be done in a functional language as 'efficiently' as it
> could be done in a procedural language. That says nothing
> about how naturally the functional solution fits the
> task.

> And that reference continued "Besides this, the
> possibility of reasoning about algorithms, in order to
> prove that the programs are correct, gives Clean and
> Haskell a clear advantage over languages like C and
> Oberon."

It would seem to me that whether the program operates without failure would be only a small issue to the devlopers of such routines. Making sure the robots are doing the proper actions in the proper sequence in the right amounts of time would be a much larger concern. I'm pretty sure that using Haskell and Clean don't help with these issues.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: functional/procedural schism Posted: Sep 14, 2006 12:14 PM
Reply to this message Reply
> James Watson wrote
-snip-
> It would seem to me that whether the program operates
> without failure would be only a small issue to the
> devlopers of such routines. Making sure the robots are
> doing the proper actions in the proper sequence in the
> right amounts of time would be a much larger concern. I'm
> pretty sure that using Haskell and Clean don't help with
> these issues.

I think Max Lybbert already made the same point about hard real-time, and Christopher Diggins already said that wasn't what concerned him. (My guess is that we could also find some imperative languages which are unsuitable for hard real-time for the same reasons.)

What I've been trying to understand is whether we're just assuming that there's a fundamental mismatch between functional programming languages and robotics programming.

Reading "Traditional functional programming techniques provide an elegant substrate for constructing and manipulating behavior-based control systems" suggests to me that there isn't a fundamental mismatch.
http://www.cs.northwestern.edu/~ian/grl-paper.pdf

It'll be interesting to see how the Hume programming language progresses.
http://www-fp.dcs.st-and.ac.uk/hume/index.html

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: functional/procedural schism Posted: Sep 14, 2006 3:11 PM
Reply to this message Reply
The more I think about it, the more I like a "make me one of these" programming model for (manufacturing) robots. That sounds like it would fall under the traditional definition of a functional language. In complex systems, you could use some traditional AI techniques to do what you want.

In fact, with our cutting table,we would draw up the patterns in AutoCAD, convert them to DXF ( http://en.wikipedia.org/wiki/ASCII_Drawing_Interchange_file_format ), and the table would draw the DXF pattern with the knife. It could as easily have been PostScript. From our point-of-view as operators, there was no traditional programming involved.

OTOH, and I think this is where Diggins was going (although I don't ahve a great track record of knowing what Diggins means), the software that actually ran the cutting head (translated the DXF file into a cut piece) was probably written in a procedural language. To be honest, it was probably written in assembly language, which isn't as bad a fit as it sounds. Each action the cutter takes is one step in a series of actions. Since the cutter has to operate in the real world, one step at a time, using a language that defines each step makes sense (at that level).

Making the higher-level interface useful and reasonable also makes sense. Which, BTW, is what CNC operators do, and which (as I understand it) falls under the "make me one of these" school of "language" design (but which does so through a lower level "G-code" -- http://en.wikipedia.org/wiki/CNC ).

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: functional/procedural schism Posted: Sep 15, 2006 5:54 AM
Reply to this message Reply
> I think Max Lybbert already made the same point about hard
> real-time, and Christopher Diggins already said that
> wasn't what concerned him. (My guess is that we could also
> find some imperative languages which are unsuitable for
> hard real-time for the same reasons.)

My point wasn't about real-time. It's that the ability to 'reason' about correctness isn't going to matter if all these other things are difficult. Personally I find the 'reason about correctness' argument extrordinarily weak in general.

> What I've been trying to understand is whether we're
> just assuming that there's a fundamental mismatch
> between functional programming languages and robotics
> programming.

I'm not saying there is. My personal experience is that the imperitive model is easier for most non-expert developers to understand because people (are trained from an early age to) think of solutions as a series of steps. Combined with the fact that most robot activities are a rigid series of steps, it seems likely that a procedural model (or OO) will be more suited to the task. But all of this is hand-waving conjecture, I'll readily admit.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: The Myth of Paradigms and TMTOWTDI Posted: Sep 15, 2006 6:49 AM
Reply to this message Reply
> There are two big schisms in the programming community:
> one along dynamic versus static type checking and another
> along functional and procedural programming styles. I
> believe that there is no real difference between these
> so-called paradigms, and they are just different, but
> limited ways, at looking at the complete space of
> programming problems.

I do not thing dynamic/static is a "paradigm".

I also think the correct categorization is imperative vs functional, not procedural vs functional.

> The big reason for the functional/procedural schism is the
> fact that computers are in fact machines that do separate
> yet very important things:
> <ol>
> <li>perform actions</li>
> <li>perform computations</li>
> </ol>

Not really. Machines only perform actions. For machines, computations are side effects.

> Consider that when you want certain kinds of computations
> performed, functional programming is often the correct way
> to do things. When you want to write a controller for an
> assembly line robot then then procedural programming is
> usually the best approach.

But all imperative languages can do computations in the exact same way (...well, more or less) functional languages do.

> This leads to a separate but intriguing question: why
> aren't true multi-paradigm languages like Scala and OCaml
> more popular? I propose that the fundamental problem of
> being a multi-paradigm language is that there is no clear
> correct way to do things. They suffer from the challenges
> of TMTOWTDI (There's More Than One Way To Do It). This may
> remind you of another reasonably succesful language, Perl,
> which suffers from severe marginalization. It is a truly
> multi-paradigm language, which is only used in a specific
> niche.

Not really. The real reason is that these other languages don't offer anything significant over the mainstream languages.

My Java programs are usually correct from the first go. Isn't that an argument in favor of functional languages? When I was programming in C++, I had great pains with manual memory management. With Java these pains are gone, and 99% of the bugs of my programs are now gone. I have no reason to move to another language, and so are most of other programmers.

> Well then what's the answer? These issues seem to be add
> odds with each other. I don't know the answer. Perhaps
> mixed language code? Perhaps some unwritten language could
> unify everything elegantly.

Actually all programming languages are essentially the same thing, and what differs is the amount of glue code need to be written in order to make a specific task.

Even functional languages are the same, because for any serious work you have to use the imperative style (i.e. monads)...

And the so-called "proof of correctness" of functional programs is just a myth: there is no algorithm to prove the correctness of another algorithm. I had to run my dissertation' program several times to catch the errors, although it was written in ML, and the program perfectly typechecked. I have seen my professors being puzzled from a deadlock that shouldn't be there, again in ML.

Object-orientation is nothing but pattern matching on different types: if your object is an A, do this, otherwise if your object is a B, do that etc.

Finally stack-based languages are also the same, with the only difference being that the arguments are implicit and on the stack.

Programming essentially comes down to being able to abstract the computations in your mind in order to see if the outcome is the desired one. And the abstractions are possible due to prior knowledge, because in some way or another, computations are similar.

And in order to back this last statement of mine up, I will use the factorial example in another thread that we tried to analyse and find its input / output values: the only reason we expect a positive return value is because we know we only multiply positive values. If we did not know that, we wouldn't know what to expect, and therefore we wouldn't know how to analyse/prove the algorithm's correctness. In a sense, we already have done factorial in our minds, and we simply project that knowledge over our problem. Since programming involves unknown problems of high complexity, there is no way to prove correctness of anything.

Therefore the reason that other "better" languages are not adopted is that they do not offer something so advanced as to really change the way we are programming. I have often heard functional languages supporters claim that "once the program typechecks, it is usually correct". Well, guess what? that happens to me with Java as well; and to my colleagues. So why should I learn Haskell or Ocaml, for example? just to type a few less characters? it really doesn't matter any more...especially when the Java platform solves so many problems of the Haskell side (libraries, support, documentation, etc).

Vladimir Nesov

Posts: 27
Nickname: robotact
Registered: Aug, 2005

Re: The Myth of Paradigms and TMTOWTDI Posted: Sep 16, 2006 8:26 AM
Reply to this message Reply
> And in order to back this last statement of mine up, I
> will use the factorial example in another thread that we
> tried to analyse and find its input / output values: the
> only reason we expect a positive return value is because
> we know we only multiply positive values. If we did not
> know that, we wouldn't know what to expect, and therefore
> we wouldn't know how to analyse/prove the algorithm's
> correctness.

It's encoded in algorithm itself so automatic tool can as well see it.

> Since programming involves unknown problems of
> high complexity, there is no way to prove correctness of
> anything.

In previous specific example you talked not about abstract 'correctenss', but of specific things, like factorial being positive. Most of vulnerability categories boil down to specific assertions, like buffer overflow. Most of errors in software in fact may be formalized as possibilities of raising different kinds of exceptions. So making sense of what correctess means is really quite a minor problem.

Roger Voss

Posts: 27
Nickname: rogerv
Registered: Aug, 2005

Re: The Myth of Paradigms and TMTOWTDI Posted: Sep 16, 2006 11:27 PM
Reply to this message Reply
When I first started programming I built single applications out of combinations of Object Pascal, C, and MC68000 assembly language.

On Windows I used C, C++, and x86 assembly.

For automotive telematics applications on WinCE I used C++, DHTML/JavaScript, XML/XSLT, and MIPS assembly language

In solutions for insurance industry I used Perl, C++, and x86 assembly language.

For some fairly recent enterprise destop apps I used C#, C++, and x86 assembly language.

For my J2EE apps I've used Java, XML (Spring IoC is effectively XML-based declarative programming), and Groovy.

For 20 years I've always found myself in the position of building real-world working applications out of a mixture of computer languages.

Now I've heard talk of people that just do programming in a single language - and supposedly even for their entire career. I regard that as fantasy talk or the ramblings of madmen. There's no way real applications could be built if stuck within the confines and limitations of any single computer language.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

the range of possibilities Posted: Sep 17, 2006 9:21 AM
Reply to this message Reply
Roger Voss wrote
>
> For 20 years I've always found myself in the position of
> building real-world working applications out of a mixture
> of computer languages.
>
> Now I've heard talk of people that just do programming in
> a single language - and supposedly even for their entire
> career. I regard that as fantasy talk or the ramblings of
> madmen. There's no way real applications could be built if
> stuck within the confines and limitations of any single
> computer language.

That has been your "real" experience - in an industry as wide-ranging as software development, thinking that our individual "real" experience defines the range of possibilities is simply a failure of imagination.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Myth of Paradigms and TMTOWTDI Posted: Sep 18, 2006 5:56 AM
Reply to this message Reply
> My Java programs are usually correct from the first go.
> Isn't that an argument in favor of functional languages?

Sorry, you lost me with these two sentences. How is that an argument for functional languages?

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: functional/procedural schism Posted: Sep 18, 2006 7:56 AM
Reply to this message Reply
James Watson wrote My personal experience is that the imperitive model is easier for most non-expert developers to understand because people (are trained from an early age to) think of solutions as a series of steps.
I think it's true that we commonly work through a list of steps, but the steps don't necessarily need to be completed in strict order. It's also true that we commonly work with declarative statements - recipes ask for egg yolks, how you get them out of the shell is unspecified.

Let's not forget how many non-expert developers successfully use spreadsheets - a spreadsheet is a functional programming language.
http://web.cecs.pdx.edu/~black/S3S/PJ.html

(As a programmer, I've forgotten those things I had to learn to become a programmer - so it surprises me when I see how difficult it is for people to move from calculating with a spreadsheet to programming the spreadsheet using an imperative language.)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: functional/procedural schism Posted: Sep 18, 2006 10:19 AM
Reply to this message Reply
> James Watson wrote My personal experience is that the
> imperitive model is easier for most non-expert developers
> to understand because people (are trained from an early
> age to) think of solutions as a series of steps.

> I think it's true that we commonly work through a list of
> steps, but the steps don't necessarily need to be
> completed in strict order.

For a manufacturing robot, they often do, however. Many fabrication processes are extremely sensitive to the order in which steps are executed.

> It's also true that we commonly
> work with declarative statements - recipes ask for egg
> yolks, how you get them out of the shell is unspecified.

That's prefectly in line with imperative languages, especially OO.

> Let's not forget how many non-expert developers
> successfully use spreadsheets - a spreadsheet is a
> functional programming language.
> http://web.cecs.pdx.edu/~black/S3S/PJ.html

I guess that's true. I never thought about it that way.

Flat View: This topic has 62 replies on 5 pages [ « | 1  2  3  4  5 | » ]
Topic: After Java and C# - what is next? Previous Topic   Next Topic Topic: A Hazard of Covariant Return Types and Bridge Methods

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use