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 (http://sourceforge.net/projects/booch95/). 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 boring. 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 structuring. :-) 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 ;-) Warren
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. :) -- Adam |