| View previous topic :: View next topic |
| Author |
Message |
Herman Rubin
Guest
|
 Posted: Thu Jul 03, 2008 1:50 am Post subject: Re: Programming skills required by mathematicians? |
 |
|
In article <b716b85c-ddfb-4bc5-b90a-5ac81624fd41@j1g2000prb.googlegroups.com>,
Marshall <marshall.spight@gmail.com> wrote:
| Quote: |
On Jul 1, 7:40 am, hru...@odds.stat.purdue.edu (Herman Rubin) wrote:
In article <ddfb7$48688db5$82a1e228$25...@news1.tudelft.nl>,
I have programmed in Fortran, C, and assembler for
different machines.
Yes, those are sure good ones. Fond memories. Have
you had a chance to work with any of the languages
that have come out in the last 35 years? Some of them
are quite good.
|
| Quote: |
I am quite aware of even the
fact that efficiency for subroutines requires taking
into account the differences in the different machines,
and I have also stated that I can see how to produce
a somewhat high level assembler language easy to use.
Certainly high level assembler is easier to use
than low level assembler. Or machine language. But
it will be harder to use than pretty much anything else.
|
I have often found that those who produce the hardware
and software seem to have no idea of much of anything.
Efficiency is important, and a decent user, with knowledge
of machine architecture and what causes loss of efficiency,
should at least be able to tell the compiler/assembler
how to do things.
| Quote: |
Those who think HLLs are such a great idea, here is a
challenge. The function I am giving arises naturally,
and it is quite difficult to do EFFICIENTLY in any HLL.
One might have an application that has to respond in
such-and-such a way within x number of milliseconds.
But "efficiency" by itself is not a goal for software
development. It might be a means to an end, but never
a goal in its own right.
|
| Quote: |
Let x be a positive real number, whose binary expansion
is x = \sum a_i/2^i, a_i = 0 or 1. Then
f(x) = \sum i*a_i/2^i.
I have done some work on methods of generating non-uniform
random variables from uniform bits. There are some technical
reports available from the Purdue Statistics Department.
Among them are some I call "infinite precision", in that
no computer roundoff is involved. The easiest one of these
is to generate the density 2x from 0 to 1. The entire
algorithm is
I = distance to the first 1 in a random bit stream;
discard this part of the bit stream
X = U with the I-th bit after the binary point
changed to 1.
Alas, few of these are efficient, except possibly on an FPGA,
but the amount of work is finite random for all distributions
in any number of dimensions with lower semi-continuous density.
I have a recent paper with Brad Johnson on acceptance-replacement
generation of exponential and normal random variables, using
exponentials to test and reuse of successful test exponentials.
These vectorize or parallelize well if one changes the "control"
part of the algorithm somewhat, and that consideration also went
into the design of the algorithm.
So, how many times is this code going to get executed, and
in what application, and in what context? Unless the answers
are severe, the correct course of action is to code it in
the most straightforward way and forget it.
|
This latter code is going to be executed very many times if
it is used at all. A billion is well within possibility.
These are likely to be the most used non-uniform random
variables in an application, as they are also used in the
generation of others. The reuse of test random variables
occurred to me some 45 years ago, and is quite efficient
and cheap.
BTW, one consideration comes in when choosing the size of
constant arrays. From the computational efficiency staandpoint,
the larger the better. But it seems that if they are too
large, paging problems arise, as one is going to use them in
a random manner, all elements equally likely to be read.
If one could tell the compiler/assembler to put these in
one page, it might help.
| Quote: |
I do know something about getting the power of the machine, and
doing operations beyond the low precision hardware. Even if only
partial, there should be a convenient way of including assembler
instructions in a program without losing "optimization"; I have
done that on the CYBER 205. I have also in my files a design for
a decent quick assembler for the 780; I cannot find what I did
on the 205, but I remember some of it, including the most complicated
single one.
I never worked with the CYBER, but I did a lot of coding in
Fortran on the good ol' 780. But you do know, don't you, that
those days are gone? Not only are those machines obsolete,
but the companies that made them are largely forgotten.
I'm sure there are people reading this who have never heard
of Control Data because they were born after it ceased to
be a computer company. DEC was acquired by a bigger
fish ten years ago which was then itself consumed by an
even larger fish. Today my iPhone has more than 100 times
the computing power of a 780.
|
The successor to the CYBER would have been a great success
if the company had given it any support.
I doubt that your iPhone has that power for doing arithmetic;
it is probably designed for certain types of operations, but
not for any precision. But the 100 times the computing power
comes from 1000 times the speed together with 100 times the
size in computing units. Anyone understanding computer
hardware will know that the x86 series was a total mistake,
but I believe it is still the Intel hardware. The Power
hardware is reasonable but not that good, and I am looking
at AMD, which is now suing Intel.
For a straightforward coding problem, which will surprise
those looking at it carefully, is the calculation of
x - ln(1+x) to machine accuracy on the entire range x > -1.
The code can be written in Fortran or C, but if one does
not understand the machine, will have a sizable loss of
accuracy. Again, this code is likely to be used millions
of times or higher orders if it is used at all.
| Quote: |
The idea of assembly code inline in high level code made
sense in the 1980s but not since. The idea of hand-coded
assembly routines for speed made a lot of sense in the
1990s, for performance-critical inner loops anyway. There
are still a few scant places where that idea makes sense,
but they are getting fewer and fewer. It is harder every
year to outperform the compiler, and there is less reason
every year to try.
|
Wrong. The compiler often fails to use the operations
needed for efficiency. It is even the case that what
the compiler does for efficiency is totally wrong even
if using the right operations.
One thing HLLs should have had for ages is a list before
the replacement statement or even in a subroutine call.
The reason is that the variables in the list can be
computed in whatever order the replacement statement
or the subroutine decides, and placed there. This is
different from a struct, which puts them in memory.
An example is the C frexp, which should have been an
inlined replacement statement with two variables to the
left of the equal sign; it might not even have any use
of memory. I believe that all the Power machines use
memory in converting between integer and float, either
way, and I suspect most others do. The 780 could do some
of that without using memory.
| Quote: |
I used to write assembly code for some different Adobe
apps in the early 1990s: Photoshop and Premiere. The
processor being targeted was the 486, and there was
a nice chart you could flip through and see how many
cycles each instruction was. You could come up with
different approaches, sum up the cycle count, and
compare.
When the Pentium came out, that got a lot harder.
Now there was a pipeline, and the cycle count wasn't
so straightforward. You might be able to pair these
two instructions, or not.
These days the situation is ridiculous, with very long
pipelines, multiple execution units, etc. etc. and you
can't even *get* a chart.
|
Why not? You have a better idea of what is needed than
the compiler writer.
| Quote: |
One danger of HLLs is that the user has no idea
of how long something will take.
That's just simply not true. Languages like C++ and
Java have quite transparent performance models; in
fact this may even be a good part of why they're
so successful. Even when using something wildly
abstract like SQL, one can still get an execution plan
out of the engine, and do various tweaks to change
it. Not that one ever has much need to.
|
| Quote: |
As for gotos, I find them easy to use,
and spaghetti code is best for spaghetti algorithms.
Sure, gotos are easy to write, but what's usually important
for code is that it be easy to read and easy to maintain,
and gotos are anathema to that.
|
Hah! They are much easier to read than following indentations.
Several levels of indentations especially.
Assembler language and the machine use gotos. The user
cannot do things efficiently without telling the machine
what to do.
One instruction I find missing on the "modern" machines I
have seen is a conditional skip of a few instructions; I
have never seen more than one. This would enable no loss
of pipelining. The compiler could count how many instructions
in a large number of cases from code.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Department of Statistics, Purdue University
hrubin@stat.purdue.edu Phone: (765)494-6054 FAX: (765)494-0558 |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
Herman Rubin
Guest
|
| Posted: Thu Jul 03, 2008 3:01 am Post subject: Re: Programming skills required by mathematicians? |
|
|
In article <7b49f964-7b90-445e-8df5-b52754301e2e@m3g2000hsc.googlegroups.com>,
aruzinsky <aruzinsky@general-cathexis.com> wrote:
| Quote: |
On Jul 1, 10:16=A0am, hru...@odds.stat.purdue.edu (Herman Rubin) wrote:
In article <84498550-6584-4d29-8703-d737ffe2e...@d45g2000hsc.googlegroups.=
com>,
aruzinsky =A0<aruzin...@general-cathexis.com> wrote:
On Jun 25, 2:40=3DA0am, rAgAv <ragav.pa...@googlemail.com> wrote:
Hello,
|
.....................
| Quote: |
Computers have been used in number theory, algebraic geometry,
computational problems which are more abstract than concrete,
as well as more "practical" problems. =A0My technical reports,
available from the Purdue Statistics Department, are a combination
of an odd type of numerical analysis, and involve using Boolean
operations on the bit patter of floats, something which is not
in any HLL to my knowledge.
Efficient random number procedures can be mainly done in HLL,
but not with full efficiency. =A0And I doubt that anyone can
get a full accuracy efficient procedure to generate
f(x) =3D x - ln(1+x) to full machine precision without using
the hardware structure. =A0Also, on most machines, multiple
precision (I consider what is called "double" to be single)
arithmetic is a mess because of the forced normalization of
floats and the hidden bit. =A0The factor may be higher than 10.
This is partly due to the HLLs, which have discounted fixed
point arithmetic.
If you were an "applied mathematician," I would recommend Fortran and
Algol only because there are many legacy programs written in these
languages. =A0In particular, the Collected Algorithms from ACM Vol I to
III are mostly in Algol and Fortran.
At that time, those were the only moderately well known HLLs.
Machine independence is fine, but one must take into account
the machine to get efficiency.
With modern compilers, one can easily mix a HLL with assembly
language. For example, Visual C++ object code can be disassembled
into assembly language, modified, and then recompiled back to object
code.
|
This is not good with the usual assemblers. Often,
the compiled code is "optimized" in such a way that
it is hard to follow. Optimization is needed later,
not at compile time.
Few current assembler languages are concise enough
for easy coding. Typing 50 characters when 5 would
suffice leads to errors. Something like the Cray
assembler language with simplifications and overloading
is needed.
| Quote: |
For mental exercise and development, I recommend learning Forth which
uses Reverse Polish Notation (RPN), i.e. operands precede operators,
as in reality. Forth and RPN foster efficient programming and
utilization of RAM. Standard Forth does not use floating point, but
Forth can be modified to do anything because it is easily extensible.
Some modified versions directly use the PC FPU stack very efficiently.
|
RPN is moderately easy to write, and is my choice for
a calculator. I am less fond of the stack idea of
Forth for a computer. I do know how to juggle registers,
and providing the appropriate information for a machine
which offers many registers is quite different from doing
good programming on a stack machine.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Department of Statistics, Purdue University
hrubin@stat.purdue.edu Phone: (765)494-6054 FAX: (765)494-0558 |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Han de Bruijn
Guest
|
| Posted: Thu Jul 03, 2008 11:00 am Post subject: Re: Programming skills required by mathematicians? |
|
|
Herman Rubin wrote:
| Quote: |
In article <b716b85c-ddfb-4bc5-b90a-5ac81624fd41@j1g2000prb.googlegroups.com>,
Marshall <marshall.spight@gmail.com> wrote:
On Jul 1, 7:40 am, hru...@odds.stat.purdue.edu (Herman Rubin) wrote:
As for gotos, I find them easy to use,
and spaghetti code is best for spaghetti algorithms.
Sure, gotos are easy to write, but what's usually important
for code is that it be easy to read and easy to maintain,
and gotos are anathema to that.
Hah! They are much easier to read than following indentations.
Several levels of indentations especially.
|
Yes ! Sometimes even running off 80 columns IBM punch cards ! Especially
with those TAB (8 characters) wide indentations. Many, if not all, Java
programmers suffer from this indentation syndrome. It seens to be a part
of their little culture. Such deep indentations can be prevented easily,
though, with proper modularization. And 2 characters wide indentations
offer much better readability - they are pretty standard in my culture,
which is Delphi Pascal. Don't think that gotos are a better way out ..
| Quote: |
Assembler language and the machine use gotos. The user
cannot do things efficiently without telling the machine
what to do.
One instruction I find missing on the "modern" machines I
have seen is a conditional skip of a few instructions; I
have never seen more than one. This would enable no loss
of pipelining. The compiler could count how many instructions
in a large number of cases from code.
|
How about: if <OK> then <do if OK true> else <do if OK false> end;
Then the <do if OK false> instructions are skipped if OK is true, that
_is_ conditionally, not ? Another (loop) construct in (Delphi) Pascal:
while true do
begin
<anything>
OK := <condition>;
if OK then Continue;
<things if not OK>
end;
So what's your problem ? Loss of pipelining ?
Han de Bruijn |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Han de Bruijn
Guest
|
| Posted: Thu Jul 03, 2008 11:00 am Post subject: Re: Programming skills required by mathematicians? |
|
|
aruzinsky wrote:
| Quote: |
On Jul 2, 2:35 am, Han de Bruijn <Han.deBru...@DTO.TUDelft.NL> wrote:
aruzinsky wrote:
If you were an "applied mathematician," I would recommend Fortran and
Algol only because there are many legacy programs written in these
languages. In particular, the Collected Algorithms from ACM Vol I to
III are mostly in Algol and Fortran.
Algol ? I thought _that_ is outdated ! And Fortran ? Indeed there are
many programs written in that language. It has even been my mother's
tongue. But I wouldn't recommend it to anyone. My favorite is Pascal.
Algol is outdated, but many of the 1950s algorithms written in Algol
are not. If you know some Pascal, you can probably read Algol well
enough to translate. I bet there are plenty of Algol algorithms in
Collected Algorithms from ACM that are better than their counterparts
published in Numerical Recipes in C (or Fortran).
|
If you mean it _this_ way, I can nothing but agree.
Han de Bruijn |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Han de Bruijn
Guest
|
| Posted: Thu Jul 03, 2008 11:00 am Post subject: Re: Programming skills required by mathematicians? |
|
|
Herman Rubin wrote:
| Quote: |
RPN is moderately easy to write, and is my choice for
a calculator. I am less fond of the stack idea of
Forth for a computer. I do know how to juggle registers,
and providing the appropriate information for a machine
which offers many registers is quite different from doing
good programming on a stack machine.
|
FORTH has been my choice once, only for the reason that it can run on
very, very small machines:
http://hdebruijn.soo.dto.tudelft.nl/www/muziek/midicode.htm
But for the rest, FORTH is a truly _dreadful_ programming language, as
all stack oriented languages; PostScript is another terrible example.
The reason is that data stacks are always, yes: always, in wrong order.
Han de Bruijn |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
zzbunker@netscape.net
Guest
|
| Posted: Thu Jul 03, 2008 11:30 am Post subject: Re: Programming skills required by mathematicians? |
|
|
On Jun 26, 5:16 pm, Phil Hobbs <pcdhSpamMeSensel...@pergamos.net>
wrote:
| Quote: |
Frederick Williams wrote:
Phil Hobbs wrote:
[...] For the theoreticians I know, it would be how to hammer in a
nail without bending it. ;)
The answer to that problem is to use a hammer to knock in screws: screws
being thicker than nails are less likely to bend.
Spoken like a theoretician. ;)
|
So, very true. Since it took real engineers to invent explosive
bolts.
The purpose being to prove to idiot theoreticians that the only
difference
between a screw and a nail is the "s". It has nothing to do with
science idiots and any amount of carpenters.
| Quote: |
Cheers,
Phil Hobbs |
|
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
aruzinsky
Guest
|
| Posted: Thu Jul 03, 2008 3:26 pm Post subject: Re: Programming skills required by mathematicians? |
|
|
On Jul 2, 4:01 pm, hru...@odds.stat.purdue.edu (Herman Rubin) wrote:
| Quote: |
In article <7b49f964-7b90-445e-8df5-b52754301...@m3g2000hsc.googlegroups.com>,
aruzinsky <aruzin...@general-cathexis.com> wrote:
On Jul 1, 10:16=A0am, hru...@odds.stat.purdue.edu (Herman Rubin) wrote:
In article <84498550-6584-4d29-8703-d737ffe2e...@d45g2000hsc.googlegroups.> >com>,
aruzinsky =A0<aruzin...@general-cathexis.com> wrote:
On Jun 25, 2:40=3DA0am, rAgAv <ragav.pa...@googlemail.com> wrote:
Hello,
.....................
Computers have been used in number theory, algebraic geometry,
computational problems which are more abstract than concrete,
as well as more "practical" problems. =A0My technical reports,
available from the Purdue Statistics Department, are a combination
of an odd type of numerical analysis, and involve using Boolean
operations on the bit patter of floats, something which is not
in any HLL to my knowledge.
Efficient random number procedures can be mainly done in HLL,
but not with full efficiency. =A0And I doubt that anyone can
get a full accuracy efficient procedure to generate
f(x) =3D x - ln(1+x) to full machine precision without using
the hardware structure. =A0Also, on most machines, multiple
precision (I consider what is called "double" to be single)
arithmetic is a mess because of the forced normalization of
floats and the hidden bit. =A0The factor may be higher than 10.
This is partly due to the HLLs, which have discounted fixed
point arithmetic.
If you were an "applied mathematician," I would recommend Fortran and
Algol only because there are many legacy programs written in these
languages. =A0In particular, the Collected Algorithms from ACM Vol I to
III are mostly in Algol and Fortran.
At that time, those were the only moderately well known HLLs.
Machine independence is fine, but one must take into account
the machine to get efficiency.
With modern compilers, one can easily mix a HLL with assembly
language. For example, Visual C++ object code can be disassembled
into assembly language, modified, and then recompiled back to object
code.
This is not good with the usual assemblers. Often,
the compiled code is "optimized" in such a way that
it is hard to follow. Optimization is needed later,
not at compile time.
Few current assembler languages are concise enough
for easy coding. Typing 50 characters when 5 would
suffice leads to errors. Something like the Cray
assembler language with simplifications and overloading
is needed.
For mental exercise and development, I recommend learning Forth which
uses Reverse Polish Notation (RPN), i.e. operands precede operators,
as in reality. Forth and RPN foster efficient programming and
utilization of RAM. Standard Forth does not use floating point, but
Forth can be modified to do anything because it is easily extensible.
Some modified versions directly use the PC FPU stack very efficiently.
RPN is moderately easy to write, and is my choice for
a calculator. I am less fond of the stack idea of
Forth for a computer. I do know how to juggle registers,
and providing the appropriate information for a machine
which offers many registers is quite different from doing
good programming on a stack machine.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Department of Statistics, Purdue University
hru...@stat.purdue.edu Phone: (765)494-6054 FAX: (765)494-0558- Hide quoted text -
- Show quoted text -
|
It is not a problem of juggling registers so much as juggling RAM. To
prevent fragmentation of heap memory, the heap must be treated like a
stack, i.e., last in - first out (LIFO). About 30 years ago, I
modified Forth for matrix operations. The actual matrices were
allocated in heap memory, but the operand references to those matrices
were placed on the Forth stack which, along with RPN, forced LIFO
allocation of matrices in the heap. Now, I find this experience
useful when writing image processing programs in C++, because heap
fragmentation is often a problem when processing large images. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
aruzinsky
Guest
|
| Posted: Thu Jul 03, 2008 4:33 pm Post subject: Re: Programming skills required by mathematicians? |
|
|
On Jul 3, 5:30 am, "zzbun...@netscape.net" <zzbun...@netscape.net>
wrote:
| Quote: |
On Jun 26, 5:16 pm, Phil Hobbs <pcdhSpamMeSensel...@pergamos.net
wrote:
Frederick Williams wrote:
Phil Hobbs wrote:
[...] For the theoreticians I know, it would be how to hammer in a
nail without bending it. ;)
The answer to that problem is to use a hammer to knock in screws: screws
being thicker than nails are less likely to bend.
Spoken like a theoretician. ;)
So, very true. Since it took real engineers to invent explosive
bolts.
The purpose being to prove to idiot theoreticians that the only
difference
between a screw and a nail is the "s". It has nothing to do with
science idiots and any amount of carpenters.
Cheers,
Phil Hobbs- Hide quoted text -
- Show quoted text -
|
What you may not appreciate is that most papers published in
electrical engineering journals (and for all I know all engineering
journals) represent PURE research in that they are of no foreseeable
practical use. It is like a carpenter authoring an in depth
mathematical analysis of using a rock to hammer a screw. It gets
published only because it has never been done before and there are no
obvious technical errors. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Guest
|
| Posted: Thu Jul 03, 2008 6:25 pm Post subject: Re: Programming skills required by mathematicians? |
|
|
On 2 Jul, 09:49, Han de Bruijn <Han.deBru...@DTO.TUDelft.NL> wrote:
| Quote: |
Marshall wrote:
On Jul 1, 7:40 am, hru...@odds.stat.purdue.edu (Herman Rubin) wrote:
As for gotos, I find them easy to use,
and spaghetti code is best for spaghetti algorithms.
Sure, gotos are easy to write, but what's usually important
for code is that it be easy to read and easy to maintain,
and gotos are anathema to that.
I think nowadays nobody, except Herman, will argue in favour of gotos.
|
FWIW, I would. In fact, my idea is that the two "poles", LLL and HLL,
should finally split, where LLL is the only true programming possible,
while HLL is to become the high-end side of user interfaces.
In any case, there may be lots of reasons to "favour gotos", all
invariably coming from those who have been programming for a life, at
least in the sense of getting back to the roots of our practices and
problems, and cleaning up to an otherwise unreachable next phase.
| Quote: |
On the other hand, I find that the Object Oriented Programming paradigm
has given rise to bad programming practices, such as putting more and
more software layers on top of each other
|
Yep, that is an easy example. What has gone wrong there?
-LV
| Quote: |
, so many that even a GigaHerz
processor can hardly plough through them, in execution time.
Han de Bruijn |
|
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Frederick Williams
Guest
|
| Posted: Fri Jul 04, 2008 4:50 pm Post subject: Re: Programming skills required by mathematicians? |
|
|
Han de Bruijn wrote:
| Quote: |
I think nowadays nobody, except Herman, will argue in favour of gotos.
|
There are common enough situations in which the goto is the clearest
thing to use, so why wouldn't one use it?
--
He is not here; but far away
The noise of life begins again
And ghastly thro' the drizzling rain
On the bald street breaks the blank day. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Guest
|
| Posted: Fri Jul 04, 2008 7:24 pm Post subject: Re: Programming skills required by mathematicians? |
|
|
On 3 Jul, 19:25, ju...@diegidio.name wrote:
| Quote: |
On 2 Jul, 09:49, Han de Bruijn <Han.deBru...@DTO.TUDelft.NL> wrote:
Marshall wrote:
On Jul 1, 7:40 am, hru...@odds.stat.purdue.edu (Herman Rubin) wrote:
As for gotos, I find them easy to use,
and spaghetti code is best for spaghetti algorithms.
Sure, gotos are easy to write, but what's usually important
for code is that it be easy to read and easy to maintain,
and gotos are anathema to that.
I think nowadays nobody, except Herman, will argue in favour of gotos.
FWIW, I would. In fact, my idea is that the two "poles", LLL and HLL,
should finally split, where LLL is the only true programming possible,
while HLL is to become the high-end side of user interfaces.
In any case, there may be lots of reasons to "favour gotos", all
invariably coming from those who have been programming for a life, at
least in the sense of getting back to the roots of our practices and
problems, and cleaning up to an otherwise unreachable next phase.
|
I wouldn't know what to suggest to the mathematician (maybe functional/
algebra systems programming?), but to the kid I'd still suggest BASIC,
in its original "basic" form. Then I'd say assembler and computer
architecture on a side, functional/logic/algebra programming on
another (the two poles). Then of course much more could follow.
-LV
| Quote: |
On the other hand, I find that the Object Oriented Programming paradigm
has given rise to bad programming practices, such as putting more and
more software layers on top of each other
Yep, that is an easy example. What has gone wrong there?
-LV
, so many that even a GigaHerz
processor can hardly plough through them, in execution time.
Han de Bruijn |
|
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Marshall
Guest
|
| Posted: Fri Jul 04, 2008 7:34 pm Post subject: Re: Programming skills required by mathematicians? |
|
|
On Jul 4, 11:55 am, goto <g...@somewhere.com> wrote:
| Quote: |
Frederick Williams wrote:
I think nowadays nobody, except Herman, will argue in favour of gotos.
There are common enough situations in which the goto is the clearest
thing to use, so why wouldn't one use it?
The principal objectioneers always were the academic airheads, those who
never wrote or imagined a real life program larger than a dozen lines.
Other than that,
"If you want to go somewhere, goto is the best way to get there."
|
Snort.
This was a fierce argument in the 1970s. Your side lost.
Marshall |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Guest
|
| Posted: Fri Jul 04, 2008 8:16 pm Post subject: Re: Programming skills required by mathematicians? |
|
|
On 4 Jul, 20:34, Marshall <marshall.spi...@gmail.com> wrote:
| Quote: |
On Jul 4, 11:55 am, goto <g...@somewhere.com> wrote:
Frederick Williams wrote:
I think nowadays nobody, except Herman, will argue in favour of gotos.
There are common enough situations in which the goto is the clearest
thing to use, so why wouldn't one use it?
The principal objectioneers always were the academic airheads, those who
never wrote or imagined a real life program larger than a dozen lines.
Other than that,
"If you want to go somewhere, goto is the best way to get there."
Snort.
This was a fierce argument in the 1970s. Your side lost.
|
That it lost doesn't necessarily mean it was wrong. Statistics on
software projects' failures anyone?
We might need make a distinction between LLL and HLL as different
degrees from machine language up to -say- scripting, and LLL and HLL
as two fundamentally distinct domains, where the higher LLL just
happens to be near to the lowest HLL, maybe due a common formal
background.
For instance, structured analysis was indeed a great step ahead (and
still it is the best reference, IMO): in the process of mapping the
problem to the conceptual domain and then down to the software modules
and concrete data structures. Still, at a certain point you need get
your hands dirty in coding: there is a discontinuity.
IMO, today's higher level programming languages, the ones actually
used in the software industry I mean, mainly suffer of being hybrids
between the conceptual and the technical domains. Not even like a RISC
vs. CISC debate, which is rather around the number of primitives as to
the implied architecture.
-LV
|
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Marshall
Guest
|
| Posted: Fri Jul 04, 2008 8:50 pm Post subject: Re: Programming skills required by mathematicians? |
|
|
On Jul 4, 1:16 pm, ju...@diegidio.name wrote:
| Quote: |
On 4 Jul, 20:34, Marshall <marshall.spi...@gmail.com> wrote:
On Jul 4, 11:55 am, goto <g...@somewhere.com> wrote:
Frederick Williams wrote:
I think nowadays nobody, except Herman, will argue in favour of gotos.
There are common enough situations in which the goto is the clearest
thing to use, so why wouldn't one use it?
The principal objectioneers always were the academic airheads, those who
never wrote or imagined a real life program larger than a dozen lines.
Other than that,
"If you want to go somewhere, goto is the best way to get there."
Snort.
This was a fierce argument in the 1970s. Your side lost.
That it lost doesn't necessarily mean it was wrong.
|
That the debate was settled decades ago and there
has been no meaningful question about it since is
a very, very strong indication that it was, in fact,
utterly wrong.
| Quote: |
Statistics on software projects' failures anyone?
|
So you blame the high rate of software project failures
on insufficient use of gotos, then? Remarkable.
| Quote: |
IMO, today's higher level programming languages, the ones actually
used in the software industry I mean, mainly suffer of being hybrids
between the conceptual and the technical domains.
|
You should say more stuff like this and less stuff about gotos.
Marshall |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Guest
|
| Posted: Fri Jul 04, 2008 9:08 pm Post subject: Re: Programming skills required by mathematicians? |
|
|
On 4 Jul, 21:50, Marshall <marshall.spi...@gmail.com> wrote:
| Quote: |
On Jul 4, 1:16 pm, ju...@diegidio.name wrote:
On 4 Jul, 20:34, Marshall <marshall.spi...@gmail.com> wrote:
On Jul 4, 11:55 am, goto <g...@somewhere.com> wrote:
Frederick Williams wrote:
I think nowadays nobody, except Herman, will argue in favour of gotos.
There are common enough situations in which the goto is the clearest
thing to use, so why wouldn't one use it?
The principal objectioneers always were the academic airheads, those who
never wrote or imagined a real life program larger than a dozen lines.
Other than that,
"If you want to go somewhere, goto is the best way to get there."
Snort.
This was a fierce argument in the 1970s. Your side lost.
That it lost doesn't necessarily mean it was wrong.
That the debate was settled decades ago and there
has been no meaningful question about it since is
a very, very strong indication that it was, in fact,
utterly wrong.
|
The debate has never been settled. It's rather become a niche thing.
| Quote: |
Statistics on software projects' failures anyone?
So you blame the high rate of software project failures
on insufficient use of gotos, then? Remarkable.
|
I blame that there is a rule where there should be an understanding.
That's where the detractors of gotos are just clueless, and that's
where the software industry has fallen to the knees.
| Quote: |
IMO, today's higher level programming languages, the ones actually
used in the software industry I mean, mainly suffer of being hybrids
between the conceptual and the technical domains.
You should say more stuff like this and less stuff about gotos.
|
Have no idea what you mean. :)
-LV
|
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
199 Attacks blocked
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
