Simplicity of IRC | Hacker News Reader

Simplicity of IRC

susam.net

364 pointssusam244 comments

A number of moons ago, I switched from a company that used IRC for its internal, real-time, ephemeral communication needs to an enterprise shop that used Microsoft Teams to do that (and of course other communication stuff, as the boundaries for what was better kept in Sharepoint, Confluence, Email/Exchange, the legacy Wiki, and/or Teams were never quite clear :)) there.

In the old shop, we eventually had all kinds of important subsystems hooked up to our internal IRC server: Monitoring and alerting. Source control and Wiki activity. The deployment pipeline. Ticket activity reports. All these services were pretty much effortlessly set up to provide useful, real-time status information broadcast to topic-specific channels users could idle in. Everyone could stay informed on topics of their interest, in real time, with no barrier to entry. It was really good, and the implementation completed in a few hours total, for all use-cases, due to irc's incredible simplicity.

Due to the benefits I had reaped from that setup before, I tried to implement parts of it on/for the MS Teams platform at the then-new job. Getting the Teams Python SDK to implement a bot-like entity running alone proved to be a days-long ordeal, and whatever followed wasn't much more pleasant.

In the end, we let someone set up two email-to-teams-channel-forwards which kinda worked, but suffered from obnoxious, multi-minute relay delays.

As a consequence of the tedious bringup and the latency shortcoming, the "effortless notification" initiative never really got traction.

Not only because of this particular experience I am a firm believer that software/system simplicity is a virtue that can neither be overstated in importance, nor substituted by anything else.

I once needed to create a bot that sent notification and I just used the webhook feature in a Team channel. Not defending Teams though, it is a horrendous piece of software.

Maybe that wasn't possible/enabled for our particular deployment (that was in the IT dept. of a big European bank), as we had what I've been told was a strange bastardization of O365 and other MSFT services - a mix of on-prem and cloud services unlikely to be found elsewhere.

At any rate, for the IRC server at the shop I was at previously, I had "webhook" support/a http(s)->irc gateway implemented on my own in much less than an hour via CGI ;)

Isn't your comment then very specifiy for that installation of yours? When you use MS Teams in a "normal" O365 environment, then every feature you described for IRC is possible with weebhooks and the cards API. Simple CURL based integration.

I will second with another anecdote at mega corporation - Teams is entirely locked down and any of the useful integration points are disabled.

Same with slack webhooks. I make custom software and everyone wants slack webhooks and they are pretty easy to implement and people love them.

The integrations are a neat trick, but often end up spamming a channel where people are trying to communicate.

Teams seamlessly works across platforms, and mobile with video chat, files, outlook integration, and screen sharing. Maybe IRC could of been that, but it never happened.

