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

Rewriting the Slack Python SDK

slack.engineering

Post reply on HN
Print view View original

1–10 of 59 posts

Re: Rewriting the Slack Python SDK

#5

Post by underyx »

I was trying to update my all-in-one duct tape Docker image[0] yesterday and was surprised to see that they ramped up the complexity so much for this release, I had to install a new C library just to be able to compile a dependency of a dependency they added.[1]

[0]: https://github.com/underyx/url

[1]: https://github.com/underyx/url#5-2019-05-31

Re: Rewriting the Slack Python SDK

#6

Post by outime »

MobileVet wrote: post #4

It still amazes me that Slack, with its infinite resources, hasn’t built native clients. One code base is nice and all, but man I loathe the Electron app.

I want to remind that Slack is not a simple chat app - it should not be oversimplified, because it has tons of added functionality. Not that you said that but it's easy to fall into that trap.

That being said, creating a native app for 2-3 (depends if you include Linux) different OS with completely different frameworks and maintaining feature parity between them involves a lot of specific knowledge and (probably) separate teams. Even if you have a good budget ("infinite resources" is quite arguable) it adds a lot of complexity to something that already has it. All of that just to somehow have a bit more fluent client (but probably much less polished).

The cost for this change would be very, very difficult to justify.

Re: Rewriting the Slack Python SDK

#7

Post by dmitriid »

MobileVet wrote: post #4

It still amazes me that Slack, with its infinite resources, hasn’t built native clients. One code base is nice and all, but man I loathe the Electron app.

> with its infinite resources

Who says their resources are infinite?

> hasn’t built native clients.

What would it gain them?

Re: Rewriting the Slack Python SDK

#8

Post by BubRoss »

outime wrote: post #6
MobileVet wrote: post #4

It still amazes me that Slack, with its infinite resources, hasn’t built native clients. One code base is nice and all, but man I loathe the Electron app.

I want to remind that Slack is not a simple chat app - it should not be oversimplified, because it has tons of added functionality. Not that you said that but it's easy to fall into that trap. That being said, creating a native app for 2-3 (depends if you include Linux) different OS with completely different frameworks and maintaining feature parity between them involves a lot of specific knowledge and (probably) sep…

> That being said, creating a native app for 2-3 (depends if you include Linux) different OS with completely different frameworks and maintaining feature parity between them involves a lot of specific knowledge and (probably) separate teams.

Why do people believe this? It could be written once in C++ using Qt, Juce, or Fltk and be blazingly fast. This has been done thousands of times over the last few decades. Where does this myth come from?

Re: Rewriting the Slack Python SDK

#9

Post by marcinzm »

kissgyorgy wrote: post #2

Don't bother, I have my own based on asyncio with Real Time API support, pagination and everything. If people interested separating this to it's own package, let me know! https://github.com/kissgyorgy/gerrit-slack-bot/blob/master/s...

>Don't bother

Why not? Theirs has better support behind it and supports everything you listed (RTM api, pagination, async, etc.).

Re: Rewriting the Slack Python SDK

#10

Post by kissgyorgy »

marcinzm wrote: post #9
kissgyorgy wrote: post #2

Don't bother, I have my own based on asyncio with Real Time API support, pagination and everything. If people interested separating this to it's own package, let me know! https://github.com/kissgyorgy/gerrit-slack-bot/blob/master/s...

>Don't bother Why not? Theirs has better support behind it and supports everything you listed (RTM api, pagination, async, etc.).

It's API is actually terrible and has bugs which mine don't.
Post reply on HN