Tech Support > Computers & Technology > Programming > Head scratching in language X superior to language Y
Head scratching in language X superior to language Y
Posted by thomas.mertes@gmx.at on February 26th, 2008


I am wondering: Has this goup finally turned in an
advocacy group?

IMHO programming languages have different application
areas and different strengths or weaknesses.

As you can find at least one bug in every nontrivial
program you can be sure to find bad concepts and
wrong design decisions in every programming language.

Besides advocacy discussions I have some points:
- I see it as bad when a programming language is
dominated by one company or is only available under
one operating system.
- I don't like programming languages which force you
to write nonportable programms. There are plenty
examples where it is presented as advantage to access
functions of the xyz library which is only available as
closed source under one operating system. Why is
this functionality not provided in a portable way in the
language library (with available source under an open
source license). The answer is simple: Such languages
and libraries are created to drive the people away from
open source. Therefore I refuse such programming
languages. I hope I am not the only one who thinks this
way: We should not allow that the embrace and extend
strategy works for programming languages.
- Generally I thing that a programming language should
be driven by the open source community instead of
a company.

Btw.: If you want to see different sorting algorithms, look here:
http://seed7.sourceforge.net/algorith/sorting.htm

If someone complains that they are not generic...
Just put them inside a template like this:

const proc: generateSort (in type: elemType) is func
begin

const proc: insertionSort (inout array elemType: arr) is func
local
var integer: i is 0;
var integer: j is 0;
var elemType: help is elemType.value;
begin
for i range 2 to length(arr) do
j := i;
help := arr[i];
while j > 1 and arr[pred(j)] > help do
arr[j] := arr[pred(j)];
decr(j);
end while;
arr[j] := help;
end for;
end func;

end func;

and then call 'generateSort' for every type you want an
insertionSort:

generateSort(integer);
generateSort(string);

After that you can use 'insertionSort' for integer arrays and
string arrays. As far as you have comparison operators
defined for a type you can generate any sorts.

Btw.: I choosed 'insertionSort' because the example was
short.

Btw2.: Seed7 has also a 'sort' function as many other
programming languages. Therefore you are not forced
to write your own sort functions.

So far about superiority...

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

Posted by Richard Heathfield on February 26th, 2008


thomas.mertes@gmx.at said:

No, not really, despite one or two people's best efforts.

Your article makes some excellent points, which will strike a chord with a
number of polyglots here.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Posted by rmoldskr+usenet@online.no on February 26th, 2008


thomas.mertes@gmx.at wrote:

For a _general purpose_ programming language, perhaps,
but for specialised languages it's really not an issue.
ELisp only runs in Emacs (or XEmacs), but that's not a
problem, since it's only used to make stuff _for_ Emacs.