There are nice IRC clients out there. I don't use them and I haven't used them in a group, because even in programming language communities many have moved to Discord/Slack, but I would prefer working with multiple simple tools than a monolith, different tools for different uses, and glue them together when needed (it doesn't need to be complicated, and if it is, than some additional effort is justified)

If you look at these communities, there is basically only one feature of Discord/Slack that they use that IRC does not easily provide and that's ephemeral/mobile. If I go offline for an hour in IRC, I lose a bunch of messages unless I've done some backflips to set up some kind of archiving/replay in a separate failure domain (e.g. znc running on gcp). With chat services, the service is essentially znc for free.

The rest of the shift is explained by discord being popular for other use cases (e.g. as a twitch companion), overwhelmingly dominated by younger users. IRC isn't getting new users and over time, this means the community will migrate due to turnover. Thank god we at least have things like matrix bridges, but discord is a lost cause.

I think the latter argument is 90% of the reason. Too bad this new generation doesn't have an opensource base of software to work with, or rather somehow didn't get acculturated to the existing one. Actually, that's probably because there were those few "killer features" such as offline messages that the existing systems didn't have.

There are web front-ends to IRC that can mitigate message loss without having to run bouncers. Convos [1] and TheLounge [2] come to mind but there are others [3]

[1] - https://convos.chat/

[2] - https://thelounge.chat/

[3] - https://www.ilmarilauhakangas.fi/irc_technology_news_from_th...

It did happen, though. Just not in the same way. When it gets to the point where notifications are too spammy, it's very very easy to direct things to use a different channel and it works at huge scale. Anyone who uses IRC more than casually via some web portal is capable of being in more than one channel at a time. Google SRE still uses IRC internally specifically because it always just works and does what people need it to do.

One of the downfalls of IRC is the notion that everything should happen in the chat. There's no reason you can't have a pastebin and a file server and screenshot sharing service, most of which don't matter anymore after 5 minutes anyway. It works really well and in fact, we kept using them after switching to fat chat because it was a better experience. There are reasons to want a fat chat client (primarily mobile, imo), but having used both for many years, the featureful chat client ends up being worse than just sharing links most of the time.

I find that the "fat" clients encourage bad behavior that IRC used to allow people to handle independently. Examples:

* bot spam that I can't /ignore

* "inviting" people to channels tht you can't opt out of (invite is slack terms is yank. there is not option to say no)

* inline sharing of screenshots of article snippets that support an argument but not sharing links to the source material

* so... many... channels...

> so... many... channels...

To compound the problem of many channels the UI uses an insipid three column layout. I like to arrange chat windows, tail -f terminal windows, and other monitoring things in a "dashboard" layout in a workspace. That way it can update in the background and if I am curious about the state of something I can decide to context switch and bring up that workspace to get an update. I can then deal with an issue or go back to the task at hand.

Slack and HipChat and all the other Electron-based attention siphons do not let me arrange their UI in a way that works for me. I hate notifications with the heat of a thousand suns and turn just about all of them off on all my devices. Slack et all hide the state of all but one channel by default and want to use notifications or stupid icons to show there's unread activity. It's the worst UI on the dumbest system but animated emojis!

Teams is by far and away the worst UI of any chat system I’ve used.

I get why it’s designed the way it is, it’s trying to be Sharepoint, Slack, Zoom and Outlook. And as a result it does every single one of them worse.

Sometimes integration is better left as event handlers rather than trying to make IRC behave like a Wiki.

Yea, but it works cross platform and on mobile. With the ability to carry voice connections from one to the other. Or even switch from wifi to mobile data without dropping. Even view people sharing their screen from mobile. For large teams and businesses I haven’t used anything better yet and we’ve gone through a lot over the years. Also Teams has met some strict Infosec reqs we need for mobile.

I cannot comment on the switching between WiFi and data aspect because I’ve not tried that myself (though it didn’t work on my MBP switching between Ethernet and WiFi) but everything else you’ve described is pretty standard features for video conferencing solutions these days.

I’d like Teams more if it just focused on the video conferencing side of things. It’s chat and Sharepoint integration just adds more frustration than anything.

Seamlessly going from a chat about a problem, to a video meeting, to screen sharing, to sharing files, and then continuing the conversation on mobile, to scheduling a teams meeting later in the week to follow up and fully integrated into outlook is what I’m talking about.

Which is fine if your chat UI doesn’t totally suck for 99.9% of the other use cases. I’d readily take the additional pain of switching applications if it means I don’t have to deal with Teams for chat.

Also all video conferencing and chat applications support sharing files. This isn’t some unheard of feature that Microsoft have pioneered. It’s been possible since the BBS days. It’s possible in XMPP and IRC. It’s possible in every other commercial service I’ve used. And I happen to think Teams does it the worst out of everyone of them because of the weird UI decisions and Sharepoint integration. Compare Slack to Teams and you see what I mean. Files are in lined in Slack and it’s easy to preview and work with them. It’s a pain in the arse in Teams. Slack also has all the other features of Teams that you’re boasting about. And Slack isn’t even perfect itself yet it still runs circulars around Teams in terms of usability.

Literally the only thing Teams gets right is the way of marking the confidentiality of shared content. But that doesn’t justify the mess Microsoft have made of Teams UI.

I’m not one of these FOSS evangelists who throws their toys out of the pram if we don’t use IRC. But Teams UI is really just a clusterfuck of bad design decisions. It’s easily the worst designed solution out there. Except maybe WebEx - which is a pretty fucking low bar, scraping the barrel really.

Microsoft know they automatically win the enterprise because of AD and Office integration. So they don’t need to compete on quality. They just need to be present.

You’re complaining a lot about the UI which is perfectly usable. The mobile app is especially nice. I can carry a meeting from my phone to my desktop without skipping a beat. They are constantly adding features and polishing, but already meetings with hundreds of people it handles no sweat. Yes the app is relatively new compared to slack but improving quickly, for example the last update - https://techcommunity.microsoft.com/t5/microsoft-teams-blog/...

“Usable” isn’t acceptable when every other solution is intuitive. I don’t just want something “usable”, after 30 years of research in GUI design I expect something better than just usable from one of the largest software developers in the world.

And this is why myself and others keep saying Teams is garbage. Why settle for something that is only just barely usable when there are a dozen other solutions on the market that are highly intuitive.

I’ve lost count of the number of textual messages I’ve missed in Teams because of the appalling way groups are handled. Or the number of lost conversations because video chat conversations are blended into private 1:1 chats. It’s a fucking mess of an interface. Literally everyone else does it better.

> The mobile app is especially nice.

I couldn’t give a crap about how nice the mobile app is when 99.99% of the time I’m chatting and running meetings from my laptop. I want MS to produce a 1st class productivity tool, not TikTok.

> They are constantly adding features

I don’t want new features. As I mentioned at the start, Teams already has too many features. I just want the core user experience not to suck.

> but already meetings with hundreds of people it handles no sweat

Yet text chat between people sucks and I (like 99% of Teams user base) spend more time messaging people than we do in video conferences for 500+ people.

Your shilling here really does demonstrate just how much Microsoft have swung and missed imo. Both you and Microsoft have completely lost touch with the kind of usage that most people actually need Teams to be good at. I mean yeah, some of the features you’ve described are handy in niche situations but if the average use case is appealing (and it really is in Teams) then you find yourself lusting after other solutions most of the time.

Case in point: At my company I literally pay for Slack despite also having Teams around just because Teams sucks so badly for anything non-video. I guess we could use IRC for free but Slack has better support for in lining files (better than Teams too), better support for Markdown (better than teams too), better search in chats than Teams, better ways of organising conversations. And it’s a thousand times easier to read conversations too. It’s just better in every way for messaging. And with huddle support, it’s also not better than Teams for quick voice chats too.

And if I had to drop Slack then I’d switch to Discord, IRC, XMPP or literal anything before being stuck with Teams for all our non-video communication.

You call me a shill and then say you’d switch to IRC over teams. IRC has no features compared to teams - screen sharing, voice/video, threaded discussion, calendars, a mobile client with all these features, etc..

This implies you don’t really care about capability at all. You have some beef with Microsoft where you’d rather have nothing than something to avoid using a product you have a irrational bias against.

> You call me a shill

No, I said you were shilling. I don’t think you’re a shill but your posts are definitely shilling the product

> and then say you’d switch to IRC over teams.

For text chat. Yes. I also said that was an extreme case however IRC is still more intuitive than Teams for text chat.

> IRC has no features compared to teams - screen sharing, voice/video, threaded discussion, calendars, a mobile client with all these features, etc..

Have you even read a single bloody thing I’ve posted? How many times have I said I don’t give a crap about mobile support because 99% of my usage is on a laptop? How many times have I said that Teams suffers from having too many features rather than doing one thing well.

It’s like talking to a brick wall…

Also I did say IRC specifically for text chat.

> This implies you don’t really care about capability at all

You’re conflating comparability with feature bloat.

I’m all for comparability as long as it doesn’t harm usability. But comparability can be in the form of supporting 3rd party API hooks - it doesn’t have to mean bundling every feature into a confused user interface.

This is where the UNIX philosophy comes in: everything in UNIX is compatible with each other but each individual program is designed to do only one thing and do it well.

Now I’m not saying we should have separate video conferencing, calendars, text chat, etc. However in the case of Teams it suffers from trying to do everything. It’s the “Jack of all trades, master if none”.

So naturally I will use a program that specialises in a specific area well if it improves my productivity. For me using a better text chat solution improves my and my teams productivity vs using MS Teams for everything.

> You have some beef with Microsoft where you’d rather have nothing than something to avoid using a product you have a irrational bias against.

Enough with the name calling. There’s no need. Especially when the issue here is your own reading comprehension.

I’ve given clear reasons why I don’t like Teams. You obviously disagree, which is fine. But at least read my comments before replying with your ridiculous bullshit. “Ridiculous” because you’re consistently citing examples of stuff I’ve already discussed as not a requirement in literally the previous post. Which you’d know if you’d bothered to read my entire posts properly.

> You’re complaining a lot about the UI which is perfectly usable.

Usable is in the eye of the beholder.

Usable as in "I can get a video call going and can send chat messages and files": true.

Usable as in "Easy to use, frustration-free to use, easy to discover functionality": false.

It's an incredible slow application for chat. I don't particularly care if it's just bad programming or an overuse of animations, but it shouldn't feel slow on a beefy computer. Mobile is even worse on a midrange android.

No easy way to quote or forward messages, the stupid distinction between teams channels that have threaded messaging and chat that doesn't, intermittent problems loading images; I could go on for hours.

100%, the fact that you can literally pipe some data in a command-line IRC client is 1000x more conducive to such tweaking than using custom APIs/SDKs

long live the Unix model!

Doesn't that mean you get a channel join/leave for almost every message?

It is possible to post a message without joining if the channel has -n set (not the default for the obvious reason).

So clients can read lines from a pipe as stdin.

I don't see why you couldn't do the same in a Slack command-line program as well? Not hard to find simple examples of that.

https://github.com/csabapalfi/slackcat

I think the op meant on the protocol level, not client. You can literally do `cat mycommands.txt > /dev/tcp/...`. IRC is pretty simple, I remember using telnet just for fun to connect (also the PING message replies are annoying to type yourself) and at one time, (ab)used an FXPable FTP server data port trickery in ASCII mode to send a message to a channel.

Due to its simplicity I could see its application as a falback for global communication downtime/outages (as we had with FB/Insta recently).

Due to its simplicity I could see its application as a falback for global communication downtime/outages

I remember when the solution to this, when everyone was still working in an office, was "pair of netcats".

Slack has made using their API much trickier over time: getting a token to post these days (officially) is under the control of the server admin (as one needs to add a "slack app" to get one). One can extract a token and some cookies from a web browser slack session still, but it's not as clean as it used to be (where one could just generate account associated tokens that didn't randomly expire).

In other words:

- to use the slack APIs, you probably need company level buy in _before_ any code is written against the API from IT folks

- in contrast, with IRC one could just try something out and at some point in the future _maybe_ create a seperate IRC account for it, if your IRC server even has logins enabled. If it doesn't, which when I worked for IBM was the case, one can just pick a new username for the IRC bot.

Beyond that, (a) implementing enough of the IRC protocol to support simple bots isn’t that hard, and (b) there are already IRC protocol implementations everywhere.

I tend to agree. I have the same reservations with HTTP2 to a lesser degree. I won’t deny that the complexity added by HTTP2 will greatly improve speeds in certain cases, and this may very well be needed to keep the greater interwebs working at comfortable speeds moving forward, but a part of me is greatly saddened by losing the sheer simplicity that is HTTP1.1.

Are we going to lose the simplicity of HTTP/1.1? I think that would only happen when we get servers that support only HTTP/2, and I hope those will be limited to hobbyist use for a while yet.

gRPC servers, which are increasingly common and certainly not a hobbyist thing, are http/2 only.

the problem is that HTTP2 mostly does not bring the expected advantages that connection multiplexing promised, as HTTP/1.1 connection multiplexing over multiple tcp sockets are in many cases better performance wise. Only HTTP/3 with QUIC addresses this, so I have mixed feelings about HTTP/2.

I've not used teams, but both slack and Google chat make it very easy to post messages, a simple curl call has often been more than enough in lots of scripts

That is, unless the enterprise has policies to abide by disallowing API calls, in which case you're stuck with the official client and vetted integrations.

