From Newsgroup: comp.misc

Actually, it's a bash script I'm writing at the moment, but I've
experienced similar issues writing Python! (Yuck).

Every trivial typo can turn into a mammoth debugging exercise. Get the
case of a variable name wrong, and you're right down into "How can it
possibly do that?" territory.

Forget to declare an array as associative, and you don't get an error
saying "What on earth are you doing? "fred" is not an integer", but just
weird unfathomable behaviour.

What would be a 5 five second correction in an IDE when writing C or
Java turns into a half hour exercise in tearing out of hair.

And they actually teach Python at universities! Are they insane?

Companies should forget AI for programming, and just tell their
developers that from now on, it's strongly types languages all the way down.

Sylvia.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Tue, 15 Sep 2026 13:08:27 +0800, Sylvia Else wrote:

Actually, it's a bash script I'm writing at the moment, but I've
experienced similar issues writing Python! (Yuck).

Python is not an rCLuntypedrCY language, it is a rCLdynamically-typedrCY language.

bash isnrCOt even dynamically-typed, since you have to declare whether a variable is an array, a hash or a scalar.

Every trivial typo can turn into a mammoth debugging exercise. Get
the case of a variable name wrong, and you're right down into "How
can it possibly do that?" territory.

This bash variable-substitution option might be helpful:

${parameter:?word}
If parameter is null or unset, the shell writes the expansion
of word (or a message to that effect if word is not present)
to the standard error and, if it is not interactive, exits
with a non-zero status. An interactive shell does not exit,
but does not execute the command associated with the
expansion. Otherwise, the value of parameter is substituted.

<https://www.gnu.org/software/bash/manual/bash.html>

And they actually teach Python at universities! Are they insane?

Python has a few safeguards in its variable-scoping rules that try to
strike a balance between accidental mistakes and forcing you to
declare everything. For one thing, you canrCOt accidently create a
global variable in an inner scope -- you have to explicitly say thatrCOs
what you are asking for.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Sylvia Else wrote:

Actually, it's a bash script I'm writing at the moment, but I've
experienced similar issues writing Python! (Yuck).

Every trivial typo can turn into a mammoth debugging exercise. Get the
case of a variable name wrong, and you're right down into "How can it possibly do that?" territory.

Forget to declare an array as associative, and you don't get an error
saying "What on earth are you doing? "fred" is not an integer", but just weird unfathomable behaviour.

Really, Sylvia, those are teething pains. This is my belief, when you
refer to dictionaries as associative arrays and confusing them with
lists. Perhaps, try setting down the notion of arrays briefly and
consider lists, sets & dictionaries.

Mainly, give it a couple weeks and this will be ancient history to you.

Sylvia.

I'm no expert either. Initializing arrays seems like busywork if I need
a specified length, but I only have 6 months in Python.
--
Everything I work for
Everything I long for is always just too far
Everything I hope for never comes to be
Everything I bleed for burns a scar on me
Everything I fight for leaves a bitter taste
Everything I cry for laughs into my face
Everything I scream for barely knows my name
Everything I'd die for will die just the same

Everything I worked for
Everything I longed for was always just too far
Everything I hoped for never came to be
Everything I bled for burned a scar on me
Everything I fought for left a bitter taste
Everything I cried for laughed into my face
Everything I screamed for barely knew my name
Everything I died for died just the same
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Sylvia Else <sylvia@email.invalid> writes:

Actually, it's a bash script I'm writing at the moment, but I've
experienced similar issues writing Python! (Yuck).

AFAIK if you donrCOt like BashrCOs untyped nature then your only options are
to put up with it or use a better language (i.e. almost anything else).

The situation with Python is much better: add type annotations and use a
static type checker (e.g. mypy). It can be a bit tedious to annotate
existing code, but well worth it in my experience.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 15-Sept-26 10:52 pm, Lane W wrote:

Sylvia Else wrote:

Actually, it's a bash script I'm writing at the moment, but I've
experienced similar issues writing Python! (Yuck).

Every trivial typo can turn into a mammoth debugging exercise. Get the
case of a variable name wrong, and you're right down into "How can it
possibly do that?" territory.

