Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.misc > #11470 > unrolled thread

What’s Your Least Favourite Programming Language?

Back to article view | Back to comp.lang.misc

Contents

  What’s Your Least Favourite Programming Language? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-31 06:48 +0000
    Re: What’s Your Least Favourite Programming Language? David Brown <david.brown@hesbynett.no> - 2025-10-31 13:28 +0100
    Re: What’s Your Least Favourite Programming Language? John Ames <commodorejohn@gmail.com> - 2025-10-31 08:17 -0700
      Re: What’s Your Least Favourite Programming Language? bart <bc@freeuk.com> - 2025-10-31 22:47 +0000
      Re: What’s Your Least Favourite Programming Language? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-01 06:26 +0000
      Re: What’s Your Least Favourite Programming Language? BGB <cr88192@gmail.com> - 2025-11-03 14:05 -0600
        Re: What’s Your Least Favourite Programming Language? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-03 20:29 +0000
          Re: What’s Your Least Favourite Programming Language? BGB <cr88192@gmail.com> - 2025-11-03 14:55 -0600
            Re: What’s Your Least Favourite Programming Language? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-03 23:10 +0000
              Re: What’s Your Least Favourite Programming Language? BGB <cr88192@gmail.com> - 2025-11-04 12:02 -0600
                Re: What’s Your Least Favourite Programming Language? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-04 20:32 +0000
        Re: What’s Your Least Favourite Programming Language? John Ames <commodorejohn@gmail.com> - 2025-11-03 15:56 -0800
      Re: What’s Your Least Favourite Programming Language? Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-27 21:11 -0300
        Re: What’s Your Least Favourite Programming Language? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-28 04:42 +0000
          Write Once, Run Anywhere (was Re: What’s Your Least Favourite Programming Language?) Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-28 16:43 -0300
            Re: What’s Your Least Favourite Programming Language? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-28 22:37 +0000
              the history of Java in Android (was Re: What’s Your Least Favourite Programming Language?) Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-28 20:27 -0300
                Re: the history of Java in Android (was Re: What’s Your Least Favourite Programming Language?) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-29 01:30 +0000
                  Re: the history of Java in Android (was Re: What’s Your Least Favourite Programming Language?) Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-29 15:24 -0300
                    Re: the history of Java in Android (was Re: What’s Your Least Favourite Programming Language?) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-29 21:57 +0000
              Python deliberately breaking backward compatibility (was Re: What’s Your Least Favourite Programming Language?) Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-28 21:03 -0300
                Re: Python deliberately breaking backward compatibility (was Re: What’s Your Least Favourite Programming Language?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-28 18:10 -0700
                  [meta] Date-formats in postings (was Re: Python deliberately breaking backward compatibility (was Re: What’s Your Least Favourite Programming Language?)) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-29 06:39 +0200
                Re: What’s Your Least Favourite Programming Language? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-29 01:42 +0000
        Re: What’s Your Least Favourite Programming Language? John Ames <commodorejohn@gmail.com> - 2026-08-28 09:59 -0700
    Re: What’s Your Least Favourite Programming Language? Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-27 20:09 -0300

Page 2 of 2 — ← Prev page 1 [2]

#11850 — Python deliberately breaking backward compatibility (was Re: What’s Your Least Favourite Programming Language?)

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>>> On Thu, 27 Aug 2026 21:11:55 -0300, Kragen Javier Sitaker wrote:
>>>> the Python maintainers have adopted a policy of deliberately
>>>> breaking standard library backward compatibility in every point
>>>> release.
>>>
>>> In what way?
>>
>> They call it “removing dead batteries from the standard library” ...
>
> So they don’t want to keep accumulating legacy baggage that just adds
> to the ongoing support burden.

Yes, that is their motivation for adopting the policy of deliberately
breaking standard library backward compatibility in every point release.
However, their motivation, understandable though it is, is irrelevant to
my point, which is that as a result of this policy, Python has, in
practice, gone from being one of the *most* portable languages to one of
the *least*; you can’t even reliably run a Python application you wrote
on Ubuntu 25.10 (Python 3.13) on Ubuntu 26.04 (Python 3.14).

In Python 3.14, the list of things removed to deliberately break
backwards compatibility in it is relatively small; it includes ast.Num,
asyncio.FastChildWatcher, pickling itertools iterators,
`pty.master_open()`, and sqlite3.version.  And they’re changing the
default start method of `multiprocessing` from `fork()`, which usually
won’t crash people’s code but will introduce massive performance
regressions in some cases.
<https://docs.python.org/3.13/deprecations/index.html>

> Every open-source project does that.  The key is to support the
> important stuff that people care about.

In some sense, this is obviously true, but there are enormous
differences of degree.  The current Python policy is way down at the
gratuitous-instability end of the spectrum.  JavaScript, by contrast,
still supports `with`, and glibc still supports `gets`.

> Does anybody still want to use the “cgi” module?

Yes.  Although CGI was pretty costly when it went out of style in the
01990s, hardware has improved dramatically, and CGI can now handle half
a billion hits per second on one server
<https://jacob.gold/posts/serving-half-billion-requests-with-rust-cgi/>
which is enough for all but the biggest public websites.  CGI is a
relatively low-tech, simple interface that is extremely widely supported
by web servers.  For cases where the Python startup overhead is killing
you, even on current hardware, you can use the `cgi` module with FastCGI
<https://www.asmallorange.com/help/article/aso-using-python-with-fastcgi>.

Nowadays, hardware is so fast that the CGI execution model has seen a
huge resurgence, mostly using a slightly different interface from the
original CGI — they call it “serverless” now.

I have three or four CGI scripts written in Python that I’ve been using
for many years without having to maintain them.

The `cgi` module probably should not have been added to the standard
library in the first place — its interface is kind of error-prone and
clumsy.  But, having been added, it should not have been removed.

In addition to `cgi` they also removed `cgitb`, which was an invaluable
aid to debugging Python programs that had nothing to do with CGI or the
Web; simply by running

    import cgitb; cgitb.enable(format="text")

at the beginning of program execution, your stack traces include the
values of local variables, which is very frequently enough to make bugs
trivial to track down.  I assume the Python maintainers removed this
functionality because they didn’t know about it.

> Sun “au” file format?

Yes, obviously?  There are plenty of audio data files from 30 years ago
in .au format.  If you have an existing Python application that can read
them, how is it beneficial to break it?  Was there a lot of maintenance
load involved due to the rapid changes in the .au file spec?  Moreover,
users of such an application would suffer even if they don’t have any
.au files — the application will crash at startup with an ImportError,
because it foolishly used the standard library support for the most
popular audio file format.

> A Unix password encryption library that doesn’t keep up with current
> password encryption formats?

This one I’m more skeptical of the importance of.  But your other two
examples are obviously egregiously bad.

Kragen

[toc] | [prev] | [next] | [standalone]

#11852 — Re: Python deliberately breaking backward compatibility (was Re: What’s Your Least Favourite Programming Language?)

Kragen Javier Sitaker <kragen@canonical.org> writes:
[...]
> Yes.  Although CGI was pretty costly when it went out of style in the
> 01990s, hardware has improved dramatically, and CGI can now handle half
[...]

Why do you write years like this?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#11855 — [meta] Date-formats in postings (was Re: Python deliberately breaking backward compatibility (was Re: What’s Your Least Favourite Programming Language?))

On 2026-08-29 03:10, Keith Thompson wrote:
> Kragen Javier Sitaker <kragen@canonical.org> writes:
> [...]
>> Yes.  Although CGI was pretty costly when it went out of style in the
>> 01990s, hardware has improved dramatically, and CGI can now handle half
> [...]
> 
> Why do you write years like this?

Some brainstorming...

Anticipation of potential "Y10k issues".[*]
Prevention of presumed misinterpretations of his posts.
Fostering non-standard formats; a still quite common habit.
Showing an individualistic peculiarity as Usenet poster.
Naive(?) believe that someone would gain something by that.
Spreading confusion to distract from the contents of the post.
Making it harder for AI-bots to extract semantics from posts.
Keeping communication busy for self-purpose or citation counts.
A religious convention. (Maybe from the Pastafarianism? - IDK.)
Aggravating the pedants as well as all the "normal" people.

Just a few random thoughts. - My guess is that it's #4.

Janis

[*] In that case we should of course consider that the world
(unless already ended before[**]) might exist yet longer[***],
so even five digits for the year might not suffice.[****]

[**] 
https://en.wikipedia.org/wiki/List_of_dates_predicted_for_apocalyptic_events

[***] Ignoring a human race's factual self-genocide that may
end the story even a lot earlier.

[****] To be about safe, and not overestimate the statistical
factors (impacts etc.), I'd suggest to use at least 9 digits
for the year.

[toc] | [prev] | [next] | [standalone]

#11854

On Fri, 28 Aug 2026 21:03:13 -0300, Kragen Javier Sitaker wrote:

> However, their motivation, understandable though it is, is irrelevant to
> my point, which is that as a result of this policy, Python has, in
> practice, gone from being one of the *most* portable languages to one of
> the *least*; you can’t even reliably run a Python application you wrote
> on Ubuntu 25.10 (Python 3.13) on Ubuntu 26.04 (Python 3.14).

I seriously doubt that. They only remove legacy stuff after a long
period of deprecation.

> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>>
>> Does anybody still want to use the “cgi” module?
>
> Yes. Although CGI was pretty costly when it went out of style in the
> 01990s, hardware has improved dramatically, and CGI can now handle
> half a billion hits per second on one server
> <https://jacob.gold/posts/serving-half-billion-requests-with-rust-cgi/>
> which is enough for all but the biggest public websites.

But it still suffers from the same old limits. No serious web
developer would want to use it (or even “higher-performance”
equivalents, like FastCGI) nowadays.

> I have three or four CGI scripts written in Python that I’ve been
> using for many years without having to maintain them.

>> Sun “au” file format?
>
> Yes, obviously?  There are plenty of audio data files from 30 years ago
> in .au format.

Leave it to purpose-built tools like FFmpeg to handle conversions on
such old formats. They’re easy enough to invoke from a Python script,
if you really need to get Python involved.

And what about the others? aifc, chunk? asynchat, asyncore? nis,
xdrlib? spwd? msilib, anybody?

[toc] | [prev] | [next] | [standalone]

#11841

On Thu, 27 Aug 2026 21:11:55 -0300
Kragen Javier Sitaker <kragen@canonical.org> wrote:

> > Another language that feels needlessly gross and tedious is Java -
> > (...) but then it's somehow still the best solution we've got for
> > write-once-run-anywhere development, which is maddening :/  
> 
> I think that may have been true around 02001, when J2ME could run more
> or less normal Java code on *all kinds* of fairly small feature
> phones. But it never made the leap to smaller microcontrollers like
> the AVR, feature phones evaporated, feature-phone-sized micro-
> controllers never acquired J2ME support, and now in 02026 we have a
> number of better solutions: C under Unix, portable C, Rust, Python,
> JavaScript, Wasm, Godot, and Golang.

Yes, things didn't quite go according to plan for them in the long run.
I s'pose I should clarify that I was thinking of write-once-run-
anywhere more in terms of GUI development and redistributable binaries;
it's true that C/stdlib is about as portable as it gets, and C/POSIX
very nearly so, but that takes a separate build step for every target
platform (and in the freenix world, every change in the ABI.) Which is
certainly possible provided the application is open-source, but would
be nice not to *have* to do. And once you get the various GUI toolkits
involved, the problem becomes even worse :/

Java, on paper, promised a nice solution to that problem, and for a
brief moment it even looked like a viable one; unfortunately, it went
astray pretty quickly, and never recovered. More unforunately still,
nothing since has really filled the same niche, and so it's still the
best we've got in that regard...which, yes, is maddening.

(Also: 02026 = 1046? My condolences on the loss of Bishops Gerard and
Bestricus...unless you're rooting for Vata & co.)

[toc] | [prev] | [next] | [standalone]

#11834

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> The most popular answer was JavaScript, with 4 votes. There were 2
> votes for PHP, and one each for Lisp and Python.

This sounds like a pretty small number of votes.  Back in 02017, before
descending into racketeering and criminal copyleft violation, Stack
Overflow wrote a post about “the most disliked programming languages”:
<https://stackoverflow.blog/2017/10/31/disliked-programming-languages/>

This was based on each user account adding tags to “liked” and
“disliked” lists.  The proportionally most disliked (over 15%) were:

- #perl
- #delphi
- #vba

And then, far behind those, between 5% and 10%:

- #php
- #objective-c
- #coffeescript
- #ruby

Nothing else was really close, although the C# confidence interval does
barely overlap 5% from below.  Python was down around 1.5% dislikes.

> One mentioned COBOL (which for him was worse than Fortran), but nobody
> thought of BASIC. I guess that is now so far in the past, many among
> the interviewees wouldn’t even have any memories of using it ...

I didn’t think it was controversial that COBOL was worse than Fortran?
VBA was #3 on SO’s list.

Kragen

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.misc

csiph-web