Same for mobile, the advantage vanishes once enterprise requires your (usually personal) phone to be surrendered to corp IT via MDM (which I sure as hell won't do).

The whole value proposition of Slack and Teams for their customers is control.

Would IRC even work in that nameless enterprise?

IRC might be run by engineering there for themselves. 3rd party chat would got through procurement and be provided by IT for the whole company, and after the last SOC2 audit, they had to lock it down.

Technically, yes. In real life, no.

I don't even blame such enterprises because most of the time it comes from regulations or outside policies that customers mandate, something like all enterprise data (and thus communication) has to be firmly under control of the enterprise with hard guarantees, otherwise you just don't get to work with those customers. So you get a locked down Slack/Teams, and the email+calendar system disallows any native app unless the device is MDM'd, and even that is only with first party clients such as the Gmail app or Outlook.

TBH I think most companies are trying to do their best there, but they're stuck with some kafkaesque liability system.

What's more "under control of the enterprise" than a self-hosted IRC server?

It doesn't prevent clients from logging communications in that server. I know the same is possible in slack or teams, but they don't consider that from a legal perspective.

From a legal, practical and technical perspective, any window displayed on any screen is equally succeptible to logging. I can't imagine the fact that the company disabled ctrl+c in the policy settings making any difference in a liability case.

*print screen and phone cameras.

> I can't imagine the fact that the company disabled ctrl+c in the policy settings making any difference in a liability case.

Taking reasonable measures absolutely does absolve the company. At that point, it becomes a rogue employee who’s deliberately circumvented policies and technical enforcements, who is now potentially personally liable.

It’s garbage, but hey ho.

Fair enough, they did "try", but still feels equivalent to putting sensitive documents in a glass frame with a "no photos please" label on it and then claiming you did everything you could to protect them. I can't imagine that would fly in court, but I guess as soon as computers are involved, all common sense is lost.

Also legal: doing it in house it's on you vs being a Slack feature means it's on them. CYA by outsourcing.

And consider this also: "hey we're quite sure pur homegrown system is as leak proof as it can be, trust us or fire up an audit team for 5 sprints to asses compliance" vs "Slack has the box checked already"

The fact that folks can e.g technically fire up a headless browser and programmatically interact with the app via capybara or whatever to rebuild a makeshift API, or just take pictures with their phones because the compliant system is inconveniencing them daily is immaterial.

that's really funny. because i did this for CYA reasons.. with different methods, but mostly with screenshotting or autohotkey stuff.

> That is, unless the enterprise has policies to abide by disallowing API calls

...What?

Welcome to enterprise, where breaking things is a feature so commonly used Microsoft has documentation for it [1] and things are often deployed by people whose sole concern is "minimize attack surfaces". Our Teams installation not only disables API calls (official Teams client only), chat sessions are deleted if no one posts to them meaning most chat history is lost every weekend.

[1] https://docs.microsoft.com/en-us/office365/troubleshoot/acce...

Microsoft uses these anti-features as a selling point, and in a large enough organization, it's not immediately clear who turned them on or who can turn them off.

What a perfect way to describe the situation.

Imagine an enterprise disallowing all VCS service providers -- whether hosted on-prem or cloud -- because they use SSH instead of HTTP.

You think you're joking but I've lived through exactly that. Reason: SSH cannot be examined by a HTTP proxy. The moment we raised that HTTP CONNECT is a TCP passthrough thus equivalent we got to install a bespoke root certificate on our machines for the proxy to MITM every single connection.

Yep. Sounds like a common-enough pattern then. (I wasn't joking in my post).

If the official client can still post and receive messages, what's preventing anyone else from doing it in the exact same way...?

Or is this something stupid like a user-agent check?

> Our Teams installation not only disables API calls (official Teams client only)

Wait? Can you even make API calls to Teams without getting the account owner to make a key for you? I’ve been looking for a way to use a personal key or credentials to make some calls, but the docs are absolutely impenetrable.

It's self-evidently false that the whole value proposition of Slack is control. The value proposition is, obviously, "IRC but more stuff, with searchable, durable messages". Which is why all sorts of groups that don't care about control at all still use Slack, rather than IRC, to coordinate.

Modern apps have modern requirements like better security. Better UX, quality and security beats dev convenience every time.

I find Matrix a fine substitute for IRC. Very simple to write clients and bots for. And you get modern features IRC either lack or does not do well.

In my experience, Teams has been a terrible alternative to most every option out there, including IRC. The entire UI/UX seems like an afterthought at best.

Agree - it's just Microsoft buy-in at this point. Every product from Office 365 to Teams to just Windows itself is suffering.

To think people build their businesses on this is mind boggling.

I think it is unfair / nonsensical to compare Teams (or Slack or Discord) to IRC. IRC is an open protocol for creating chat networks, not a desktop client. The user expierence from IRC could differ vastly depending on which client you use (mIRC, xchat, irssi...). But it shows how in todays world we create this silos/islands of proprietary solutions that are not inter-operable.

GP is comparing the integration experience and API layer.

With your IRC system, how did you deal with channel history, i.e. seeing messages that were delivered to the channel while the user wasn't there, something that slack and teams does well?

I'm not the OP, but the usual method is that everyone runs an irc client in a screen on a server that they SSH into from their workstation.

I did this years ago and this was indeed one way to do it (apparently still is)

I can confirm that I use this method. It works.

I have a possible thing I discovered recently that you might like (especially if the machine you leave screened is on your home LAN): https://tailscale.com/ has a free tier that lets you pretty trivially set up a VPN (with separate DNS and everything) from anywhere, to anywhere (and the name resolves correctly from anywhere as well). Avoids having to map ports etc. Anyway I've been playing with it and it's a neat toy at least, for sure, being able to access anything in my network from anywhere without having to manage port-mapping at my router, etc.

I'm actually going to use it to set up my own cloud dev I can access from anywhere, but it has tremendous utility beyond that

We had an internal instance of ZNC for human users to connect their clients to (at their option - but that was the documented and preferred way of getting onto the IRC network). Creating ZNC user profiles was part of the semi-automated onboarding/setup procedure, whilst ZNC authentication was done against the dovecot IMAP/SASL server we had for email. More casual IRC users in the company (marketing etc.) usually preferred to use an intranet-hosted web application (The Lounge) to access it from their browser, while most IT people had native clients of their choice set up (hexchat, irssi, etc.). Worked well.

Thanks, I was inspired by your post and looked at irc servers. The main problem, vis-a-vis slack, was the channel history. There are modules but they have timestamp and limit problems. And irssi in gnu screen would only work while screen is running and would only work for those happy with the setup. ZNC, although sadly adding more complexity, seems to be the way to go.

> There are modules but they have timestamp

You need a client and bouncer (or server, if you connect directly) that supports this extension: https://ircv3.net/specs/extensions/server-time

> and limit problems.

ditto, but https://ircv3.net/specs/extensions/chathistory if I understand you correctly.

ZNC has its own issues. We had a repeatable crash that happened every time a particular user connected (it took us a while to figure that out).

Sure, most software projects and products have their share of flaws and bugs :)

I do not claim ZNC or our whole IRC setup was perfect, but for me and many others, it did a very decent job of providing effective, no-frills, getting-things-done means of communicating, all while consuming little resources on both server and clients, and being simple, underestandable, and easy to hook other software into.

I really miss it, and personally dislike (especially the client UX of) most trendy/recent alternatives.

We had a similar thing going, people could set up a packages znc bouncer but the general rule was to assume everything was pretty much ephemeral to anyone not there. the best part to me about irc rooms is that they are allowed to be considered ephemeral, just like hallway talk and coffee breaks.

If something comes of the discussion. Update docs, post the chat log in the wiki, send an email with cliff notes and ask if others care to discuss, halt and get the right people in the room.

When you decide, 'hey, we have an idea, or a change in direction' you'd then document or make the case in a way that is more clear and user friendly than a mile of ephemeral chat. This is the same reason people send out meeting summaries instead of transcripts.

We've moved to this point where nothing is ephemeral. But a random chat isn't a good way to understand why things are being done. It's just too much to parse. And at some point new people are looking for a needle in a haystack and they just kinda checkout.

I thing documentation should be intentional, the why should be clear in a doc that doesn't waste time and is formated in a way that we have come to understand as the best practices of technical documentation. You'd start with a quick overview of both the problem and proposed or adopted solution and the reader can decide if they need more info.

Especially with remote work, I think it's important to have ephemeral areas for discussion without expectations that everyone keeps up on the whole chat. Thinking every team member needs to know every word of discussion is ludicrous.

I don’t think it’s about referring to the chat log in the long term, it’s just about not obligating people to constantly follow the chat.

I’d be fine with all chats being deleted after a month. But if I’m out one day I’d like to see my colleague’s message about the project I currently work on.

> everything was pretty much ephemeral

Reminds me of this classic: https://www.youtube.com/watch?v=O2rGTXHvPCQ

It’s a real shame how difficult programming is. I don’t mean that it is difficult to write difficult things, but that it is difficult to write simple things. Once upon a time, one could download visual studio, click about to make a new project in (e.g.) Visual Basic, draw a gui in the gui editor, and click the run button. One could then start adding simple functionality (e.g. working through a book). Or even longer ago when a computer might dump you practically straight into BASIC when you turned it on or you might get access to a mainframe/minicomputer with programming tools already set up. Nowadays, an ‘easy’ introduction could involve the horrific process of installing and setting up python on windows (where it is hard to do things other than input/output text) or editing some html/JavaScript files where there are more easily possible interactive things but lots of things are difficult like ‘just drawing things’ or anything that requires a server side.

P.S. if you, like me, were wondering what Libera Chat is, it’s the moral successor of Freenode with Freenode now being a shell of its former self.

Rose tinted glasses?

Visual Basic (classic) that you mentioned, discontinued in 2008, was not free, unless you pirated it.

> ‘just drawing things’

For that you have much more amazing things today, like Shadertoy, or various artistic programming languages like Processing, ...

Programming is easier than ever, computers are extremely cheap, software is free, documentation on the internet is free, YouTube is full of tutorials, there are literally no obstacles if you want to do it.

Back in my day I had to pay for computers, for programming software, for books, Internet cost a fortune, ...

I believe there were some visual basic books you could get that would have a CD-ROM with a limited version in the back, but I may not be remembering correctly. Of course, you could also check those books out of the library and online activation wasn't really a thing then, so that's how I remember starting.

However, today there is no VB-like experience for modern development regardless how much you’d be willing to pay for it.

Delphi still exists:

> Build Native Apps 5x Faster With One Codebase. For Windows, Android, iOS, macOS, and Linux

https://www.embarcadero.com/products/delphi

And it's free if you don't make a lot of money of what you build.

And if you don't need/want to compile to x64 bit

Delphi Community Edition only allows x32 compilation

I downloaded it to try. It's not a huge limitation for most usecases I would imagine.

Do they make an exception for Mac, considering recent macOS no longer supports 32-bit binaries?

I remember Delphi being pretty close back in the day, and it's still around[0] if you're willing to pay for it. Lazarus[1] is another option.

Apart from the underlying language, the experience is pretty close.

[0] https://www.embarcadero.com/

[1] https://www.lazarus-ide.org/

Have you tried Lazarus?

https://www.lazarus-ide.org

> Programming is easier than ever

Really, it's not. This trade has got much, much harder since I started. The languages are harder, because the targets are both more complicated and more various. Computers were mainly used to do sums (I worked on accounting systems written in COBOL).

I mean, it's easier if you take into account the complexity and richness of the modern computing environment, USB, PCI, caches, what have you. You are producing more powerful programs. But the onboarding ramp for modern programming is steep.

> Once upon a time, one could download visual studio, click about to make a new project in (e.g.) Visual Basic, draw a gui in the gui editor, and click the run button

The world that lived behind that experience - COM & Active X Controls - was extremely complex. If you needed to build a new active x control for your app, god save you.

It's been said a million times, but in programming there is always complexity. Sometimes it is just well hidden.

I think there's a difference between intrinsic complexity and accidental complexity, though.

You're right to observe that programming involves irreducible complexity (one of the reasons why so many low code/no code tools fail is the refusal to accept this, imo), on the other hand modern toolchains are extremely complicated and could be a little more streamlined.

It's a meme at this point, but there's no way having six different pythons on your machine or whatever the hell modern JS toolchains do -- just to pick two examples -- is the simplest it can possibly be.

Older machines and toolchains certainly had their problems (arguably even worse ones), but I completely understand the complaints.

The complexity of modern tool-chains suck, specially when you are just beginning. It gets you very confused, and some people end just giving up. Python is confusing with all the environment juggling if you're at the stage of doing something not trivial. But for the beginner, at least it gives you IDLE, a barebones IDE by default. I think there is a parallel universe where I use Ruby as my main language, instead of Python, as I tried Ruby before Python, several years ago. But in this timeline I got stuck trying to call the Ruby interpreter from Geany, and never came back.

Similarly, I tried to learn Clojure before Pharo. Spent over a hour setting Atom with all dependencies required to convert the editor into a Clojure IDE. But I botched the set-up somewhere, and ended with a dead REPL. Again, never came back.

The best experience I had so far, as a beginner trying a new programming language, was Pharo. You type a couple of lines in the terminal, and gets a full environment with _everything_ you need included in the system image. No need to spending a lot of time wrangling dependencies to get a functional system. I think the image-based development strategy from the Smalltalks is underrated.

Thank you for posting this. I’ve had the same experience with Clojure and was wondering whether to try Pharo. So I did a search on HN and your comment came up, written no 24 hours before. Jung would have called this a synchronicity, or “meaningful coincidence”.

>If you needed to build a new active x control for your app, god save you.

regsvr32 coolcontrol.ocx

> ... difficult to write simple things...

and

> Once upon a time, one could download visual studio,

don't seem to agree very well. Visual Studio is a behemoth and usually results in stuff that's non-standard, non-portable and with lots of dependencies.

That certainly wasn’t the case with Visual Studio VB6 (or earlier) that the GP alluded to.

Visual studio won at the zero-to-interactive-program metric. People who have never programmed are not going to care so much about portability as they are about not getting stuck trying to figure out how to install/make things work properly on their systems. The modern ‘getting started’ choice is often python which doesn’t give you such an easy path to interactivity and has its own portability problems.

Bash is the Basic of our era, the fact that it's so easy to do simple things explains why people are so often ready to use it despite its perceived and real shortcomings. Hopefully one of the new shells gains enough popularity to "flip" usage and give us a renaissance of powerful scripting interfaces.

Why bash over the browser javascript console? It is everywhere and allows interactive editing of a "program", much like the BASIC interpreters of old.

Yeah but how do I pipe to other programs? How do I schedule something and integrate it with my filesystem? Also the syntax is complicated (don't underestimate this, for many of us trouble parsing syntax is a distant memory). Also easy interop between many programming languages.

Maybe when the browser fully swallows the OS but I hope it won't be JavaScript or it would have morphed into something else.

Bash is terrible, adding an extra space breaks it

BASIC is smarter than C, it knows when = means assign and when it means equality

TCL/TK >>>>>> VB. By a huge margin. VB would work great under Windows, but TCL/TK kits would work everywhere.

I liked VB6 when I first tried it. You drew a UI, then you double-clicked the components to get a menu of stub code-blocks. It was good for making UIs.

Then suddenly there were masses of weird, undocumented APIs, including APIs from any application installed on the machine. Unfortunately I was making my living from VB6 at the time, so I had to learn it all. (And then MS withdrew support for VB6, forcing me to learn a new trade, which is only one driver of my animus against MS)

Long ago I owned a Sinclair QL. That toy had a rather nice BASIC editor. I think their dialect was called QBasic. You selected a function in the left pane, and it appeared for editing in the right pane. (I also loved that it used a 68K processor; that chip had a sweet instruction set)

Indeed, just like VB6, tcl/tk is a great reminder of the late 90s.

Tcl was such an expressive yet minimalist language. Probably the only fast and easy way back then to create GUI applications on *nix systems. I guess Python + QT has killed it now, but with a massively larger footprint and resource usage obviously.

> on windows

This is the mistake. Linux and, I believe, OSX come with several tools pre-installed including python.

Windows comes with PowerShell, which is a pretty fully featured programming language that can interface directly with the .NET ecosystem.

> Windows comes with PowerShell (...)

It might be just me, but PowerShell feels outright developer-hostile even when compared to Bash. Perhaps it's their approach to rely primarily on .NET stuff which makes things so arcane, but when given the option it's far simpler and better to go with, say, python than PowerShell.

I couldn't disagree more, I think bash is a horrifically bad programming language. Honestly I'm incredibly surprised anyone could compare PowerShell and bash and think that PowerShell is the arcane one.

> I couldn't disagree more, I think bash is a horrifically bad programming language.

Bash is described as a "command language" and not a programming language per se.

Bash is what you use to type in commands, and automate said commands if you need to whip out a quick script that runs what you would otherwise run manually. Bash, scripting-wise, is command line glue.

If all you want to do is run commands with some logic, PowerShell is simply dreadful and outright developer-hostile. I doubt there is a single person on earth who uses PowerShell as a command shell like Bash is used.

Again, I disagree and regularly use PowerShell as a command language --as do many Windows admins-- and much prefer its object-based pipelining and relatively sensible and consistent command and argument naming to bash's error-prone text pipeline and mixture of 2-letter abbreviations and complete nonsense names. But whatever, to each their own.

This subthread was specifically about programming languages being available out of the box in OSs, so when you brought up bash my natural assumption was that meant as a programming language.

> If all you want to do is run commands with some logic, PowerShell is simply dreadful and outright developer-hostile. I doubt there is a single person on earth who uses PowerShell as a command shell like Bash is used.

Expand your views. Everyone aren't you, didn't learn the same things as you and understand different things than you.

I learned some C++ as my first language, therefore I got stuck in an object oriented mindset, this translates really well to PowerShell and really poorly to bash. The thing where everything is text doesn't make sense, text isn't stable and everyone will write their own partially broken parsing implementation. In PowerShell they try to make everything an object, with type checking and other goodies, solid autocomplete for scripts being one.

In PowerShell I can deserialise JSON and perform CRUD operations on the data easily.

I'd say powershell is outright developer friendly as it brings a production grade language to the scripting table.

If powershell could parse bash completion files and integrate sudo better I'd use it as a command shell on all platforms, which right now are limited to MacOS and Linux.

The problem is that you think bash is a programming language.

Its bad even for one liners.

People complained about Python using whitespace, adding an extra space in bash can break the whole thing

The person who you're responding to is engaging with the person who they're responding to in the terms chosen by the latter. If the original commenter hadn't written, "PowerShell feels outright developer-hostile even when compared to Bash", then we might have some reason to find fault with the person who replied. Considering that's what did happen, however, this comment of yours—which is both snarky and implicitly demands the wrong person to take responsibility for the comparison—just comes across as annoying.

Totally. Bash is such nonsense. Its little better then batch on Windows.

PowerShell is such joy that it should be there on any Linux as default interactive shell.

PowerShell is the worst of bash and perl combined. It's like Microsoft took a look at each of those, "We can do that!" and implemented them.... worse.

What's bad about it specifically? Main thing I don't like is verb-noun, breaks tab complete

A tool shouldn’t need to come preinstalled with the OS in order to be useable. And “switch to a different OS” is not a good solution especially for cases where you don’t control the OS you run.

For a long time MacOS came with only Python 2.x installed. I looked up what the latest version of MacOS comes with and came across an Apple support forum post with several responses posting conflicting answers [0]. One person got an Xcode related error. Having to install a heavyweight IDE just to get a language to run correctly is the type of needless complication the parent comment is talking about.

[0] https://developer.apple.com/forums/thread/691403

> Having to install a heavyweight IDE

xcode-select --install pulls in the CLT, which is a fairly reasonably sized download given that it includes various essential dev tools including python3 but without Xcode.

This is hinted at by attempting to run python3 before any install, which calls a stub prompting you to do just that.

py2/ruby/perl/etc... are part of the base OS for backwards compatibility/expectations (because they were so before Xcode/CLT were even a thing) but have been marked as due for removal from base for something like half a decade. My bet is that at some point they will move to the CLT (or some other optional download) as well.

> Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages.

https://apple.stackexchange.com/questions/406244/will-macos-...

That's probably for the best, as the ones that ship are often old and buggy, and Apple doesn't seem to care for maintaining them (even if they pretend to care about developers). As long as there's a way for actual developers to install these tools themselves (such as Homebrew), things will work out fine.

Anytime I do anything with python on Linux or MacOS I encounter python, python3, pip, pip3, venv, virtualenv, conda, poetry... so much machinery around the code. Throw in your platform-specifc package manager of choice as well (apt, brew, etc)

EDIT: Oh and pipenv!

Which creates more problems than solutions.

If the Python version that comes with your OS is not the one you want (e.g. it's outdated), then you'll have to:

1. Install the version you want anyway, and all the tools required (that usually don't come preinstalled in the OS)

2. Try to not make them collide, which, last time I tried, was a PITA, because the OS depends on original version of Python being in the the $PATH or something.

Python on Ubuntu is notoriously misleading for newbies, because even if you apt install python3 and it tells you that it's already installed, it's not fully installed. For example, venv is not installed, you have to `sudo apt install python3-venv` and do that for every Python module that's not installed by default.

It would be easier if Linux didn't come with Python, and then people simply installed the actual, full version of Python they wanted.

>and then people simply installed the actual, full version of Python they wanted.

Which then wouldn't work for all the repository python programs. The repo's python is what everything is built and tested against, so there is no replacing that.

The package manager could install its own version of Python, isolated from the rest of the system, so that it doesn't get in the way of the user, but repository programs know where it is and can use it.

I wanted to focus on a ‘first introduction to programming’ which on average means windows. Obviously installing and running python can be easier on Linux but you still have problems with anything not-just-text.

Yes! I learned BASIC on the BBC Micro. You turned it on, and you got a BASIC interpreter. It was the most painless, most fun experience. Graphics, sound,, etc., were all available by reading the User Guide.

I couldn't have afforded buying one, but my university had half a dozen.

I wish kids today could get that.

The closest I've found to having a modern experience to programming in that manner is DragonRuby Game Toolkit [0]. It's not free (with some exceptions for eligible users and indie game developers), but it does offer a standard version for a one-off payment, which is the version I have. It's sold as a game dev toolkit but it brings back those same memories of BASIC for me. I firmly believe that it could be a very viable method of introducing programming as well.

If you bought either of the two itch.io bundles "Bundle for Racial Justice and Equality" or "Indie bundle for Palestinian Aid", then you have the Standard license already included in that bundle. It's well worth a look IMO.

(Not affiliated other than a very happy user.)

[0] https://dragonruby.org/toolkit/game

This was my attempt at providing easy graphics to kids inspired by the BBC Micro: https://github.com/akkartik/mu/tree/main/shell

Here's a 6-minute demo: https://archive.org/details/akkartik-mu-2021-06-09

Requires Qemu, though. And no sound yet, unfortunately. I'd love contributions there or elsewhere.

Python is just one installer on Windows and there are tons of pip installable packages, for 2d or 3d graphics, GUI, sound/midi, math/data and whatever you can think of. Tons of docs and tutorials or colabs.

How is that not easy?

A friend of mine was recently taking a course on machine learning and she had to use Python with some packages for the homework assignments. She downloaded VSCode and installed Python on her machine and then attempted to get the packages installed with pip. They weren’t showing up in the VSCode terminal though. Somehow she had six different installations of Python, one of Python 3 living inside of a VSCode namespace, one each of Python 2 and 3 living in a global location, and one each of Python 2 and 3 living in a user-specific location, and a Python installed by Anaconda. Calling python, python3, pip, and pip3 in all went to different Python installations. The VSCode installation didn’t seem to have pip at all, even with python -m pip. I managed to eventually sort it all out for her, but it took me over two hours to figure it out, and I’m a professional programmer who uses Python in my daily job. I admittedly don’t use Windows everyday, but it was a huge mess and I have no idea how it happened.

Computers are complex, and people who don’t work closely with them daily can easily get very confused.

In such cases, it maybe better to just use Google Colab.

Reminds me of this visualization[1]. The amount of code it takes to simply draw a triangle in OpenGL 1.x, OpenGL 3+, and Vulcan

The learning curve has been sacrificed. It's now a learning cliff for everything. We've used to have computers that make it simple to do simple things and hard to do complex things. Now, just so it can be slightly less hard to do complex things, we've made it hard to learn and do simple things.

1: https://twitter.com/sol_hsa/status/1174233868536356866

In the case of graphics, the only thing that's changed is the abstraction layer which is stable. Most folks won't use Vulkan directly, but rather through a layer which they have control to optimize or fix bugs in if they need to. Learning graphics programming will never start directly with Vulkan programming. I suppose there are benefits to make the standard, stable API easy to work with as a beginner, but there are plenty of great open source projects that fill that niche.

TBH GLIDE was the Vulkan of its era.

I have never written for Vulkan and have only done bits and pieces of OpenGL but this can't possibly be an honest representation can it?

No, not entirely. Each version does progressively more error checking / debug output. Also the first two output a static single color triangle, while the Vulkan sample outputs a rotating triangle with different colors for each vertex.

Even conceptually using Vulkan is much more complicated.

In old GL it's basically glClear, glBegin, glVertex, glVertex, glVertex, glEnd and a bit of window setup.

In Vulkan you need to know what these things are: queues, command buffers, image/geometry buffers, memory locations (constant, uniform, varying), resources, bindings, shader programs, fences, swap chains, and how they all coordinate together.

And until they are all properly coordinated together, you'll just be staring at a black image or just get errors.

This is how I learned how to code, by downloading Visual Studio and randomly trying stuff out. Visually you can have an immediate feedback about your work, and then you start learning the code.

Nowadays, it's all about interconnecting different microservices just to bootstrap something, let alone build something complete.

> Nowadays, it's all about interconnecting different microservices just to bootstrap something

What is an example of this?

Here's a great (but comedic) example: https://www.youtube.com/watch?v=y8OnoxKotPQ

As an aside, can I just say how refreshing this website is? It's 100% content, just text. Now view the html source, and be amazed. I daresay the author actually wrote the html by hand. I suppose it could be a very conservative and conscientious site generator that even respects line length, but I'd be surprised. Short css file for minimal style tweaks, and readable markup. Fitting that the article is about simplicity. When I first learned html (late 90s) this is what it looked like. Very nice.

Possibly a pandoc generated html from markdown. My favorite way of doing things.

Source code [0] is available on GitHub; looks like they wrote their own simple site generator.

I've been thinking about something similar (maybe even simpler) for my blog too.

[0]: https://github.com/susam/susam.net

Thank you for sharing the link to the source code. My simple site generator is based on my wife's project makesite.py[1]. In fact, I used her site generator for a few years. Later I reimplemented makesite.py in Common Lisp. As a result, it inherits the design, layout, minimalism, and simplicity of makesite.py.

[1] https://github.com/sunainapai/makesite/

It does appear to be handcrafted HTML, generated using [1].

> This is a static website generated using a Common Lisp program. See github.com/susam/maze for the source code of this website[2]

> Just like the original website, every line of HTML and CSS that appears in the website is handcrafted.[3]

[1] https://github.com/susam/maze/blob/main/site.lisp

[2] https://susam.net/maze/about.html

[3] https://github.com/susam/maze

It seems like the CSS used is shared under the MIT license by the author here: https://github.com/susam/spcss.

Unfortunately, the inline code is dark blue, unreadable in dark mode.

Thanks for commenting about this issue here. I had accidentally removed the CSS code for pre, code, etc. in a recent commit. Fixed it now.[1] You should no longer see this issue after a hard refresh.

[1] https://github.com/susam/maze/commit/1d58e13

I miss IRC. The simplicity in design is one thing. I think the other part I miss is the pseudonyms and having an identity not be directly attached is another.

I remember joining so many IRC channels to learn about everything in college. You'd get help and be humbled by the many regular names in each channel. There was more of a human element to it as most people simply acted as extensions of themselves.

You think about Slack, Discord, and Teams today and there's a whole corporate or personal identity attached behind each name. You can't always act like you would in IRC. You can't always be blunt and to the point. You can't call someone an idiot or to RTFM in the most sincere way possible.

When things were simple with a single pseudonym and a message, things were great. Now things are much more complex. Threads, DMs, notifications of mentions, bots, gifs, etc. It's definitely been changing quickly, but it was nice when everyone's attention was in one place instead of fragmented in each of these new apps that are just glorified IRC.

Totally agree! Just one ever-so-minor nitpick...

>When things were simple with a single pseudonym and a message, things were great. Now things are much more complex. Threads, DMs...

IRC has DMs too, /msg

> You can't always act like you would in IRC. You can't always be blunt and to the point. You can't call someone an idiot or to RTFM in the most sincere way possible.

You can absolutely still do that in IRC. Tens of thousands of people still use it to communicate.

I used IRC for gaming around 2004 - fond memories!

I recently tried Discord to find programming communities but I just don't get it. When you join a server you are automatically subscribed to all the channels. And apparently you can't leave them, you can only 'silence' them by manually doing that for each channel. After a few days I just gave up as I could not keep up with all the notifications.

An IRC network can have thousands of channels; a discord server typically has dozens.

Think of a discord channel as a permanent thread or a topic and a discord server like an irc channel. I find discord's model more manageable than irc for a large number of users; irc channels become a mess around 50-100 active users. Dividing the conversations into topics helps a lot.

(I have been using irc since around 1994 and am still somewhat active.)

I would imagine one could tweak the web frontends like Convos or TheLounge to make IRC look and behave like Discord at least in terms of text chat and channel/user visibility. I theorize that's what they are doing behind the scenes.

Discord does allow you to set notifications across an entire community to "all messages" (which is the default), "only mentions" or "nothing" if you right-click on the community icon.

I was not precise when I said notifications. I already set it to "only mentions". My problem was that each channel will "light-up" when anyone is commenting in them. I have to mute each channel or mark all as read for the whole server to avoid this. On IRC you opt in to channels.

Discord is horrible and I don't understand why so many people like it so much.

First thing I do when joining a new "server" is to mute all and any broadcast (@everyone/@here/roles) mentions. Broadcast mentions should have never been invented.

People like it because people enjoy ownership and power. That and it's way more user friendly for newcomers. Also before Zoom got popular, it was the best voice chat for a while.

> People enjoy ownership and power.

What "ownership" and "power?" Discord controls it all.

Well yes, but the illusion is enough for enough people.

Also probably why security theater (TSA et al) still exists.

I'm officially coining Ownership Theatre for Discord, Fandom, and Reddit.

For me, discord was an easy way to get friends on voice chat together. The chat functionality is a nice bonus.

If you think about it like this, it makes more sense:

A server is to IRC what Discord is in its entirety

A channel is to IRC what a server is to Discord

If IRC let you subsection a channel, those would be channels to Discord

And instead of obnoxious netsplits, you get annoyed with popups to buy Nitro or whatever other crap whenever you log in

I'd say it's in the same general box as the simplicity of 8-bit computers booting into Basic interpreter, and the simplicity of Legos.

It's wonderful when you can have your toys in a sandbox where you use and develop them mostly for fun, and for scratching your own itch, away from well-moneyed interests. No need to carefully identify participants. No need to encrypt, or otherwise complicate the implementation. No need to efficiently serve millions of users. No need to add bling to attract more of those who barely cares. (The latter is not the case with Legos lately, though.)

This is why I think that a lot of innovation starts in the fringe, and looks like mostly useless toys, until one of these toys proves very useful for "real world" needs.

I never used IRC growing up, to my knowledge, though I'm sure I used it by proxy in software that used it under the hood.

Instead, I grew up with AOL Instant Messenger, and then MSN Messenger which later became Windows Live Messenger, then Skype, Xfire, Pidgin and Trillian as clients, then back to Skype again, and now Discord, which is where I still reside most of the time today.

When I thought about existing chat protocols I wanted to use in game engines and websites that would allow one to connect through existing clients without having to join the game or navigate to the website in question directly, I thought about IRC.

But it seems like people use Matrix now, and it just hasn't caught on to my circle of friends. If I'm not mistaken, it almost seems like FOSS Discord.

I was recently introduced to it by a member of a community of very friendly Quake Mappers. I wonder if there is primarily first a cultural barrier to these technologies and not a technical one. As usually I find more technical people on IRC than on Discord.

I've never really played around with IRC, but I've definitely had the experience the author talks about with Matrix. The server (like mentioned about IRC) is complicated, but interfacing with it as a user or a bot is mostly a few REST endpoints. I've started using Matrix as my go-to interface for new projects. You get IO for free, plus auth, user accounts, and multi-device; leaving just the fun stuff.

Speaking of ‘simplicity’, this blog has a fantastic design. The CSS is only ~30 lines and is largely just applying spacing/padding.

No JS, no custom font, etc.

https://susam.net/css/main.css

It's pretty nice indeed. I like the use of keywords for sizes "thin", "large", and the shorthand hex for colors, and the fact that there's zero boilerplate and only styling what's actually used.

Agreed, but I hate this:

a:link, a:visited { color: #00e; }

Why do this?

Oh, yeah, that should be illegal.

Right to jail.

Also to a mandatory review of WCAG standards.

Fortunately that’s easy to override with some custom CSS, but I also don’t understand the reasoning behind that…

Thank you for pointing this out. I have fixed it now. You should no longer see this issue after a hard refresh.

Write programs that do one thing and do it well.

Write programs to work together.

Write programs to handle text streams, because that is a universal interface.

; basically.

(https://en.wikipedia.org/wiki/Unix_philosophy)

While some of those guidelines offer some value still, end-user programs dealing with text just aren’t ever going to be a thing.

People expect to be able to paste a photo or screenshot just as easily as they post a sentence. Requiring a second app to do it (posting a link) isn’t nearly as good a UX as simply pasting in pictures.

Well, in practice you can have binary input, as many programs do, but human-readable free-form text is the simplest interface there is.

We just need more modern terminals that can handle that.

> We just need more modern terminals

Yeah like smartphone apps , webapps, and desktop guis…

Those are apps, I mean a glue / universal interface layer that's 100% owned by the user

Then have the chat client automatically upload to a service and generate a link behind the scenes.

That’s what any client does of course. But the default should be to also display the images (or clickable miniatures). Nothing that can’t be solved in any protocol - but you are both having to duct tape several services (a poor UX for the maintainer of the service) and what you are creating is basically converging on any of the modern alternatives.

I mean, yes, the idea is to recreate the same-ish experience as the alternatives, but in a modular way; the point is to make it flexible and expose the absolute maximum API surface.

> Requiring a second app to do it (posting a link) isn’t nearly as good a UX as simply pasting in pictures.

But what about the UX of other people in the channel? Someone posts an image and the previous text is moved off screen. Now they have to scroll up to read what they were just reading. What about the case where someone posts an animated gif which becomes a distraction that requires you to stop the animation or hide it? What about the case where multiple animated images are posted which forces your client to use a lot of CPU resources to render them[1]?

[1] https://mobile.twitter.com/slackhq/status/879755518843252736

Auto playing animation can be a client setting. As can rendering pictures at all.

Regardless, the UX of slack, discord, teams etc. is different from IRC because it’s what people expect from an IM client

That may be true for personal use, but not necessarily true for business related use. That's because the former case is limited to users who want to use the product precisely because of its features. In the latter case, users are required to use the product as part of their job. Given that, the ideal case would be to not introduce features that lead to a negative user experience.

The same people who use smartphone IM apps in their free time are using corporate IM clients at work. I can't see why business users would be any different. I expect my app at work to be able to do what my at-home IM client does. It could even be the same one.

> features that lead to a negative user experience.

Any feature can be a negative user experience. There is only one way to see what a majority of users are "expecting" and that is to open the mainstream IM apps in default configuration. The worst case of poor user experience is breaking the expectation that it works exactly like that.

In the beginning was the command line. Then work of bright people of Xerox PARC was used to hide from users the reality that underneath their beloved GUI, computers are just passing around strings of text. Now we yearn for a time when you were just one INT and several MOV away from putting a pixel on a screen, instead of downloading multi-GB IDE to fiddle for a weekend before you can show a simple window.

You don't understand what happened at Xerox PARC or what their "GUI" was. Smalltalk wasn't a language, it wasn't a GUI, it was an _environment_, and its whole point was that it didn't hide anything! It was a completely different paradigm to how computers and their programs are architected today. A Smalltalk system was always meant to be so simple that one could understand, and change, everything about it.

That's why I've said that their work was used, not that they did it.

IRC, the protocol, is really simple. It's so simple it's almost the most minimal chat protocol you could possibly layer on top of TCP - it's literally a live message routing protocol with the least support for the notion of persistent users possible.

There was a joke on bash.org that IRC is basically multiplayer Telnet and ... they aren't really too far off.

This has good and bad things about it:

Good: it's extremely flexible.

Good: it's extremely efficient - your major IRC servers at there peak were probably one machine, possibly single core, and handled 20,000+ active connections. Protocol is extremely proxyable and tunnelable.

Good: It works well over dialup. If you can get .002Mbit/sec between you and the server you can use IRC.

Bad: no real concept of identity - everything is based on IP addresses and current connections. Connection drops, you're gone. Things have arisen to address this (NickServ, etc.) and using a bouncer has always been a thing.

Good: no real concept of identity - if your IP is cloaked or you're not accessing from your home IP, you're very anonymous.

Bad: First user on a channel is it's op and it's owner and can control the channel. If all ops connections drop, someone can take it over. DoSes/DDoSes to disrupt channels have been a thing. Things have arisen to address this on modern IRC (ChanServ) but before then, any really serious channel had to have a network of bots with out-of-band coordination to protect it (eggdrop).

Bad: Doesn't support file transfer directly. This is done with another protocol DCC which is hard to work with over firewalls, etc.

Bad: Media and link support is up to clients and requires non-IRC protocols to be effective. You're not posting pictures in IRC channels unless you are using a client that supports it such as thelounge, and even then what thelounge does is upload your pictures to a local server.

Good: Mature IRC clients give you a lot of control.

Bad: Mature IRC clients are complicated.

Bad: IRC is one of those protocols that arose before encryption was considered a basic need. Modern IRC supports SSL but all it takes is one client connecting non-SSL to ruin it like email, unless the server is SSL only.

Bad: Mature IRC servers tend to be from the age where the Internet was ruled by universities. So, DNS is relied on for security and identity far more than it should be. Configuration of mature IRC server daemons I find somewhat complex and difficult.

Same with SMTP and POP, I would routinely send or get email via telnet when I wanted to debug or delete some messages. They're all very simple protocols.

In my experience, email protocols are anything but simple as soon as some security or authentication comes into play.

Depends on the auth mechanisms in use, the simplest ones are still still pretty straightforward. Nowadays you just use the TLS equivalent of telnet (openssl s_client).

POP3:

  1. run openssl s_client -connect myserver.example.com:995
  2. enter two commands: "user myusername" "pass mypassword"
  3. profit

SMTP & AUTH PLAIN is only slightly more complicated but similarly just an additional protocol command, connecting with s_client. (You need to generate the auth string in another shell window with: echo -ne "\0username\0password"|openssl base64)

Usenet too. Getting news and discuss stuff "offline" and fetching/sending the messages once a week it's magical and resting.

The fall of Usenet more and more looks like a mistake. I’d love to have hyper-localized newsgroups, in place of Facebook.

Often local stuff like: “Why does is smell like somethings on fire”, “Has the water been turned of” or is “Is soccer cancelled this week?” is only posted on Facebook. So if you don’t have Facebook, you can’t get those information. Then again the Facebook algorithm will hide it for three weeks before deciding that you need to know that the hot water will be turned of for quarter of the town at three o’clock.

I feel that Usenet would be ideal for this.

Some newsgroup messages have a distribution header. But I don't really recall that feature being used at all during the time I was on Usenet (late '90s till about 7 years ago).

I was just suggesting having a group or two for your town, rather than just having them for major cities.

On Usenet, MUDs, and IRC, look what could be achieved back in the day by tweaking the source code of a MUD: they converted it into a full groupware tool thanks to TCL/TK and some glue here and there.

https://paparisa.unpatti.ac.id/linux_journal_archive_1994_20...

I've been forced to use Slack for the past 5 or 6 years in my professional life and I despise it. It gives me absolutely no ability to customize or automate my workflow without my employer giving me the keys to the kingdom, which they rightly won't do. Slack's service is where the value is. The client is only a means to an end. And yet they guard it with such zeal, threatening those who develop augments or alternatives.

I have the skills. Just let me automate my own machine without making me have to fight you tooth and nail!

Nice article, thanks :-) I grew up with IRC and realize that it isn't the same any longer. It isn't the place where everyone is, which some social networks seem to be today. The local communities on IRC, a channel for a town used to be the place to be and meet others.

I think Discord took over the role of IRC. It has a lot of same functions and terminology.

Discord is internet relay meme.

IRC is probably used by more people now than ever before, though in a very different way than before. The whole of Twitch's chat infrastructure is running on it and it have hundreds of thousands of concurrent users. Though for most people it is running though a websocket instead of a raw socket, but the commands are the same a long way

The IRC protocol is for the bot API only. The chat on the website uses a custom protocol, and the IRC daemon has always been a custom implementation with weird quirks.

It is a custom protocol that follows IRC very closely, they just have a lot of extensions on it to add support for the things on twitch. to start a connection you send PASS, NICK, USER and then JOIN, over the websocket so I would not really call it a custom protocol. The url it uses is wss://irc-ws.chat.twitch.tv/ as well.

IRC was fun. I do miss that period of time (and being a teenager who could learn things very quickly). I'm not particularly nostalgic about the protocol or the user experience though. Maybe we will find a good middle ground some day, fast native clients with media rich experience and great searchability. I use Teams every day and find it to be just fine for most things.

The simplicity also comes with problems, such as nickname registration in practice being implemented with bots that have administrative rights, which can lead to social engineering exploits and poor standardization of their interfaces, or the fact that the protocol does not seem to support sending an encoding so it relies on the gentleman's agreement that everyone use UTF-8, which works until that one user using latin-1 enters and starts sending characters that appear strange to everyone else.

It could be a little bit more complex in my opinion. Perhaps it is time for servers to start supporting an i.r.c. 2.0 protocol but otherwise allow 1.0 and 2.0 users to still communicate with each other to facilitate the migration.

You mean IRCv3? It’s not all ready/implemented yet, but some of it is already in daily use.

https://ircv3.net/

For example a server can tell the client that it only accepts UTF-8: https://ircv3.net/specs/extensions/utf8-only

Well I am still sometimes seeing this user that is sending latin-1, confusing everyone else.

I also wish that nicknames would not be handled via the hack of bots, as this sysem allows one to take a nickname one does not own, at least for a short while, but simply no identify it and ignore that message, and thus impersonate another user.

I've finally migrated away from the last of my irc channels the last remaining people except for one holdout agreed it's time to move on. Things have been way better since the switch..I wouldn't go back, a new bar has been set

Preferred chat notwithstanding, at least the holdout didn't go the xkcd route: https://xkcd.com/1782/

LOL thanks for that I never saw that one

Switch to what?

Somehow I never heard of Matrix until now. I'm now running Element with a bridge to the Libera IRC network. Thanks!

I am if the opinion that IRCv3 is horrid and has taken the email route of (forgive the language) "polishing turd". You cannot have a secure irc that is backwards compatible, you can have separate default ports and uri schemes like http vs https, but you can't connect to http and opportunistically redirect 301 to https and call that an improvement of securiry because it is actually worsening security by introducing false assurances of securiry.

I also believe it is possible to have a protocol that has proper E2EE and simple enough to where you can use netcant and one other tool to use IRC.

Trust-on-first-use authentication (like signal or ssh) is also terrible in practice on its own. Keep it simple. Let the servers handle public key distribution and certification so that compromise of the server/mesaaging infrastructure is required to mount identity attacks, then do the normal TOFU authentication so users won't have to trust middleware. Have a commandline tool that "connects" to the other user (like ssh or sendmail) and opens a socket/fd you can use with a proper frontend or just echo/netcat to it.

I love IRC, unfortunately it doesn't work properly with smartphones because they have a "loose" connectivity (4G towers data etc). I'm not sure IRC apps can deal with this already. It would be nice to have some update to the IRC RFC.

If it was well supported for smartphones, I'm still wondering if it would cause some bandwidth costs to servers.

EDIT: I know about bouncers, but I would prefer to do without.

You can use IRC bouncer for that. e.g. https://wiki.znc.in/ZNC

It's not free, and it add hardware and software and bandwidth.

If you are into self-hosting, thelounge is a great web-based IRC client that works well on my iPhone. It does its magic by staying connected to servers on the backend, similar to a bouncer.

It works well for me by using screen and irssi on a server and then using mosh on the smartphone to connect there, as well as irssi-notifier for notifications. Has worked well around the work, including traveling in africa, from high speed trains in Europa and airplanes above the Atlantic. And before you say "but that needs a server". Yes it does. A little VM as a shell host that is cheaper be month than the cheapest nitro package on Discord. Not even one coffee per month. If you don't think it's worth to have control over your communication for that price, I can't help you.

It'd be nice if as a society we stopped making all software worse in order to make up for smartphone's many limitations.

IRC clearly had same problems already back in the day when many users were still on dial-up connections...

> I'm not sure IRC apps can deal with this already. It would be nice to have some update to the IRC RFC.

They can do it with some help from the IRC server: https://ircv3.net/specs/extensions/chathistory + https://github.com/ergochat/ergo/blob/master/docs/USERGUIDE....

If the server itself doesn't support it, you'll need to add a bouncer inbetween, which is still very common, unfortunately.

I just pay $5/month for IRCCloud. The iOS app could be a lot better, but not only does it make IRC work like any standard chat app that allows messages while you're away, it also offers some modern bare minimum UX like inline images and link cards.

> EDIT: I know about bouncers, but I would prefer to do without.

Well doing without bouncers like other "modern" chat services is kinda like using another person's bouncer. An IRC server is just a realtime relay, it's not meant to store history, manage replay to different devices, etc. This would require much more code and a bigger database (and the logging of all messages).

Everyone should write an IRC client as an exercise in network programming due to its simplicity. The other IM protocol for which I've written a client is early MSNP, which is also text-based and not immensely more complicated than IRC. IMHO all the newer web-based stuff is a horrible mess of abstraction bloat. TCP, and TLS if you want encryption, should be a sufficient base to build upon.

Have we learned nothing from the iPod and Dropbox? Simplicity doesn't matter. What matters are:

1) How easy is it to use?

2) What features does it offer me?

3) How well does it integrate into my lifestyle?

4) Do my family and friends use it? Can I get them to?

