nocman

Yeah, the main references I found to IVR systems and REXX were from IBM articles discussing IVR, and some open-source Asterisk-based systems using ooRexx that appear to have been created as an open-source alternative to IBM OS/2 IVR solutions that used REXX.

OS/2 is the primary environment where I had experience reading and writing REXX a long time ago. I was also aware of it being used in IBM mainframe systems, but I had no direct experience there.

> The Sealed-Bid auction should generate a price that is greater than or equal to the English Open Cry in all situations.

Not necessarily. In many sealed-bid auctions, bidders hope to win with a lower bid (often much lower) than they would if they were bidding against others in the same room. This is especially true if you have no idea whether anyone else is bidding on the item at all. I have placed very low bids on items in sealed-bid auctions for things I had no immediate need for, but would happily pay for if the cost was very low (and I have won many such items, sometimes because no one else even bid on them).

That makes perfect sense to me. I've never seen anyone use Rexx outside of an IBM-heavy environment.

Perl's reputation for this is entirely unfair, in my opinion.

I just opened up a random reasonably-large Perl program that I last touched over three years ago, browsed through the source, and I have absolutely no trouble telling what it does.

I don't think Perl code is any more difficult to revisit than code in most other programming languages are. I think the difficulty mostly rests with how proficient the developer is in the language, and how long it has been since they wrote any code in that language. If you are really rusty with the programming language, or you never really had a high level of proficiency in it in the first place, you are going to have a hard time revisiting the code no matter what language it is.

Of course, it will be harder if the code is not your own. Also, it depends a great deal on how well the code was written. There's plenty of garbage code out there, in any language you might use. And if it was garbage to begin with, it won't get any better with age.

