luckystarr @ luckystarr @feddit.de

Posts

0

Comments

58

Joined

2 yr. ago

It teaches you to think about data in a different way. Even if you never will use it in your products, the mental facilities you have to build for it will definitely benefit you.

Completely agree. I really love SQL, but I hate it's syntactic limitations. SQLAlchemy was my band-aid with an after-burner to make it bearable (and maintainable).

Python development without PyCharm (or IntelliJ) and the IdeaVim plugin is unbearable. List usages is a game changer. Don't care much for anything else.

You could be onto something. On of my first language was "dBase" (early 90s) which, through it's style, enabled you to build complex user interfaces with data storage very quickly. I only built small things with it at the time, but it influenced my desire for some better solutions than we have to today.

How much power does this thing draw?

They don't want you to see the "if benchmark_xyz { do less work }" blocks of code.

The way I perceive PRQL is somewhat like SQLAlchemy-Core (the SQL expression layer, not the ORM). Almost a 1:1 mapping to SQL but softening the rough edges in SQL when constructing more complex queries dynamically, in particular: no function calls, no real variables, only string concatenation. While SQLAlchemy-Core lets you even extract sub-queries into variables, I don't know about how powerful PRQL is in this regard.

From what I see from the docs I'm rather hopeful though.

The one argument that even flies understand:

Switch light on outside of my room. -> Get out!

Sir, your washing machine will arrive on Wednesday. Be sure to be at home at around 3.

Can the ozone be countered by a reverse polarity static charge? Not sure how the laser printer do it, but recent printers barely emit ozone. I think it should be possible.

Can the ozone be countered by a reverse polarity static charge? Not sure how the laser printer do it, but recent printers barely emit ozone. I think it should be possible.

That would invalidate their position as "we're just a platform and not liable for the things our users post". They'd have to take responsibility then and I'm not sure they've got the resources for that.

In order to compete in user experience we need to up our game. We need to set up communities which collect, categorize and funnel user requests upstream. These features should be focused on:

• reducing frictions like unclear UI, broken links, etc.
• improving usability of the various web frontends (the one from Lemmy, kbin, etc.)
• collecting bug reports and making sure they will be fixed

This is meant to be a proxy between average users and tech enthusiasts who know how to do pull requests or open GitHub issues. Moderators of these communities would do it for them. This would enable us to gain visibility in the needs of the users.

This is only a part of what needs to be done, but I think this can be done quickly.

Burn me once, shame on you. Burn me twice, shame on me. Big corporations want mainly one thing: gobble up as much value exclusively to themselves. They will take whatever means necessary to get there. The strategies to privatize public resources (XMPP, ActivityPub, etc.) are known. They look great for the public on the outside, but over the years will erode the value for everybody BUT them. In order to not let it get as far, many (including me) are of the conviction to not even give them a finger, let alone the whole hand.

Because they want it. It's the main reason why they've built the app.

Some other critter would evolve to take their niche. Not sure how long that would take though, but eventually there would be other insects which will annoy you.

This is soooo true. With a few notable exceptions (e.g. Matrix 2) most of the hacking scenes are a really bad caricature of the real deal. Sometimes even worse than that.

Nothing lasts longer than a crudely thought out band aid solution to a not fully understood problem.

Each instance is free to field their own donation drives for their running cost. They even can display advertisements if they feel like it. There is no "one size fits all" here, and there shouldn't.

Each instance is potentially in a different jurisdiction, making it hard to transfer money, etc.

Not only that, but I think having funds centrally collected and then distributed is a particularly bad idea. It comes with too much opportunities for bad blood. Money and friendship don't mix.

The only unifying constant of the network is the software that runs it. This though needs to be improved in various areas, for which centrally collected funds would be ideal, as every instance will benefit from it. No operator of any instance would have a disadvantage from advertising the central donation drive. They would benefit from it by having better software in the end.