[SNIP~
I prefer it being driven by standardisation bodies. That
way, languages might actually be thought through and not
merely implemented.

--
Leif Roar Moldskred

Posted by thomas.mertes@gmx.at on February 27th, 2008


On 26 Feb., 22:53, rmoldskr+use...@online.no wrote:
I agree

While I think that standardisation of programming languages
is importent it IMHO obvious that standards that establish
existing practice are more successful than the standards
which try to invent new things. Designed by committee is
usually not a good idea.

If you look at some programming languages you can see
that either they can be traced back to one person:
C --> Dennis Ritchie
C++ --> Bjarne Stroustrup
Perl --> Larry Wall
Python --> Guido van Rossum
Ruby --> Yukihiro Matsumoto
or they are promoted by a company:
Java --> Sun
C# -> Microsoft
Programming languages designed by a committee usually
have a bad reputation.

For clearness of design I prefer things (not only programming
languages) that are designed by one person or a small
group. Languages designed by companies always have the
danger of a vendor lock in. Therefore I am very sceptical
towards people which promote programming languages
which are created to drive people to one operating system
(specially when these languages are promoted by a quasi
monopolist). Although such things like Mono exist I doubt
that programs written at the home operating system of this
language are portable to other operating systems. I have
seen just to much "portable" programs with drive letters,
include files and librarys which are only available at one
operating system. And the quasi monopolist is promising
for decades that the next os will be better regarding
portability, documentation of features ...

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

Posted by Randy Howard on February 27th, 2008


On Wed, 27 Feb 2008 07:01:06 -0600, thomas.mertes@gmx.at wrote
(in article
<0298aa3f-35a0-4563-8827-f5c2365e0842@d62g2000hsf.googlegroups.com>):

Putting a new language together /is/ inventing new things. Just as
your own language has done. Sure, it may borrow ideas from elsewhere,
but it combines them into something different.

It all depends upon the committee.

Little of "original C" from the 70s remains unchanged today. This was
also true in the late 80s. C has changed considerably, (you can argue
whether the changes are good or bad perhaps) since dmr first put it
together.

Also, plenty of people complain about C, and the blame is put on dmr,
the committee(s), or both in various camps.

Similar to the above. Plenty of people complain about various aspects,
how big the overall language is, pros/cons of various language
features, etc.

All of these have both good and bad points, and groups of people happy
to argue pro/con.

Well, Gosling is usually recognized as the implementor. Why didn't you
say that C was promoted by AT&T?

And a host of other .Net languages as well, yes.

Can you name a language that was designed by a committee? Ada maybe,
I'm not sure about its ancestry. Others? There aren't very many I
suspect. There are a lot of languages that started out non-standard,
but became maintained and/or extended by standard bodies later due to
popularity or a perceived need for standardization for portability
reasons.

If there is a published specification for the language, you are free to
implement the language elsewhere. Without it, it's difficult to even
program in it on a single platform.

A wise policy, but if a project is aimed at a single platform, and that
language is the best tool for the job, it would be silly not to use it
for "religious" reasons.

Likely true, although I haven't spent any time testing the theory.
It's probably also the case that porting C# on win32 to Mono (even with
porting issues) is simpler than rewriting it in something else from
scratch.

Then it wasn't portable code. Just because someone /claims/ that code
is portable doesn't make it true. Just today I was looking at an open
source library that claims on a bullet list to be "pure ISO/ANSI
standard C", but then when you look under the covers, you see warnings
about "we have to bend the rules here, and many compilers won't like
this trick..." in the comments or other documentation. IOW, people
/lie/. :-(

Bullshit marketing claims are not restricted to "quasi monopolists".
The open source community is also filled with them.

Microsoft has no "monopoly" on marketing BS.


--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw






Posted by Stuart on February 27th, 2008


"Randy Howard" <randyhoward@FOOverizonBAR.net> wrote in message
news:0001HW.C3EAC8D703F2C24FF01846D8@news.verizon. net...
<much snipping>

But, then Ada is an excellent language - so rather disproves the OP's
allegation ;-)

A history of Ada can be found at
http://en.wikipedia.org/wiki/Ada_(programming_language)

The sobriquet of being a language designed by committee seems largely
undeserved - the language has benefited greatly from a strong initial design
(Ada 83) by Jean Ichbiah's team at Honeywell Bull, a well reasoned revision
(Ada95) with disciplined input from some very skilled people, and some nice
touches added in the latest revision (Ada05).

I have heard that some of the debates in committee were fiercely argued [in
the best sense of being a proper technical argument]; but there were also
some 'typical' committee moments. But, on the whole [IMHO], the language
has gained more from being 'designed by committee' than it might have lost.

[I find it quite interesting reading some of the 'arguments' made in the Ada
Implementation notes, try Googling for
"Ada Implementation" AI95
for some links.]

--
Stuart





Posted by thomas.mertes@gmx.at on February 27th, 2008


On 27 Feb., 14:59, Randy Howard <randyhow...@FOOverizonBAR.net> wrote:
Thank you for mentioning my language. The extensibility of Seed7
should make borrowing of ideas from elswhere easier. In the optimal
case you can borrow an idea without changing the interpreter.
BTW. everybody is invited to help improving Seed7.

In most commitees politics play a role...

Yes

C was promoted by AT&T, but compared to the hype generated for
Java and C# this promotion was small.

So there is a vendor lock in for several languages.
Does an open source VB exist which runs unmodified
code?

I was referring to situation where a standard exists and it takes
many years until an implementation shows up. Ada and C99 are
such cases.

A published specification is important. OTOH it is hard to create a
good specification as long as no prototype implementation exists.

