|
Prev: swift MT940 files
Next: Is there neq for strings?
From: Ray Dillinger on 2 Jun 2005 00:43 Matthias Buelow wrote: > And btw., I haven't used Pascal in a dozen years but my latest info is > that Turbo Pascal still lives in the form of "Delphi" for the Windows > platform. Surely not "dead" as I understand it. There's also FreePascal, which compiles approximately the same language as Turbo Pascal/Delphi, (and inherits most of Borland's linguistic extensions) and is opensource, works fine on Unixes, etc. It's in active use by several people, making games. Bear
From: Xah Lee on 3 Jun 2005 16:20 The Rise of “Inheritance†In well-thought-out languages, functions can have inner functions, as well as taking other functions as input and return function as output. Here are some examples illustrating the use of such facilities: subroutine generatePower(n) { return subroutine (x) {return x^n}; } In the above example, the subroutine generatePower returns a function, which takes a argument and raise it to nth power. It can be used like this: print generatePower(2)(5) // prints 25 Example: fixedPoint: subroutine fixedPoint(f,x) { temp=f(x); while (f(x) != temp) { temp=f(temp); } return temp; } In the above example, fixedPoint takes two arguments f and x, where f is taken to be a function. It applies f to x, and apply f to that result, and apply f to that result again, and again, until the result is the same. That is to say, it computes f[f[f[...f[x]...]]]. FixedPoint is a math notion. For example, it can be employeed to implement Newton's Method of finding solutions as well as many problems involving iteration or recursion. FixedPoint may have a optional third parameter of a true/false function fixedPoint(func,arg,predicate) for determining when the nesting should stop. In this form, it is equivalent to the “while loop†in procedural languages. Example: composition: subroutine composition(a,b,c,...) { return subroutine {a(b(...c...))}; } The above example is the math concept of function composition. That is to say, if we apply two functions in sequence as in g[f[x]], then we can think of it as one single function that is a composition of f and g. In math notation, it is often denoted as (g∘f). For example, g[f[x]]→y is the same as (g∘f)[x]→y. In our pseudo-code, the function composition takes any number of arguments, and returns a single function of their composition. When we define a subroutine, for example: subroutine f(n) {return n*n} the function is power of two, but the function is named f. Note here that a function and its name are two different concepts. In well-thought-out languages, defining a function and naming a function are not made inseparable. In such languages, they often have a keyword “lambda†that is used to define functions. Then, one can assign it a name if one so wishes. This separation of concepts made many of the lingustic power in the above examples possible. Example: lambda (n) {return n^2;} \\ a function (lambda (n) {return n^2;})(5) \\ a function applied to 5. f = lambda (n) {return n^2;} \\ a function is defined and named f(5) \\ a function applied to 5. lambda (g) {return lambda {g(f)} } \\ a function composition of (g∘f). The above facilities may seem exotic to industrial programers, but it is in this milieu of linguistic qualities the object oriented paradigm arose, where it employees facilities of inner function (method), assigning function to variable (instantiation), function taking function as inputs (calling method thru object), and application of function to expressions (applying method to data in a class). The data-bundled-with-functions paradigm finds fitting application to some problems. With the advent of such Objet-Oriented practice, certain new ideas emerged. One of great consequence is the idea of inheritance. In OOP practice computations are centered around data as entities of self-contained boxed sets (objects). Thus, frequently one needs slightly different boxed sets than previously defined. Copy and Pasting existing code to define new boxed sets quickly made it unmanageable. (a messy set of classes). With powerful lingustic evironment and habituation, one began to write these new boxed-subroutines (classes) by extending old subroutines (classes) in such a way that the new subroutine contains all variables and subroutines of a base subroutine without any of the old code appearing in the body of the subroutine. Here is a pseudo-code illustration: g = subroutine extend(f) { new variables ... new inner-subroutines ... return a subroutine that also contains all stuff in subroutine f } Here, “extend†is a function that takes another function f, and returns a new function such that this new function contains all the boxed-set things in f, but added its own. This new boxed-set subroutine is given a name g. In OOP parlance, this is the birth of inheritance. Here, g inherited from that of f. f is called the base class or superclass of g. g is the derived class or subclass of f. In functional terms, inheritance mechanism is a function E that takes another function f as input and returns a new function g as output, such that g contained all enclosed members of f with new ones defined in E. In pure OOP languages such as Java, the function E is exhibited as a keyword “extendsâ€Â. For example, the above code would be in Java: class g extends f { new variables ... new inner-subroutines ... } Here is the same example in Python, where inheritance takes the form of a class definition with a parameter: class g(f): new variables ... new inner-subroutines ... Data are the quintessence in computation. Because in OOP all data are embodied in classes, and wrapping a class to each and every variety of data is unmanageable, inheritance became the central means to manage data. ----- to be continued tomorrow. This is part of an installment of the article “What are OOP's Jargons and Complexities†by Xah Lee, 20050128. The full text is at http://xahlee.org/Periodic_dosage_dir/t2/oop.html © Copyright 2005 by Xah Lee. Verbatim duplication of the complete article for non-profit purposes is granted. The article is published in the following newsgroups: comp.lang.c,comp.lang.c++,comp.lang.lisp,comp.unix.programmer comp.lang.python,comp.lang.perl.misc,comp.lang.scheme,comp.lang.java.programmer comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns Xah xah(a)xahlee.org ∑ http://xahlee.org/
From: Matthias Buelow on 3 Jun 2005 19:53 Xah Lee wrote: > to be continued tomorrow. Please don't... mkb.
From: Andrea Griffini on 4 Jun 2005 08:24 On Wed, 01 Jun 2005 23:25:00 +0200, Matthias Buelow <mkb(a)incubus.de> wrote: >Of course it is a language, just not a standardized one (if you include >Borland's extensions that make it practical). The history of "runtime error 200" and its handling from borland is a clear example of what I mean with a product. You are of course free to call even Microsoft Access a language (and make long term investment on it) if you want. Andrea
From: Dale King on 5 Jun 2005 00:47
Anno Siegel wrote: > Tassilo v. Parseval <tassilo.von.parseval(a)rwth-aachen.de> wrote in comp.lang.perl.misc: > >>Also sprach Dale King: >> >> >>>David Formosa (aka ? the Platypus) wrote: >>> >>>>On Tue, 24 May 2005 09:16:02 +0200, Tassilo v. Parseval >>>><tassilo.von.parseval(a)rwth-aachen.de> wrote: >>>> >>>> >>>>>[...] I haven't yet come across a language that is both statically and >>>>>strongly typed, in the strictest sense of the words. I wonder whether >>>>>such a language would be usable at all. >>>> >>>> >>>>Modula2 claims to be both statically typed and strongly typed. And >>>>your wonder at its usablity is justified. >>> >>>I used a variant of Modula-2 and it was one of the best languages I have >>>ever used. That strong, static type checking was a very good thing. It >>>often took a lot of work to get the code to compile without error. >>>Usually those errors were the programmers fault for trying to play fast >>>and loose with data. But once you got it to compile it nearly always worked. >> >>I am only familiar with its successor Modula-3 which, as far as I >>understand, is Modula-2 with uppercased keywords and some OO-notion >>bolted onto it (I still recall 'BRANDED' references). >> >>I have to say that doing anything with this language was not exactly a >>delight. > > > I've been through Pascal, Modula2 and Oberon, and I agree. > > These languages had an axe to grind. They were designed (by Niklas > Wirth) at a time of a raging discussion whether structured programming > (goto-less programming, mostly) is practical. Their goal was to prove > that it is, and in doing so the restrictive aspects of the language > were probably a bit overdone. I fail to see how they were that different in terms of structured programming than C. The main benefit I was talking had more to do with types. It had types that were not compatible just because they had the same base type. For example you could have a type inches that was an integer and a type ounces that was also integral. Just because they were both integral did not make them type compatible. You couldn't just assign one to the other without you as the programmer explicitly saying that it was OK (by casting). In the environment I was programming in (engine controls for cars) where safety was a critical thing and a programming bug could kill people that safety was a very good thing. I think that also has a lot to do with why the government uses Ada. > In the short run they succeeded. For a number of years, languages of > that family were widely used, primarily in educational programming > but also in implementing large real-life systems. > > In the long run, the languages have mostly disappeared from the scene. I've posted before that hardly any language that has ever been somewhat popular has actually died (depending on your definition of that word). When asked for someone to name one once I got Simula for example (the forerunner of OO languages). Turns out that it continues to actually grow in popularity. > It has been discovered that "structured programming" is possible in > about any language. It turns out that programmers prefer the > self-discipline it takes to do that in a liberal language over the > enforced discipline exerted by Papa Pascal and his successors. There are lots of reasons they have not taken over, although Ada is still in wide use. It seems to me that too many people like playing with dangerous power tools without the guards in place. -- Dale King |