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 | » ]
Leo Lipelis

Posts: 111
Nickname: aeoo
Registered: Apr, 2006

Re: The Myth of Paradigms and TMTOWTDI Posted: Sep 12, 2006 5:54 PM
Reply to this message Reply
Advertisement
The problem is that the coolest and most expressive languages come from research/academic environments. And researchers just don't care about pragmatic use of the language. They don't care about IDEs or complete libraries. In fact, they hate such things in some cases, because they spoil the purity of the language (see Scheme, which specifically does NOT define many things to keep the standard small and understandable). The result is that you have a very cool language that's very hard to use in a down to earth pragmatic sense.

Making nice, bug-free, complete GUI libs is boring to a language researcher who just wants to play with garbage collection. So the result is you get some implementation that has state of the art gc and nothing else.

If someone could create a package equivalent to Java in scope out of a research language, of commercial quality, I am sure it would get used widely, especially if it's also open source/free software.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: functional/procedural schism Posted: Sep 12, 2006 7:04 PM
Reply to this message Reply
Max Lybbert wrote Assembly line robots often need to be hard real-time
That's a phrase I can look up even when I'm blissfully ignorant of the details :-)

"Towards Formally Verifiable WCET Analysis for a Functional Programming Language"
http://moss.csc.ncsu.edu/~mueller/wcet06/accepted/1_paper.pdf

They write both that "Functional languages have rarely been applied to hard real-time systems, partly because they are perceived as hard to cost" and that "The use of purely functional expressions within Hume boxes simplifies both the construction of the cost model and the corresponding proofs, by avoiding the need for dataflow analysis, alias analysis and other consequences of the use of side-effects. This also improves the accuracy of the result."

John Cowan

Posts: 36
Nickname: johnwcowan
Registered: Jul, 2006

Re: The Myth of Paradigms and TMTOWTDI Posted: Sep 12, 2006 9:36 PM
Reply to this message Reply
What do you mean, "only used in a specific niche"? Perl is used in a whole pile of specific niches: system administration, Web programming, one-offs come to mind at once, and a quick look at Wikipedia immediately adds glue, reporting, finance programming, and bioinformatic programming.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: functional/procedural schism Posted: Sep 12, 2006 10:22 PM
Reply to this message Reply
> /* [Diggins] 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.
>
> [Guouy] Huh?
> */
>
> I don't like to put words in Diggins's mouth, but I
> believe the idea here is that you can usually get better
> control of timing in a procedural language. Sometimes a
> "helpful" language (regardless of programming style,
> functional, procedural, OOP, etc.) will cache values, or
> the garbage collector will decide to run, or something.

Performance isn't my concern as much as the fact that any interaction with the external world is order dependent.

My point was that expressing the actions of an assembly robot is precisely the act of defining a procedure. As a result it fits the metaphor of procedural programming better than that of functional programming.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: The Myth of Paradigms and TMTOWTDI Posted: Sep 12, 2006 10:29 PM
Reply to this message Reply
> What do you mean, "only used in a specific niche"? Perl
> is used in a whole pile of specific niches: system
> administration, Web programming, one-offs come to mind at
> once, and a quick look at Wikipedia immediately adds glue,
> reporting, finance programming, and bioinformatic
> programming.

I'll accept that my statement is somewhat overstated. My point is that Perl isn't quite as widespread in commercial software development as one might expect given its flexibility, and age.

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: The Myth of Paradigms and TMTOWTDI Posted: Sep 13, 2006 1:30 AM
Reply to this message Reply
> why aren't true multi-paradigm languages like Scala and OCaml more popular?

For Scala: Maybe because it's been out with decent tool support only for 8 months? (a more experimental version with less support was released 2 years before that). How long did it take Python and Ruby to grow large user communities?

