Prev: Lost in translation (with SPARK user rules)
Next: Sockets package in SPARK (Was: Lost in translation (with SPARK user rules))
From: Simon Wright on 26 May 2010 17:55
"Yannick Duchêne (Hibou57)" <yannick_duchene(a)yahoo.fr> writes:
> Did you ever heard about Literate Programming ? What do you think
> about it in this area ? (possibly with editor support for that)
Your earlier remarks about LP reminded me of nuweb
(http://sourceforge.net/projects/nuweb/) and my desire to write more
extensive unit tests for the Booch Components
nuweb-related work so far at http://public.me.com/simon.j.wright,
subdirectory lp/ - bc_tests.w is the web source, .pdf the readable
version of it, the .gpr and .ad[bs] files are the generated code.
One thing I find is that LP is fine for the overall description BUT you
have to get down to the detail at some point and there comes a time when
it really doesn't justify a lot of explanation. As an example, section
4.1 in bc_tests.pdf isn't too bad but sections 4.2, 4.3 and 4.4 are just
Of course writing unit tests for several different versions of the same
concept is going to be boring anyway!
From: Georg Bauhaus on 26 May 2010 19:36
On 5/26/10 9:33 PM, Yannick Duchêne (Hibou57) wrote:
> Le Wed, 26 May 2010 19:20:00 +0200, Georg Bauhaus
> <rm.dash-bauhaus(a)futureapps.de> a écrit:
>> Anyway, if understanding text requires more than linear
>> reading, there are arguments in favor of conciseness.
>> UML or any other "bird's eye view" tool show the usefulness
>> of seeing relations between pieces of source text in one place.
> Did you ever heard about Literate Programming ? What do you think about
> it in this area ? (possibly with editor support for that)
There even was/is a WEB adaptation for Ada 83
with all the features of the original WEB.
Like the other WEB systems, it can help with PERFORM-like
subdivisions, but not act as a replacement for "powerful"
operators (APL style), or with seeing call chains, say. (The tools
to show the latter are all outside the language, I think.)
Being able to give detailed procedures as to how an operation
is to be performed (Ada) comes at a price (more things
to specify). Program planners who would rather leave the
programming to the engineers might then say "not my job!"
and go on with writing algorithms very concisely,
not using Ada ;-) Understanding an algorithm might
be easier without the details...
Hypothesis: Compiler makers don't like the literate programming
tools out there. Reason: Literate Programming makes your
programming language appear to be less than perfect for
IIRC, Robert Dewar once explained how Jean Ichbiah used
Word for writing about Ada and then called macros to
copy Ada text from the Word document to some external file.
From: Yannick Duchêne (Hibou57) on 27 May 2010 00:19
Le Thu, 27 May 2010 04:07:19 +0200, Fritz Wuehler
<fritz(a)spamexpire-201005.rodent.frell.theremailer.net> a écrit:
> Extremes in the the direction of terseness are APL and Perl. They can be
> impossible to read. Sometimes even reading code you wrote last week is
> hard. I'm sure there are others but those two come to mind at the moment.
Sed scripts ?
There is even better than a pragma Assert: a SPARK --# check.
From: Warren on 27 May 2010 13:10
Jeffrey R. Carter expounded in news:htjce2$31g$1(a)tornado.tornevall.net:
> Peter C. Chapin wrote:
>> However, the argument that I see some people putting forth on the
>> Scala group is that conciseness is good because it saves typing. I
>> really can't understand that. How hard is it to type?
> The important point is that in the real world, code is written once,
> but read many times. I'm sure this is just as true with Scala as it is
> with every other language.
Not so (snickers) - Perl is read once, rewritten many times.
Even the perl code's author can't remember how it worked,
3 months later ;-)
From: Adam Beneschan on 27 May 2010 18:15
On May 27, 10:10 am, Warren <ve3...(a)gmail.com> wrote:
> Not so (snickers) - Perl is read once, rewritten many times.
> Even the perl code's author can't remember how it worked,
> 3 months later ;-)
That's why Perl, and many other computer languages, provide features
called "comments". But I suspect our friend Rex would think that the
purpose of comments is just busywork to prove to some evil IT
supervisor that his employees aren't lazy. :)