Programming thread

[Marvin]

Yeah, but why isn't that just a method that exists on all objects? I don't understand why this requires a keyword.

Beats me.

Javascript was originally jimmied up in ten days. It's probably just a wart.

 

[Splendid]

But Pythin, a language with a very different heritage, has the del operator, which works almost the same way (it actually removes shit from arrays instead of setting them to undefined.)
I feel like there's some principle of language design I'm missing here.

 

[Marvin]

But Pythin, a language with a very different heritage, has the del operator, which works almost the same way (it actually removes shit from arrays instead of setting them to undefined.)
I feel like there's some principle of language design I'm missing here.

When you're implementing a language, the further down you go, it gets harder to do ordinary things that you could do in the language itself. Every implementor wants to make it turtles all the way down, or as far down as is feasible. It's because it's easier to work in a garbage collected, non-C language than in C.

Manipulating objects (for example, to add methods) in C is more complicated than adding a new syntax feature.

Adding a new syntax element is trivial. The reason is is because you already have a parser. You already have simple syntax elements like new. You've got all the hard parts done already.

But if you wanted to add a new method? That gets more complicated. It requires you to fiddle with objects. You've got to seize a particular variable (in this case, I'm guessing Object) from the environment, figure out what incantation of C calls you need to do to add a new function to the prototype. Make sure that function properly removes the key from the object. And at every step, you've got to pore over the documentation to make sure you're handling the GC properly.

If you've ever worked with the C api for a scripting language, you'll know it's a nightmare to deal with the GC and error handling. (If you do SCRIPTINGOBJ* foo = my_scriptinglang_api_get_key_from_obj(), does that mean your C code has custody of the object? Will the interpreter garbage collect it? I don't know, look through the docs and don't fuck up!)

I usually just use SWIG, or sometimes it's more convenient to use dynamic linking and write my C bindings from within the language and skip C entirely.

Now if they wanted to add a .delete_key method? They could just do:

Object.prototype.delete_key = function(key_name) {
  return delete this[key_name];
};

(I think that's how you do it? I don't often fiddle with Javascript's prototype stuff. They keep trying to bootstrap it into a real OOP system and I'm not feeling it.)

 

[The Flawless Gazelles]

to practice working with restfull apis i would like to create a small app to display data from said such an api using the mvc approach. now my question is how to plan such an application?
for now i wrote down what the user interactions should be and made a sketch of the page. what methods are there for planing the details, the small steps towards the final product. from the back end to the front end or the other way around? for now the apps where very small and i just coded what felt right to be done next, without any planing beforehand. what is the approach you guys use to structure the work and what literature would useful to read .

 

[Marvin]

to practice working with restfull apis i would like to create a small app to display data from said such an api using the mvc approach. now my question is how to plan such an application?
for now i wrote down what the user interactions should be and made a sketch of the page. what methods are there for planing the details, the small steps towards the final product. from the back end to the front end or the other way around? for now the apps where very small and i just coded what felt right to be done next, without any planing beforehand. what is the approach you guys use to structure the work and what literature would useful to read .

Does the API already exist? Or do you want a project that involves doing both the API and the frontend?