That is an argument I often hear from people who always decide for
the OS and the development environment of the quasi monopolist.
There are always several best tools for a job. What about Java and
Eclipse or some other portable language (note that I did not mention
Seed7 :-) ).

When you choose a more portable language beforehand you don't
have this problem. A usual porting issue is: You need a windows dll
under unix/linux/bsd. There are people rewriting them (project wine)
but
it takes time. I speak of portability when no code change is
necessary.

I agree

At least one area where it has no monopoly.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

Posted by Leslie Sanford on February 27th, 2008



<thomas.mertes@gmx.at> wrote :

<snip>

Anders Hejlsberg is the lead architect for C#.

(just giving credit where credit is due)



Posted by santosh on February 27th, 2008


Leslie Sanford wrote:

Thanks for the clarification. I was under the impression that it was
Herb Sutter.


Posted by Randy Howard on February 27th, 2008


On Wed, 27 Feb 2008 12:38:51 -0600, thomas.mertes@gmx.at wrote
(in article
<cae970f1-1f2f-457b-b8fa-666a1f3b7bab@34g2000hsz.googlegroups.com>):

No problem, although I merely alluded to it. :-)

Sadly this is correct, but it is not always problematic, although I
agree it often is. Either way, if you have an industry standard
language specification, you can bet there is at least one committee
under the covers or it wouldn't exist. A lot of good things happen in
these committees, for example, more sets of eyes attempting to remove
unwarranted platform assumptions that would hinder portability.

It was also different times. The mere existence of a portable,
compiled language was more than enough hype at the time. Also, the
pool of programmers was a tiny fraction of what it is today, although
the percentage of good ones was arguably much higher. As a result, the
need for hype to sell to a tiny market didn't really exist. Today, you
see mass competition for developer mindshare, for example wanting
people to merely mention your product in a Usenet post. ;-)

I don't know. If it does, it's probably within Mono, but I can't say
for sure. Personally, I'd just as soon no VB exist at all, but that's
just me.

I am not that familiar with the evoluton of Ada, so I won't comment on
that either way. As far as C99 goes, the reason for the slow (almost
nonexistent) adoption of it is that many people believe some
significant mistakes were made. For example, not following their own
mantra of codifying existing practice in many cases. The other issue
is, imnsho, due to C89 being plenty good for most uses of C already.
They could have made a few minor changes and additions, but instead
they made some rather sweeping changes, ones that conflicted with the
existing extensions used in contemporary compilers. As a result, much
resistance, and in some cases outright refusal to adopt the changes
ensued. Despite this, nothing bad seems to have happened. Most people
still write code in one of three major flavors, Microsoft's visual C++
default behavior on .c files, Strict C89, or "whatever the hell gcc
does by default".

True enough. Which is why languages are usually developed first, and
standardized later (once enough people decide the language is
worthwhile and start calling for a formal standard).

It appears that you're making an assumption about my motives. For the
record, I am not a fan of either the OS or any of its pushed languages
that you seem to be alluding to, presumably Microsoft and friends.

I can separate my personal opinions however from the practicalities of
writing code that is by design not portable, but tailored to a
particular environment. Not all projects need to be, or even should be
written in a portable language, and in such cases, arguments about
portability are moot.

This doesn't hold logically. At least, not for any definition of
"best" that I am aware of that doesn't also mean "equivalent".

Note: Yes you did. :P

If it turns out that Java is the best language for a project, then use
it.

I find that whole effort somewhat suspect. The last thing I want is to
be running windows binaries on a linux system. Use of a virtualization
technology is both safer and simpler to achieve.


--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw






Posted by Stuart on February 28th, 2008


<thomas.mertes@gmx.at> wrote in message
news:cae970f1-1f2f-457b-b8fa-666a1f3b7bab@34g2000hsz.googlegroups.com...
<comment by Randy Howard <randyhow...@FOOverizonBAR.net> 27 Feb., 14:59:
For Ada, are you referring to the core language or the special needs annexes
(which the standard identifies as optional)?

