Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #4681 > unrolled thread

From pseudo to spaghetti

Back to article view | Back to comp.programming

Contents

  From pseudo to spaghetti b <mike7411@gmail.com> - 2014-08-03 19:43 -0700
    Re: From pseudo to spaghetti Kaz Kylheku <kaz@kylheku.com> - 2014-08-04 04:51 +0000
    Re: From pseudo to spaghetti Öö Tiib <ootiib@hot.ee> - 2014-08-04 09:11 -0700

#4681 — From pseudo to spaghetti

What are some of the main reasons that code gets ugly when it goes from pseudocode into the real world?

[toc] | [next] | [standalone]

#4682

On 2014-08-04, b <mike7411@gmail.com> wrote:
> What are some of the main reasons that code gets ugly when it goes from
> pseudocode into the real world?

One reason may be that the pseudo-code is not perfect, and so it it requires
debugging. It's the same reason that any code gets ugly when it is debugged:
you write some ideal piece of bullshit that looks nice, but it doesn't
actually specify the necessary computation. The program that does specify
the correct computation properly is more ugly. It is more ugly because it
has to handle more cases that were missing.

But let's say you have some polished piece of pseudo-code from the 15th edition
of some textbook that has been proof read up and down and sideways, so it is
safe to assume there is nothing wrong with the pseudo-code.

That can still get ugly when it goes into the real world, and the main
reason for that is that it is written in an ideal language, and the real
language that it is translated into is not up to the task of expressing
that approach directly. For instance, the pseudo-code may be assuming that some
garbage collector cleans up, but the actual language doesn't have one,
and so the code becomes riddled with ugly manual memory management.
Or the pseudo-code may be assuming you have first-class functions, with lexical
capture, but you don't. Or maybe the pseudo-code assumes you have
first class continuations, but the real language you're using has
only closures. Or maybe the pseudo-code assumes you have a certain
kind of pattern matching or type inference, and all you have is some clumsy
library to emulate them. Maybe the pseudo-code assumes you have an
object-oriented system, but you don't. Maybe it is dynamically typed,
and you have a static language.

In other words, there can be various kinds of semantic gaps between the
ideal language of the pseudo-code and the actual language which is chosen.

[toc] | [prev] | [next] | [standalone]

#4683

On Monday, 4 August 2014 05:43:00 UTC+3, b  wrote:
> What are some of the main reasons that code gets ugly when it goes
> from pseudocode into the real world?

In real world there are always bit different or more detailed goals
and corner cases than in ideal-case pseudo-code. Real world changes
constantly and that may change the goals of program. That causes 
developers to work on the product and if they work they make defects.
Defects are sometimes repaired not by avoiding root cause but by 
fixing the erroneous outcome.

Such work goes on for a while and about 80% of mature code base
deals with supporting such corner-case goals or fixing or avoiding
such corner-case defects. With mature product there are no much to 
do so the core developers get bored, start to work on something
else and further maintenance is handed over to weaker developers.

The code (like anything) will become ugly if it is worked on, 
repaired and extended but is not cleaned, reorganized and beautified.
End user however (who actually pays for the product) does not care
if developers have beautiful code or not. Developers must find ways
to invest into it (and partially against end-user's will) if they
want to have beautiful code.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web