On 30/08/2024 13:59, David Brown wrote:
On 30/08/2024 01:49, Bart wrote:
On 29/08/2024 13:24, David Brown wrote:
On 28/08/2024 21:27, Bart wrote:
On 28/08/2024 19:48, David Brown wrote:
<snipping for brevity>
It's just too 'open'. The contents of foo look like they're leaking into the rest of the program. As it is, someone looking at this in the future wanting to a a new statement to 'if a:' might think it ends before the comments since that 'anewstmt' is too far from the main body.
>
It needs delimiters:
>
>
def foo(a, b, c) :
if a :
if b :
if c :
doThis()
end
bnewstmt
end
>
# comment
# comment
anewstmt
end
end
It does not /need/ delimiters.
There's lot of things that language syntax might not need. For example, I could dispense with the closing parentheses here:
x = (a + (b + (c + d
as they can supplied as needed at end-of-line. But it's much better idea to supply them for all sorts of reasons.
(My Casio calculator allows such parentheses to be left out.)
It does, sometimes, need a bit more care, especially if you have lots of nesting.
A /lot/ more care.
(And again let me repeat - I prefer languages to have explicit delimiters. But that does not stop me being able to write Python code, or being happy with the language overall. There are a dozen things I dislike about Python, of which whitespace blocking is a very minor one, but there are many dozens more things I do like about it for the tasks for which I use the language.)
I just find the syntax fragile.
How about just fixing the ******* language? That must be better than a million programmers wasting time creating their own fixes.
Ah, so it is better to invalidate all the work done by these million programmers so far, along with all the tools, books, courses, documentation, etc., than to say that people writing big functions might want to add an occasional comment? Yes, I can see how that makes perfect sense.
If you're going fix it, then fix up, and not wait 30+ years to do so!
But there can be ways to do it without needing to change existing code or tools.
>
Having made your own language(s) gives you no more and no less right to comment about features of other languages that you like or dislike.
>
>
I had my opinions even before I used my own stuff.
>
Sure. We all have opinions about all sorts of things. Some people even have /informed/ opinions, that might be relevant to other people.
One thing I despised was the begin-end business in Algol60 and Pascal, which has the same nuisance as braces in C-like languages.
>
You don't like whitespace based blocks, and you don't like explicit delimiters for blocks. Maybe you just don't like structured programming? (Not all programming languages are structured.)
Both brace-style (and especially C-style optional braces) and indent-based have their problems.
I didn't like writing 'end else begin' any more than '} else {'. My stuff (and a few languages have picked up on it), uses just 'else', which also limits the placement possibilities when you have one token rather than three.
Ah, it is the need to press a couple of extra keys that you despise so much?
no, it's just poor ergonomics. Language designers must have thought it neat to allow only a single statement for function bodies, loop bodies, or branches of conditional code.
If someone wanted more than one statement, they wrapped them inside a 'compound' statement (and hence you ended up with conditional '{-}' and conditional 'begin-end'.
But look at these examples:
if (cond) {s1; s2;} else {s3; s4;}
if cond then begin s1; s2 end else begin s3; s4 end
It's clear that those first sets of block delimiters are not needed: s1 and s2 are already delimited by ') ... else' or 'then ... else'.
A delimiter is only really needed at the end of the final 'else' block:
if (cond) s1; s2; else s3; s4;}
if cond then s1; s2 else s3; s4 end
With the second line, it works (this is what Algol68 introduced, and what I copied).
But that first line looks weird with its unbalanced closing }. There can also be a problem if you wanted to dispense with the brackets around '(cond)', as now 'cond' runs into 's1'.
So C-style syntax is not an easy fix; better to leave it.
Note that Python does use block delimiters in some cases:
if cond:
s1
s2
else
s3
s4
Like the 'else' here. It is the one for the final block that is missing.
Yes. I'm into language design. But I'm also interested in aspects of it that many disregard, such as microfeatures, or ease of deployment.
>
That's great. But being interested in languages, their design, and their features does not mean having an obsession about calling their features "flaws".
Are you saying that no language (C for example) has flaws?
If not, then why can't I call them flaws?
It's not just me!
>
For every programmer involved in changing and developing the Fortran language, there are a thousand programmers who use it - whichever version of it they find best for their job. Now, it is important that these one-in-a-thousand programmers are there, improving the language. But most of us are in the 999-in-a-thousand group that /use/ the language. (In that one-in-a-thousand I am including the people who actively take part in discussions or proposals for changing the language, but not people who just moan about stuff in discussion groups.)
So I don't count?
Apparently I'm in the 999/1000 group even though I don't use those languages. But I can't be in the 1/1000 group because I'm not involved in those languages.
So I guess I'm nowhere.
Clearly you can take your own complaints seriously for your own languages, and they are very important to you personally. But in the grand scheme of things, they are utterly irrelevant to everyone else. So you are also in the 999-in-a-thousand group, just like everyone else here.
Not really. You just want to belittle the stuff I do.
Pretty much everything I've complained about in a mainstream language, is something that I've fixed in my own products. So I know much work that was to do, how well it worked, or whether it failed, or if I decided it wasn't worthwhile.
People in the 999/1000 group don't normally run their own languages, or manage their own implementations of existing languages, to try such experiments.
In my case the experiment has been running since 1982.
Complaining about languages (or any kind of tool) doesn't change them - it doesn't do anything except make you less happy about using them. It's fine to discuss alternative ways to handle aspects of a language that you don't like, and to see if you can make it work better for your needs and preferences. It's fine to compare it to other languages, and see if there are alternatives that would suit you better. And sometimes having a rant is fun - after all, complaining (especially about the weather) is the national pastime for Brits. But mostly it is counter-productive.
You still get it. I can actually change my 'weather'! You're just jealous.
Python is full of ill-advised choices. And it's become almost as much of a monster as C++, with a million incompatible features bolted on.
>
So don't use it if you don't like it. Mushy peas are an ill-advised choice - I choose not to eat them, rather than to go to cookery groups and tell everyone how horrible they are.
This isn't a Python group nor a C group. Any language can be discussed including private ones.
Funny, I can complain about lots of languages that I never use!
Yes, and no one takes your opinions seriously. Do you think there might be some reason for that?
You don't, certainly.
I have to keep reminding you, the stuff I do isn't just mouthing off, it is actually implementing things. And it's not just toy hobbyist stuff either, it's *what I used to earn a living*.
Even last century I could write stuff like this:
[10]int a, b
a := b
This copies array b to a. Even after 50 years, C can't do this, you have to write (AFTER including string.h, jesus..):
memcpy(a, b, sizeof(a)/sizeof(a[0]));
But here a compiler can't check that a and b are the same size, or even of the same type! Nor can it check I've supplied the right size.
According to you however, I'm not allowed to point out such shortcomings or 'flaws' in a language, because I don't have any clout.
So, the flaws don't exist, or do they only exist if that 1/1000 Alpha individual says they do?
Command Languages Versus Programming Languages
Re: Command Languages Versus Programming Languages
