Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simplicity of IRC

susam.net

Post reply on HN
Print view View original

111–120 of 250 posts

Re: Simplicity of IRC

#111

Post by erwincoumans »

dan-robertson wrote: post #6

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 a…

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?

Re: Simplicity of IRC

#112

Post by jacobolus »

lambdaba wrote: post #21
c0l0 wrote: post #10

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…

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!

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.

Re: Simplicity of IRC

#113

Post by fivea »

AnIdiotOnTheNet wrote: post #80
fivea wrote: post #72

Earlier quoted context omitted.

> 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.

Re: Simplicity of IRC

#114

Post by u801e »

alkonaut wrote: post #78
lambdaba wrote: post #29

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.

> 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

Re: Simplicity of IRC

#115

Post by Jasper_ »

erk__ wrote: post #99
hoyd wrote: post #2

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.

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.

Re: Simplicity of IRC

#116

Post by littlecranky67 »

Nemi wrote: post #54
c0l0 wrote: post #10

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…

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.

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.

Re: Simplicity of IRC

#117

Post by u801e »

mrweasel wrote: post #63
anthk wrote: post #55

Earlier quoted context omitted.

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 befo…

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).

Re: Simplicity of IRC

#118

Post by miked85 »

c0l0 wrote: post #10

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…

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.

Re: Simplicity of IRC

#119

Post by efdee »

lloeki wrote: post #88
mcfedr wrote: post #61

Earlier quoted context omitted.

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.

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

...What?

Re: Simplicity of IRC

#120

Post by littlecranky67 »

c0l0 wrote: post #10

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…

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.
Post reply on HN