That said, I think you are right that multi-paradigm is not a silver bullet. It makes experienced programmers more productive and is a source of new discoveries for curious ones. But people who just want a simple recipe to their recurring programming problems are probably better served with picking the right paradigm and sticking with it.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Paradigm or Style? Posted: Sep 13, 2006 4:03 AM
Reply to this message Reply
> iirc (which in this case is doubtful) when people started
> talking about programming paradigms they were using
> paradigm in a more specific and stronger sense than
> the dictionary definition - they were riffing on Kuhnian
> paradigm shifts to suggest that the existing
> programming paradigm would be over-turned and
> replaced by a new paradigm.
>
> "The Structure of Scientific Revolutions"
> http://www.des.emory.edu/mfp/Kuhn.html
>
> In that sense, multi-paradigm is a contradiction in
> terms.

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). It's similar with things like quantum mechanics, which you typically don't need to take into account, unless you're concerned with atomic or subatomic phenomena.

Thus, typically, earlier "paradigms" (in fields like physics) were not "wrong" - they just don't cover all cases, and may have been approximations, that could become intolerable in different conditions. If they had been completely wrong (or at least didn't provide any predictive power), they never would have been "paradigms" in the first place.

Isaac Asimov has a great article about this, "The Relativity of Wrong" (http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm).

Even the view that the earth is flat (which me may find laughable today) is _almost_ right (but the approximation becomes intoleable from an astronomical point of view). As he writes:

"In the early days of civilization, the general feeling was that the earth was flat. This was not because people were stupid, or because they were intent on believing silly things. They felt it was flat on the basis of sound evidence.
[...]
Another way of looking at it is to ask what is the "curvature" of the earth's surface Over a considerable length, how much does the surface deviate (on the average) from perfect flatness. The flat-earth theory would make it seem that the surface doesn't deviate from flatness at all, that its curvature is 0 to the mile.

Nowadays, of course, we are taught that the flat-earth theory is wrong; that it is all wrong, terribly wrong, absolutely. But it isn't. The curvature of the earth is nearly 0 per mile, so that although the flat-earth theory is wrong, it happens to be nearly right. That's why the theory lasted so long."

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

V.H.Indukumar

Posts: 28
Nickname: vhi
Registered: Apr, 2005

Re: The Myth of Paradigms and TMTOWTDI Posted: Sep 13, 2006 4:13 AM
Reply to this message Reply
Considering Perl's ugly syntax, it is no wonder that it did not go so far.

Language design, in addition to the obvious technical skills it requires, also needs a sense of beauty from the language designer. It is not only what paradigm(s) one chooses but also how they are represented as code. In a way, Ruby has far more elegance due to the choice of tokens, the sentence layout etc. For me,
i := 1 is far more elegant than var i = 1 , although both convey exactly the same thing. A block x.each {a | puts 's'} is much better than x.each (a)=>{puts("s")} although it conveys the same thing. As we are spending a huge amount of our waking hours coding, it would be nice to have something asthetically good to look at.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Paradigm or Style? Posted: Sep 13, 2006 5:29 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.


> 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 ;-)

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