Forget to declare an array as associative, and you don't get an error
saying "What on earth are you doing? "fred" is not an integer", but
just weird unfathomable behaviour.

Really, Sylvia, those are teething pains. This is my belief, when you
refer to dictionaries as associative arrays and confusing them with
lists. Perhaps, try setting down the notion of arrays briefly and
consider lists, sets & dictionaries.

Bash has associative arrays. That's what the documentation calls them.

Mainly, give it a couple weeks and this will be ancient history to you.

Sylvia.

I'm no expert either. Initializing arrays seems like busywork if I need
a specified length, but I only have 6 months in Python.

I've spent decades working with strongly typed languages. Perhaps those
who've only used things like Python have failed to recognise the
benefits of strong typing.

Sylvia.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Wed, 16 Sep 2026 12:03:02 +0800, Sylvia Else wrote:

I've spent decades working with strongly typed languages. Perhaps
those who've only used things like Python have failed to recognise
the benefits of strong typing.

Python is a strongly-typed language.

Are you thinking of languages which need a rCL===rCY operator in addition
to rCL==rCY? (*Cough* JavaScript, PHP *cough*)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Sylvia Else wrote:

On 15-Sept-26 10:52 pm, Lane W wrote:

Sylvia Else wrote:

Actually, it's a bash script I'm writing at the moment, but I've
experienced similar issues writing Python! (Yuck).

Every trivial typo can turn into a mammoth debugging exercise. Get
the case of a variable name wrong, and you're right down into "How
can it possibly do that?" territory.

Forget to declare an array as associative, and you don't get an error
saying "What on earth are you doing? "fred" is not an integer", but
just weird unfathomable behaviour.

Really, Sylvia, those are teething pains. This is my belief, when you
refer to dictionaries as associative arrays and confusing them with
lists. Perhaps, try setting down the notion of arrays briefly and
consider lists, sets & dictionaries.

Bash has associative arrays. That's what the documentation calls them.

Mainly, give it a couple weeks and this will be ancient history to you.

Sylvia.

I'm no expert either. Initializing arrays seems like busywork if I
need a specified length, but I only have 6 months in Python.

I've spent decades working with strongly typed languages. Perhaps those who've only used things like Python have failed to recognise the
benefits of strong typing.

Sylvia.

True. I can wholly say that I fell off a turnip truck yesterday. All
those dreams of Pascal, Basic, and C were just illusory memories
implanted by the Central Intelligence Agency.

Are you my contact then? My life is just a dream, Sylvia. Get your ass
to Mars.
--
Everything I fight for leaves a bitter taste
Everything I cry for laughs into my face
Everything I scream for barely knows my name
Everything I'd die for will die just the same
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Sylvia Else wrote:

I'm no expert either. Initializing arrays seems like busywork if I
need a specified length, but I only have 6 months in Python.

I've spent decades working with strongly typed languages. Perhaps those who've only used things like Python have failed to recognise the
benefits of strong typing.

Perhaps I misunderstood you and you are claiming that I've gone to the
dark side. That I've come to embrace weak typing.

Not really. It's just not what I think about very much presently while
writing software in Python. I also continue to use C# regularly too.
It's my preferred flavor of C. I guess I'm in the minority on this. It's
a powerful language and I hope Microsoft continues to develop it. But
many shun it, probably for the only reasons that it's novel & also is maintained by Microsoft.

As someone else here said, Python is actually strongly typed. You just
don't have to think about it much.

That's not the best way to put it, but I wouldn't be graced with endless clueless trolls to fight off if I didn't have an internally opaque way
of putting things. English is far from my strong suit.
--
Everything I fight for leaves a bitter taste
Everything I cry for laughs into my face
Everything I scream for barely knows my name
Everything I'd die for will die just the same
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Sylvia Else <sylvia@email.invalid> wrote:

I've spent decades working with strongly typed languages. Perhaps those >who've only used things like Python have failed to recognise the
benefits of strong typing.

Scripting languages like bash aren't really intended for large software projects, even though sometimes people use them as if they were. They
don't provide a lot of the features that a full programming language might.
You can't expect them because it's just not for that.

