| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 42 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 01:39:38 |
| Calls: | 220 |
| Calls today: | 1 |
| Files: | 824 |
| Messages: | 121,542 |
| Posted today: | 6 |
Windows inter-process API are far more advanced than what UNIX ever had.
It would be enough to mention famous file locks.
The reason why processes are not included is that they are used to deal
with some OS or design flaw that forces you to spawn some script or application.
On Sat, 17 Aug 2024 12:58:31 +0200, Dmitry A. Kazakov wrote:
Windows inter-process API are far more advanced than what UNIX ever had.
It would be enough to mention famous file locks.
Except those file locks are more of a liability than an asset.
They are
what prevent you from continuing to use a Windows system while it is being updated, for example.
The reason why processes are not included is that they are used to deal
with some OS or design flaw that forces you to spawn some script or
application.
Or because the *nix tradition of being able to spawn a pipeline of
multiple processes, all cooperating to perform a common task, is difficult and expensive, or even unreliable, under Windows.
On 2024-08-17 23:51, Lawrence D'Oliveiro wrote:
Or because the *nix tradition of being able to spawn a pipeline of
multiple processes, all cooperating to perform a common task, is difficult >> and expensive, or even unreliable, under Windows.
It is as expensive under Windows as it is under UNIX. There is no
problem to produce the same mess as under UNIX. In fact Windows shells
do this just same.
Windows has a pipe object named and anonymous. No problem. Pipes are
rarely used in applications because it is not how distributed systems
(where multiple processes are indeed used) are designed. They usually
require processes be able to run on different nodes.
P.S. It is no wonder that Windows process API are far beyond UNIX.
Historically UNIX started with singe fork() call. There was nothing but >files, no system objects, nothing.
On the other hand, Windows NT was developed by people influenced with
the VMS design. VMS had a very elaborated process communication API. So >Windows inherited much of that, but must importantly the concept of
system resources managed by the OS.
On 2024-08-17 23:51, Lawrence D'Oliveiro wrote:
On Sat, 17 Aug 2024 12:58:31 +0200, Dmitry A. Kazakov wrote:
Windows inter-process API are far more advanced than what UNIX ever had. >>> It would be enough to mention famous file locks.
Except those file locks are more of a liability than an asset.
Like so many things in UNIX...
On 2024-08-17 11:01, Muttley@dastardlyhq.com wrote:
On Fri, 16 Aug 2024 15:02:20 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) gabbled:
So it is indeed a vague question of what belongs in given programming
languages.
Indeed. And this gives rise to inconsistency. Why is threading now considered
a core part of C++ but multi process isn't? Perhaps because Windows is >hopeless
at the latter in user space but it could just be personal preference within >the
C++ steering committee, who knows.
Windows inter-process API are far more advanced than what UNIX ever had.
It would be enough to mention famous file locks. These days Linux has
futex + file mapping. So, finally, you can create a system-wide mutex.
Which under Windows is a single API call.
The reason why processes are not included is that they are used to deal
with some OS or design flaw that forces you to spawn some script or >application. Then real-time embedded applications may have no processes
In article <v9sa91$2afht$1@dont-email.me>,
Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
On 2024-08-17 23:51, Lawrence D'Oliveiro wrote:
On Sat, 17 Aug 2024 12:58:31 +0200, Dmitry A. Kazakov wrote:
Windows inter-process API are far more advanced than what UNIX ever had. >>>> It would be enough to mention famous file locks.
Except those file locks are more of a liability than an asset.
Like so many things in UNIX...
Ah, funny!
Yup - just what we need: Another Unix vs. Windows dick waving contest!!!
So productive use of Usenet bandwidth.
The windows process API is crippled which is why threading is the main parallel processing method in Windows and has been since 3.0.
If you think
otherwise please give some examples. However I distincly remember trying to port server to windows only to discover that sockets are some wierd structure in windows instead of a simple file descriptor meaning it was impossible to multiplex using poll() or select() on them, you had to have
a seperate thread to manage each connection. What a fucking mess designed
by idiots.
Historically UNIX started with singe fork() call. There was nothing but
files, no system objects, nothing.
fork() copies the entire process space. No idea what you mean by "system objects". Must be some windows thing.
On the other hand, Windows NT was developed by people influenced with
the VMS design. VMS had a very elaborated process communication API. So
Windows inherited much of that, but must importantly the concept of
system resources managed by the OS.
Windows NT was a slow unreliable dog.
Windows did many things wrong, but accessing file descriptors by numbers
is beyond even Windows. In Windows a file is an OS object. You access it getting an opaque handle to. Note that a handle can be marshaled from
one process to another. Try that with process-local numbers!
In comp.unix.programmer Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
Windows did many things wrong, but accessing file descriptors by numbers
is beyond even Windows. In Windows a file is an OS object. You access it
getting an opaque handle to. Note that a handle can be marshaled from
one process to another. Try that with process-local numbers!
UNIX domain sockets support the passing of file descriptors between processes.
On Thu, 29 Aug 2024 14:05:41 +0200, David Brown wrote:
... put in so much extra
crap and silliness that readers get caught up in that instead of
noticing that most of the function is meaningless.
Interesting. Now you are trying to claim that, because you don’t
understand what the code does, that makes it somehow “meaningless”?
On Thu, 29 Aug 2024 14:24:01 +0200, David Brown wrote:
def foo(a, b, c) :
if a :
if b :
if c :
doThis()
That looks unfinished to me. So I will add a "return" at the end (with
a single tab indent, in this case).
A redundant “return” ... kind of like my redundant “#end” comments, except
yours work in a more restricted set of places ...
Don't you ever just accept that a language is the way it is, and it is
perfectly useable that way?
Of course not.
Or think that perhaps other people in the world know better than you do
about how they want their language to work?
And vice versa.
Has it never occurred to you that the people behind a given
language - such as Python - considered various alternatives and decided
that making it the way they did was the best choice overall for the
language they wanted?
Barring a few obvious stupidities, yes of course they were, and are, smart people.
Subjectively, I prefer early returns over nested ifs:
On Sat, 14 Sep 2024 10:06:12 +0200, Janis Papanagnou wrote:
On 30.08.2024 04:53, Lawrence D'Oliveiro wrote:
Emacs makes no such assumption, and can also edit non-text files.
You have obviously no clue.
I have actually used it for that. That’s my “clue” to you.
LDO: >> Vim is only good for text-editing, though.On 30.08.2024 04:53, Lawrence D'Oliveiro wrote:
$ man vim | grep -i binary
-b Binary mode. A few options will be set that makes it
possible to edit a binary or executable file.
On Sat, 14 Sep 2024 19:10:06 GMT, Scott Lurndal wrote:
$ man vim | grep -i binary
-b Binary mode. A few options will be set that makes it
possible to edit a binary or executable file.
Wow, a special mode just to edit binary files, when Emacs can do it in
its regular mode.
It just sets a bunch of options to minimize the chance of screwing up
the file in ways you don’t want. Apart from that, it’s still editing
it as a text file.
On Fri, 16 Aug 2024 15:02:20 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) gabbled:
So it is indeed a vague question of what belongs in given programming
languages.
Indeed. And this gives rise to inconsistency. Why is threading now considered a core part of C++ but multi process isn't? Perhaps because Windows is hopeless
at the latter in user space but it could just be personal preference within the
C++ steering committee, who knows.
In comp.unix.programmer Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2024-08-15, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Thu, 15 Aug 2024 19:48:36 -0000 (UTC), Kalevi Kolttonen wrote:
The last I checked, the O'Reilly Python book is just absolutely
*MASSIVE*. The language has a huge number of features now ...
No, it hasn’t. The core language reference spec is only a small fraction >>> of, say, the Java language spec.
It’s just that you can do so many things with Python. And that is down to >>> the huge variety of off-the-shelf addon libraries that build on that core >>> language spec. It has to be a strong, very solidly founded core in order >>> to be such a versatile basis for these addons, and it is.
That's idiotic; you're saying that the standard library packages of
Python are not part of Python, and do not contribute to its size.
You seem to have a point. The core of C language is also small. I
guess they even said in the original K & R book that C is a small
language best described by a small book.
But in order to do anything with C, you need to know the standard
libraries. They have grown bigger and bigger during all these
years. One could also well argue that to program on UNIX, you also
need to know all the POSIX libraries.
So it is indeed a vague question of what belongs in given programming languages.
On 2024-08-18 10:30, Muttley@dastardlyhq.com wrote:
The windows process API is crippled which is why threading is the main
parallel processing method in Windows and has been since 3.0.
Threading is the main method because of its performance in a tight
coupled application. Crossing the process borders is very expensive.
otherwise please give some examples. However I distincly remember trying to >> port server to windows only to discover that sockets are some wierd
structure in windows instead of a simple file descriptor meaning it was
impossible to multiplex using poll() or select() on them, you had to have
a seperate thread to manage each connection. What a fucking mess designed
by idiots.
There is no problem using socket select with Windows. Here is an >implementation of a server doing that:
http://www.dmitry-kazakov.de/ada/components.htm#17.1
You can check the Windows implementation of to learn how it is done with >Windows sockets.
fork() copies the entire process space. No idea what you mean by "system
objects". Must be some windows thing.
Objects managed by the OS.
Windows NT was a slow unreliable dog.
It is not slow. Actually you can get same or better performance under
Windows as under Linux. The problem is the default settings of the
On 17/08/2024 11:01, Muttley@dastardlyhq.com wrote:
On Fri, 16 Aug 2024 15:02:20 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) gabbled:
So it is indeed a vague question of what belongs in given programming
languages.
Indeed. And this gives rise to inconsistency. Why is threading now considered
a core part of C++ but multi process isn't? Perhaps because Windows is >hopeless
at the latter in user space but it could just be personal preference within >the
C++ steering committee, who knows.
No, it is because of what the term "program" usually means, along with
the terms "process" and "thread" (at the OS level). With C++, you write >"programs", and each process is a running program. Like most languages,
C++ does not cover what happens outside the program - that's part of the
OS specification, or specifications for other programs or other parts of
the complete system. But threads are /within/ the program, and thus
covered (to at least some extent) by the language used to write the program.
On Sun, 18 Aug 2024 12:19:10 +0200
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> boringly babbled:
On 2024-08-18 10:30, Muttley@dastardlyhq.com wrote:
The windows process API is crippled which is why threading is the main
parallel processing method in Windows and has been since 3.0.
Threading is the main method because of its performance in a tight
coupled application. Crossing the process borders is very expensive.
Most (all?) versions of unix use copy-on-write when forking
Also shared memory is pretty cheap too.
No idea what the pages of all that crap is.
Windows sockets are not integers ,
they can't be multiplexed with file
descriptors, pipes etc in a single call.
fork() copies the entire process space. No idea what you mean by "system >>> objects". Must be some windows thing.
Objects managed by the OS.
Like what? Why does the OS need to manage "objects"?
I'm not talking about now, I was talking about when NT came out. Learn to read.
On 2024-08-17 23:51, Lawrence D'Oliveiro wrote:
On Sat, 17 Aug 2024 12:58:31 +0200, Dmitry A. Kazakov wrote:
Windows inter-process API are far more advanced than what UNIX ever had. >>> It would be enough to mention famous file locks.
Except those file locks are more of a liability than an asset.
Like so many things in UNIX...
They are
what prevent you from continuing to use a Windows system while it is being >> updated, for example.
Windows mutex gets collected when the last process using it dies. UNIX
file lock does not.
If you want to compare Windows vs UNIX API, create a table and list
commonly used process communication things. In the cells write the API
call. E.g. mutex, pipe, pulse event etc.
On 2024-08-18, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
If you want to compare Windows vs UNIX API, create a table and list
commonly used process communication things. In the cells write the API
call. E.g. mutex, pipe, pulse event etc.
PulseEvent is an unreliable API left over from 16 bit Windows.
If a mutex is actually used to protect shared data against concurrent
access, and the owner dies while holding the mutex, the next thread
to try to grab the mutex must be informed so it can try to recover
the shared data into a sane state.
Most (all?) versions of unix use copy-on-write when forking so while the processes are only reading its no different to threading. I doubt windows implements CoW since - in user space at least - it can't do fork and you wouldn't need it for executing a brand new process from scratch.
Windows sockets are not integers,
On 2024-08-17 23:51, Lawrence D'Oliveiro wrote:
On Sat, 17 Aug 2024 12:58:31 +0200, Dmitry A. Kazakov wrote:
Windows inter-process API are far more advanced than what UNIX ever
had. It would be enough to mention famous file locks.
Except those file locks are more of a liability than an asset.
Like so many things in UNIX...
They are what prevent you from continuing to use a Windows system while
it is being updated, for example.
Windows mutex gets collected when the last process using it dies. UNIX
file lock does not.
The reason why processes are not included is that they are used to
deal with some OS or design flaw that forces you to spawn some script
or application.
Or because the *nix tradition of being able to spawn a pipeline of
multiple processes, all cooperating to perform a common task, is
difficult and expensive, or even unreliable, under Windows.
It is as expensive under Windows as it is under UNIX.
Windows has a pipe object named and anonymous. No problem.
P.S. It is no wonder that Windows process API are far beyond UNIX.
On the other hand, Windows NT was developed by people influenced with
the VMS design. VMS had a very elaborated process communication API.
They usually require processes be able to run on different nodes.
Windows did many things wrong, but accessing file descriptors by numbers
is beyond even Windows. In Windows a file is an OS object. You access it getting an opaque handle to. Note that a handle can be marshaled from
one process to another. Try that with process-local numbers!
On 2024-08-17 11:01, Muttley@dastardlyhq.com wrote:
On Fri, 16 Aug 2024 15:02:20 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) gabbled:
Windows inter-process API are far more advanced than what UNIX everSo it is indeed a vague question of what belongs in givenIndeed. And this gives rise to inconsistency. Why is threading now
programming languages.
considered a core part of C++ but multi process isn't? Perhaps
because Windows is hopeless at the latter in user space but it could
just be personal preference within the C++ steering committee, who
knows.
had. It would be enough to mention famous file locks. These days
On 2024-08-18 18:46, Kaz Kylheku wrote:
If a mutex is actually used to protect shared data against concurrent
access, and the owner dies while holding the mutex, the next thread
to try to grab the mutex must be informed so it can try to recover
the shared data into a sane state.
There is no recovery if a protected operation crashes, because the state
of the object is unknown.
On 2024-08-18, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
On 2024-08-18 18:46, Kaz Kylheku wrote:
If a mutex is actually used to protect shared data against concurrent
access, and the owner dies while holding the mutex, the next thread
to try to grab the mutex must be informed so it can try to recover
the shared data into a sane state.
There is no recovery if a protected operation crashes, because the state
of the object is unknown.
That is false; the object's state can be analyzed and repaired.
David Brown <david.brown@hesbynett.no> writes:
[...]
Without looking it up, what does the C standard library "fegetmode"
function do?
Nothing, it's specific to GNU libc.
On Sun, 18 Aug 2024 10:10:09 +0200, Dmitry A. Kazakov wrote:
On 2024-08-17 23:51, Lawrence D'Oliveiro wrote:
On Sat, 17 Aug 2024 12:58:31 +0200, Dmitry A. Kazakov wrote:
Windows inter-process API are far more advanced than what UNIX ever
had. It would be enough to mention famous file locks.
Except those file locks are more of a liability than an asset.
Like so many things in UNIX...
People voluntarily choose to use Unix-type OSes. There’s a reason why Unix-type OSes are the official de-facto standard in the computing world,
not Windows.
They are what prevent you from continuing to use a Windows system while
it is being updated, for example.
Windows mutex gets collected when the last process using it dies. UNIX
file lock does not.
What happens to a file lock when there is no file for it to lock?
Remember, the current Windows (aka Windows NT) was masterminded by Dave Cutler, who came from the nest of Unix-haters at DEC. He carried over many
of the characteristics of his last major brainchild there, VMS. One of
them is that creating multiple processes is expensive, so you try to avoid it.
Windows has a pipe object named and anonymous. No problem.
One problem: you can’t use them with poll/select calls.
P.S. It is no wonder that Windows process API are far beyond UNIX.
Linux has clone(2). This can create regular POSIX-style processes, as well
as regular POSIX-style threads. And quite a few things in-between.
On the other hand, Windows NT was developed by people influenced with
the VMS design. VMS had a very elaborated process communication API.
And single drive letters?
On 2024-08-19 01:14, Lawrence D'Oliveiro wrote:
Both OSes contributed to the Dark Ages of computing. The reasons are not technical, because both were worst on the market.
Windows does not use lock files.
The reason why Windows NT could no compete Linux on servers is
unbearable maintenance and being fat. Linux had a monolithic kernel. I compiled it for each machine to include only drivers I needed. I did not install X11 stuff. The result was twice leaner than Windows NT.
On the other hand you still cannot have decent gaming under Linux.
On Sun, 18 Aug 2024 10:10:09 +0200, Dmitry A. Kazakov wrote:
Windows has a pipe object named and anonymous. No problem.
One problem: you can’t use them with poll/select calls.
You can. See overlapped I/O.
And single drive letters?
They are dozens characters long actually, if you mean the device names.
On 2024-08-18 17:45, Muttley@dastardlyhq.com wrote:
On Sun, 18 Aug 2024 12:19:10 +0200
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> boringly babbled:
On 2024-08-18 10:30, Muttley@dastardlyhq.com wrote:
The windows process API is crippled which is why threading is the main >>>> parallel processing method in Windows and has been since 3.0.
Threading is the main method because of its performance in a tight
coupled application. Crossing the process borders is very expensive.
Most (all?) versions of unix use copy-on-write when forking
You seems do not understand that spawning a process is not an issue of >interprocess communications. It is synchronization, e.g. events, mutexes >which is.
Also shared memory is pretty cheap too.
Again, you need to synchronize in order to access shared objects, not to >mention elaboration of such objects, e.g. calling constructors and >destructors. With threads there is a linker support in most languages.
With processes you are on your own.
In the same library you might find portable implementation of basic >communication objects and compare Windows vs Linux vs BSD implementations:
http://www.dmitry-kazakov.de/ada/components.htm#12
No idea what the pages of all that crap is.
Hmm, if you ever dealt with networking applications you should have had
some idea...
Windows sockets are not integers ,
Windows did many things wrong, but accessing file descriptors by numbers
is beyond even Windows. In Windows a file is an OS object. You access it >getting an opaque handle to. Note that a handle can be marshaled from
one process to another. Try that with process-local numbers!
they can't be multiplexed with file
descriptors, pipes etc in a single call.
Of course it can. Windows overlapped I/O supports sockets.
Like what? Why does the OS need to manage "objects"?
Like a graphic context or a mutex. Things that leak if the process dies >unless the OS takes care of.
I'm not talking about now, I was talking about when NT came out. Learn to
read.
Honestly I do not know what you are talking about. The option to change
the scheduling interval existed in Windows NT.
If you want to compare Windows vs UNIX API, create a table and list
commonly used process communication things. In the cells write the API
call. E.g. mutex, pipe, pulse event etc.
On 2024-08-19 01:14, Lawrence D'Oliveiro wrote:
On Sun, 18 Aug 2024 10:10:09 +0200, Dmitry A. Kazakov wrote:
On 2024-08-17 23:51, Lawrence D'Oliveiro wrote:
On Sat, 17 Aug 2024 12:58:31 +0200, Dmitry A. Kazakov wrote:
Windows inter-process API are far more advanced than what UNIX ever
had. It would be enough to mention famous file locks.
Except those file locks are more of a liability than an asset.
Like so many things in UNIX...
People voluntarily choose to use Unix-type OSes. There’s a reason why
Unix-type OSes are the official de-facto standard in the computing world,
not Windows.
Both OSes contributed to the Dark Ages of computing. The reasons are not technical, because both were worst on the market.
The similar process
happened with programming languages, e.g. C and with the hardware architectures, e.g. x86. It is always a race to the bottom...
They are what prevent you from continuing to use a Windows system while >>>> it is being updated, for example.
Windows mutex gets collected when the last process using it dies. UNIX
file lock does not.
What happens to a file lock when there is no file for it to lock?
Windows does not use lock files.
Under Linux you must log in as the root
and remove the stray file lock manually. It happens in UNIX
administration all the time.
Remember, the current Windows (aka Windows NT) was masterminded by Dave
Cutler, who came from the nest of Unix-haters at DEC. He carried over
many
of the characteristics of his last major brainchild there, VMS. One of
them is that creating multiple processes is expensive, so you try to
avoid
it.
A wise decision. The look of UNIX SysV process list was a sheer horror
to any user of RSX or VMS. No wonder UNIX was many times slower on same machines. A VMS 1Mb machine supported 4 users running an interactive IDE sessions (in LSE). UNIX users enjoyed Vi and permanent fatal crashes.
The early filesystem rewrote the master block, so after the crash you
could not boot anymore and have to restore the system from the tape.
Under RSX you could turn the main disk off and on without reboot.
The reason why Windows NT could no compete Linux on servers is
unbearable maintenance and being fat. Linux had a monolithic kernel. I compiled it for each machine to include only drivers I needed. I did not install X11 stuff. The result was twice leaner than Windows NT.
On the other hand you still cannot have decent gaming under Linux.
Windows has a pipe object named and anonymous. No problem.
One problem: you can’t use them with poll/select calls.
You can. See overlapped I/O.
P.S. It is no wonder that Windows process API are far beyond UNIX.
Linux has clone(2). This can create regular POSIX-style processes, as
well
as regular POSIX-style threads. And quite a few things in-between.
On the other hand, Windows NT was developed by people influenced with
the VMS design. VMS had a very elaborated process communication API.
And single drive letters?
They are dozens characters long actually, if you mean the device names.
On Mon, 19 Aug 2024 09:37:39 +0200, Dmitry A. Kazakov wrote:
The reason why Windows NT could no compete Linux on servers is
unbearable maintenance and being fat. Linux had a monolithic kernel. I
compiled it for each machine to include only drivers I needed. I did not
install X11 stuff. The result was twice leaner than Windows NT.
You don’t think the design of Windows NT contributed to that failure?
On the other hand you still cannot have decent gaming under Linux.
Actually, you can. Look at the Steam Deck, which runs a purpose-built GUI
for handheld gaming.
Windows “Handheld Mode” for about two years now, but still has nothing to ship.
On Sun, 18 Aug 2024 10:10:09 +0200, Dmitry A. Kazakov wrote:
Windows has a pipe object named and anonymous. No problem.
One problem: you can’t use them with poll/select calls.
You can. See overlapped I/O.
I said “poll/select calls”. Do you not know what those are? On Windows, they work with sockets, but not with pipes. Or even ordinary files. So
unlike *nix systems, you have to keep in mind the different kinds of files you might be working with.
And single drive letters?
They are dozens characters long actually, if you mean the device names.
Drive names are only single letters. You’re not talking about reserved
file names, are you?
On 19/08/2024 09:37, Dmitry A. Kazakov wrote:
Both OSes contributed to the Dark Ages of computing. The reasons are
not technical, because both were worst on the market.
What sort of time-frame are you thinking of here, what were the
alternatives that you think were "better", what markets or uses are you considering, and in what way were other OS's "better" ?
There's no doubt that non-technical issues have had a big influence on
which OS's or types of OS have succeeded, but you seem to have something specific in mind.
Windows has locks on files, which are a different thing. While I can understand the point of them, they can be a real inconvenience (try
deleting a directory tree when a file from that tree is in use).
Under Linux you must log in as the root and remove the stray file lock
manually. It happens in UNIX administration all the time.
As someone who has administrated Linux servers for decades, and used it
as my desktop OS on many machines, I am not sure I can ever remember
removing a stray lock file. Certainly needing to do so "all the time"
is a very wild exaggeration. Linux, like all systems, undoubtedly has
its flaws and weaknesses, but this is not one of them IME.
Times change. Needs and uses change. Hardware changes.
Keeping things separate and modular has advantages in scalability,
security and stability. Keeping things monolithic has advantages in efficiency (speed and memory) and consistency. There is no "right" answer.
On the other hand you still cannot have decent gaming under Linux.
I do almost all my gaming under Linux. Some games do work better under Windows, but that is primarily because most games developers target
Windows as their main platform. It may also be because Linux systems
are more varied.
And single drive letters?
They are dozens characters long actually, if you mean the device names.
I thought by "drive letters", he meant "drive letters" - "c:", "d:", etc.
On 2024-08-25 09:50, Sebastian wrote:
In comp.unix.programmer Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>
wrote:
Windows did many things wrong, but accessing file descriptors by
numbers is beyond even Windows. In Windows a file is an OS object. You
access it getting an opaque handle to. Note that a handle can be
marshaled from one process to another. Try that with process-local
numbers!
UNIX domain sockets support the passing of file descriptors between
processes.
File descriptor (a pointer to) is not file number.
You cannot pass number 1 simply because 1 is already in use.
On 21/08/2024 17:37, John Ames wrote:
Yes, books can be wrong, and yes, community fora can have valuable
information - but there really is no substitute for a good manual, in
print or otherwise. StackOverflow is very useful for clearing up some
kinds of esoteric-yet-common questions, but if you just need to double-
check what the legal values for parameter X in function Y are, it's
much quicker (and usually less error-prone) to turn to a reference
guide than it is to go poking around looking for records of times in
history where someone else might've had the same question.
(Doubly so, now that Google is as friggin' useless as it's gotten the
last few years.)
I do like a good manual, whether it be a physical book or an online
manual. So I am not objecting to reading them, learning from them, or
using them as references.
I am just objecting to the concept that reading particular books is
somehow "required" in order to write "useful C" or "program for
Linux". They are neither necessary nor sufficient, especially when
picking one or two particular books.
(Note: I'm not setting Followup-To since I don't know where the
participants are reading this, but do note that I'm only subscribed to comp.unix.programmer. I will probably subscribe to .shell soon, though.)
On 2024-08-21, David Brown wrote:
On 21/08/2024 17:37, John Ames wrote:
Yes, books can be wrong, and yes, community fora can have valuable
information - but there really is no substitute for a good manual, in
print or otherwise. StackOverflow is very useful for clearing up some
kinds of esoteric-yet-common questions, but if you just need to double-
check what the legal values for parameter X in function Y are, it's
much quicker (and usually less error-prone) to turn to a reference
guide than it is to go poking around looking for records of times in
history where someone else might've had the same question.
(Doubly so, now that Google is as friggin' useless as it's gotten the
last few years.)
I do like a good manual, whether it be a physical book or an online
manual. So I am not objecting to reading them, learning from them, or
using them as references.
I'd say the online manual can be useful as a reference, at least in my experience with Linux programming. It also has some information on
POSIX. And is local, so can be used even in the absence of a network connection of any sort.
Do people feel differently about online manuals on other systems? Or are these usually good to be used as a reference? (Asking out of curiosity,
as I don't have much experience yet coding on environments other than "GNU/Linux".)
I am just objecting to the concept that reading particular books is
somehow "required" in order to write "useful C" or "program for
Linux". They are neither necessary nor sufficient, especially when
picking one or two particular books.
But once you start pointing out that there are bad books, doesn't that
also imply that people commenting on which books they found good is
useful, so that one can have an idea of which books to avoid or prefer,
even if some comments end up being subjective to some extent?
(But yes, it might well be the case that someone just can't work so well
with a book as a medium and prefers some other approach. A lot of people these days are sharing youtube videos as "tutorials" and that's
something I can't easily "consume", so I can kind of imagine what that'd
be like. - Now if only Google had a GET parameter in the web (not video) search for "do not provide video results. ever."...)
On 2024-08-25 09:50, Sebastian wrote:
In comp.unix.programmer Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>
wrote:
Windows did many things wrong, but accessing file descriptors by
numbers is beyond even Windows. In Windows a file is an OS object. You
access it getting an opaque handle to. Note that a handle can be
marshaled from one process to another. Try that with process-local
numbers!
UNIX domain sockets support the passing of file descriptors between
processes.
File descriptor (a pointer to) is not file number.
You cannot pass number 1 simply because 1 is already in use.
Do people feel differently about online manuals on other systems?
On this Linux system, "man 7 unix", in the section "SCM_RIGHTS", it
explains how the passing mechanism is handled. One paragraph reads:
Commonly, this operation is referred to as "passing a
file descriptor" to another process. However, more
accurately, what is being passed is a reference to an
open file description (see open(2)), and in the re‐
ceiving process it is likely that a different file de‐
scriptor number will be used.
On Sat, 14 Sep 2024 19:10:06 GMT, Scott Lurndal wrote:
$ man vim | grep -i binary
-b Binary mode. A few options will be set that makes it
possible to edit a binary or executable file.
Wow, a special mode just to edit binary files
LDO: >> Vim is only good for text-editing, though.
Janis:> You have obviously no clue.
Janis is correct, you have no clue
$ man vim | grep -i binary
-b Binary mode. A few options will be set that makes it possible to edit a binary or executable file.
On 30.08.2024 21:20, Muttley@dastardlyhq.com wrote:
On Fri, 30 Aug 2024 08:14:21 -0700
John Ames <commodorejohn@gmail.com> gabbled:
[...]Sure - but picking one that best suits your needs doesn't mean you
can't critique its annoyances/flaws. This team-sports mentality is just
weird.
Some insecure people feel an attack on their favourite language is some kind >> of attack or slight against them personally. Its a pathetic and juvenile trait
that unfortunately is found a lot amongst IT types.
It's not restricted to languages or IT-stuff; you can see it with
books or films or music or political or religious preferences...
In IT we had as well various "wars" in the past. More considerate
folks avoid such wars (and respect diversity of thoughts/opinions
and preferences) by focusing on the facts alone. Other folks feel
an urge to (unnecessarily) ignite them.
On 29.08.2024 21:36, David Brown wrote:
On 29/08/2024 18:44, Janis Papanagnou wrote:
On 29.08.2024 14:30, David Brown wrote:
On 29/08/2024 09:28, Muttley@dastardlyhq.com wrote:[...]
[...]
Then don't use vim - use an editor that suits your needs.
But what makes you think that his needs are not covered by Vim?
You seem to have missed the point - sorry if I was not clear.
He complained that he didn't want to learn complicated macros in Vim
just to be able to indent or un-indent lines of code. The solution is
obvious - he should use an editor other than Vim.
This is not what I'd call a solution. I'd call it elusion; and in both
senses - if he didn't use his editor for that space-indenting because
he doesn't know how to do it he could look that up, but it is not any
issue to do that, only more laborious than indenting brace structures,
and the suggestion to switch to another tool is also elusive because
it doesn't address the issue (he would still have to learn how to do
it in any other tool). - But that was not the point.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Sat, 14 Sep 2024 19:10:06 GMT, Scott Lurndal wrote:
$ man vim | grep -i binary
-b Binary mode. A few options will be set that makes it >>> possible to edit a binary or executable file.
Wow, a special mode just to edit binary files
So, you admit you were wrong. You again elided the con-text that showed
you were incorrect. Dishonest of you, to be sure, yet typical of your
posts.
You again elided the con-text that showed you were incorrect.
On 14/09/2024 09:59, Janis Papanagnou wrote:
On 29.08.2024 21:36, David Brown wrote:
On 29/08/2024 18:44, Janis Papanagnou wrote:
On 29.08.2024 14:30, David Brown wrote:
On 29/08/2024 09:28, Muttley@dastardlyhq.com wrote:[...]
[...]
Then don't use vim - use an editor that suits your needs.
But what makes you think that his needs are not covered by Vim?
You seem to have missed the point - sorry if I was not clear.
He complained that he didn't want to learn complicated macros in Vim
just to be able to indent or un-indent lines of code. The solution is
obvious - he should use an editor other than Vim.
This is not what I'd call a solution. I'd call it elusion; and in both
senses - if he didn't use his editor for that space-indenting because
he doesn't know how to do it he could look that up, but it is not any
issue to do that, only more laborious than indenting brace structures,
and the suggestion to switch to another tool is also elusive because
it doesn't address the issue (he would still have to learn how to do
it in any other tool). - But that was not the point.
This thread died out two weeks ago, and should have been left there.
On 19/08/2024 09:37, Dmitry A. Kazakov wrote:
The similar process happened with programming languages, e.g. C and
with the hardware architectures, e.g. x86. It is always a race to the
bottom...
The success of the x86 was very much a race to the bottom - it was
picked specifically to give a cheaper system rather than the technically superior architecture (m68k) preferred by the engineers. Momentum and backwards compatibility has kept it going ever since.
I am not as convinced with respect to C. It certainly has its flaws,
and it certainly has been, and continues to be, used in situations where
it is not a good choice of language. But I think much of the bad
reputation of C is the result of poor C programmers and poor use of the language, rather than the language itself.
Good programmers will write
good code in any language, bad programmers (or badly managed
programmers) will write bad code in any language.
On 2024-08-19 10:40, David Brown wrote:
On 19/08/2024 09:37, Dmitry A. Kazakov wrote:
There's no doubt that non-technical issues have had a big influence on
which OS's or types of OS have succeeded, but you seem to have something
specific in mind.
I think the main reason is that we do not pay the actual costs of
software developing. OS, compiler require huge investments. Vendors
never passed these to the end users funding developing from other
sources. That effectively killed the market. Free software only
aggravated the situation. In effect it is akin to the socialist
production method which always kills quality.
Initially an ability to trim the system and sometimes to patch a driver
was a huge advantage Linux had over Windows NT.
On 2024-08-19 16:59, Muttley@dastardlyhq.com wrote:
On Mon, 19 Aug 2024 12:39:33 +0200
Initially an ability to trim the system and sometimes to patch a driver
was a huge advantage Linux had over Windows NT.
Linux can also load and unload drivers on the fly unlike Windows which AFAIK >> still requires a reboot each time.
I was talking about monolithic kernel Linux had in 90's. Plug and play, >kernel modules came much later with much bigger machines. I ran Linux on
i386 25MHz 4Mb. Try it now.
On Mon, 19 Aug 2024 12:39:33 +0200
Initially an ability to trim the system and sometimes to patch a driver
was a huge advantage Linux had over Windows NT.
Linux can also load and unload drivers on the fly unlike Windows which AFAIK still requires a reboot each time.
On 2024-08-19 06:54, Kaz Kylheku wrote:^^^^^^^^^^^^^^^^^^^^^^
On 2024-08-18, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
On 2024-08-18 18:46, Kaz Kylheku wrote:
If a mutex is actually used to protect shared data against concurrent
^^^^^^^^^^^^^^^^^^^^^^^^^^access, and the owner dies while holding the mutex, the next thread
to try to grab the mutex must be informed so it can try to recover
the shared data into a sane state.
There is no recovery if a protected operation crashes, because the state >>> of the object is unknown.
That is false; the object's state can be analyzed and repaired.
The object must be designed in a special way in order to support roll
backs etc. Such techniques exclude concurrent access, e.g. memory is
never overwritten etc.
On 2024-08-19 10:40, David Brown wrote:
On 19/08/2024 09:37, Dmitry A. Kazakov wrote:
Both OSes contributed to the Dark Ages of computing. The reasons are
not technical, because both were worst on the market.
What sort of time-frame are you thinking of here, what were the
alternatives that you think were "better", what markets or uses are
you considering, and in what way were other OS's "better" ?
There's no doubt that non-technical issues have had a big influence on
which OS's or types of OS have succeeded, but you seem to have
something specific in mind.
I think the main reason is that we do not pay the actual costs of
software developing. OS, compiler require huge investments. Vendors
never passed these to the end users funding developing from other
sources. That effectively killed the market. Free software only
aggravated the situation. In effect it is akin to the socialist
production method which always kills quality.
Windows has locks on files, which are a different thing. While I can
understand the point of them, they can be a real inconvenience (try
deleting a directory tree when a file from that tree is in use).
Oh, yes! I understand why I should not remove a locked file, but I still enjoy Linux's ability to remove anything an be it all damned!
The usual case is when Windows locks some file on the Linux Samba server share for some mysterious reason. It is a sheer fun to log into the
server do "rm -rf" on the file and then go back to Windows: "eat that!"
Under Linux you must log in as the root and remove the stray file
lock manually. It happens in UNIX administration all the time.
As someone who has administrated Linux servers for decades, and used
it as my desktop OS on many machines, I am not sure I can ever
remember removing a stray lock file. Certainly needing to do so "all
the time" is a very wild exaggeration. Linux, like all systems,
undoubtedly has its flaws and weaknesses, but this is not one of them
IME.
In main case it is packet manager. I am too lazy to find how to turn off automatic update checks. So when I try to run apt or dnf I have to kill
the lock.
Times change. Needs and uses change. Hardware changes.
Keeping things separate and modular has advantages in scalability,
security and stability. Keeping things monolithic has advantages in
efficiency (speed and memory) and consistency. There is no "right"
answer.
Yes. E.g. in automotive you still need the system booted right after you turned the key.
Initially an ability to trim the system and sometimes to patch a driver
was a huge advantage Linux had over Windows NT.
On the other hand you still cannot have decent gaming under Linux.
I do almost all my gaming under Linux. Some games do work better
under Windows, but that is primarily because most games developers
target Windows as their main platform. It may also be because Linux
systems are more varied.
"You are in an open field on the west side of a white house with a
boarded front door." That sort of games? (:-))
And single drive letters?
They are dozens characters long actually, if you mean the device names.
I thought by "drive letters", he meant "drive letters" - "c:", "d:", etc.
The official file name of "C:" would be some messy string with lots of backslashes. C: is a "DOS name." There are API to convert DOS names into proper names. It is a mess. All Windows API is a mess.
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
On 2024-08-19 10:45, Lawrence D'Oliveiro wrote:[...]
On Mon, 19 Aug 2024 09:37:39 +0200, Dmitry A. Kazakov wrote:
reservedAnd single drive letters?
They are dozens characters long actually, if you mean the device names. >>> Drive names are only single letters. You’re not talking about
file names, are you?
No, I am talking about proper file paths under Windows. Letters is a
DOS layer on top of it. E.g. see QueryDosDeviceW call.
OK, I tried a test program that invokes QueryDosDeviceW() on L"C:".
The result was "\Device\HarddiskVolume4". (That's not a C string
literal. It contains two single backslash characters.)
What can I do with that string?
Well, handheld gaming to gaming is like masturbation to love. Sorry...
Microsoft has been talking about bringing out a
Windows “Handheld Mode” for about two years now, but still has nothing >> to ship.
On 2024-08-19 10:45, Lawrence D'Oliveiro wrote:
On Mon, 19 Aug 2024 09:37:39 +0200, Dmitry A. Kazakov wrote:
On 2024-08-19 01:14, Lawrence D'Oliveiro wrote:
On Sun, 18 Aug 2024 10:10:09 +0200, Dmitry A. Kazakov wrote:
Windows has a pipe object named and anonymous. No problem.
One problem: you can’t use them with poll/select calls.
You can. See overlapped I/O.
I said “poll/select calls”. Do you not know what those are? On Windows, >> they work with sockets, but not with pipes. Or even ordinary files. So
unlike *nix systems, you have to keep in mind the different kinds of
files you might be working with.
Again. It is called overlapped I/O. You can start multiple
*asynchronous* I/O operations from a thread.
On Mon, 19 Aug 2024 13:03:23 +0200, Dmitry A. Kazakov wrote:
Again. It is called overlapped I/O. You can start multiple
*asynchronous* I/O operations from a thread.
I’m not talking about using threads. I’m talking about avoiding threads, and all their potential for difficult-to-fix race-condition-type bugs.
I’m talking about situations where the bottleneck is the I/O, not the CPU, so multithreading gets you nothing.
Experience shows that commercial software vendors rarely passed the real costs on to the users - they often pass vastly higher charges on to the
user for software than it cost to develop the software. Other times,
they might charge very little or nothing because they have other sources
of income, such as giving away the main software and charging
subscription fees for add-on features. There are all sorts of models -
free and open source software provides different models. At my company,
the software we write is closed source, but we never charge for licenses
for it. Customers either pay for the time used in development, or they
pay for it as part of the cost of the electronics boards we make for them.
If you use, for example, gcc or Linux, you don't pay the costs directly.
But you /do/ pay them indirectly. The solid majority of development
for major free and open source projects is paid work. Intel and ARM pay developers to work on gcc - every time you buy a device with an Intel or
ARM processor in it, you are paying a little towards gcc. Google pays
for Linux development - every time you buy a new pair of shoes, some of
what you pay goes to the manufacturer's advertising budget, some of
which goes to Google, some of which goes to Linux development, so that Google's servers can use a steadily better quality OS to serve up those adverts.
It all goes around - there's always money there, somewhere.
Just like any other kind of competition, free and open source has been disruptive in many software markets where some companies were used to spending some money on development, then living off that software for
years as nearly pure profit. It has forced other companies to change
models - making their software better, or providing better support. But
it hasn't killed the good quality, imaginative and flexible software companies. In the embedded development world, there are large numbers
of compilers available at a range of prices because they offer something
that pure gcc does not - support, certification, additional tools,
training, libraries, specialised extra features, or whatever. Other companies exist by taking gcc (or clang) and adding more and charging
for it. These markets were not /killed/ by free and open source
compilers - they were /created/ by them.
And customer companies - successful, well-run ones at least - are still
quite happy to pay a lot of money for software if it does a better job
than equivalent free software, saving them money in the end. At my
company we have bought compilers when they were better tools for the job
than free tools. But they have to be /better/ - not just more
expensive, and they have to be better enough to justify the price.
Usually, they are not.
So no, free and open source development does not "kill quality" or "kill markets". It is often /better/ quality than commercial alternatives, at least in some ways, and it forces commercial alternatives to improve
their quality and cost-effectiveness. It does not /kill/ markets - it /changes/ them. It spells the end for some suppliers, and opens up opportunities for new ones, just like progress always does.
People who complain about how free and open source software has killed
their businesses are like saddle-makers sitting about complaining about
how the car killed their markets, while their competitors have switched
from making saddles to opening car repair shops.
It is no complain, merely stating an elementary economic fact. If the
price does not reflect the costs, there is no market. No market, no competition. No competition, no quality.
On 2024-08-20 01:03, Lawrence D'Oliveiro wrote:
On Mon, 19 Aug 2024 13:03:23 +0200, Dmitry A. Kazakov wrote:
Again. It is called overlapped I/O. You can start multiple
*asynchronous* I/O operations from a thread.
I’m not talking about using threads. I’m talking about avoiding
threads, and all their potential for difficult-to-fix race-condition
-type bugs.
I’m talking about situations where the bottleneck is the I/O, not the
CPU, so multithreading gets you nothing.
It seems you suffer some form of dyslexia. I clearly stated that all instances of overlapped I/O is started from the same/single/one thread. Better now?
NT has its own low-level scheme for identifying devices/representing
file paths. If you're curious, someone at the Google compound did a
write-up on it some years back: >https://googleprojectzero.blogspot.com/2016/02/the-definitive-guide-on-win32-to
-nt.html
For most practical purposes, users and user-level application software
pretty much never see this or have to think about it - but it *is*
there, and it does cause strange corner-case behavior sometimes. (I'm
pretty sure the underlying reason why cmd.exe sometimes cannot access
network shares mapped to a conventional drive letter has to do with
this, f'rinstance.)
On 2024-08-19 21:09, David Brown wrote:
Experience shows that commercial software vendors rarely passed the
real costs on to the users - they often pass vastly higher charges on
to the user for software than it cost to develop the software. Other
times, they might charge very little or nothing because they have
other sources of income, such as giving away the main software and
charging subscription fees for add-on features. There are all sorts
of models - free and open source software provides different models.
At my company, the software we write is closed source, but we never
charge for licenses for it. Customers either pay for the time used in
development, or they pay for it as part of the cost of the electronics
boards we make for them.
If you use, for example, gcc or Linux, you don't pay the costs
directly. But you /do/ pay them indirectly. The solid majority of
development for major free and open source projects is paid work.
Intel and ARM pay developers to work on gcc - every time you buy a
device with an Intel or ARM processor in it, you are paying a little
towards gcc. Google pays for Linux development - every time you buy a
new pair of shoes, some of what you pay goes to the manufacturer's
advertising budget, some of which goes to Google, some of which goes
to Linux development, so that Google's servers can use a steadily
better quality OS to serve up those adverts.
It all goes around - there's always money there, somewhere.
Just like any other kind of competition, free and open source has been
disruptive in many software markets where some companies were used to
spending some money on development, then living off that software for
years as nearly pure profit. It has forced other companies to change
models - making their software better, or providing better support.
But it hasn't killed the good quality, imaginative and flexible
software companies. In the embedded development world, there are
large numbers of compilers available at a range of prices because they
offer something that pure gcc does not - support, certification,
additional tools, training, libraries, specialised extra features, or
whatever. Other companies exist by taking gcc (or clang) and adding
more and charging for it. These markets were not /killed/ by free and
open source compilers - they were /created/ by them.
And customer companies - successful, well-run ones at least - are
still quite happy to pay a lot of money for software if it does a
better job than equivalent free software, saving them money in the
end. At my company we have bought compilers when they were better
tools for the job than free tools. But they have to be /better/ - not
just more expensive, and they have to be better enough to justify the
price. Usually, they are not.
So no, free and open source development does not "kill quality" or
"kill markets". It is often /better/ quality than commercial
alternatives, at least in some ways, and it forces commercial
alternatives to improve their quality and cost-effectiveness. It does
not /kill/ markets - it /changes/ them. It spells the end for some
suppliers, and opens up opportunities for new ones, just like progress
always does.
People who complain about how free and open source software has killed
their businesses are like saddle-makers sitting about complaining
about how the car killed their markets, while their competitors have
switched from making saddles to opening car repair shops.
It is no complain, merely stating an elementary economic fact. If the
price does not reflect the costs, there is no market. No market, no competition. No competition, no quality.
One could argue that there cannot be software market at all for costs-intensive stuff like OS and compilers similarly to the communal infrastructure like roads etc. That might be but it is another question.
On Tue, 20 Aug 2024 08:52:27 +0200, Dmitry A. Kazakov wrote:
It is no complain, merely stating an elementary economic fact. If the
price does not reflect the costs, there is no market. No market, no
competition. No competition, no quality.
Elementary economic fact: in a competitive market, the unit price of the product tends to converge towards the marginal cost of producing that product.
What’s the marginal cost of producing a copy of a piece of software? Essentially, zero.
On 2024-08-20 01:03, Lawrence D'Oliveiro wrote:
On Mon, 19 Aug 2024 13:03:23 +0200, Dmitry A. Kazakov wrote:
Again. It is called overlapped I/O. You can start multiple
*asynchronous* I/O operations from a thread.
I’m not talking about using threads. I’m talking about avoiding threads, >> and all their potential for difficult-to-fix race-condition-type bugs.
I’m talking about situations where the bottleneck is the I/O, not the CPU, >> so multithreading gets you nothing.
It seems you suffer some form of dyslexia. I clearly stated that all instances of overlapped I/O is started from the same/single/one thread. Better now?
That's an easy claim to make - saying something that sounds obvious and calling it a "fact". But that does not make it true in general.
There are endless numbers of situations where price and cost are highly
out of sync. And there are endless different ways in which price and
cost can be measured for different things.
Software development, licensing and sale is /totally/ different. The
cost models are completely different. Base cost is high, but unit cost
is near zero.
One could argue that there cannot be software market at all for
costs-intensive stuff like OS and compilers similarly to the communal
infrastructure like roads etc. That might be but it is another question.
That might be a slightly less bad model than the traditional cost/price market model, but it's not good either.
Software is in a very different
category from "real" things - and indeed there are many different
categories of software with very different economic models. Any attempt
to compare it to traditional economic market theory is doomed to be of
little relevance.
The success or failure of software companies or products is mostly a combination of skill, hard work, diplomacy, ruthlessness and luck - with
luck being perhaps the biggest part.
On Thu, 22 Aug 2024 08:21:29 -0000 (UTC)
Muttley@dastardlyhq.com wrote:
Yes, this is a royal PITA. I use tabs as in vim I can instantly
change the indentation using "set ts=". With spaces its fixed short
of dicking about with macros.
All of this. Are there some safeguards in place for the most egregious
cases? Yes - but literal whitespace is still a horrendous misfeature, >something the world at large has known for so long that it was already
an established joke by the time Ed Post was cracking wise about JCL in >freakin' _Datamation._
Python is far from the worst language out there - in fact, it's quite
usable for a wide variety of applications, in spite of that - but the
simple fact that Guido & co. made a boneheaded choice like that is the
reason I'll never be able to *respect* it, even when I do find myself
using it. There should - plain and simple - *never* be a time where you
can end up with unexpected semantic behavior because of settings in
your editor-of-choice.
... the simple fact that Guido & co. made a boneheaded choice like that
is the reason I'll never be able to *respect* it, even when I do find
myself using it.
On Mon, 26 Aug 2024 08:33:30 -0700, John Ames wrote:
... the simple fact that Guido & co. made a boneheaded choice like that
is the reason I'll never be able to *respect* it, even when I do find
myself using it.
I restore the redundancy by using “#end” comments. E.g. a seriously nontrivial case:
I restore the redundancy by ...
This might [...] the human reader but the redundancy really needs to be supported by the language.
if condition:
foo()
bar()
baz()
if one needs to re-arrange the order of operations, for reasons, and one
is incautious about selecting and shuffling lines in one's editor, such
that one ends up with this:
if condition:
bar()
foo()
baz()
On Mon, 26 Aug 2024 21:35:25 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
I restore the redundancy by using ?#end? comments. E.g. a seriously
nontrivial case:
But even if that helps you organizationally, it doesn't resolve issues
of the interpreter potentially mis-parsing things due to mismatches in tab/space factor between $EDITOR and the Python RTE, which is a truly ridiculous thing to have to be concerned about.
(Thing I'm curious about, but don't have a test environment to hand -
does a blank line with a different indent level, in between lines of
the same level, break out of the block? E.g., given the following:
if condition:
foo()
bar()
baz()
But even if that helps you organizationally, it doesn't resolve issues
of the interpreter potentially mis-parsing things due to mismatches in tab/space factor between $EDITOR and the Python RTE, which is a truly ridiculous thing to have to be concerned about.
John Ames <commodorejohn@gmail.com> writes:
But even if that helps you organizationally, it doesn't resolve issues
of the interpreter potentially mis-parsing things due to mismatches in
tab/space factor between $EDITOR and the Python RTE, which is a truly
ridiculous thing to have to be concerned about.
In many years of using Python routinely and extensively I’ve simply
never found the whitespace issues that people are worrying about here to
be a problem in practice. Some of this may be a matter of experience but
if so, it’s a form of experience that must have built up very quickly.
As an aesthetic objection, of course, there’s no accounting for
taste. But it doesn’t seem to be a practical problem in reality.
(In contrast C’s rules have occasionally been a practical problem, contributing to at least one high-profile software vulnerability and attracting compiler warnings to mitigate the risks.)
On 31/08/2024 01:49, Lawrence D'Oliveiro wrote:
Interesting. Now you are trying to claim that, because you don’t
understand what the code does, that makes it somehow “meaningless”?
I covered that in an earlier post.
On Sat, 31 Aug 2024 17:06:05 +0200, David Brown wrote:
On 31/08/2024 01:49, Lawrence D'Oliveiro wrote:
Interesting. Now you are trying to claim that, because you don’t
understand what the code does, that makes it somehow “meaningless”?
I covered that in an earlier post.
Maybe in your mind you thought you did. Nowhere in your comments on this
code did you say so, that I can find.
On Sat, 14 Sep 2024 22:25:53 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> boringly babbled:
[...]
Any sane person uses a dedicated hex editor to edit binary files, not vim
or emacs.
On Sat, 14 Sep 2024 10:06:12 +0200, Janis Papanagnou wrote:
On 30.08.2024 04:53, Lawrence D'Oliveiro wrote:
Emacs makes no such assumption, and can also edit non-text files.
You have obviously no clue.
I have actually used it for that. That’s my “clue” to you.
On 2024-08-19 16:59, Muttley@dastardlyhq.com wrote:
On Mon, 19 Aug 2024 12:39:33 +0200
Initially an ability to trim the system and sometimes to patch a driver
was a huge advantage Linux had over Windows NT.
Linux can also load and unload drivers on the fly unlike Windows which AFAIK >> still requires a reboot each time.
I was talking about monolithic kernel Linux had in 90's. Plug and play, kernel modules came much later with much bigger machines. I ran Linux on
i386 25MHz 4Mb. Try it now.
On Sat, 14 Sep 2024 22:25:53 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> boringly babbled:
On Sat, 14 Sep 2024 19:10:06 GMT, Scott Lurndal wrote:
$ man vim | grep -i binary
-b Binary mode. A few options will be set that makes it >>> possible to edit a binary or executable file.
Wow, a special mode just to edit binary files, when Emacs can do it in
its regular mode.
The 1980s phoned, they want their editor wars back.
It just sets a bunch of options to minimize the chance of screwing up
the file in ways you don’t want. Apart from that, it’s still editing
it as a text file.
Any sane person uses a dedicated hex editor to edit binary files, not vim
or emacs.
On Wed, 21 Aug 2024 09:26:41 +0200, David Brown wrote:
And you don't need to know anything about Linux, UNIX or POSIX to
program in C.
I think the point has been made on comp.lang.c more than once, that C
without POSIX can be a very dull language indeed ...
Any sane person uses a dedicated hex editor to edit binary files, notEmacs has the hexl-mode. Emacs isn't just an editor, it's an Elisp
vim or emacs.
platform.
On 2024-08-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Wed, 21 Aug 2024 09:26:41 +0200, David Brown wrote:
And you don't need to know anything about Linux, UNIX or POSIX to
program in C.
I think the point has been made on comp.lang.c more than once, that C
without POSIX can be a very dull language indeed ...
... you can do a lot with C99.
Albeit I prefer Elisp and Common Lisp.
On 2024-08-20 09:44, David Brown wrote:
That's an easy claim to make - saying something that sounds obvious
and calling it a "fact". But that does not make it true in general.
But sometimes it does.
There are endless numbers of situations where price and cost are
highly out of sync. And there are endless different ways in which
price and cost can be measured for different things.
Yes
Software development, licensing and sale is /totally/ different. The
cost models are completely different. Base cost is high, but unit
cost is near zero.
Yes, and that is the problem. Not really a unique problem, e.g. books,
music records etc.
One could argue that there cannot be software market at all for
costs-intensive stuff like OS and compilers similarly to the communal
infrastructure like roads etc. That might be but it is another question.
That might be a slightly less bad model than the traditional
cost/price market model, but it's not good either.
... counting the potholes ...
Software is in a very different category from "real" things - and
indeed there are many different categories of software with very
different economic models. Any attempt to compare it to traditional
economic market theory is doomed to be of little relevance.
Maybe, but then we have what we have.
The success or failure of software companies or products is mostly a
combination of skill, hard work, diplomacy, ruthlessness and luck -
with luck being perhaps the biggest part.
The question is sustainability in long term.
To know Linux, you need Michal Kerrisk's book the Linux Programming >Interface. I have this book, but admittedly you are kind of right:
It is large and I do not know every single part of it, but I have
studied it a lot and I am familiar with the most important features.
On 16/08/2024 17:02, Kalevi Kolttonen wrote:
In comp.unix.programmer Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2024-08-15, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Thu, 15 Aug 2024 19:48:36 -0000 (UTC), Kalevi Kolttonen wrote:
The last I checked, the O'Reilly Python book is just absolutely
*MASSIVE*. The language has a huge number of features now ...
No, it hasn’t. The core language reference spec is only a small fraction >>>> of, say, the Java language spec.
It’s just that you can do so many things with Python. And that is down to
the huge variety of off-the-shelf addon libraries that build on that core >>>> language spec. It has to be a strong, very solidly founded core in order >>>> to be such a versatile basis for these addons, and it is.
That's idiotic; you're saying that the standard library packages of
Python are not part of Python, and do not contribute to its size.
You seem to have a point. The core of C language is also small. I
guess they even said in the original K & R book that C is a small
language best described by a small book.
But in order to do anything with C, you need to know the standard
libraries. They have grown bigger and bigger during all these
years. One could also well argue that to program on UNIX, you also
need to know all the POSIX libraries.
Absolute nonsense.
In order to use a programming language for a given task, you need to
know the basics of the language and libraries appropriate for the task.
You most certainly do not need to know all about the language, or all
about all the libraries provided as standard for the language or the
host OS.
On Tue, 20 Aug 2024 14:21:38 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) boringly babbled:
To know Linux, you need Michal Kerrisk's book the Linux Programming >>Interface. I have this book, but admittedly you are kind of right:
It is large and I do not know every single part of it, but I have
studied it a lot and I am familiar with the most important features.
Luckily not much has changed in core unix systems programming over the decades
(seems they got it mostly right first time) so Advanced Programming in the Unix Enviroment by W. Richard Stevens is still a very relevant book to anyone who wants to develop on unix.
On 20/08/2024 10:27, Dmitry A. Kazakov wrote:
On 2024-08-20 09:44, David Brown wrote:I think your line of reasoning was too simplistic to be realistic. It
is simply not the case that you have to have price reflecting cost to
make a market, or that you have to have a market to have competition, or
that you have to have competition to have quality. None of these is
true in general (even taking into account that the term "market" could
be defined in many ways). Each of them is true in some cases, but even
that does not mean they follow as logical consequences.
Yes, and that is the problem. Not really a unique problem, e.g. books,
music records etc.
Those are different situations again, but certainly closer than the production of "wotsits". Traditionally, books and records have relevant unit costs as well as base "development" costs, and then much of their
later income comes from sources invisible to end users (like film rights
or royalties).
I don't think any of this is a "problem", it is simply that you can't
wildly mix simplified (or invented) "economic facts" in totally
different situations.
It often surprises me that economic theories give any usable results at
all.
On Tue, 20 Aug 2024 14:21:38 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) boringly babbled:
To know Linux, you need Michal Kerrisk's book the Linux Programming >>Interface. I have this book, but admittedly you are kind of right:
It is large and I do not know every single part of it, but I have
studied it a lot and I am familiar with the most important features.
Luckily not much has changed in core unix systems programming over the decades
(seems they got it mostly right first time) so Advanced Programming in the Unix Enviroment by W. Richard Stevens is still a very relevant book to anyone who wants to develop on unix.
NT has its own low-level scheme for identifying devices/representing
file paths.
In comp.unix.programmer David Brown <david.brown@hesbynett.no> wrote:
On 16/08/2024 17:02, Kalevi Kolttonen wrote:
In comp.unix.programmer Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2024-08-15, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Thu, 15 Aug 2024 19:48:36 -0000 (UTC), Kalevi Kolttonen wrote:
The last I checked, the O'Reilly Python book is just absolutely
*MASSIVE*. The language has a huge number of features now ...
No, it hasn’t. The core language reference spec is only a small fraction
of, say, the Java language spec.
It’s just that you can do so many things with Python. And that is down to
the huge variety of off-the-shelf addon libraries that build on that core >>>>> language spec. It has to be a strong, very solidly founded core in order >>>>> to be such a versatile basis for these addons, and it is.
That's idiotic; you're saying that the standard library packages of
Python are not part of Python, and do not contribute to its size.
You seem to have a point. The core of C language is also small. I
guess they even said in the original K & R book that C is a small
language best described by a small book.
But in order to do anything with C, you need to know the standard
libraries. They have grown bigger and bigger during all these
years. One could also well argue that to program on UNIX, you also
need to know all the POSIX libraries.
Absolute nonsense.
In order to use a programming language for a given task, you need to
know the basics of the language and libraries appropriate for the task.
You most certainly do not need to know all about the language, or all
about all the libraries provided as standard for the language or the
host OS.
I would not label it as "absolute nonsense".
In order to program on UNIX,
you need to be familiar with the facilities that are available. I
know of a very smart man who ended up as a professor of physics who programmed on Amiga back in the 1980s. Even though his PhD thesis
was something like 100-150 pages of strange-looking formulas, he said
he had problems with C on the Amiga. For some reason, he was unable
to remember what functions where provided as standard libraries, so
he always ended up writing his own functions instead of using libraries.
To know Linux, you need Michal Kerrisk's book the Linux Programming Interface. I have this book, but admittedly you are kind of right:
It is large and I do not know every single part of it, but I have
studied it a lot and I am familiar with the most important features.
No, you do not need your particular favourite out of the thousand and
one Linux programming books in order to program for Linux. You do not
need /any/ book in order to write useful and successful code for Linux.
Of course you need /some/ reference - and in the days before the
internet was so easily available and so full of information, I went
through a lot of programming books. Some were good, some less so, and
some have become famous. But none of them were /necessary/ in any way.
The question is sustainability in long term.
Even though his PhD thesis was
something like 100-150 pages of strange-looking formulas, he said he had problems with C on the Amiga. For some reason, he was unable to remember
what functions where provided as standard libraries, so he always ended
up writing his own functions instead of using libraries.
On 2024-08-20 09:21, Lawrence D'Oliveiro wrote:
On Tue, 20 Aug 2024 08:52:27 +0200, Dmitry A. Kazakov wrote:
It is no complain, merely stating an elementary economic fact. If the
price does not reflect the costs, there is no market. No market, no
competition. No competition, no quality.
Elementary economic fact: in a competitive market, the unit price of
the product tends to converge towards the marginal cost of producing
that product.
What’s the marginal cost of producing a copy of a piece of software?
Essentially, zero.
Again, I do not say what is right and what is wrong.
On the other hand you still cannot have decent gaming under Linux.
On Mon, 19 Aug 2024 09:37:39 +0200, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in <v9uso3$2pdrg$2@dont-email.me>:
On the other hand you still cannot have decent gaming under Linux.
Modern proton has changed all that.
(That's why you have lovely devices like the SteamDeck on the market.)
In comp.unix.programmer David Brown <david.brown@hesbynett.no> wrote:
No, you do not need your particular favourite out of the thousand and
one Linux programming books in order to program for Linux. You do not
need /any/ book in order to write useful and successful code for Linux.
Of course you need /some/ reference - and in the days before the
internet was so easily available and so full of information, I went
through a lot of programming books. Some were good, some less so, and
some have become famous. But none of them were /necessary/ in any way.
Well, I am a quite bad programmer but I am interested enough in the >Linux/UNIX workings so that reading the newest APUE and The Linux
Programming Interface did not feel painful or unnecessary at all. On
the contrary, it was a great pleasure to examine what kind of
programming facilities my favourite OS offers.
Having these two books, or just one of them, is a great way to educate >oneself about Linux/UNIX. I see that The Linux Programming Interface
is available online as a free PDF, but I am not sure whether it is
a pirated version.
There is no better way to learn Linux/UNIX workings than these two
books. Period.
So I don't question that it is interesting, informative, or a pleasure
to read. I question that it is /necessary/. You simply cannot argue
that people who want to program for Linux /must/ read that book. There
is no justification for that claim. There is no justification for
claiming that people wanting to program for Linux need to read any books
on the topic at all, nor for claims that people need to "know POSIX" to
be able to write code for Linux and/or in C.
There are a thousand and one ways to learn about the workings of Linux -
and that's counting "reading books" as one way, regardless of /which/
In comp.unix.programmer David Brown <david.brown@hesbynett.no> wrote:
No, you do not need your particular favourite out of the thousand and
one Linux programming books in order to program for Linux. You do not
need /any/ book in order to write useful and successful code for Linux.
Of course you need /some/ reference - and in the days before the
internet was so easily available and so full of information, I went
through a lot of programming books. Some were good, some less so, and
some have become famous. But none of them were /necessary/ in any way.
Well, I am a quite bad programmer but I am interested enough in the Linux/UNIX workings so that reading the newest APUE and The Linux
Programming Interface did not feel painful or unnecessary at all. On
the contrary, it was a great pleasure to examine what kind of
programming facilities my favourite OS offers.
Having these two books, or just one of them, is a great way to educate oneself about Linux/UNIX. I see that The Linux Programming Interface
is available online as a free PDF, but I am not sure whether it is
a pirated version.
There is no better way to learn Linux/UNIX workings than these two
books. Period.
And you don't need to know anything about Linux, UNIX or POSIX to
program in C.
On Tue, 20 Aug 2024 10:27:01 +0200, Dmitry A. Kazakov wrote:
The question is sustainability in long term.
In the long term, proprietary software is in retreat, while Free software
is on the rise. So it’s quite clear which one is more “sustainable”.
On Wed, 21 Aug 2024 09:26:41 +0200
David Brown <david.brown@hesbynett.no> boringly babbled:
So I don't question that it is interesting, informative, or a pleasure
to read. I question that it is /necessary/. You simply cannot argue
that people who want to program for Linux /must/ read that book. There
is no justification for that claim. There is no justification for
claiming that people wanting to program for Linux need to read any books
on the topic at all, nor for claims that people need to "know POSIX" to
be able to write code for Linux and/or in C.
Only knowing core C will severely limit what you can do on any OS. If
you're happy just coding up file processors or some self contained mathematical algo and simply writing to stdout or a file then fine, but to do anything more sophisticated you'll need to know the OS API whether its posix + X on *nix or Win32 on Windows.
There are a thousand and one ways to learn about the workings of Linux -
and that's counting "reading books" as one way, regardless of /which/
Linear learning is usually better than snippets from google. If you want
to learn a shakespear play you read the book, you don't google little bits
of it at a time.
On Tue, 20 Aug 2024 14:21:38 -0000 (UTC), Kalevi Kolttonen wrote:
Even though his PhD thesis was
something like 100-150 pages of strange-looking formulas, he said he had
problems with C on the Amiga. For some reason, he was unable to remember
what functions where provided as standard libraries, so he always ended
up writing his own functions instead of using libraries.
Was he not able to keep some reference docs handy? For example, I rarely
get very far in working on Python code without having this page <https://docs.python.org/3/library/> open in a browser.
On Wed, 21 Aug 2024 09:26:41 +0200, David Brown wrote:
And you don't need to know anything about Linux, UNIX or POSIX to
program in C.
I think the point has been made on comp.lang.c more than once, that C
without POSIX can be a very dull language indeed ...
On Tue, 20 Aug 2024 20:56:00 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) boringly babbled:
In comp.unix.programmer David Brown <david.brown@hesbynett.no> wrote:
No, you do not need your particular favourite out of the thousand and
one Linux programming books in order to program for Linux. You do not
need /any/ book in order to write useful and successful code for Linux.
Of course you need /some/ reference - and in the days before the
internet was so easily available and so full of information, I went
through a lot of programming books. Some were good, some less so, and
some have become famous. But none of them were /necessary/ in any way.
Well, I am a quite bad programmer but I am interested enough in the
Linux/UNIX workings so that reading the newest APUE and The Linux
Programming Interface did not feel painful or unnecessary at all. On
the contrary, it was a great pleasure to examine what kind of
programming facilities my favourite OS offers.
Having these two books, or just one of them, is a great way to educate
oneself about Linux/UNIX. I see that The Linux Programming Interface
is available online as a free PDF, but I am not sure whether it is
a pirated version.
There is no better way to learn Linux/UNIX workings than these two
books. Period.
The advantage of books written by professionals is that the code and explanations are usually much clearer and of better equality than the quickly knocked up might-work-might-not crap you often find on stack overflow and similar sites. Thats not to say good example code isn't out there but wading through the rubbish can be a tedious business and IME its often quicker just to reach for APUE or similar.
If you are writing network software for Linux, how is it relevant to
learn about the sound API, or the more advanced filesystem API's ? If
you are writing a gui program with QT, why should you be interested in X
APIs or POSIX threading and file handling - you'll be using the QT
libraries and APIs for graphics, threading and file handling.
I have not suggested, or even hinted, that all you need is "core C" -
what you need is the knowledge that is relevant to the task at hand, >regardless of the OS, language, or whatever.
On 27/08/2024 09:39, Richard Kettlewell wrote:
John Ames <commodorejohn@gmail.com> writes:
But even if that helps you organizationally, it doesn't resolve issues
of the interpreter potentially mis-parsing things due to mismatches in
tab/space factor between $EDITOR and the Python RTE, which is a truly
ridiculous thing to have to be concerned about.
In many years of using Python routinely and extensively I’ve simply
never found the whitespace issues that people are worrying about here to
be a problem in practice. Some of this may be a matter of experience but
if so, it’s a form of experience that must have built up very quickly.
As an aesthetic objection, of course, there’s no accounting for
taste. But it doesn’t seem to be a practical problem in reality.
(In contrast C’s rules have occasionally been a practical problem,
contributing to at least one high-profile software vulnerability and
attracting compiler warnings to mitigate the risks.)
These are the problems I've seen. I haven't used the language
extensively, but I've used it enough.
(1) An tab at the start of a line gets accidentally indented or
unindented. If you weren't paying close attention, it may not be clear
that that has happened, if this line was either the last line of an
indented block, or the line following
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block. And, also the block then merges with the
following one as it's at the same level, so when you want to change it back...
(3) Similarly, you want to temportarily wrap an 'if' statement, for
example, around a block of code. But you can't do it witout indenting
that block.
(4) Sometimes you want to add temporary debug code as part of a block. Usually I write such lines in all-caps and without indentation to make
them stand out clear. With Python, I can't use all-caps and I have to
use exactly the same indent as the rest of the block. So the lines
merge. Then when I need to remove the code, it's not clearly delimited.
(5) Sometimes you want to temporarily comment out the contents of a
block. But Python doesn't allow an empty block; now you have to use
'pass'. And then get rid of if later.
(6) You want to add extra statements to the end of a block, but where IS
the end? You have to INFER the ending by looking for a line with a
smaller indent. But suppose you're at the bottom of a window; is that
bottom line the last in the block, or is there another one at the same
indent just out of sight? You have to tentatively keep peeking ahead!
(6a) And maybe there's big comment blocking in the middle of block;
comments don't need nesting! If there are lots of comments and few statements, finding the end of the block (ie. the last statement of this block) can become quite an exercise.
(7) You take some Python code you've seen online (eg. in a usenet post)
and paste into your editor. Maybe you want to merge it with your own code.
But its tabbing is all spaces; yours is all tabs. Plus invariably, the
whole thing has extra indentation (eg. the leftmost statement is already indented). Or you want to copy code from within a block to a different
indent level.
The whole thing gets very messy and error prone. You need special editor commands to deal with the mess.
Indented, non-delimited code and data is fine for machine-generated and machine processed code. But it's a disaster for code that has to be human-generated and human-maintained. It's just too fragile.
The fact that people have to resort to adding #end lines, which only
partly deals with one or two of those problems, suggest that something
is badly wrong.
On 27/08/2024 09:39, Richard Kettlewell wrote:
John Ames <commodorejohn@gmail.com> writes:
But even if that helps you organizationally, it doesn't resolve issuesIn many years of using Python routinely and extensively I’ve simply
of the interpreter potentially mis-parsing things due to mismatches in
tab/space factor between $EDITOR and the Python RTE, which is a truly
ridiculous thing to have to be concerned about.
never found the whitespace issues that people are worrying about here to
be a problem in practice. Some of this may be a matter of experience but
if so, it’s a form of experience that must have built up very quickly.
As an aesthetic objection, of course, there’s no accounting for
taste. But it doesn’t seem to be a practical problem in reality.
(In contrast C’s rules have occasionally been a practical problem,
contributing to at least one high-profile software vulnerability and
attracting compiler warnings to mitigate the risks.)
These are the problems I've seen. I haven't used the language
extensively, but I've used it enough.
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block. And, also the block then merges with the
following one as it's at the same level, so when you want to change it back...
(5) Sometimes you want to temporarily comment out the contents of a
block. But Python doesn't allow an empty block; now you have to use
'pass'. And then get rid of if later.
The fact that people have to resort to adding #end lines, which only
partly deals with one or two of those problems, suggest that something
is badly wrong.
On 27/08/2024 12:26, Bart wrote:
On 27/08/2024 09:39, Richard Kettlewell wrote:
John Ames <commodorejohn@gmail.com> writes:
But even if that helps you organizationally, it doesn't resolve issues >>>> of the interpreter potentially mis-parsing things due to mismatches in >>>> tab/space factor between $EDITOR and the Python RTE, which is a truly
ridiculous thing to have to be concerned about.
In many years of using Python routinely and extensively I’ve simply
never found the whitespace issues that people are worrying about here to >>> be a problem in practice. Some of this may be a matter of experience but >>> if so, it’s a form of experience that must have built up very quickly. >>>
I have occasionally, but only occasionally, seen problems with white
space. And those would normally be caught by Python 3.
As an aesthetic objection, of course, there’s no accounting for
taste. But it doesn’t seem to be a practical problem in reality.
(In contrast C’s rules have occasionally been a practical problem,
contributing to at least one high-profile software vulnerability and
attracting compiler warnings to mitigate the risks.)
These are the problems I've seen. I haven't used the language
extensively, but I've used it enough.
Your problems below are all valid, but not insurmountable. I too would rather have explicit block delimiters, but it's not actually hard to
work with Python as it is.
(1) An tab at the start of a line gets accidentally indented or
unindented. If you weren't paying close attention, it may not be clear
that that has happened, if this line was either the last line of an
indented block, or the line following
That /can/ happen. It is a good idea to avoid mixing tabs and spaces in
the same file. Most editors can be configured one way or the other, but
if you use different editors under different circumstances (as I do), mistakes are possible. They are usually quickly identified and quickly handled.
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block. And, also the block then merges with the
following one as it's at the same level, so when you want to change it
back...
Replace your
if cond :
with
if 1 :
or
if True :
(3) Similarly, you want to temportarily wrap an 'if' statement, for
example, around a block of code. But you can't do it witout indenting
that block.
True. But any editor will let you select the lines and indent them.
(4) Sometimes you want to add temporary debug code as part of a block.
Usually I write such lines in all-caps and without indentation to make
them stand out clear. With Python, I can't use all-caps and I have to
use exactly the same indent as the rest of the block. So the lines
merge. Then when I need to remove the code, it's not clearly delimited.
Comments are an extremely easy way to make the code stand out.
(5) Sometimes you want to temporarily comment out the contents of a
block. But Python doesn't allow an empty block; now you have to use
'pass'. And then get rid of if later.
You can leave the "pass" in, if you don't want to get ride of it later.
I sometimes find "pass" to be helpful as an alternative to leaving a
hanging indented block.
(6) You want to add extra statements to the end of a block, but where
IS the end? You have to INFER the ending by looking for a line with a
smaller indent. But suppose you're at the bottom of a window; is that
bottom line the last in the block, or is there another one at the same
indent just out of sight? You have to tentatively keep peeking ahead!
Keep your blocks small and neat.
(6a) And maybe there's big comment blocking in the middle of block;
comments don't need nesting! If there are lots of comments and few
statements, finding the end of the block (ie. the last statement of
this block) can become quite an exercise.
That applies to every programming language (unless you know of one that doesn't support comments).
(7) You take some Python code you've seen online (eg. in a usenet
post) and paste into your editor. Maybe you want to merge it with your
own code.
But its tabbing is all spaces; yours is all tabs. Plus invariably, the
whole thing has extra indentation (eg. the leftmost statement is
already indented). Or you want to copy code from within a block to a
different indent level.
Any sane editor will give you tools to fix that - automatic indentation, tab-to-space and space-to-tab conversion, manual indent or outdent block tools, etc.
The whole thing gets very messy and error prone. You need special
editor commands to deal with the mess.
No, you don't. (Unless you think "special" means "anything but Windows Notepad" .)
Indented, non-delimited code and data is fine for machine-generated
and machine processed code. But it's a disaster for code that has to
be human-generated and human-maintained. It's just too fragile.
In real-life Python coding, it works fine. I prefer explicit block delimiters, but I cannot say Python's white-space blocking has been a significant source of trouble or inconvenience for me. Perhaps that's because I have always been used to careful and consistent formatting. I don't write C code (or any other code) with inconsistent spacing, mixes
of tabs and spaces, or unexpected indentations. So for me, the spacing
and tabbing of Python code would be identical if it had braces or other begin-end markers.
The fact that people have to resort to adding #end lines, which only
partly deals with one or two of those problems, suggest that something
is badly wrong.
No one has to do that. It's a Lawrence peculiarity, and his coding
style (in Python or C, and probably anything else) would be rejected by anyone with a coding standard. I agree that it suggests that something
is badly wrong, but it is not with the language!
It applies very much moreso to languages where comments *must* follow
the indentation level of the surrounding code, so that the deeper you
go, the more lines you have to split comments across.
On Tue, 27 Aug 2024 15:10:08 +0200
David Brown <david.brown@hesbynett.no> wrote:
(6) You want to add extra statements to the end of a block, but
where IS the end? You have to INFER the ending by looking for a
line with a smaller indent. But suppose you're at the bottom of a
window; is that bottom line the last in the block, or is there
another one at the same indent just out of sight? You have to
tentatively keep peeking ahead!
Keep your blocks small and neat.
That's very much one for the "good advice that is not always feasible
in the Real World" file. Every project has its own natural balance of
"large things that can be easily re-factored into sets of small things"
(i.e. things you can function-ize) vs. "large things that cannot."
(6a) And maybe there's big comment blocking in the middle of block;
comments don't need nesting! If there are lots of comments and few
statements, finding the end of the block (ie. the last statement of
this block) can become quite an exercise.
That applies to every programming language (unless you know of one
that doesn't support comments).
It applies very much moreso to languages where comments *must* follow
the indentation level of the surrounding code, so that the deeper you
go, the more lines you have to split comments across.
It is not common to have to have indent comment lines (certainly in
Python it is not necessary). And if you find yourself writing large
comments in the middle of a block in the middle of a function, it is
probably time to consider re-organising the code and/or the comments and documentation. (Again, there can be exceptions to this general rule.)
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block.
And, also the block then merges with the
following one as it's at the same level, so when you want to change it back...
(6a) And maybe there's big comment blocking in the middle of block;
comments don't need nesting! If there are lots of comments and few statements, finding the end of the block (ie. the last statement of this block) can become quite an exercise.
(7) You take some Python code you've seen online (eg. in a usenet post)
and paste into your editor. Maybe you want to merge it with your own
code.
But its tabbing is all spaces; yours is all tabs. Plus invariably, the
whole thing has extra indentation (eg. the leftmost statement is already indented). Or you want to copy code from within a block to a different
indent level.
I've done some Python programming, and it wouldn't occur to me to add
"#end" comments. If I saw them in a code review I'd probably recommend deleting them.
John Ames <commodorejohn@gmail.com> writes:
But even if that helps you organizationally, it doesn't resolve issues
of the interpreter potentially mis-parsing things due to mismatches in
tab/space factor between $EDITOR and the Python RTE, which is a truly
ridiculous thing to have to be concerned about.
In many years of using Python routinely and extensively I?ve simply
never found the whitespace issues that people are worrying about here to
be a problem in practice. Some of this may be a matter of experience but
if so, it?s a form of experience that must have built up very quickly.
Bart <bc@freeuk.com> writes:
On 27/08/2024 09:39, Richard Kettlewell wrote:
The fact that people have to resort to adding #end lines, which only
partly deals with one or two of those problems, suggest that something
is badly wrong.
I?ve never encountered anyone else doing that in Python. It suggests
more than the individual doing that just doesn?t like the language, in
which case I?d just suggest that person doesn?t use it.
It is not common to have to have indent comment lines (certainly in
Python it is not necessary). And if you find yourself writing large
comments in the middle of a block in the middle of a function, it is
probably time to consider re-organising the code and/or the comments and documentation. (Again, there can be exceptions to this general rule.)
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Tue, 27 Aug 2024 14:49:19 -0700, Keith Thompson wrote:
I've done some Python programming, and it wouldn't occur to me to add
"#end" comments. If I saw them in a code review I'd probably
recommend deleting them.
Give them a try. They simplify a lot of situations. I already posted a
reasonably complex example in this thread. Go have a look at it, and
see what happens when you delete those comments.
No, I won't be doing that.
In comp.unix.programmer David Brown <david.brown@hesbynett.no> wrote:
It is not common to have to have indent comment lines (certainly in
Python it is not necessary). And if you find yourself writing large
comments in the middle of a block in the middle of a function, it is
probably time to consider re-organising the code and/or the comments and
documentation. (Again, there can be exceptions to this general rule.)
It may not be "common" (ie, not a lot of languages have this requirement), but if it's your job to maintain a project written in such a language,
then you'll have to deal with that problem every single day.
I changed it in a re-write to:
def register_additional_standard(self, managed_objects) :
if managed_objects :
# ....
On Tue, 3 Sep 2024 10:46:55 +0200, David Brown wrote:
I changed it in a re-write to:
def register_additional_standard(self, managed_objects) :
if managed_objects :
# ....
My original was meant with future extensibility in mind. That was made
clear in the docstring. You *did* read the docstring, didn’t you?
On Wed, 21 Aug 2024 11:10:53 +0200
David Brown <david.brown@hesbynett.no> boringly babbled:
If you are writing network software for Linux, how is it relevant to
learn about the sound API, or the more advanced filesystem API's ? If
You don't, but the subsystems don't exist in isolation, there's a lot of overlap. Eg network sockets use a lot of the same API functions as files
(eg: read, write, fcntl, ioctl) so understanding may well help to understand the other.
you are writing a gui program with QT, why should you be interested in X
APIs or POSIX threading and file handling - you'll be using the QT
libraries and APIs for graphics, threading and file handling.
Not necessarily.
I have not suggested, or even hinted, that all you need is "core C" -
what you need is the knowledge that is relevant to the task at hand,
regardless of the OS, language, or whatever.
Its certainly the impression you gave.
On 21/08/2024 12:26, Muttley@dastardlyhq.com wrote:
Trying to understand the Linux documentation for UARTs is a nightmare.
They are horrendous - the APIs, structs, flag sets, etc., are a vast
jumble of crap for handling terminals that haven't been seen outside a
museum for 50 years, long before Linux was conceived. Trying to get the
Even better, of course, is to ditch C and use Python - "pyserial" does
it all, simply and cleanly. (And the same code works on Windows, if
On Wed, 21 Aug 2024 17:27:04 +0200
David Brown <david.brown@hesbynett.no> boringly babbled:
On 21/08/2024 12:26, Muttley@dastardlyhq.com wrote:
Trying to understand the Linux documentation for UARTs is a nightmare.
They are horrendous - the APIs, structs, flag sets, etc., are a vast
jumble of crap for handling terminals that haven't been seen outside a
museum for 50 years, long before Linux was conceived. Trying to get the
Unfortunately terminals are complex beasts with many permutations though
all that should be a higher level that what you were doing with a UART.
Even better, of course, is to ditch C and use Python - "pyserial" does
it all, simply and cleanly. (And the same code works on Windows, if
The problem with pyserial is you have to use Python. Horrible language
though like BASIC, useful for teaching kids to code.
Yes, books can be wrong, and yes, community fora can have valuable information - but there really is no substitute for a good manual, in
print or otherwise. StackOverflow is very useful for clearing up some
kinds of esoteric-yet-common questions, but if you just need to double-
check what the legal values for parameter X in function Y are, it's
much quicker (and usually less error-prone) to turn to a reference
guide than it is to go poking around looking for records of times in
history where someone else might've had the same question.
(Doubly so, now that Google is as friggin' useless as it's gotten the
last few years.)
On 21/08/2024 09:38, Lawrence D'Oliveiro wrote:
On Wed, 21 Aug 2024 09:26:41 +0200, David Brown wrote:
And you don't need to know anything about Linux, UNIX or POSIX to
program in C.
I think the point has been made on comp.lang.c more than once, that C
without POSIX can be a very dull language indeed ...
It was wrong on comp.lang.c, and it is wrong here. Proof by repeated assertion is not valid.
On 2024-08-21 02:59, Lawrence D'Oliveiro wrote:
On Tue, 20 Aug 2024 10:27:01 +0200, Dmitry A. Kazakov wrote:
The question is sustainability in long term.
In the long term, proprietary software is in retreat, while Free
software is on the rise. So it’s quite clear which one is more
“sustainable”.
I mean economic sustainability.
I have never owned Commodore Amiga and I have no knowledge about its C compilers or the related documentation.
On Wed, 21 Aug 2024 21:15:14 +0200
David Brown <david.brown@hesbynett.no> boringly babbled:
On 21/08/2024 17:40, Muttley@dastardlyhq.com wrote:
The problem with pyserial is you have to use Python. Horrible language
though like BASIC, useful for teaching kids to code.
Let's just say, opinions differ. Python /can/ be used for beginner
Yes, its ultimately subjective. The reasons I don't like it are that I can't stand dynamic typing in supposed "proper" languages and the syntatically meaningful whitespace nonsense they took from Occam really grinds my gears. In my current job I'm forced to use it but I'd never do it out of choice.
programmers - but it is also an excellent language for many real tasks.
Of course it has its weaknesses and disadvantages as well as its
strengths, and aspects that will appeal to some programmers and not others.
IMO its fine for small scripts up to maybe a few hundred lines. Beyond that no.
On 21/08/2024 17:40, Muttley@dastardlyhq.com wrote:
The problem with pyserial is you have to use Python. Horrible language
though like BASIC, useful for teaching kids to code.
Let's just say, opinions differ. Python /can/ be used for beginner
programmers - but it is also an excellent language for many real tasks.
Of course it has its weaknesses and disadvantages as well as its
strengths, and aspects that will appeal to some programmers and not others.
On Wed, 21 Aug 2024 21:15:14 +0200
David Brown <david.brown@hesbynett.no> boringly babbled:
On 21/08/2024 17:40, Muttley@dastardlyhq.com wrote:
The problem with pyserial is you have to use Python. Horrible language
though like BASIC, useful for teaching kids to code.
Let's just say, opinions differ. Python /can/ be used for beginner
Yes, its ultimately subjective. The reasons I don't like it are that I can't stand dynamic typing in supposed "proper" languages and the syntatically meaningful whitespace nonsense they took from Occam really grinds my gears. In my current job I'm forced to use it but I'd never do it out of choice.
programmers - but it is also an excellent language for many real tasks.
Of course it has its weaknesses and disadvantages as well as its
strengths, and aspects that will appeal to some programmers and not others.
IMO its fine for small scripts up to maybe a few hundred lines. Beyond that no.
On 22/08/2024 09:42, Muttley@dastardlyhq.com wrote:
Yes, its ultimately subjective. The reasons I don't like it are that I can't >> stand dynamic typing in supposed "proper" languages and the syntatically
meaningful whitespace nonsense they took from Occam really grinds my gears. >> In my current job I'm forced to use it but I'd never do it out of choice.
Dynamic typing has its advantages and disadvantages. You do lose a lot
of human checking and static checking when you have dynamic typing, but
you gain flexibility. Have you tried using type annotations in Python?
I am a big fan of clear and consistent layout and indentation, which is >forced on you by Python (and Occam), but I too prefer explicit blocking.
It's harder to get things wrong with explicit blocking, and you are
never faced with space vs. tab conflicts causing semantic changes to the >code.
IMO its fine for small scripts up to maybe a few hundred lines. Beyond that >> no.
Oh, it's fine for /far/ bigger programs than that. But it is excellent
On Thu, 22 Aug 2024, Muttley@dastardlyhq.com wrote:
programmers - but it is also an excellent language for many real tasks.IMO its fine for small scripts up to maybe a few hundred lines. Beyond that >> no.
Of course it has its weaknesses and disadvantages as well as its
strengths, and aspects that will appeal to some programmers and not others. >>
I liked python in the beginning, but I find that over the years, it has >become worse. My biggest complaint is dependency management and that you
have to download so many things in order to get a modern project to work.
On the other hand, I'm not a programmer, so I'm probably doing it wrong or >not accordin to best practices by not using containers for all my python >stuff.
I am a big fan of clear and consistent layout and indentation, which is forced on you by Python (and Occam), but I too prefer explicit blocking.
It's harder to get things wrong with explicit blocking, and you are
never faced with space vs. tab conflicts causing semantic changes to the code.
I liked python in the beginning, but I find that over the years, it has become worse. My biggest complaint is dependency management and that you
have to download so many things in order to get a modern project to work.
On Thu, 22 Aug 2024 10:10:18 +0200, David Brown wrote:
I am a big fan of clear and consistent layout and indentation, which is
forced on you by Python (and Occam), but I too prefer explicit blocking.
It's harder to get things wrong with explicit blocking, and you are
never faced with space vs. tab conflicts causing semantic changes to the
code.
Python prohibits those space/tab inconsistencies.
Nevertheless, I don’t like the loss of redundancy in the way code
structure is expressed, which is why I like to put in “#end” comments.
On Wed, 21 Aug 2024 11:11:46 +0200, David Brown wrote:
On 21/08/2024 09:38, Lawrence D'Oliveiro wrote:
On Wed, 21 Aug 2024 09:26:41 +0200, David Brown wrote:
And you don't need to know anything about Linux, UNIX or POSIX to
program in C.
I think the point has been made on comp.lang.c more than once, that C
without POSIX can be a very dull language indeed ...
It was wrong on comp.lang.c, and it is wrong here. Proof by repeated
assertion is not valid.
It came up repeatedly because of repeated examples where it was true.
In comp.unix.programmer Richard Kettlewell <invalid@invalid.invalid> wrote:
Bart <bc@freeuk.com> writes:
On 27/08/2024 09:39, Richard Kettlewell wrote:
The fact that people have to resort to adding #end lines, which only
partly deals with one or two of those problems, suggest that something
is badly wrong.
I?ve never encountered anyone else doing that in Python. It suggests
more than the individual doing that just doesn?t like the language, in
which case I?d just suggest that person doesn?t use it.
I think it's a great idea. I'm considering asking my team to start adding >#end comments to our codebase.
On Wed, 28 Aug 2024 02:48:59 -0000 (UTC)
Sebastian <sebastian@here.com.invalid> wrote:
At my company, somebody tried to delete a method like method2() above,
but forgot the last few lines (represented by call6()). This does
not introduce a SyntaxError. Instead, call6() is now part of method1()
because it's at the same level of indentation. In most programming
languages, the beginning of method2() would be preceded by some
delimiter marking the end of method1(), which would prevent an
accidental merger of this type.
(Waiting for the Python advocates to fire back with "well, don't do
that, then!" and completely miss the point that it's exactly the topic
of contention here that Python's scope-by-layout approach that makes it
easy to do that...)
Sebastian <sebastian@here.com.invalid> wrote:
At my company, somebody tried to delete a method like method2()
above, but forgot the last few lines (represented by call6()). This
does not introduce a SyntaxError. Instead, call6() is now part of
method1() because it's at the same level of indentation. In most
programming languages, the beginning of method2() would be preceded
by some delimiter marking the end of method1(), which would prevent
an accidental merger of this type.
(Waiting for the Python advocates to fire back with "well, don't do
that, then!" and completely miss the point that it's exactly the topic
of contention here that Python's scope-by-layout approach that makes it
easy to do that...)
On 28/08/2024 16:25, John Ames wrote:
On Wed, 28 Aug 2024 02:48:59 -0000 (UTC)
Sebastian <sebastian@here.com.invalid> wrote:
At my company, somebody tried to delete a method like method2() above,
but forgot the last few lines (represented by call6()). This does
not introduce a SyntaxError. Instead, call6() is now part of method1()
because it's at the same level of indentation. In most programming
languages, the beginning of method2() would be preceded by some
delimiter marking the end of method1(), which would prevent an
accidental merger of this type.
(Waiting for the Python advocates to fire back with "well, don't do
that, then!" and completely miss the point that it's exactly the topic
of contention here that Python's scope-by-layout approach that makes it
easy to do that...)
Or they will say that whoever deleted method2 could also have deleted
that 'end' line if one was used. Whilst also forgetting to delete
method2's own 'end' line.
Or maybe they deleted method2 plus both the preceding and succeeding
lines so that method1 merges into method3.
Generally, they might point all the ways that such oversights and all
kinds of other typos can result in still-valid code in any language. But fragile syntax like Python's just makes it so easier to do that.
I do the same in Python. The difference is that in Python the
indentation is the single source of truth about program structure,
while in other languages it's a matter of convention.
https://en.wikipedia.org/wiki/Single_source_of_truth
On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block.
In Emacs, I have commands defined to adjust the indentation of the
selected region. Surely any other decent editor would offer the same.
On Tue, 27 Aug 2024 21:34:54 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block.
In Emacs, I have commands defined to adjust the indentation of the
selected region. Surely any other decent editor would offer the same.
Writing editor editor macros in order to work around fundamentally bad language design is not something a programmer should have to waste time on.
On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
On Tue, 27 Aug 2024 21:34:54 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block.
In Emacs, I have commands defined to adjust the indentation of the
selected region. Surely any other decent editor would offer the same.
Writing editor editor macros in order to work around fundamentally bad
language design is not something a programmer should have to waste
time on.
I don't know about Emacs, but in most editors the way you indent a block
of code is to select the lines, then press "Tab". Unindenting is "shift-Tab". Changing tabs to spaces or spaces to tabs is done by
selecting "Tabs to spaces" from the Edit menu, or something equally
simple and obvious. Many editor can be set to convert tabs to spaces
(or vice versa) when saving files, perhaps specific to the file type (so
you don't muck up your makefiles).
It takes a special kind of genius to be able to program, and yet still
have trouble with this kind of thing.
Bart <bc@freeuk.com> writes:
On 28/08/2024 19:48, David Brown wrote:
On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
On Tue, 27 Aug 2024 21:34:54 -0000 (UTC)I don't know about Emacs, but in most editors the way you indent a
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:Writing editor editor macros in order to work around fundamentally bad >>>> language design is not something a programmer should have to waste
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block.
In Emacs, I have commands defined to adjust the indentation of the
selected region. Surely any other decent editor would offer the same. >>>>
time on.
block of code is to select the lines, then press "Tab". Unindenting
is "shift-Tab". Changing tabs to spaces or spaces to tabs is done
by selecting "Tabs to spaces" from the Edit menu, or something
equally simple and obvious. Many editor can be set to convert tabs
to spaces (or vice versa) when saving files, perhaps specific to the
file type (so you don't muck up your makefiles).
It takes a special kind of genius to be able to program, and yet
still have trouble with this kind of thing.
The main problem isn't in changing the indentation of a block of code;
it is in HAVING to do so because of poor language design. A lesser one
is having to rely on whatever varied features that 100s of different
editors may have to do so.
And yet another, of more significance, if that after you've indented a
block, it may now merge into an adjacent block that was already at
that new indent. If you later need to revert that first block back to
it's original position, you'd better make sure you mark that boundary.
It is a language design issue pure and simple. Don't try and pin it on
the users and make out it's due to lack of expertise with their
editors. Of course we can all indent blocks; it's just an unnecessary
palaver.
Clearly your point of view is as a language /user/ where languages and
their characteristics are an invariant that you can't do anything
about, can't change, and need to work around.
But some of us devise (and, importanly, implement) languages of our
own and can be more vocal about misfeatures in others.
If I'm moving chunks of code around in a C or C++ program, from one
scope to another, I can get away with leaving the indentation as it is, because all the compiler cares about is where the braces are. But I
*always* adjust the indentation to fit the code's new context.
Python's use of indentation to indicate scoping just means that I have
to do what I would have done anyway.
This was an attempt to port an benchmark into Nim; I'd spent the
best part of an hour trying to get it right, but it kept going
wrong. In the end I resorted to artificial block terminators.
The final code looked like that below. Now it is much, much easier
to see what goes where, and what belongs to what. I can more
confidently write that extra statement following the opening 'if'.
With these changes, the porting went much more smooothly.
if q1!=1:
for i in countup(2,n):
q[i]=p[i]
# end
flips=1
while true:
qq=q[q1]
if qq==1:
sum+=sign*flips
if flips>maxflips:
maxflips=flips # end
break
# end
q[q1]=q1
if q1>=4:
i=2
j=q1-1
while true:
t=q[i]
q[i]=q[j]
q[j]=t
i+=1
j-=1
if i>=j:
break # end # end
# end
q1=qq
flips+=1
# end
# end
Sure, people CAN program in such languages, but it is harder work> and more error prone.
But ok, I found your post and removed all the #end comments. I found it
just as readable without them as with them.
If you have some code that needs a lot of documentation (and some does),
then put the comments in a place that does not interfere with reading
and understanding the code.
The main problem isn't in changing the indentation of a block of code;
it is in HAVING to do so because of poor language design.
On 27/08/2024 15:18, Bart wrote:
[Previous discussion and code snipped -- ANW]
This was an attempt to port an benchmark into Nim; I'd spent the
best part of an hour trying to get it right, but it kept going
wrong. In the end I resorted to artificial block terminators.
The final code looked like that below. Now it is much, much easier
to see what goes where, and what belongs to what. I can more
confidently write that extra statement following the opening 'if'.
With these changes, the porting went much more smooothly.
if q1!=1:
for i in countup(2,n):
q[i]=p[i]
# end
flips=1
while true:
qq=q[q1]
if qq==1:
sum+=sign*flips
if flips>maxflips:
maxflips=flips
# end
break
# end
q[q1]=q1
if q1>=4:
i=2
j=q1-1
while true:
t=q[i]
q[i]=q[j]
q[j]=t
i+=1
j-=1
if i>=j:
break
# end
# end
# end
q1=qq
flips+=1
# end
# end
Sure, people CAN program in such languages, but it is harder work> and
more error prone.
ISTM that the difficulty in reading and writing code like that
stems not from the indentation, but
from a
long narrow
corridor
of program
which is
difficult to
read
and write
no matter how
it is indented.
Variable indentation
merely
makes the long
column wriggly.
It reminds me of the early autocodes, before the days of block structure.
I don't know Nim [and only a little of Python], so I can't apportion the difficulty of understanding the code between the language and the chosen programming style. But I can't resist adding a few comments:
(a) Bart takes 14 lines [from "if q1>=4" to the corresponding "# end"]
to express the notion [E&OE]
for i from 2 to q1%2
swap (q[i], q[q1 - i + 1])
Small wonder that he found the code hard to get right!
(b) There are two occurrences of "while true" and two of "break" in the code which would not be necessary or appropriate in C or Algol [amongst others]. Again, IMO these contribute to the obscurity of the code.
(c) I recognise that code as coming from a version of the "Fannkuch" benchmark, so I already have it in C and in Algol 68G. Bart's Nim code
is substantially longer [around twice the length of the A68G]. Brevity
is not everything, but if you are forever scrolling from one window to
the next while your friend gets it all into one window [without losing clarity of expression], then guess who is going to find it easier to
read, write and understand the code.
(d) Further, if the code is harder to understand, it has more need of explanatory comments, which in turn make the code longer, so harder to navigate around.
On Wed, 28 Aug 2024 20:27:53 +0100, Bart wrote:
The main problem isn't in changing the indentation of a block of code;
it is in HAVING to do so because of poor language design.
If you think the need for refactoring is something that can be solved by “language design”, I’d like to hear how.
Bart <bc@freeuk.com> writes:
On 28/08/2024 19:48, David Brown wrote:
But some of us devise (and, importanly, implement) languages of our
own and can be more vocal about misfeatures in others.
If I'm moving chunks of code around in a C or C++ program, from one
scope to another, I can get away with leaving the indentation as it is, because all the compiler cares about is where the braces are. But I
*always* adjust the indentation to fit the code's new context.
Python's use of indentation to indicate scoping just means that I have
to do what I would have done anyway.
On 28/08/2024 23:49, Lawrence D'Oliveiro wrote:
On Wed, 28 Aug 2024 20:27:53 +0100, Bart wrote:
The main problem isn't in changing the indentation of a block of code;
it is in HAVING to do so because of poor language design.
If you think the need for refactoring is something that can be solved
by “language design”, I’d like to hear how.
The aim is to not NEED refactoring when you are playing around with different, short-term bits of code.
That's not the conventional way to format a docstring. If you're using backslashes to splice lines in Python, it's likely you're doing
something wrong.
I think "is not None" is more idiomatic.
You don't need the \ if you put the ( on the same line.
You leave a space between "else" and ":". It's not wrong, but it's not something I've ever seen.
In any language, if a block of code is so deeply indented that it's confusing, you should consider refactoring it. (Though that's not
always the answer.)
On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
Writing editor editor macros in order to work around fundamentally bad
language design is not something a programmer should have to waste time on. >>
I don't know about Emacs, but in most editors the way you indent a block
of code is to select the lines, then press "Tab". Unindenting is >"shift-Tab". Changing tabs to spaces or spaces to tabs is done by
selecting "Tabs to spaces" from the Edit menu, or something equally
simple and obvious. Many editor can be set to convert tabs to spaces
(or vice versa) when saving files, perhaps specific to the file type (so
you don't muck up your makefiles).
It takes a special kind of genius to be able to program, and yet still
have trouble with this kind of thing.
On Thu, 29 Aug 2024 00:21:43 +0100, Bart wrote:
On 28/08/2024 23:49, Lawrence D'Oliveiro wrote:
On Wed, 28 Aug 2024 20:27:53 +0100, Bart wrote:
The main problem isn't in changing the indentation of a block of code; >>>> it is in HAVING to do so because of poor language design.
If you think the need for refactoring is something that can be solved
by “language design”, I’d like to hear how.
The aim is to not NEED refactoring when you are playing around with
different, short-term bits of code.
“Playing around” is exactly one of those situations where you will need to
do all kinds of things to the code, including refactoring.
The last I checked, the O'Reilly Python book is just absolutely
*MASSIVE*. The language has a huge number of features now ...
On Thu, 15 Aug 2024 19:48:36 -0000 (UTC), Kalevi Kolttonen wrote:
The last I checked, the O'Reilly Python book is just absolutely
*MASSIVE*. The language has a huge number of features now ...
No, it hasn’t. The core language reference spec is only a small fraction of, say, the Java language spec.
It’s just that you can do so many things with Python. And that is down to the huge variety of off-the-shelf addon libraries that build on that core language spec. It has to be a strong, very solidly founded core in order
to be such a versatile basis for these addons, and it is.
Then there are those that - wisely or unwisely - program in C for
Windows, without POSIX.
On Thu, 22 Aug 2024 09:52:24 +0200
D <nospam@example.net> boringly babbled:
On Thu, 22 Aug 2024, Muttley@dastardlyhq.com wrote:
programmers - but it is also an excellent language for many real tasks. >>>> Of course it has its weaknesses and disadvantages as well as its
strengths, and aspects that will appeal to some programmers and not others.
IMO its fine for small scripts up to maybe a few hundred lines. Beyond that >>> no.
I liked python in the beginning, but I find that over the years, it has
become worse. My biggest complaint is dependency management and that you
have to download so many things in order to get a modern project to work.
Yes, that appears to be a big issue these days. On a project I was working
on recently the version of Pandas (stupid name but thats python libs) had some minor bug and to update Pandas we had to update just about everything else as well.
On the other hand, I'm not a programmer, so I'm probably doing it wrong or >> not accordin to best practices by not using containers for all my python
stuff.
For a properly designed language a container shouldn't be required. Using
a container to prevent library hell is like seeing a mess on your floor but instead of clearing the mess you sweep it into seperate piles depending on the type of rubbish. With C/C++ you can set LD_LIBRARY_PATH to use particular shared object files but doing something similar with Python AFAIK is a hell of
a task.
On Thu, 22 Aug 2024, Muttley@dastardlyhq.com wrote:[snip]
For a properly designed language a container shouldn't be required. Using
a container to prevent library hell is like seeing a mess on your floor but >> instead of clearing the mess you sweep it into seperate piles depending on >> the type of rubbish. With C/C++ you can set LD_LIBRARY_PATH
to use particular shared object files
but doing something similar with Python AFAIK is a hell of
a task.
Thank you! You make me feel less of an outsider and old timer! ;)
Please forgive my interruption, but something in Muttley's comment needs
some clarification....
For a properly designed language a container shouldn't be required. Using >>> a container to prevent library hell is like seeing a mess on your floor but >>> instead of clearing the mess you sweep it into seperate piles depending on >>> the type of rubbish. With C/C++ you can set LD_LIBRARY_PATH
1) The ability to alter the loader's library search path isn't a C/C++ feature,
but, instead, is a feature of the loader, and is applicable to /any/ binary
that uses "shared objects" ("DLL"s to those who came from a Windows
environment).
Depending on the Unix system, the environment variable can be called:
LD_LIBRARY_PATH, or
LIBPATH, or
SHLIB_PATH, and
there may be other names that I don't know of.
On 2024-08-22 13:00, David Brown wrote:
Then there are those that - wisely or unwisely - program in C for
Windows, without POSIX.
Yes, that is true. There is no reason to use POSIX under Windows,
whatsoever.
It takes but one single counter-example to invalidate general claims
like this.
On 2024-08-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
On 2024-08-22 13:00, David Brown wrote:
Then there are those that - wisely or unwisely - program in C for
Windows, without POSIX.
Yes, that is true. There is no reason to use POSIX under Windows,
whatsoever.
David also wrote this, in the same comment:
It takes but one single counter-example to invalidate general claims
like this.
It applies to your reply as well.
There are excellent, excellent reasons to use POSIX under Windows.
Such as, oh, having an entire POSIX appliation ported to Windows
almost without lifting a finger.
For the TXR project I use a POSIX layer called Cygnal (see signature
below). It gives a decent Windows port which preserves most of the functionality. All the POSIX stuff in the TXR Lisp standard library just works. The interactive listener ("REPL") with history and editing just
works, right in your cmd.exe console.
Bart <bc@freeuk.com> writes:
On 22/08/2024 16:28, Kaz Kylheku wrote:
For the TXR project I use a POSIX layer called Cygnal (see signature
below). It gives a decent Windows port which preserves most of the
functionality. All the POSIX stuff in the TXR Lisp standard library just >>> works. The interactive listener ("REPL") with history and editing just
works, right in your cmd.exe console.
(It's also not clear how well your product manages to use POSIX under
pure Windows, or whether you have to drag this other thing called 'CygWin'.
He specified in the paragraph to which you responded the posix
interposer he used.
On 22/08/2024 16:28, Kaz Kylheku wrote:
For the TXR project I use a POSIX layer called Cygnal (see signature
below). It gives a decent Windows port which preserves most of the
functionality. All the POSIX stuff in the TXR Lisp standard library just
works. The interactive listener ("REPL") with history and editing just
works, right in your cmd.exe console.
(It's also not clear how well your product manages to use POSIX under
pure Windows, or whether you have to drag this other thing called 'CygWin'.
On 2024-08-22, Bart <bc@freeuk.com> wrote:
On 22/08/2024 16:28, Kaz Kylheku wrote:
On 2024-08-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
On 2024-08-22 13:00, David Brown wrote:
Then there are those that - wisely or unwisely - program in C for
Windows, without POSIX.
Yes, that is true. There is no reason to use POSIX under Windows,
whatsoever.
David also wrote this, in the same comment:
It takes but one single counter-example to invalidate general claims >>>>> like this.
It applies to your reply as well.
There are excellent, excellent reasons to use POSIX under Windows.
Such as, oh, having an entire POSIX appliation ported to Windows
almost without lifting a finger.
For the TXR project I use a POSIX layer called Cygnal (see signature
below). It gives a decent Windows port which preserves most of the
functionality. All the POSIX stuff in the TXR Lisp standard library just >>> works. The interactive listener ("REPL") with history and editing just
works, right in your cmd.exe console.
You can use the same argument to justify using X11 under Windows.
I could use a similar argument, but it would lack nuance.
Using X11 under Windows requires a server component, which is
somewhat clunky for a stand-alone application to carry.
On 22/08/2024 17:31, Scott Lurndal wrote:
Bart <bc@freeuk.com> writes:
On 22/08/2024 16:28, Kaz Kylheku wrote:He specified in the paragraph to which you responded the posix
For the TXR project I use a POSIX layer called Cygnal (see signature
below). It gives a decent Windows port which preserves most of the
functionality. All the POSIX stuff in the TXR Lisp standard library just >>>> works. The interactive listener ("REPL") with history and editing just >>>> works, right in your cmd.exe console.
(It's also not clear how well your product manages to use POSIX under
pure Windows, or whether you have to drag this other thing called 'CygWin'. >>
interposer he used.
So this is only indirectly using POSIX under Windows.
On 22/08/2024 16:28, Kaz Kylheku wrote:
On 2024-08-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
On 2024-08-22 13:00, David Brown wrote:
Then there are those that - wisely or unwisely - program in C for
Windows, without POSIX.
Yes, that is true. There is no reason to use POSIX under Windows,
whatsoever.
David also wrote this, in the same comment:
It takes but one single counter-example to invalidate general claims
like this.
It applies to your reply as well.
There are excellent, excellent reasons to use POSIX under Windows.
Such as, oh, having an entire POSIX appliation ported to Windows
almost without lifting a finger.
For the TXR project I use a POSIX layer called Cygnal (see signature
below). It gives a decent Windows port which preserves most of the
functionality. All the POSIX stuff in the TXR Lisp standard library just
works. The interactive listener ("REPL") with history and editing just
works, right in your cmd.exe console.
You can use the same argument to justify using X11 under Windows.
(It's also not clear how well your product manages to use POSIX under
pure Windows, or whether you have to drag this other thing called 'CygWin'.
Can you write a normal Windows app and just call into a DLL called
posix.dll or is there an extra layer or two involved?)
On 2024-08-22, Bart <bc@freeuk.com> wrote:
So this is only indirectly using POSIX under Windows.
That is correct; the Microsoft POSIX subsystem isn't used, if that's
what you mean by "direct".
It's not designed to be usable, as far as I know.
Such as, oh, having an entire POSIX appliation ported to Windows
almost without lifting a finger.
On 2024-08-22 17:28, Kaz Kylheku wrote:
Such as, oh, having an entire POSIX appliation ported to Windows
almost without lifting a finger.
It presumes that your application is already limited to POSIX.
In the scenario of designing a portable application there are more comprehensive choices, e.g. glib (and other parts of GTK).
On 2024-08-22 13:00, David Brown wrote:
Then there are those that - wisely or unwisely - program in C for
Windows, without POSIX.
Yes, that is true. There is no reason to use POSIX under Windows,
whatsoever.
On 22/08/2024 11:02, Lawrence D'Oliveiro wrote:
No, it does not. Python treats tabs (at the start of lines, which is
Python prohibits those space/tab inconsistencies.
the only relevant point here) as 8 spaces by default. You can change
that with command-line flags if you want. But it is quite happy with mixtures of tabs and spaces as long as the result after tab-to-space conversion is consistent with Python syntax.
On Thu, 22 Aug 2024 12:47:16 +0200, David Brown wrote:
On 22/08/2024 11:02, Lawrence D'Oliveiro wrote:
No, it does not. Python treats tabs (at the start of lines, which is
Python prohibits those space/tab inconsistencies.
the only relevant point here) as 8 spaces by default. You can change
that with command-line flags if you want. But it is quite happy with
mixtures of tabs and spaces as long as the result after tab-to-space
conversion is consistent with Python syntax.
src = \
"""
def fun() :
\t\tprint("line 1")
\t\x20\x20\x20\x20\x20\x20\x20\x20print("line 2")
fun()
"""
exec(src)
Output:
TabError: inconsistent use of tabs and spaces in indentation
On Thu, 22 Aug 2024 13:30:19 +0200, Dmitry A. Kazakov wrote:
On 2024-08-22 13:00, David Brown wrote:
Then there are those that - wisely or unwisely - program in C for
Windows, without POSIX.
Yes, that is true. There is no reason to use POSIX under Windows,
whatsoever.
That’s strange. Didn’t Microsoft tout the POSIX compatibility of Windows to its US Government customers?
On 23/08/2024 02:19, Lawrence D'Oliveiro wrote:
On Thu, 22 Aug 2024 12:47:16 +0200, David Brown wrote:
But it is quite happy with
mixtures of tabs and spaces as long as the result after tab-to-space
conversion is consistent with Python syntax.
Mixtures of tabs and spaces are accepted without complaint.
(The incompatibilities between Python 2 and Python 3 are another pain in Python.
The fundamental problem was that Unicode was a mess in Python 2 that
needed to be cleaned up. Since they had no choice but to break backward compatibility in that regard, they figured they would fix a few other
things while they were at it.
Without the constraints imposed by the language, I could just write it as:
if a == b:
s1
RETURN
s2
s3
NOW it stands out!
On Wed, 28 Aug 2024 17:23:25 -0700, Keith Thompson wrote:
That's not the conventional way to format a docstring. If you're using
backslashes to splice lines in Python, it's likely you're doing
something wrong.
What exactly is wrong?
I think "is not None" is more idiomatic.
When I want an equality comparison, I use “==”, not “is”.
You don't need the \ if you put the ( on the same line.
But I do otherwise.
You leave a space between "else" and ":". It's not wrong, but it's not
something I've ever seen.
People who look at my code tend to get triggered by the little things;
maybe it’s a way to avoid thinking about the big things?
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Wed, 28 Aug 2024 13:29:18 -0700, Keith Thompson wrote:
But ok, I found your post and removed all the #end comments. I found it >>> just as readable without them as with them.
You know what? You are right. That example was just too
well-structured.
Here’s a more dangerous one:
def register_additional_standard(self, **kwargs) :
"registers additional standard interfaces that are not automatically" \
" installed at Connection creation time. Currently the only one is" \
" the object-manager interface, registered with\n" \
"\n" \
" «conn».register_additional_standard(managed_objects = True)\n"
That's not the conventional way to format a docstring. If you're using backslashes to splice lines in Python, it's likely you're doing
something wrong.
for key in kwargs :
if kwargs[key] :
if key == "managed_objects" :
if self._managed_objects != None :
I think "is not None" is more idiomatic.
raise asyncio.InvalidStateError \
(
"object manager interface already registered" >> )
You don't need the \ if you put the ( on the same line.
#end if
self.register \
(
path = "/",
interface = ManagedObjectsHandler(),
fallback = True
)
Again, you've decided how you want to place parentheses and you're
forcing the syntax to cater to that. I might write that as:
self.register(
path = "/",
interface = ManagedObjectsHandler(),
fallback = True
)
self._managed_objects = {}
else :
You leave a space between "else" and ":". It's not wrong, but it's not something I've ever seen. It's likely to be just a little jarring to readers.
raise TypeError("unrecognized argument keyword “%s”" % key)
Do you have a requirement to use older versions of Python that don't
support f-strings?
#end if
#end if
#end for
return \
self
Why not just "return self"?
#end register_additional_standard
versus
def register_additional_standard(self, **kwargs) :
"registers additional standard interfaces that are not automatically" \
" installed at Connection creation time. Currently the only one is" \
" the object-manager interface, registered with\n" \
"\n" \
" «conn».register_additional_standard(managed_objects = True)\n"
for key in kwargs :
if kwargs[key] :
if key == "managed_objects" :
if self._managed_objects != None :
raise asyncio.InvalidStateError \
(
"object manager interface already registered" >> )
self.register \
(
path = "/",
interface = ManagedObjectsHandler(),
fallback = True
)
self._managed_objects = {}
else :
raise TypeError("unrecognized argument keyword “%s”" % key)
return self
Again, the #end comments don't make it any more readable *for me*.
I suspect that would be even more true for more experienced Python programmers.
I was looking for quite a tricky example I remember seeing on the
ArjanCodes channel on YouTube, but I can’t find it.
In any language, if a block of code is so deeply indented that it's confusing, you should consider refactoring it. (Though that's not
always the answer.)
I once reviewed some C code with misleading indentation. Depending on
the viewer's tab settings (4 vs 8 columns) it looked either like this:
if (condition)
this;
that;
or like this:
if (condition)
this;
that;
Of course it meant the same to the compiler.
In any language, I think it's important to use consistent indentation
that reflects the structure of the code, and to avoid mixing tabs and
spaces. (My personal preference is to use spaces exclusively, but I'll conform to what existing code does.) As I've said elsethread, Python's
rules just force me to do what I would have done anyway.
On Wed, 28 Aug 2024 20:48:08 +0200
David Brown <david.brown@hesbynett.no> wrote:
On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
Writing editor editor macros in order to work around fundamentally bad
language design is not something a programmer should have to waste
time on.
I don't know about Emacs, but in most editors the way you indent a
block of code is to select the lines, then press "Tab". Unindenting
is "shift-Tab". Changing tabs to spaces or spaces to tabs is done by
selecting "Tabs to spaces" from the Edit menu, or something equally
simple and obvious. Many editor can be set to convert tabs to spaces
(or vice versa) when saving files, perhaps specific to the file type
(so you don't muck up your makefiles).
It takes a special kind of genius to be able to program, and yet still
have trouble with this kind of thing.
Don't be a patronising prick, it doesn't help your argument. Personally I have better things to do that figure out some obscure functionality of vim
to achieve something I shouldn't have to do in the first place if the language was designed properly. Thankfully I don't have to use Python much.
On 28/08/2024 19:48, David Brown wrote:
On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
On Tue, 27 Aug 2024 21:34:54 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block.
In Emacs, I have commands defined to adjust the indentation of the
selected region. Surely any other decent editor would offer the same.
Writing editor editor macros in order to work around fundamentally bad
language design is not something a programmer should have to waste
time on.
I don't know about Emacs, but in most editors the way you indent a
block of code is to select the lines, then press "Tab". Unindenting
is "shift-Tab". Changing tabs to spaces or spaces to tabs is done by
selecting "Tabs to spaces" from the Edit menu, or something equally
simple and obvious. Many editor can be set to convert tabs to spaces
(or vice versa) when saving files, perhaps specific to the file type
(so you don't muck up your makefiles).
It takes a special kind of genius to be able to program, and yet still
have trouble with this kind of thing.
The main problem isn't in changing the indentation of a block of code;
it is in HAVING to do so because of poor language design.
A lesser one
is having to rely on whatever varied features that 100s of different
editors may have to do so.
And yet another, of more significance, if that after you've indented a
block, it may now merge into an adjacent block that was already at that
new indent. If you later need to revert that first block back to it's original position, you'd better make sure you mark that boundary.
It is a language design issue pure and simple. Don't try and pin it on
the users and make out it's due to lack of expertise with their editors.
Of course we can all indent blocks; it's just an unnecessary palaver.
Clearly your point of view is as a language /user/ where languages and
their characteristics are an invariant that you can't do anything about, can't change, and need to work around.
But some of us devise (and, importanly, implement) languages of our own
and can be more vocal about misfeatures in others.
On 2024-08-29 12:49, Bart wrote:
Without the constraints imposed by the language, I could just write it as: >> ááá if a == b:
ááááááá s1
RETURN
ááááááá s2
ááááááá s3
NOW it stands out!
In Ada I use indentation for the purpose:
if A = B then -- This I will remove later
s1;
end if;
s2;
s3;
I remember FORTRAN in its glory days had D-comments. In the first column
the letter D meant a conditional, compiled in the debug mode, ignored otherwise.
Presumably you are /not/ trying to claim that - you are just trolling.
On 29/08/2024 09:28, Muttley@dastardlyhq.com wrote:
[...]
Then don't use vim - use an editor that suits your needs.
If you are trying to claim that you do software development, and that
the editor(s) you use regularly do not have easily available functions
for indenting and un-indenting sections of code, then you are either
lying, or you /are/ an aforementioned special kind of genius.
On Thu, 29 Aug 2024 14:24:01 +0200
David Brown <david.brown@hesbynett.no> wrote:
Don't you ever just accept that a language is the way it is, and it
is perfectly useable that way? Or think that perhaps other people in
the world know better than you do about how they want their language
to work? Has it never occurred to you that the people behind a given
language - such as Python - considered various alternatives and
decided that making it the way they did was the best choice overall
for the language they wanted?
They probably did - but did they do that *because* of the point in
question, in spite of it, or without any meaningful inclination toward
or against it? There are plenty of other aspects about Python that may
tip the balance in spite of its annoyances.
F'rinstance, the *very* comprehensive set of libraries make bashing out
quick utilities to do A Complex Thing often very simple. (That was the
reason I first used it - needed a quick-'n-easy way to programmatically deliver data in a POST request from a Windows box in production, and it
beat the hell out of trying to wrap my head around Win32 network programming.) But if the language "wins" on that score, that doesn't
mean its annoyances or flaws are any less real or worthy of complaint.
Like, obviously it's way too late in the game for Python to change this
now. But we can still say it's stupid for them to have done it that way
in the first place. Is that a matter of opinion? Sure, but that's never stopped anybody from expressing themselves re: any other language. (How
many people are still bitching about C being "insecure," 50+ years down
the line?)
On 29.08.2024 14:30, David Brown wrote:
On 29/08/2024 09:28, Muttley@dastardlyhq.com wrote:
[...]
Then don't use vim - use an editor that suits your needs.
LOL. (You appear to be joking. - If not, continue reading...)
But what makes you think that his needs are not covered by Vim?
On Thu, 29 Aug 2024 14:30:27 +0200
David Brown <david.brown@hesbynett.no> wrote:
Presumably you are /not/ trying to claim that - you are just trolling.
Ah ok, you're the type who thinks anyone who disagrees with you is a troll.
You're not worth the effort mate.
def foo(a, b, c) :
if a :
if b :
if c :
doThis()
That looks unfinished to me. So I will add a "return" at the end (with
a single tab indent, in this case).
Don't you ever just accept that a language is the way it is, and it is perfectly useable that way?
Or think that perhaps other people in the world know better than you do
about how they want their language to work?
Has it never occurred to you that the people behind a given
language - such as Python - considered various alternatives and decided
that making it the way they did was the best choice overall for the
language they wanted?
On 29/08/2024 02:23, Keith Thompson wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Wed, 28 Aug 2024 13:29:18 -0700, Keith Thompson wrote:
But ok, I found your post and removed all the #end comments. I found
it just as readable without them as with them.
You know what? You are right. That example was just too
well-structured.
So why not try to write /all/ your code in a well-structured manner, so
that you don't feel the need to add these "#end" comments?
def register_additional_standard(self, managed_objects) :
"""
registers additional standard interfaces that are not
automatically installed at Connection creation time. Currently
the only one is the object-manager interface, registered with
«conn».register_additional_standard(managed_objects = True)
"""
Line continuation characters in Python are usually an indicator of poor formatting, or an unhealthy obsession with line length limits.
I don't know if I am more experienced than you in Python (I may have
been using Python for longer, but you may have worked with it more), but
I would say that the "#end" comments directly detract from readability.
On 28/08/2024 21:27, Bart wrote:
On 28/08/2024 19:48, David Brown wrote:
On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
On Tue, 27 Aug 2024 21:34:54 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:Writing editor editor macros in order to work around fundamentally bad >>>> language design is not something a programmer should have to waste
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block.
In Emacs, I have commands defined to adjust the indentation of the
selected region. Surely any other decent editor would offer the same. >>>>
time on.
I don't know about Emacs, but in most editors the way you indent a
block of code is to select the lines, then press "Tab". Unindenting
is "shift-Tab". Changing tabs to spaces or spaces to tabs is done by
selecting "Tabs to spaces" from the Edit menu, or something equally
simple and obvious. Many editor can be set to convert tabs to spaces
(or vice versa) when saving files, perhaps specific to the file type
(so you don't muck up your makefiles).
It takes a special kind of genius to be able to program, and yet
still have trouble with this kind of thing.
The main problem isn't in changing the indentation of a block of code;
it is in HAVING to do so because of poor language design.
If I am adding or removing blocks (such as surrounding existing code in
a new conditional), then I /have/ to change the indentation - in /any/ language. (I use indents in my assembly programming too.) Call it OCD
or compulsive behaviour if you like, but I cannot consider code to be finished - even to the level of a quick compile or test - if the
indentation is not correct.
I simply cannot see the problem with Python here, because I would not
indent things in any other way in any language.
The only thing I see as annoying in Python is when you have two or three indentations left hanging :
def foo(a, b, c) :
if a :
if b :
if c :
doThis()
That looks unfinished to me.
So I will add a "return" at the end (with
a single tab indent, in this case). If it is not the end of the
function, I will sometimes use a "pass" to pull back the indent level.
Of course, being a sane software developer, I do most of my programming
using editors that are suitable for software development. Most
professional carpenters use hammers for their nails, rather than bashing
them in with stones - it's the same thing, really.
And yet another, of more significance, if that after you've indented a
block, it may now merge into an adjacent block that was already at
that new indent. If you later need to revert that first block back to
it's original position, you'd better make sure you mark that boundary.
So mark the boundary. Add a blank line. Put a comment line describing
the steps of the function. You are making up problems for which you
already have good solutions that you would be using in any programming language.
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.
Your problem here is that you are obsessed with finding things that you
want to see as misfeatures, design flaws, or problems in other languages
- and then obsess about how you can find new ways to make it more
difficult to "work around" them.
Don't you ever just accept that a language is the way it is, and it is perfectly useable that way?
Or think that perhaps other people in the
world know better than you do about how they want their language to
work? Has it never occurred to you that the people behind a given
language - such as Python - considered various alternatives and decided
that making it the way they did was the best choice overall for the
language they wanted?
As Bjarne Stustroup said, there are two kinds of programming languages - those that people complain about, and those that no one uses.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
[...]
Think about why you bother to indent code in languages where the
compiler ignores such indentation anyway: it means you are expressing
the structure of code in two different ways, one via statement
brackets, and the other via indentation. This redundancy aids in
understanding that the code does what you think it does.
Python gets rid of this redundancy, by having the compiler take notice
of the whitespace and removing the statement bracketing symbols. So I
put it back, by adding statement bracketing symbols that the compiler
ignores.
Vim is an editor that has the most simple and also very powerful
indenting for well structured data and programs I've yet seen. (Not mentioning its equally powerful other editing facilities.)
On Thu, 29 Aug 2024 14:01:05 +0200, David Brown wrote:
On 29/08/2024 02:23, Keith Thompson wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Wed, 28 Aug 2024 13:29:18 -0700, Keith Thompson wrote:
But ok, I found your post and removed all the #end comments. I found >>>>> it just as readable without them as with them.
You know what? You are right. That example was just too
well-structured.
So why not try to write /all/ your code in a well-structured manner, so
that you don't feel the need to add these "#end" comments?
Because not all examples can be made that neat, as I demonstrated.
def register_additional_standard(self, managed_objects) :
"""
registers additional standard interfaces that are not
automatically installed at Connection creation time. Currently
the only one is the object-manager interface, registered with
«conn».register_additional_standard(managed_objects = True)
"""
Note that Python’s indentation rules don’t apply to multiline string literals -- don’t you wish they did? So you end up with all that extra space within the literal. Do you see why I prefer to avoid that?
Line continuation characters in Python are usually an indicator of poor
formatting, or an unhealthy obsession with line length limits.
I like to keep within a line length limit of about 100 characters.
I don't know if I am more experienced than you in Python (I may have
been using Python for longer, but you may have worked with it more), but
I would say that the "#end" comments directly detract from readability.
Think about why you bother to indent code in languages where the compiler ignores such indentation anyway: it means you are expressing the structure
of code in two different ways, one via statement brackets, and the other
via indentation. This redundancy aids in understanding that the code does what you think it does.
Python gets rid of this redundancy, by having the compiler take notice of
the whitespace and removing the statement bracketing symbols. So I put it back, by adding statement bracketing symbols that the compiler ignores.
On Thu, 29 Aug 2024 14:24:01 +0200, David Brown wrote:
def foo(a, b, c) :
if a :
if b :
if c :
doThis()
That looks unfinished to me. So I will add a "return" at the end (with
a single tab indent, in this case).
A redundant “return” ... kind of like my redundant “#end” comments, except
yours work in a more restricted set of places ...
Don't you ever just accept that a language is the way it is, and it is
perfectly useable that way?
Of course not.
Or think that perhaps other people in the world know better than you do
about how they want their language to work?
And vice versa.
Has it never occurred to you that the people behind a given
language - such as Python - considered various alternatives and decided
that making it the way they did was the best choice overall for the
language they wanted?
Barring a few obvious stupidities, yes of course they were, and are, smart people.
On Sat, 7 Sep 2024 18:30:03 -0000 (UTC), candycanearter07 wrote:
Subjectively, I prefer early returns over nested ifs:
Nested ifs nest, early returns don’t.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 22:48 this Saturday (GMT):
On Sat, 7 Sep 2024 18:30:03 -0000 (UTC), candycanearter07 wrote:
Subjectively, I prefer early returns over nested ifs:
Nested ifs nest, early returns don’t.
Right, they remove some nesting which makes it easier to read.
On Thu, 26 Sep 2024 18:00:09 -0000 (UTC), candycanearter07 wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 22:48 this Saturday (GMT):
On Sat, 7 Sep 2024 18:30:03 -0000 (UTC), candycanearter07 wrote:
Subjectively, I prefer early returns over nested ifs:
Nested ifs nest, early returns don’t.
Right, they remove some nesting which makes it easier to read.
Nestability helps with refactorability.
On Thu, 15 Aug 2024 19:48:36 -0000 (UTC), Kalevi Kolttonen wrote:
The last I checked, the O'Reilly Python book is just absolutely
*MASSIVE*. The language has a huge number of features now ...
No, it hasn’t. The core language reference spec is only a small fraction of, say, the Java language spec.
It’s just that you can do so many things with Python. And that is down to the huge variety of off-the-shelf addon libraries that build on that core language spec. It has to be a strong, very solidly founded core in order
to be such a versatile basis for these addons, and it is.
On 2024-08-15, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Thu, 15 Aug 2024 19:48:36 -0000 (UTC), Kalevi Kolttonen wrote:
The last I checked, the O'Reilly Python book is just absolutely
*MASSIVE*. The language has a huge number of features now ...
No, it hasn’t. The core language reference spec is only a small fraction >> of, say, the Java language spec.
It’s just that you can do so many things with Python. And that is down to >> the huge variety of off-the-shelf addon libraries that build on that core
language spec. It has to be a strong, very solidly founded core in order
to be such a versatile basis for these addons, and it is.
That's idiotic; you're saying that the standard library packages of
Python are not part of Python, and do not contribute to its size.
Okay. I must confess that just seeing the book's size discouraged
me from buying or reading it. Programming Python, 4th Edition by
O'Reilly has whopping 1628 pages! This has to be one of the longest >programming books ever published.
So are you saying that most of the 1628 pages describe libraries
instead of the core language?
So are you saying that most of the 1628 pages describe libraries instead
of the core language?
There’s a decent amount in the standard Python libraries, but even more so in the huge number of third-party libraries. This is all part of the “batteries included” Python philosophy.
So it is indeed a vague question of what belongs in given programming >languages.
On Fri, 16 Aug 2024 15:02:20 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
You seem to have a point. The core of C language is also small. I
guess they even said in the original K & R book that C is a small
language best described by a small book.
But in order to do anything with C, you need to know the standard
libraries. They have grown bigger and bigger during all these
years. One could also well argue that to program on UNIX, you also
need to know all the POSIX libraries.
What you *need* is also very much dependent on what you need to *do.*
If all you're doing is batch-munging of files in some basic format, f'rexample, you don't particularly need to delve into POSIX esoterica
or some whiz-bang Python bolt-on for frobbing the servos on a lunar
probe while generating novel text from cosmic background radiation; you certainly can if you want to, but stdlib or the Python equivalent will
get you there just fine.
On Fri, 16 Aug 2024 15:02:20 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) gabbled:
So it is indeed a vague question of what belongs in given programming
languages.
Indeed. And this gives rise to inconsistency. Why is threading now considered a core part of C++ but multi process isn't? Perhaps because Windows is hopeless
at the latter in user space but it could just be personal preference within the
C++ steering committee, who knows.
On Fri, 23 Aug 2024 09:19:06 +0200, David Brown wrote:
On 23/08/2024 02:19, Lawrence D'Oliveiro wrote:
On Thu, 22 Aug 2024 12:47:16 +0200, David Brown wrote:
But it is quite happy with
mixtures of tabs and spaces as long as the result after tab-to-space
conversion is consistent with Python syntax.
Mixtures of tabs and spaces are accepted without complaint.
I understood you to mean that different mixtures of tabs and spaces would work, so long as they were equivalent to the same indentation under the 8- spaces = 1 tab rule that you cited.
In fact there is no such equivalence rule. Tabs are tabs, and spaces are spaces, and never the twain shall be interconvertible.
(The incompatibilities between Python 2 and Python 3 are another pain in
Python.
The fundamental problem was that Unicode was a mess in Python 2 that
needed to be cleaned up. Since they had no choice but to break backward compatibility in that regard, they figured they would fix a few other
things while they were at it.
On 2024-08-23 10:29, Lawrence D'Oliveiro wrote:
The fundamental problem was that Unicode was a mess in Python 2 that
needed to be cleaned up. Since they had no choice but to break backward
compatibility in that regard, they figured they would fix a few other
things while they were at it.
and again in Python 4... (:-))
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:
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
Now you know that 'if a' doesn't end at that blank line, because no
'end' has been seen for it.
So I will add a "return" at the end (with a single tab indent, in this
case). If it is not the end of the function, I will sometimes use a
"pass" to pull back the indent level.
So you have problems too. Would you have needed 'return' if 'end's had
been used in the original?
Of course, being a sane software developer, I do most of my
programming using editors that are suitable for software development.
Most professional carpenters use hammers for their nails, rather than
bashing them in with stones - it's the same thing, really.
And yet another, of more significance, if that after you've indented
a block, it may now merge into an adjacent block that was already at
that new indent. If you later need to revert that first block back to
it's original position, you'd better make sure you mark that boundary.
So mark the boundary. Add a blank line. Put a comment line
describing the steps of the function. You are making up problems for
which you already have good solutions that you would be using in any
programming language.
How about just fixing the ******* language? That must be better than a million programmers wasting time creating their own fixes.
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.
One thing I despised was the begin-end business in Algol60 and Pascal,
which has the same nuisance as braces in C-like languages.
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.
Your problem here is that you are obsessed with finding things that
you want to see as misfeatures, design flaws, or problems in other
languages
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.
- and then obsess about how you can find new ways to make it more
difficult to "work around" them.
Fortunately I don't need to work with them much. If I did, I would find
the means to make them tolerable.
Don't you ever just accept that a language is the way it is, and it is
perfectly useable that way?
Well, I used Fortran IV for a year. But presumably lots of people
weren't that happy with it as we've since had Fortran 77, 90, 95, 2008,
2018 and 2023.
It's not just me!
Or think that perhaps other people in the world know better than you
do about how they want their language to work? Has it never occurred
to you that the people behind a given language - such as Python -
considered various alternatives and decided that making it the way
they did was the best choice overall for the language they wanted?
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.
I'm not surprised that mere matters of syntax have low priority.
As Bjarne Stustroup said, there are two kinds of programming languages
- those that people complain about, and those that no one uses.
Funny, I can complain about lots of languages that I never use!
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
[...]
Think about why you bother to indent code in languages where the
compiler ignores such indentation anyway: it means you are expressing
the structure of code in two different ways, one via statement
brackets, and the other via indentation. This redundancy aids in
understanding that the code does what you think it does.
Python gets rid of this redundancy, by having the compiler take notice
of the whitespace and removing the statement bracketing symbols. So I
put it back, by adding statement bracketing symbols that the compiler
ignores.
You might find Bython useful.
https://github.com/mathialo/bython
(I don't, but you might.)
On Thu, 29 Aug 2024 18:44:35 +0200, Janis Papanagnou wrote:
Vim is an editor that has the most simple and also very powerful
indenting for well structured data and programs I've yet seen. (Not
mentioning its equally powerful other editing facilities.)
Vim is only good for text-editing, though
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.
It does, sometimes, need a bit more care, especially if you have lots of nesting.
(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.)
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.
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.)
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?
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".
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.)
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.
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.
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.
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?
On Fri, 30 Aug 2024 11:38:05 +0200
David Brown <david.brown@hesbynett.no> wrote:
Getting worked up about the way Python blocking works is about as
productive as getting worked up about the way English language
spelling works. There are countless other more useful ways to spend
your time - and certainly many more enjoyable ways.
Some people actually enjoy arguing on the Internet, y'know.
When there are a number of smart, experienced and educated people
involved in the decisions, "obvious stupidities" are extremely
unlikely. That's the point of involving multiple people and gathering
opinions from many in the field.
You may consider it as "unlikely" as you wish, but the fact is that
literal whitespace has been considered Obviously Stupid in the computer- programming world for so long that it was the subject of a joke re: JCL
in "Real Programmers Don't Use Pascal," published in 1983.
That's not to say that "considered Obviously Stupid" is the same thing
as "objectively wrong" - but if your argument is that all of this is on
equal footing as Just Opinions, discounting decades of established
opinion across the industry in preference to the opinions of the subset
of Python developers & advocates who believe in literal whitespace as Unambiguously Good rather gives the lie to that.
On Thu, 29 Aug 2024 21:27:36 +0200
David Brown <david.brown@hesbynett.no> wrote:
/All/ languages, except perhaps Bart's private language that is only
used by him, have their annoyances. I have worked at least a little
with a fair number of languages, and I've never seen one that I
thought was "perfect". But different people have different things
that the like and dislike about any given language.
So if you have the choice of which language to use (many programmers
do not), you pick one that has more things you like for the task in
question in comparison to the things you don't like.
Sure - but picking one that best suits your needs doesn't mean you
can't critique its annoyances/flaws. This team-sports mentality is just weird.
But it's important to understand that these are opinions - the
designers of Python were /not/ stupid to have made the language that
way. They just had different opinions from you, and the had a much
better basis for forming those opinions than you or I.
Yeah, well, your opinion that my opinion is just, like, my opinion is
just, like, your opinion, man.
On Thu, 29 Aug 2024 21:27:36 +0200
David Brown <david.brown@hesbynett.no> wrote:
/All/ languages, except perhaps Bart's private language that is only
used by him, have their annoyances. I have worked at least a little
with a fair number of languages, and I've never seen one that I
thought was "perfect". But different people have different things
that the like and dislike about any given language.
So if you have the choice of which language to use (many programmers
do not), you pick one that has more things you like for the task in
question in comparison to the things you don't like.
Sure - but picking one that best suits your needs doesn't mean you
can't critique its annoyances/flaws. This team-sports mentality is just >weird.
On 29/08/2024 18:44, Janis Papanagnou wrote:
On 29.08.2024 14:30, David Brown wrote:
On 29/08/2024 09:28, Muttley@dastardlyhq.com wrote:
[...]
Then don't use vim - use an editor that suits your needs.
LOL. (You appear to be joking. - If not, continue reading...)
I was not joking.
But what makes you think that his needs are not covered by Vim?
You seem to have missed the point - sorry if I was not clear.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Thu, 29 Aug 2024 18:44:35 +0200, Janis Papanagnou wrote:
Vim is an editor that has the most simple and also very powerful
indenting for well structured data and programs I've yet seen. (Not
mentioning its equally powerful other editing facilities.)
Vim is only good for text-editing, though
Again, L'D'O' is wrong.
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.
You should work to improve the things you can, instead of
wasting effort arguing with brick walls.
It's not your language, so there is no "vice versa".
Barring a few obvious stupidities, yes of course they were, and are,
smart people.
When there are a number of smart, experienced and educated people
involved in the decisions, "obvious stupidities" are extremely unlikely.
My impression is that your unconventional style indicates a relative
lack of experience in Python.
... put in so much extra
crap and silliness that readers get caught up in that instead of
noticing that most of the function is meaningless.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Wed, 28 Aug 2024 19:19:38 -0700, Keith Thompson wrote:
My impression is that your unconventional style indicates a relative
lack of experience in Python.
You think maybe I should practise by writing more Python code?
And you snipped the part where I acknowledged that might be an invalid conclusion. I have no opinion on what you should do.
OK, how about your thoughts on comparing this
for attrname in obj.tag_attrs :
attr = getattr(obj, attrname)
if attr != None :
if isinstance(attr, enum.Enum) :
attr = attr.value
elif isinstance(attr, Type) :
attr = unparse_signature(attr)
elif not isinstance(attr, str) :
raise TypeError("unexpected attribute type %s for %s" % (type(attr).__name__, repr(attr)))
attrs.append("%s=%s" % (attrname, quote_xml_attr(attr)))
out.write(" " * indent + "<" + tag_name)
with this
for attrname in obj.tag_attrs :
attr = getattr(obj, attrname)
if attr != None :
if isinstance(attr, enum.Enum) :
attr = attr.value
elif isinstance(attr, Type) :
attr = unparse_signature(attr)
elif not isinstance(attr, str) :
raise TypeError("unexpected attribute type %s for %s" % (type(attr).__name__, repr(attr)))
attrs.append("%s=%s" % (attrname, quote_xml_attr(attr)))
out.write(" " * indent + "<" + tag_name)
The difference is obvious: the second calls attrs.append() even if attr
is None. I don't know what point you're trying to make.
On Thu, 29 Aug 2024 18:44:35 +0200, Janis Papanagnou wrote:
Vim is an editor that has the most simple and also very powerful
indenting for well structured data and programs I've yet seen. (Not
mentioning its equally powerful other editing facilities.)
Vim is only good for text-editing, though.
It assumes a file is split into
lines. Emacs makes no such assumption, and can also edit non-text files.
On 29/08/2024 18:44, Janis Papanagnou wrote:
On 29.08.2024 14:30, David Brown wrote:
On 29/08/2024 09:28, Muttley@dastardlyhq.com wrote:[...]
[...]
Then don't use vim - use an editor that suits your needs.
But what makes you think that his needs are not covered by Vim?
You seem to have missed the point - sorry if I was not clear.
He complained that he didn't want to learn complicated macros in Vim
just to be able to indent or un-indent lines of code. The solution is obvious - he should use an editor other than Vim.
He could, of course, learn how to use Vim. It's a perfectly good editor
with a lot of features. [...]
There are more than enough decent editors to choose from, that cover the basic needs of programmers. Some people use one editor for everything, others use a range for different purposes - whatever suits you. But it
is pretty absurd to complain that it is difficult to indent code just
because you (i.e., Muttley) think it is hard to do in one particular
editor.
On Fri, 30 Aug 2024 08:14:21 -0700
John Ames <commodorejohn@gmail.com> gabbled:
[...]Sure - but picking one that best suits your needs doesn't mean you
can't critique its annoyances/flaws. This team-sports mentality is just
weird.
Some insecure people feel an attack on their favourite language is some kind of attack or slight against them personally. Its a pathetic and juvenile trait
that unfortunately is found a lot amongst IT types.
On 30.08.2024 04:53, Lawrence D'Oliveiro wrote:
Emacs makes no such assumption, and can also edit non-text files.
You have obviously no clue.
On 30.08.2024 21:20, Muttley@dastardlyhq.com wrote:
On Fri, 30 Aug 2024 08:14:21 -0700
John Ames <commodorejohn@gmail.com> gabbled:
[...]Sure - but picking one that best suits your needs doesn't mean you
can't critique its annoyances/flaws. This team-sports mentality is just
weird.
Some insecure people feel an attack on their favourite language is some kind >> of attack or slight against them personally. Its a pathetic and juvenile >trait
that unfortunately is found a lot amongst IT types.
It's not restricted to languages or IT-stuff; you can see it with
books or films or music or political or religious preferences...