In a former life Posted: Sep 13, 2006 5:57 AM
Reply to this message Reply
Once upon a time, I used to run a "three-axis cutting machine" (the company that made my machine was later bought by Gerber -- http://www.gerbertechnology.com/gtwww/03Prods/cam/MedHigh.htm ). I worked at a company that made airline upholstery. Because I didn't know anything about programming at the time, I though the cutter was incredibly high technology. That's partly because I thought the computer kept track of the cutting head's position by knowing acceleration, velocity, time, direction and momentum.

Turns out I was probably wrong. The machine used servo motors ( http://www.societyofrobots.com/actuators_servos.shtml ), which a computer can tell "turn X degrees" (and knowing the gears attached to that motor the computer knows how far the cutting head will travel). This machine had to move reasonably quickly, without making dramatic turns while the blade was down, and without dragging material around (a function of how fast the cutting head was moving and how much pressure was behind it). The more I think about it, programming this machine with a functional programming language would be possible.

But imagine a car assembly line with multiple robotic arms working on the car frame at a time. Each arm has to promise to stay within a particular zone at a particular time so that it won't hit the other arms that are in their particular zones. It's not enough to promise to get the right result; it's also necessary to go in the right order and take the right amount of time doing so.

The guys who program these robots think sequentially ( http://en.wikipedia.org/wiki/Industrial_robot#Movement_and_singularities ), "do this, then do that").

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: functional/procedural schism Posted: Sep 13, 2006 6:23 AM
Reply to this message Reply
Christopher Diggins wrote

> Performance isn't my concern as much as the fact that any
> interaction with the external world is order dependent.
>
> My point was that expressing the actions of an assembly
> robot is precisely the act of defining a procedure. As a
> result it fits the metaphor of procedural programming
> better than that of functional programming.

I'm struggling to understand what you mean.

Why is the fact that any interaction with the external world is order dependent a special concern? Basic arithmetic operations (subtraction, division, exponentiation) are non-associative and so they are also order dependent (5-4)-3 != 5-(4-3)

What if I rephrase your statement slightly: expressing the actions of an assembly robot is precisely the act of defining an algorithm.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: functional/procedural schism Posted: Sep 13, 2006 6:55 AM
Reply to this message Reply
> I'm struggling to understand what you mean.
>
> Why is the fact that any interaction with the external
> world is order dependent a special concern? Basic
> arithmetic operations (subtraction, division,
> exponentiation) are non-associative and so they are also
> order dependent (5-4)-3 != 5-(4-3)
>
> What if I rephrase your statement slightly: expressing the
> actions of an assembly robot is precisely the act of
> defining an algorithm.

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.

Jesse Williamson

Posts: 9
Nickname: chardan
Registered: Dec, 2005

Re: The Myth of Paradigms and TMTOWTDI Posted: Sep 13, 2006 8:43 AM
Reply to this message Reply
Hi, Issac!

> Considering Perl's ugly syntax, it is no wonder that it
> did not go so far.

C and C++ were (are :>) both widely criticised for ugly syntax, and they both went very far.

Perl may not be used extensively in Microsoftland, but in Linux (and Unix) shops it is very popular. Nearly any system will have it installed, and it itsn't exaggurating to say that most depend on it in some way to function.

> Language design, in addition to the obvious technical
> skills it requires, also needs a sense of beauty from the > language designer.

No, it doesn't. Look at Perl. :-P

> It is not only what paradigm(s) one chooses but also how
> they are represented as code. In a way, Ruby has far more > elegance due to the choice of tokens, the sentence layout > etc.

While I agree with you in spirit, I do also think that at a certain point it is more important to ask about what the language lets you express than it is to worry about "second order" issues such as syntax preferences.

English is a nice example, because it has abyssmal spelling rules and a really bizzare grammar. But you can still say a lot with it.

But, I do think that a nice syntax is important to. Except, see, I prefer i = 5 over i := 5... oh dear...

Anyway, I'm not exactly trying to defend Perl here. I am saying that what constitutes a sucessful languge in the media often has to do with "pretty", but what constitutes a succesful language in the real world almost never does.

_Jesse Williamson ;-};

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: The Myth of Paradigms and TMTOWTDI Posted: Sep 13, 2006 9:49 AM
Reply to this message Reply
> > why aren't true multi-paradigm languages like Scala and
> OCaml more popular?
>
> For Scala: Maybe because it's been out with decent tool
> support only for 8 months? (a more experimental version
> with less support was released 2 years before that). How
> long did it take Python and Ruby to grow large user
> communities?

You are right, that is probably the biggest reason. I forgot how new Scala is.

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: functional/procedural schism Posted: Sep 13, 2006 10:05 AM
Reply to this message Reply
> > I'm struggling to understand what you mean.
> >
> > Why is the fact that any interaction with the external
> > world is order dependent a special concern? Basic
> > arithmetic operations (subtraction, division,
> > exponentiation) are non-associative and so they are
> also
> > order dependent (5-4)-3 != 5-(4-3)
> >
> > What if I rephrase your statement slightly: expressing
> the
> > actions of an assembly robot is precisely the act of
> > defining an algorithm.
>
> 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.


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 ;-))

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