Python... Python doesn't know what it is. Sometimes it seems like it's a
real programming language, and sometimes it seems like it's a scripting language. And I thought the whole position-dependent statement thing
went out with JCL and 80-column cards, but now it's back again with a vengeance.

But I have also seen typing that was too strong, where floats had to be
coerced into double-precision and integers could never be pointers....
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Sylvia Else <sylvia@email.invalid> wrote: |----------------------------------------------------------------------------| |"And they actually teach Python at universities! Are they insane?" | |----------------------------------------------------------------------------|

Yes. Program in Ada.

|----------------------------------------------------------------------------| |"Companies should forget AI for programming, and just tell their | |developers that from now on, it's strongly types languages all the way down.| | | |Sylvia." | |----------------------------------------------------------------------------|

This is a crosspost to comp.lang.ada

(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

=?UTF-8?B?Q8OzaWzDrW4=?= =?UTF-8?B?IE5pb2Nsw6Fzw61u?= =?UTF-8?B?IEdsb3N0w6lpcg==?= <thanks-to@Taf.com> wrote or quoted:

Sylvia Else <sylvia@email.invalid> wrote:
|developers that from now on, it's strongly types languages all the way down.|

(Sorry for that indirect quotation, but I might have missed
Sylvia's post!)

Python actually is strongly typed, just not statically!

Statically Types are checked BEFORE execution (during compilation).
You must usually declare variable types in advance.
Examples: Java, C++, Rust.

Dynamically Types are checked DURING execution (at runtime).
Variables can hold any type of value and change over time.
Examples: Python, JavaScript, Ruby.

Strongly The language strictly enforces type rules. It prevents
implicit conversions (like adding a string to a number).
Examples: Python, Java, Python.

Weakly The language allows implicit type conversion (coercion).
It tries to guess and convert types behind the scenes.
Examples: JavaScript, C.

Newsgroups: comp.misc


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

ram@zedat.fu-berlin.de (Stefan Ram) writes:

=?UTF-8?B?Q8OzaWzDrW4=?= =?UTF-8?B?IE5pb2Nsw6Fzw61u?= =?UTF-8?B?IEdsb3N0w6lpcg==?= <thanks-to@Taf.com> wrote or quoted:

Sylvia Else <sylvia@email.invalid> wrote:
|developers that from now on, it's strongly types languages all the way down.|

(Sorry for that indirect quotation, but I might have missed
Sylvia's post!)

Python actually is strongly typed, just not statically!

Python is optionally statically typed (since 3.something).

Statically Types are checked BEFORE execution (during compilation).
You must usually declare variable types in advance.
Examples: Java, C++, Rust.

Dynamically Types are checked DURING execution (at runtime).
Variables can hold any type of value and change over time.
Examples: Python, JavaScript, Ruby.

--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 2026-09-15, Sylvia Else wrote:

Actually, it's a bash script I'm writing at the moment, but I've
experienced similar issues writing Python! (Yuck).

Every trivial typo can turn into a mammoth debugging exercise. Get the
case of a variable name wrong, and you're right down into "How can it possibly do that?" territory.

Forget to declare an array as associative, and you don't get an error
saying "What on earth are you doing? "fred" is not an integer", but
just weird unfathomable behaviour.

What would be a 5 five second correction in an IDE when writing C or
Java turns into a half hour exercise in tearing out of hair.

And they actually teach Python at universities! Are they insane?

I think you're conflating programming with coding. Python has, at one
point, been chosen in some places as the introductiory language to teach *programming*.

Companies should forget AI for programming, and just tell their
developers that from now on, it's strongly types languages all the way
down.

Sylvia.

--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Nuno Silva <nunojsilva@invalid.invalid> wrote or quoted:

On 2026-09-15, Sylvia Else wrote:

. . .

Every trivial typo can turn into a mammoth debugging exercise. Get the
case of a variable name wrong, and you're right down into "How can it >>possibly do that?" territory.
Forget to declare an array as associative, and you don't get an error >>saying "What on earth are you doing? "fred" is not an integer", but
just weird unfathomable behaviour.

. . .

I think you're conflating programming with coding. Python has, at one
point, been chosen in some places as the introductiory language to teach >*programming*.

Python is fantastic for teaching algorithmic thinking because
the pseudo-code-like syntax, the comprehensive library, and the
garbage collector help a lot. Some minor problems with Python
are just the tax you pay for that lack of friction elsewhere.

Now, let me add some remarks to the quoted material:

I think the character case aspect is similar in Python and C:

The following program has a case-related bug, and Python shows
no error message:

c = 299792458
C = 1
print( f"The speed of light is {C}." )

. But the same can be written in C:

#include <stdio.h>

int main( void )
{ long long c = 299792458LL;
long long C = 1LL;

printf("The speed of light is %lld.\n", C); }

. And in C you can't declare an array as associative anyway. Writing
your own associative arrays in C and then using them in a non-trivial
project with proper memory management is so hard, most people don't
get it right (that's why we get languages like Rust or Zig).

But here's a Python program trying to use an integer as an associative
array:

c = {} # associative array
C = 1 # integer
key = 0 # example key
value = 0 # example value
C[ key ]= value

Console Transcript

Traceback (most recent call last):
File "demo.py", line 5, in <module>
C[ key ]= value
TypeError: 'int' object does not support item assignment

. That's typing at work!


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Stefan Ram <ram@Zedat.FU-Berlin.De> schrieb: |------------------------------------------------------------------------|
|"[. . .] |
| |
| I think the character case aspect is similar in Python and C: |
| |
| The following program has a case-related bug, and Python shows |
| no error message: |
| |
|c = 299792458 |
|C = 1 | |print( f"The speed of light is {C}." ) |
| |
| . But the same can be written in C: |
| |
|[. . .]" | |------------------------------------------------------------------------|

This bug cannot happen in Ada.

|------------------------------------------------------------------------|
|" But here's a Python program trying to use an integer as an associative|
| array: |
| |
|c = {} # associative array |
|C = 1 # integer |
|key = 0 # example key | |value = 0 # example value |
|C[ key ]= value |
| |
| Console Transcript |
| | |Traceback (most recent call last): |
| File "demo.py", line 5, in <module> |
| C[ key ]= value | |TypeError: 'int' object does not support item assignment |
| |
| . That's typing at work!" | |------------------------------------------------------------------------|

Ada compilers refuse to let this mistake even become compiled, so an Ada-runtime executive does not perpetrate such a crash. This is a
crosspost to comp.lang.ada
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Nuno Silva wrote:

On 2026-09-15, Sylvia Else wrote:

Actually, it's a bash script I'm writing at the moment, but I've
experienced similar issues writing Python! (Yuck).

Every trivial typo can turn into a mammoth debugging exercise. Get the
case of a variable name wrong, and you're right down into "How can it
possibly do that?" territory.

Forget to declare an array as associative, and you don't get an error
saying "What on earth are you doing? "fred" is not an integer", but
just weird unfathomable behaviour.

What would be a 5 five second correction in an IDE when writing C or
Java turns into a half hour exercise in tearing out of hair.

And they actually teach Python at universities! Are they insane?

I think you're conflating programming with coding. Python has, at one
point, been chosen in some places as the introductiory language to teach *programming*.

LOL. Are you trying to claim that 'coding' is better than 'programming'?
I purposely avoid the term 'coding' in all my reports, because I think
it is, well, gay. What exactly are you putting in code? No, it is as
plain as English what you are doing. There is no cryptography in
programming. Choose a new term. 'Coding' sucks.
--
Everything I fight for leaves a bitter taste
Everything I cry for laughs into my face
Everything I scream for barely knows my name
Everything I'd die for will die just the same
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lane W <cactus_DAC@yahoo.com> wrote:

LOL. Are you trying to claim that 'coding' is better than 'programming'?
I purposely avoid the term 'coding' in all my reports, because I think
it is, well, gay. What exactly are you putting in code? No, it is as
plain as English what you are doing. There is no cryptography in >programming. Choose a new term. 'Coding' sucks.

We used to have "systems analysis" and "programming." But now most of
what we now call "programming" is what we used to call "systems analysis"
and what we used to call "programming," which is to say the drudge work
part, is called "coding." That is, turning the design into code.
--scott

--
Everything I fight for leaves a bitter taste
Everything I cry for laughs into my face
Everything I scream for barely knows my name
Everything I'd die for will die just the same

--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Thu, 17 Sep 2026 11:57:16 -0000 (UTC), C||il|!n Niocl|is|!n Glost|-ir wrote:

This bug cannot happen in Ada.

But then, Ada cannot offer anything with the convenience of printf,
can it?

Python can.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 2026-09-17, Lane W wrote:

Nuno Silva wrote:

On 2026-09-15, Sylvia Else wrote:

Actually, it's a bash script I'm writing at the moment, but I've
experienced similar issues writing Python! (Yuck).

Every trivial typo can turn into a mammoth debugging exercise. Get the
case of a variable name wrong, and you're right down into "How can it
possibly do that?" territory.

Forget to declare an array as associative, and you don't get an error
saying "What on earth are you doing? "fred" is not an integer", but
just weird unfathomable behaviour.

What would be a 5 five second correction in an IDE when writing C or
Java turns into a half hour exercise in tearing out of hair.

And they actually teach Python at universities! Are they insane?

I think you're conflating programming with coding. Python has, at one
point, been chosen in some places as the introductiory language to teach
*programming*.

LOL. Are you trying to claim that 'coding' is better than
'programming'?

I'm claiming they are separate things. In education, a least out of language/toolset-specific courses, you usually want to teach students
how to program, so that they do grasp the relevant concepts and ideas,
with coding being a byproduct, often necessary for the practical side of
it.

It's not that coding is no good, but that decent engineering happens by designing and writing code separately. Coding can be quite the art too.

It's possible to learn by coding, too, and often that will happen. But,
when you're trying to teach higher-level concepts and you have some
language that assists in making teaching less centered on writing code,
you probably want to use that.

This used to be a nice spot for R5RS, btw.

I purposely avoid the term 'coding' in all my reports,
because I think it is, well, gay. What exactly are you putting in
code? No, it is as plain as English what you are doing. There is no cryptography in programming. Choose a new term. 'Coding' sucks.

What do you suggest I use for "writing code", then?
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Nuno Silva <nunojsilva@invalid.invalid> wrote or quoted:

It's not that coding is no good, but that decent engineering happens by >designing and writing code separately. Coding can be quite the art too.

|source code is the real software design
"Code as Design" (1992) - Jack W. Reeves


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Stefan Ram <ram@Zedat.FU-Berlin.De> schrieb: |-----------------------------------------|
|"|source code is the real software design|
|"Code as Design" (1992) - Jack W. Reeves"| |-----------------------------------------|

A non-Dragon compiler-construction book from circa the 1980's in the
library of the European Space-TEchnology-and-research Centre states
that the source code of a program is up-to-date documentation of a
program. A report by the European Space Agency cites this book to this
effect.

(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

=?UTF-8?B?IEdsb3N0w6lpcg==?= <thanks-to@Taf.com> wrote:

A non-Dragon compiler-construction book from circa the 1980's in the
library of the European Space-TEchnology-and-research Centre states
that the source code of a program is up-to-date documentation of a
program. A report by the European Space Agency cites this book to this >effect.

I will buy this. Unfortunately, if this is the case, many people
document very poorly.

And of course, my favorite piece of Honeywell source code:

groovy:: ; do that groovy thing
.call_entry max_args=33,home_args=true,preserve=<r3,r5>
movl (ap),r3 ; boogity boogity boogity
moval 4(ap),r5 ; yeah, you got it baby
ret ; go back and do it again
.psect idata,wrt,noexe,quad
.align quad

--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Fri, 18 Sep 2026 14:07:48 -0000 (UTC), C||il|!n Niocl|is|!n Glost|-ir wrote:

A non-Dragon compiler-construction book from circa the 1980's in the
library of the European Space-TEchnology-and-research Centre states
that the source code of a program is up-to-date documentation of a
program. A report by the European Space Agency cites this book to
this effect.

We all know from (bitter) experience that thatrCOs nonsense. Maybe some
code succeeds in being rCLself-documentingrCY, but most of it isnrCOt.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> wrote:

On Fri, 18 Sep 2026 14:07:48 -0000 (UTC), C||il|!n Niocl|is|!n Glost|-ir wrote:

A non-Dragon compiler-construction book from circa the 1980's in the
library of the European Space-TEchnology-and-research Centre states
that the source code of a program is up-to-date documentation of a
program. A report by the European Space Agency cites this book to
this effect.

We all know from (bitter) experience that thatrCOs nonsense. Maybe some
code succeeds in being rCLself-documentingrCY, but most of it isnrCOt.

What could possibly be less than perfectly clear from code like this?

--cut here--
#include <stdio.h>
main(t,_,a )
char
*
a;
{
return!
0<t?
t<3?
main(-79,-13,a+
main(-87,1-_,
main(-86, 0, a+1 )
+a)):
1,
t<_?
main( t+1, _, a )
:3,
main ( -94, -27+t, a )
&&t == 2 ?_
<13 ?
main ( 2, _+1, "%s %d %d\n" )
:9:16:
t<0?
t<-72?
main( _, t, "@n'+,#'/*{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l+,/n{n+,/+#n+,/#\ ;#q#n+,/+k#;*+,/'r :'d*'3,}{w+K w'K:'+}e#';dq#'l \ q#'+d'K#!/+k#;q#'r}eKK#}w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]'/+#n';d}rw' i;# \ ){nl]!/n{n#'; r{#w'r nc{nl]'/#{l,+'K {rw' iK{;[{nl]'/w#q#n'wk nw' \ iwk{KK{nl]!/w{%'l##w#' i; :{nl]'/*{q#'ld;r'}{nlwb!/*de}'c \ ;;{nl'-{}rw]'/+,}##'*}#nc,',#nw]'/+kd'+e}+;#'rdq#w! nr'/ ') }+}{rl#'{n' ')# \ }'+}##(!!/")
:
t<-50?
_==*a ?
putchar(31[a]):

main(-65,_,a+1)
:
main((*a == '/') + t, _, a + 1 )
:
0<t?
main ( 2, 2 , "%s")
:*a=='/'||
main(0,
main(-61,*a, "!ek;dc i@bK'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m .vpbks,fxntdCeghiry") ,a+1);}

--cut here--
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:

Nuno Silva <nunojsilva@invalid.invalid> wrote or quoted:

It's not that coding is no good, but that decent engineering happens by >>designing and writing code separately. Coding can be quite the art too. >|source code is the real software design

"Code as Design" (1992) - Jack W. Reeves

I found additional statements on the Web that resonate
with my own experiences when editing source code:

|The software creation itself is the part that makes you
|understand what you are building. It's impossible to
|understand things before you start building them
xendo

and

|It's _extremely_ unlikely that you'll have the full spec and
|shape and architecture of something large fully settled in
|your head before you start.
Arubis

. Regarding programming with AI:

|Software is part of my identity and I won't abandon it that
|quickly.
Xendo

.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence DrCOOliveiro <ldo@nz.invalid> wrote: |----------------------------------------------------------------------|
|"We all know from (bitter) experience that thatrCOs nonsense. Maybe some| |code succeeds in being rCLself-documentingrCY, but most of it isnrCOt." | |----------------------------------------------------------------------|

I am sorry if I failed to paraphrase well. I had those documents 21
years ago. I never own that book. The point in that book and in that
report which I cite them about in this thread is not nonsense. That
point is not that all programming is literate programming. That point
is not that all source codes are good documentation. I hereby make
another attempt to indicate that point . . .

if your documentation in English about your software says the sum of Y
and Z is assigned to X

but

your software says

X : constant integer := Y - Z;

then

your documentation in English is wrong, and your software accurately
documents your software.

Cf. if the terrain and the map disagree, trust the terrain.

(That point does not include that a
compiler/runtime/interpreter/virtual machine/operating system is
buggy. That point does not include unsatisfactory hardware - e.g. the
source code of cp might not describe what cp would do if a hard disk
would run out of diskspace.)

(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sat, 19 Sep 2026 19:38:25 -0000 (UTC), C||il|!n Niocl|is|!n Glost|-ir
wrote:

if your documentation in English about your software says the sum of
Y and Z is assigned to X

but

your software says

X : constant integer := Y - Z;

then

your documentation in English is wrong, and your software accurately documents your software.

No, the software documents nothing. The documentation is still the documentation, and the documentation is wrong.

Cf. if the terrain and the map disagree, trust the terrain.

The whole point with having a map is not having to traverse the entire
terrain every time you want to go somewhere.

Similarly, the whole point with having program documentation is not
having to decipher the entire program code every time you want to use/modify/fix the program.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> wrote:

Similarly, the whole point with having program documentation is not
having to decipher the entire program code every time you want to >use/modify/fix the program.

If the code is written well, there are a lot of comments interspersed
with the code to explain what it is doing, and comments in front of each
block to explain why it's there, as well as comments at each function
that explain what the function does and what side effects it might have
and what might call it.

You could argue that the code itself is not documentation, but the documentation is inserted into the code and that might not be wrong
either.

Comments like "Add one to the accumulator" and "this is magic" are
not useful and not a sign of well-written code.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 17-Sept-26 5:34 pm, Nuno Silva wrote:

On 2026-09-15, Sylvia Else wrote:

Actually, it's a bash script I'm writing at the moment, but I've
experienced similar issues writing Python! (Yuck).

Every trivial typo can turn into a mammoth debugging exercise. Get the
case of a variable name wrong, and you're right down into "How can it
possibly do that?" territory.

Forget to declare an array as associative, and you don't get an error
saying "What on earth are you doing? "fred" is not an integer", but
just weird unfathomable behaviour.

What would be a 5 five second correction in an IDE when writing C or
Java turns into a half hour exercise in tearing out of hair.

And they actually teach Python at universities! Are they insane?

I think you're conflating programming with coding. Python has, at one
point, been chosen in some places as the introductiory language to teach *programming*.

For most of my adult life, my technical colleagues and I were
programmers, because what we did was programming, even if, when things
went wrong, we'd examine the code.

The only time I had to deal with "coding sheets" was at university, and
I rapidly realise that it was quicker just to punch my own cards, than
to deal with the law of diminishing returns when trying to get the punch
card operators to correctly transcribe what I'd written.

Later on were were software engineers.

It seems to me that only relatively recently (perhaps during last 10-15
years, or so) did the practice of writing programs start to be called
coding, and the people who did it called coders.

I dunno. Perhaps it just got to me because I wondered who decided that
it needed to be changed, suspecting that it was the media, who knew
little about it (nothing's changed there).

Sylvia.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence DrCOOliveiro <ldo@nz.invalid> wrote: |-------------------------------------------------------------------|
|"No, the software documents nothing. The documentation is still the| |documentation, and the documentation is wrong." | |-------------------------------------------------------------------|

Fair enough.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sun, 20 Sep 2026 19:10:50 +0800, Sylvia Else wrote:

The only time I had to deal with "coding sheets" was at university,
and I rapidly realise that it was quicker just to punch my own
cards, than to deal with the law of diminishing returns when trying
to get the punch card operators to correctly transcribe what I'd
written.

Been there, done that.

Thankfully my class only caught the tail-end of the flow-charts fad,
and our lecturers were enlightened enough to agree that they were a
waste of time.

Though -#'ve lately been developing a soft spot for Nassi-Shneiderman
diagrams ...

It seems to me that only relatively recently (perhaps during last
10-15 years, or so) did the practice of writing programs start to be
called coding, and the people who did it called coders.

Maybe itrCOs a disparaging term or something.

Probably applies to PHP programmers, though ...
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Sylvia Else <sylvia@email.invalid> wrote:

Actually, it's a bash script I'm writing at the moment, but I've
experienced similar issues writing Python! (Yuck).

Every trivial typo can turn into a mammoth debugging exercise. Get the
case of a variable name wrong, and you're right down into "How can it possibly do that?" territory.

Bash's -u option might help during development: any reference to an
unset variable is considered an error. Also, I've found the -x option
useful (prints commands with expanded variables as they are executed).

Both options are also found on other Bourne-type shells like ksh or dash.
--
Dario Niedermann -:- PGP key available at the best keyservers
--- Synchronet 3.22a-Linux NewsLink 1.2