I'm more of a backend guy. I usually start with an idea of what I want the app to do and get a rough idea in my head about what screens it'll need. Nothing concrete needs to go on paper (but maybe that's useful?), just get an idea of what data structures I'll want to model.

Let's say I was making a todo list app. The goal would be to have todo entries, and then they can be in different lists (chores, errands, "prep for birthday party", etc).

In my head, I'd imagine you'd have a screen where you edit a todo item (or create a new one), a screen that shows you your different lists, and maybe a screen to edit a given list, maybe reorder the todo items.

The easy API endpoints to make:

• /todo/entry - POST to create a new entry, GET to get a list of entry URIs
• /todo/entry/321 - GET to get the entry as some JSON data, DELETE to delete it, obviously, PUT to update it
• /todo/list - POST to create a new list, GET to get a list of list URIs
• /todo/list/456 - GET to get the list data, DELETE to delete it, PUT to update it

That's a naive representation, anyway. If your app gets really complicated / big / doesn't perform that efficiently, you'll need to look into pagination and things like that.

Then there's also user accounts and authentication and things like that.

I usually start with a dockerfile and a docker-compose file for projects like these. So I can quickly do: "docker-compose up --build" in a terminal and have all my code up and ready to go.

I don't do much frontend development, but yeah, then I'd work on the frontend.

 

[The Flawless Gazelles]

for this project i'm using a already existing api, so i can be sure it follows the restful pattern.
writing my ideas down help me so far staying somewhat on track. the api is cached and has no limit on how many calls i can make, for some data it will work fine to read them every time someone asks for them. others are refreshed every 24h and are used to create a json object out of different endpoints. how do i get a function to execute every day at the same time?

edit: so the part that runs every 24h could be done on a node server and for the rest i'm using js that got translated with babel in the browser?

 

[Marvin]

for this project i'm using a already existing api, so i can be sure it follows the restful pattern.
writing my ideas down help me so far staying somewhat on track. the api is cached and has no limit on how many calls i can make, for some data it will work fine to read them every time someone asks for them. others are refreshed every 24h and are used to create a json object out of different endpoints. how do i get a function to execute every day at the same time?

edit: so the part that runs every 24h could be done on a node server and for the rest i'm using js that got translated with babel in the browser?

Are you going to be writing any backend code of your own? Are you going to be writing your own API?

 

[The Flawless Gazelles]

Are you going to be writing any backend code of your own? Are you going to be writing your own API?

the only backend part i'll have is creating 2 json objects every 24h, a planned feature for later would involve storing the data i'm getting from the api but again said task can be done once again every 24h.

 

[CrunkLord420]

@Marvin @garakfan69 have any suggestions for a webapp authentication library for Golang? I'm looking into authboss right now. I'm not even really sure how modern webdevs do sessions, does everyone use JWT now?

 

[Marvin]

@Marvin @garakfan69 have any suggestions for a webapp authentication library for Golang? I'm looking into authboss right now. I'm not even really sure how modern webdevs do sessions, does everyone use JWT now?

JWT is useful for when you've got more than two parties. So like, other than just client and server.

Otherwise I'd just make normal login tokens, store them in the database and cache them in redis.

 

[CrunkLord420]

I've been balls deep in webdev land. Learning Vue, PixiJS and webpack. It takes 250x+ longer to build a tiny JavaScript site than my Golang webservice, which has way more code in it. Why is this allowed?

-Golang Game Server Logic-
# du -sh src/
44K     src/
# time go build
0.16user 0.02system 0:00.12elapsed 154%CPU (0avgtext+0avgdata 24920maxresident)k
0inputs+0outputs (0major+1757minor)pagefaults 0swaps

-The Tiny Website-
# du -sh src/
25K     src/
# time npm run build
[...]
40.69user 0.93system 0:30.13elapsed 138%CPU (0avgtext+0avgdata 413960maxresident)k
95056inputs+328outputs (0major+331223minor)pagefaults 0swaps

# du -sh node_modules/
170M    node_modules/

 

[Stock Image Photographer]

Can someone explain why the matrix devs decided to implement their home server in python of all languages? Is it because python interpreters exist for pretty much all CPU architectures, so it can run almost anywhere? Because from my point of view, it seems like something a little more performant might be a better choice.

 

[Least Concern]

Can someone explain why the matrix devs decided to implement their home server in python of all languages? Is it because python interpreters exist for pretty much all CPU architectures, so it can run almost anywhere?

Probably because whoever started the project was most comfortable with using Python. That's usually the reason any particular language is chosen for any particular project.

That being said, yes, Python runs on anything and isn't a bad choice for server-side stuff, IMO. Not what I'd choose, but at least it's not JavaScript.

 

[CrunkLord420]

Can someone explain why the matrix devs decided to implement their home server in python of all languages? Is it because python interpreters exist for pretty much all CPU architectures, so it can run almost anywhere? Because from my point of view, it seems like something a little more performant might be a better choice.

Synapse is just one implementation of the matrix protocol, albiet the reference implementation. Dendrite is written in Golang, but not ready yet: https://github.com/matrix-org/dendrite

 

[Marvin]

Can someone explain why the matrix devs decided to implement their home server in python of all languages? Is it because python interpreters exist for pretty much all CPU architectures, so it can run almost anywhere? Because from my point of view, it seems like something a little more performant might be a better choice.

Why is yet another IM protocol necessary?

 

[CrunkLord420]

Why is yet another IM protocol necessary?

The Matrix protocol (which Riot is a client for) is an open source federated protocol that allows for Slack/Discord like features (persistent chat logs, voice/video, rich text) in addition to optional E2E encrypted chat.

The fact it's federated allows you to connect to other Matrix servers (called "homeservers") via your own homeserver. You can think of this like email. Your email provider can ban you, but other email providers can only block you from sending messages to them. You can see me demonstrating the federation feature in my screenshot by viewing the Linux chat hosted on the main official homeserver via the KF server. I never directly connect to the official Matrix homeserver.

KiwiFarms has a secret Riot server on an obvious subdomain that no one chats in.

 

[Stock Image Photographer]

Why is yet another IM protocol necessary?

I think the only answer to that question is that I've never seen an IM protocol that people were actually happy with using. A lot of protocols are just dead (ICQ, AIM, etc.), and IRC is "dead" seemingly only because everyone insists that it is. Tox and Ricochet are full of pedos and basically equivalent to routing your IRC traffic through tor. Slack and Discord are accessible only through webapps or bloated electron-based desktop clients, with Slack having boring corporate associations and Discord being barely above spyware. I've never used XMPP, but the main complaints I've heard about it are that it doesn't scale well and that it uses xml (which I personally don't consider bad, but others disagree). Matrix is like a federated version of Discord based on an open standard, like CrunkLord420 said above. In terms of failings, I can see it eventually becoming like XMPP where the open standard eventually leads to the devs becoming lazy and telling client devs to implement massive amounts of functionality on their own, or maybe it'll fail because the devs eventually want people to use third-party IDs like phone numbers and email addresses.

 

[Least Concern]

Slack and Discord are accessible only through webapps or bloated electron-based desktop clients

Recently I've been using a program called Ripcord, a cross-platform Qt program which can connect to both Discord and Slack servers. It's still kinda janky - I need to manually reconnect to servers after switching from wi-fi to my wired connection and vice versa, and the one time I tried to do Discord voice chat with it it couldn't detect my headset as an output device properly - but chatting works well enough and it sure as hell uses a lot less RAM than running either the official Discord or Slack clients, much less both of them. I even found out about it here on the Farms. I suggest giving it a try.

 

[AnOminous]

Recently I've been using a program called Ripcord, a cross-platform Qt program which can connect to both Discord and Slack servers. It's still kinda janky - I need to manually reconnect to servers after switching from wi-fi to my wired connection and vice versa, and the one time I tried to do Discord voice chat with it it couldn't detect my headset as an output device properly - but chatting works well enough and it sure as hell uses a lot less RAM than running either the official Discord or Slack clients, much less both of them. I even found out about it here on the Farms. I suggest giving it a try.

It kicks ass, is super fast, consumes negligible system resources, and does everything I need without all the bloated idiotic bullshit of Discord or the ads.

 

[Marvin]

I think the only answer to that question is that I've never seen an IM protocol that people were actually happy with using. A lot of protocols are just dead (ICQ, AIM, etc.), and IRC is "dead" seemingly only because everyone insists that it is. Tox and Richochet are full of pedos and basically equivalent to routing your IRC traffic through tor. Slack and Discord are accessible only through webapps or bloated electron-based desktop clients, with Slack having boring corporate associations and Discord being barely above spyware.

I still use IRC. The hardcore crypto protected stuff is usually swarming with pedos, but I use it when I'm in a foreign country to be safe. (Like Telegram.)

electron-based desktop clients

The problem with this is that, while electron is bloated as shit, it's probably the best way to make an attractive desktop app.

Until someone comes up with something lighter weight, but approximately as powerful as the css box model / html5 model, electron's still gonna have a bunch of users.

Maybe something cairo based.

I've never used XMPP, but the main complaints I've heard about it are that it doesn't scale well and that it uses xml (which I personally don't consider bad, but others disagree).

Yeah, XML is a shitty aspect of it. But otherwise it functions pretty well. It fulfills the needs for a classic IM protocol like AIM very well.

Though if you want persistent chats like discord/slack, that would take a bit of work.