The core language (for Ada95) is supported by several compilers; Adacore
(www.adacore.com) claim to support all the special needs annexes in GNAT
(http://www.adacore.com/wp-content/fi...2.html#SEC426).

The Ada05 standard (ISO/IEC 8652:1995/Amd 1:2007) was officially approved in
March 2007 and Adacore already support the new features
(http://www.adacore.com/home/gnatpro/...e/compilation).

Regards
--
Stuart



Posted by thomas.mertes@gmx.at on February 28th, 2008


On 28 Feb., 10:50, "Stuart" <stu...@0.0> wrote:
In 1980 or 1981 (at the beginning of my studies) I attend a lecture
at the technical university of vienne where Ada was intruduced.
In 1984 a fellow student finished his study of computer science
(together with me). His diploma thesis was about writing an Ada
compiler. He did not finish code generation but the other parts
where there. From this fellow student I have the information that
his compiler would have been one of the first Ada compilers.
Years later I still heard stories about: Ada not available at this
and that machine.

I do not want to blame Ada. I just think that a specefication has a
better quality and is easier to implement when some prototype
implementation exists and has a feedback to the specification.

The fellow student who did the Ada compiler told me about problems
in parsing an Ada program. He told me that he needed an extra
function to determine what meaning a parenthesis has. When you
compare this to Pascal which can be parsed with LL(1) such
complexity can be seen as unneccessary. A prototype implementation
would have shown such hard to parse parts and the specification
could have been changed before releasing it.

I know what I am talking about: Seed7 (under its former name MASTER)
did exist on paper for a long time. The attempts to implement it
directly from the paper specification failed. It turned out to be
better when a prototype implementation helps to change some
hard-to-implement features in the specification. Using the feedback
from an implementation helped to succeed finally in the
implementation of Seed7. This incremental process leads IMHO to
better results (for big and complex problems).

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

Posted by Walter Banks on February 28th, 2008




thomas.mertes@gmx.at wrote:

One of the properties of Wirth languages is ease of implementation
it wasn't an accident. Most of his ideas and syntax were tested as he
developed them. Having to work around parsing issues makes
implementations prone to incompatibilities.


Regards,

--
Walter Banks
Byte Craft Limited
Tel. (519) 888-6911
http://www.bytecraft.com
walter@bytecraft.com






Posted by Stuart on February 28th, 2008


<thomas.mertes@gmx.at> wrote in message
news:e7071617-6d9e-4603-8c54-fa7e40c107e0@n77g2000hse.googlegroups.com...

<snip comment by Randy Howard>

<TM>
<S@0>
<TM>
<aside: They still look to be active in the Ada field>

Availability for particular machines, and Ada cost were among the issues in
that era; but it is not so representative of the situation today.

I think this depends on how you are measuring quality and what your
objectives are. Ada did not set out to make the compiler writer's job easy,
it set out to make software writing more reliable, software maintenance
easier, and improve the effectiveness of software development. However, it
did not disregard the practical issues of implementing a compiler, as can be
seen from many of the comments in the Annotated Language Reference Manual
and many of the Ada Implementation discussions.

When I first started with Ada, having previously worked with Pascal, I was
perplexed by the change of array references from using Arr[] to Arr() - and
in particular the potential 'confusion' with a subprogram (function) calls.
However, the Arr() form was in established use in other languages (COBOL,
FORTRAN), and given specific requirements in the Ada83 requirements to
constrain the language to a restricted character set - including EBCDIC
which did not have [ ] - and the outcome is what we have. There are also
debates on the advantages/disadvantages over referential transparency
between arrays and functions vs easy distinction between array uses and
function use. These seem finely balanced.

What would not be of interest is the inconvenience, to a compiler writer, of
writing an extra function as, in the grand scheme of things, this is done
once while the implications for the users of the language will recur for
decades.

I don't doubt your experience, and your point of view is a fair one. But
design by reference implementation has its pitfalls - just as design by any
other approach has.

My experiences are different from yours, and having spent many years using
Ada I offer a different perspective - namely that designing a language by
committee can be very successful.

I was never involved with the development or implementation of the Ada
language so I do not know what role the early compiler/translator
development at New York University had in assisting the language
definition - I suspect it did help. (I believe one of the DoD requirements
was that there would be a language translator available when the Ada83
standard was released).

Regards
--
Stuart



Posted by dave_mikesell@fastmail.fm on March 1st, 2008


On Feb 26, 9:30 am, thomas.mer...@gmx.at wrote:
I've never really visited this group until this week, but my first
impression is that it sucks. There's less animosity and pissing
contests at alt.talk.politics.

Posted by Richard Heathfield on March 1st, 2008


dave_mikesell@fastmail.fm said:

Actually, when we get to talk about programming, it can be a very good
group indeed. Alas, there are many distractions.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Posted by CBFalconer on March 1st, 2008


dave_mikesell@fastmail.fm wrote:
I think if, once you discover "spinoza" as the author, or in the
quote attributes, of any message, you immediately kill the thread,
that the remainder of the group will be quite calm and even
intelligent.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com


Posted by thomas.mertes@gmx.at on March 1st, 2008


On 1 Mrz., 05:04, dave_mikes...@fastmail.fm wrote:
The advocacy discussions are a new phenomenon and you can
easily see who caused this... This group has several advantages.
It is focused on programming, but not on a specific programming
language. There is knowledge about different programming
languages here. Specially people who create interpreters or
compilers or invented new programming languages are here.
Not that such people are inherently better, but when you
implement or design a language feature you have a different
view than the user of it. Since I have also a programming language
project (look for Seed7), I can get valuable feedback from here.

This implementer/user view difference makes it hard for me
to get help. E.g.:

I recently discovered that using fgetc() on a file opened with
popen() in a program compiled with MinGW returns 0 instead
of -1 (a file opened with a popen() is a pipe which is not seekable
and this should be notified with -1 ). Since this happens under
windows I asked under comp.os.ms-windows.programmer.win32
and comp.lang.c . Most answers indicated that the people did not
see this as a problem since I know the situation. This is a typical
users view. The implementers view is: The popen() is called from
a Seed7 program and the ftell() also (the interpreter or a compiled
Seed7 program and the Seed7 library are in between). Therefore the
only information about the file at the place ftell() is called is a
parameter of type FILE * . I finally found the solution myself:
I have to call fstat() to get the filetype. Finally I added some
check for this strange behavior in the makefile (the mingw versions
of the makefile) that is done with 'make depend'. Based on this
check the original ftell() is replaced with an improved_ftell()
which checks with fstat() and reacts accordingly.

There were further issues with popen(): Under windows it is okay
to open a file with fopen() and using a '/' as path delimiter.
Since I want to have portable Seed7 programs this is okay.
The popen() behavior is different: Under windows it needs '\' as
path delimiter. Since in Seed7 programs the path delimiter should
always be a '/' it is necessary to convert the command string under
windows. Further: This conversion should only take place in the
command not the command parameters. The command ends with a space.
But there could be spaces in the path leading to the command...
A Seed7 program could contain the expression:

popen("sp\ ace/dirx", "r")

which means: Execute the dirx program which is found in the
'sp ace' directory (the directory name contains a space).
To make Seed7 programs portable the above call of popen() in a
Seed7 program causes a C call which is:

popen("sp\ ace/dirx", "r")

under linux/unix/bsd and a C call which is:

popen("\"sp ace\\dirx\"", "r")

under windows. In a windows command window you would just type:

prompt> "sp ace\dirx"

I hope that ilustrates the difference between users and implementers
view.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

Posted by Bartc on March 1st, 2008



<dave_mikesell@fastmail.fm> wrote in message
news:40e096bc-fd8b-4bfd-8751-c47634cd9d4d@b1g2000hsg.googlegroups.com...

alt.talk.politics doesn't seem to exist. So you could be right.

--
Bart



Posted by Jon Harrop on March 2nd, 2008


thomas.mertes@gmx.at wrote:
I agree but there are two main problems:

Firstly, .NET is far better than any other platform for building new
programming languages and F# is an pioneering programming language built
upon it. I'd love to use them both cross platform but the reality is that
the open source community have nothing even vaguely comparable. Not only is
there nothing even remotely close now, I cannot even imagine how an open
source competitor might come about because so much talent and dedication is
required.

Secondly, although open source is very popular overall it is nothing like as
popular among people with money. Consequently, we are finding it much
easier to earn revenue by selling closed source commercial software. The
only notable exception that we have found is books, which are a viable
market in the context of open source.

Provided you're talking about coding for fun, I agree, but I can't see how
to build a business around open source software.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u