Slack and Discord win on ALL FOUR of the above points vs. IRC. IRC is a dead horse... stop beating it, please.

"The only thing that matters in software is the experience of the user." --Ryan Dahl

I use Matrix and bridge in IRC, and third-party platforms whenever necessary. So much less cognitive load having it all in one place.

IRC might be designed around a simple protocol, but it is not simple in operation. The plethora of command line options explains why IRC is only loved by (some) developers and nobody else.

I suspect some IRC users like the high barrier to entry (but would never admit to it): it keeps out all those clueless 'non-technical' users.

There are GUI clients for IRC that don’t need any “command line options” (some don’t even support them).

And there are (and certainly were) plenty of people on IRC who aren’t very technical. Seriously, around 20 years ago it was often used as a "dating app" by regular users, or for radio listeners & DJs to chat, etc.

Prior to IRC becoming an accepted protocol, the "talker BBS systems" tried to avoid the need for a user to have a "client application." I'd say it was AOL that put an interface on chat and sold (a) the idea of a chat client and (b) the idea of online chat to less technical users.

I still have discord somewhere.. but I don't use it. I think the technical simplicity of IRC also leads to chiller chans (and I know there are toxic people on IRC but it feels like an open garden unlike tiny realms with a lot of efforts put in setting up servers and rules by the original team)