JetBrains makes their survey data available here ( https://www.jetbrains.com/lp/devecosystem-2023/ ):

Based on my calculations from that data (extracting only the US responses, based on their entries for 'os_devenv', I get these numbers:

- Linux: 45% - Windows: 58.9 % - Mac: 51.2 %

That is conclusive enough for me to say that Windows is still the most common daily driver for developers in the US. I'm not one of those developers, as I don't use Windows as my primary development platform.

I suspect this may be a case where people tend to think that because most developers they know use a particular OS for development, that must be true everywhere.

I would not be surprised, for instance, to find out that the numbers of developers primarily using Macs at some big tech companies is much higher.

[edited for formatting]

fair point, however I suspect that if you narrow the scope of the data to the US (even the data from those surveys) it will not change the results much.

Out of curiosity, I'm looking for data that is limited to the US, and will respond with results if I find them.

> At least here in the US, the majority of developers daily drive macs on their desktop.

Not according to statista.com (I am not a registered user, but it looks like you could register for no cost, in order to check the source):

https://www.statista.com/statistics/869211/worldwide-softwar...

Windows is the majority OS for development, with Unix/Linux and Mac being close to equal, but both considerably less than Windows.

This is also consistent with the 2023 Stack Overflow Developer Survey (https://survey.stackoverflow.co/2023/):

Under the "Operating System" heading it says:

  "Windows is the most popular operating system for developers, across both personal and professional use."

[edited to include Stack Overflow survey]

> It’s a title, nothing more. It means nothing, because there is no legal certification process for any of this.

I believe I understand where you are coming from. However, that's not entirely fair. Most jobs have "no legal certification process", but that doesn't make their job title meaningless. Not everyone who wants to define what a title means is doing so to gain or assign clout, many just want to understand what a person with that title typically does.

Granted, there are some titles (especially in technical roles, in some companies), that tell nothing more than "that person works in I. T." (or whatever your company calls it). For example, I've seen roles called "Systems Analyst", that varied greatly in responsibility -- some where all the person did was code all day, some where the person almost never wrote any code. Sometimes that was two people in the same group at the same company.

So yes, titles can hold only a very small amount of meaning, at times, but that doesn't make them entirely meaningless.

not the parent, but 'everything' is a mostly unhelpful answer.

A few important concrete examples would be much more interesting. In fairness, you did somewhat, but I would be interested in some more details.

What do you mean "remember"? It still makes using the command line in Windows tolerable. And yes, I am familiar with PowerShell, and NO I'm not interested in using it.

I keep clicking on these 'MTA' articles expecting them to be about a "message transfer agent".

Then I think, oh, right, wrong MTA. Guess I've spent too much time dealing with email servers.

I heartily disagree. The differences are almost entirely non-cosmetic, IMHO.

I am fine with the "holy war" talk as long as it is just good-natured tongue-in-cheek fun (which it often is, in my experience). Often the stupidity of the jokes is purposeful, and is intended to be programmers poking fun at themselves almost as much as they are poking fun of their peers.

However, if someone, in all seriousness, says "you are just stupid or unskilled if you use X" (where 'X' is whichever editor you choose to use), well I'll just tune that out at the first opportunity.

Oh, I thought it stood for:

"Suffering A Massive Lot" - jk

Let's just say my interaction with managing websites that used SAML was less than pleasant.

Yeah, well, we all use things that we wish we didn't have to use.

Well, I wasn't arguing that the language is actually named ADA. I was just saying it seems like a common mistake.

Plus for some reason (not sure why, exactly), ADA looks more likely to me to be an acronym than JAVA does. Also, way more people are familiar with Java than Ada, and I'm sure the number of programmers who do not remember (or never knew) who Ada Lovelace was closely resembles the number that are unfamiliar with Ada the language.

> The holy war between vim and emacs is like a bunch of machinists arguing over whether they prefer a lathe, or an entire machine shop that also includes a lathe if you want it.

IMHO not really a fair comparison. There are signifcant differences in the feel and the workflow between using vim and using emacs in evil mode. Other people have preferences that differ from yours. I have many years experience using both vim and emacs (in evil-mode), and I see both sides. Don't get me wrong, emacs in evil mode is great, and I would not want to be without it, but it does not 100% reproduce the workflow of logging in to a terminal and editing text there in vim.

The differences are significant. I'm not saying the experience in emacs is bad, it's just different. If you already have, say, 10 years of muscle memory built up from using vim in a terminal, it will take a fair amount of adjustment to move to an emacs/evil-mode way of doing things.

I personally see no reason that I have to pick one or the other, and at present I spend a lot of time in both editors. I realize that would drive some people crazy, but I'm OK with my preferences being a little unusual.

Well, in fairness to them, one of the two books in the list spells it all caps right there on the cover.

The accounting people I know all hate Quickbooks (with an extra portion of hate for the online version).

"For you turquoise is blue" - no, for me turquoise is turquoise, but you did give me that as an option. Multiple times I thought to myself "I would not call this color blue or green, it is some variety of blue-green". So in my opinion that makes this whole test kind of nonsensical.

It depends totally on how you read it. In this case, my first thought after reading that was "play stupid games, win stupid prizes". There are plenty of people (especially on the internet) who actually do think that way -- by which I mean people that are serious when they respond with "you guys ruin all the fun" to others who bring up genuine concerns that will most likely have wide-sweeping ramifications.

Do you genuinely think the GP needs you to point that out to them?

I can't think of a single person I know that uses a text-only email client (and yes, I know more than one of them) who isn't what you'd call a "power user".

All of them know that most people don't use a plain-text email client, they just prefer to use one themselves.

Which has nothing to do with BNSF :-D

I'm not saying it is for everyone, or for every project. My point was that "Literate programming only works for small scripts and narrative documentation" is far too wide-sweeping of a statement. There are plenty of non-trivial examples of its use, and it obviously "works" for some people.

not true:

"This book describes pbrt, a physically based rendering system based on the ray-tracing algorithm." ( https://www.pbr-book.org/3ed-2018/Introduction )

and:

"This book (including the chapter you’re reading now) is a long literate program." ( https://www.pbr-book.org/3ed-2018/Introduction/Literate_Prog... )

Generally I hear that in reference to chromatic's book / blog posts:

http://modernperlbooks.com/

No, you are not alone.

Over 25 years of Perl experience. Still writing new stuff daily, both for work and personal use.

>The Linux kernel doesn't matter.

While I agree on the importance of "the history, philosophy, and purpose of the unix environment", saying that the Linux kernel doesn't matter seems a bit harsh at best. It seems to me that the Linux kernel is the most successful Unix-like kernel in the history of computing. It certainly matters for its ubiquity alone.

Thanks to reader mode I can read this article. When I opened the link the first time I just closed it immediately. I know they were trying to be "cool", but that was just horrible.

> I haven't been using it as my daily driver for almost 10 years now.

Is there some humor I'm missing there, or is that just a typo (and you meant to say "I have" )?

Out of curiosity, why bother to unmap the cursor keys? I don't ever use them in vim either, but is there something that is prevented from working with having them mapped in vim?