I don't know if a snippet of IRC shows it being simple. The colons are quite mysterious, especially to anyone who's seen HTTP/POP/SMTP. They look out of place with whitespace before rather than after, and are used for two separate things...

Could someone with more insight summarise how this compares to xmpp as an open chat protocol?

Whenever IRC comes up I never miss a chance to recommend my favorite extensible (in several languages) IRC client weechat. I believe there have been some forks to handle discord and matrix as well.

IRC is great!

I like the interface way more than Discord.

And it seems to attract more knowledgeable people.

If you are into startups, check out #startups on Libera!

Are netsplits still a thing in modern IRC network deployments?

>I often remark how simple the Internet Relay Chat (IRC) protocol is and how that has fostered creativity in the lives of young programmers growing up in the late 90s and early 2000s. For many of us who were introduced to the Internet during that time, writing an IRC bot turned out to be our first non-trivial hobby programming project that involved network sockets, did something meaningful, and served actual users.

While that is true, most of those who wrote bots did not meaningfully interact with the protocol because they used abstractions (eggdrops, mirc scripts, etc). The simplicity of the protocol was unrelated, as a well abstracted library for any other protocol or even service (such as twitter) can be as simple.

Is this true? It’s not my experience. My first meaningful programs were raw socket IRC clients as a teenager explicitly because they were simpler to figure out than using things like egg drop.

That isn’t to say that most fully featured tools were written from scratch — I can’t speak to that one way or another. But I know a lot of people who were learning about internet protocols by using telnet to interact directly with IRC servers then transferring that knowledge into a socket-level reimplementation of the protocol.

RFC1459 certainly proved to me that RFCs can be simple and worth reading. And the whole experience taught me early that a simple enough, well documented protocol could be easier to use than a wrapper library in a foreign language. I certainly use a lot of libraries these days, but those lessons have served me extremely well.

With ii you can write a bot today with any language reading and writting to files. Even with sh.

Admittedly my first bot was indeed in mIRCScript and its abstractions but it wasn't long before I had a !spawn command that was a function that connected sub-bots directly to IRC as a protocol because why not I guess

Also wrote a script that sent email directly for tinkering purposes, later used that protocol knowledge to get my first tech job haha "how does email work?" "how in-depth do you want?"

I dunno, I was there in the very early 2000s and as I remember it, for the subset of programmers I knew on IRC at the time, it was as Susam says: writing a shitty IRC bot - not a script, something from "scratch" that actually spoke the IRC protocol - was almost a rite of passage back then. From rose-tinted me-tinted glasses, I seem to remember that IRC-bot-related questions were a plurality of the questions asked in #vb on Dalnet back in the day!

You are also right to some extent as well; I wonder how much mIRC scripting has been underestimated as the gateway drug to programming for thousands.

(Rose-tinted/me-tinted disclaimer: the first non-trivial program I wrote was an IRC quote bot, in Visual Basic. I later rewrote it into Python, because I wanted to learn Python, which eventually led to my day job today...)

Equally rose-tinted user here. My first unix service ever configured and started, was eggdrop (and it took me hours to get it running on a shell account).

If you want an even simpler and more scalable chat you can use my multiplayer online system:

http://github.com/tinspin/fuse

The HTTP server is written in Java with a custom JSON database and it has clients in C++, C# and HTML5.

Reply on news.ycombinator.com