8
submitted 3 months ago by wols@lemm.ee to c/syncforlemmy@lemmy.world

On posts that I access through my home instance, i.e. any post present in the "Your local instance" feed, nothing appears in the comments section apart from the message "There are no comments", despite the UI suggesting that there are several.

When accessing the post's permalink in the web UI of the instance, the comments show up without issue, even when logged in.

To reproduce, log in to sync with a lemm.ee account, switch to local feed and click on any post that appears to have comments. For example: https://lemm.ee/post/35476369

For some reason I haven't been able to replicate this on any other instance (tried with .world and .ml, both of which don't seem to have this issue)

[-] wols@lemm.ee 27 points 4 months ago

I don't share the hate for flat design.
It's cleaner than the others, simpler and less distracting. Easier on the eyes, too. It takes itself seriously and does so successfully imo (nice try, aero). It feels professional in a way all the previous eras don't - they seem almost child-like by comparison.

Modern design cultivates recognizable interactions by following conventions and common design language instead of goofy icons and high contrast colors. To me, modern software interfaces look like tools; the further you go back in time, the more they look like toys.

Old designs can be charming if executed well and in the right context. But I'm glad most things don't look like they did 30 years ago.

I'm guessing many people associate older designs with the era they belonged to and the internet culture at the time. Perhaps rosy memories of younger days. Contrasting that with the overbearing corporate atmosphere of today and a general sense of a lack of authenticity in digital spaces everywhere, it's not unreasonable to see flat design as sterile and soulless. But to me it just looks sleek and efficient.
I used to spend hours trying to customize UIs to my liking, nowadays pretty much everything just looks good out of the box.

The one major gripe I have is with the tendency of modern designs to hide interactions behind deeply nested menu hopping. That one feels like an over-correction from the excessively cluttered menus of the past.
That and the fact that there's way too many "settings" sections and you can never figure out which one has the thing you're looking for.

P S. The picture did flat design dirty by putting it on white background - we're living in the era of dark mode!

[-] wols@lemm.ee 5 points 7 months ago

I want to preface this with the mention that understanding other people's code and being able to modify it in a way that gets it to do what you want is a big part of real world coding and not a small feat.
The rest of my comment may come across as "you're learning wrong". It is meant to. I don't know how you've been learning and I have no proof that doing it differently will help, but I'm optimistic that it can. The main takeaway is this: be patient with yourself. Solving problems and building things is hard. It's ok to progress slowly. Don't try to skip ahead, especially early on.
(also this comment isn't directed at you specifically, but at anyone who shares your frustration)

I was gonna write an entire rant opposing the meme, but thought better of it as it seems most people here agree with me.
BUT I think that once you've got some basics down, there really is no better way to improve than to do. The key is to start at the appropriate level of complexity for your level of experience.
Obviously I don't know what that is for you specifically, but I think in general it's a good idea to start simple. Don't try to engineer an entire application as your first programming activity.

Find an easy (and simple! as in - a single function with well defined inputs and outputs and no side effects) problem; either think of something yourself, or pick an easy problem from an online platform like leetcode or codechef. And try to solve the problem yourself. There's no need to get stuck for ages, but give it an honest try.
I think a decent heuristic for determining if you have a useful problem is whether you feel like you've made significant progress towards a solution after an hour or two. If not, readjust and pick a different problem. There's no point in spending days on a problem that's not clicking for you.

If you weren't able to solve the problem, look at solutions. Pick one that seems most straight forward to you and try to understand it. When you think you do, give the original problem a little twist and try to solve that. While referencing the solution to the original if you need to.
If you're struggling with this kind of constrained problem, keep doing them. Seriously. Perhaps dial down the difficulty of the problems themselves until you can follow and understand the solutions. But keep struggling with trying to solve little problems from scratch. Because that's the essence of programming: you want the computer to do something and you need to figure out how to achieve that.
It's not automatic, intuitive, inspired creation. It's not magic. It's a difficult and uncertain process of exploration. I'm fairly confident that for most people, coding just isn't how their brain works, initially. And I'm also sure that for some it "clicks" much easier than for others. But fundamentally, the skill to code is like a muscle: it must be trained to be useful. You can listen to a hundred talks on the mechanics of bike riding, and be an expert on the physics. If you don't put in the hours on the pedals, you'll never be biking from A to B.
I think this period at the beginning is the most challenging and frustrating, because you're working so hard and seemingly progress so slowly. But the two are connected. You're not breezing through because it is hard. You're learning a new way of thinking. Everything else builds on this.

Once you're more comfortable with solving isolated problems like that, consider making a simple application. For example: read an input text file, replace all occurrences of one string with another string, write the resulting text to a new text file. Don't focus on perfection or best practices at first. Simply solve the problem the way you know how. Perhaps start with hard-coded values for the replacement, then make them configurable (e.g. by passing them as arguments to your application).

When you have a few small applications under your belt you can start to dream big. As in, start solving "real" problems. Like some automation that would help you or someone you know. Or tasks at work for a software company. Or that cool app you've always wanted to build. Working on real applications will give you more confidence and open the door to more learning. You'll run into lots of problems and learn how not to do things. So many ways not to do things.

TLDR: If it's not clicking, you need to, as a general rule, do less learning (in the conventional sense of absorbing and integrating information) and more doing. A lot of doing.

[-] wols@lemm.ee 7 points 7 months ago

The point is not the difference between a fake memory and a real one (let's grant for now that they are undistinguishable) but the fact that positive experiences are worth a lot more than just the memories they leave you with.

I may not know the difference between a memory of an event that I experienced and a memory of an event I didn't experience. Looking back on the past, they're the same.
But each moment of pleasure that I only remember, without having experienced it, was essentially stolen from me. Pleasure is a state of consciousness and only exists in the present.

[-] wols@lemm.ee 7 points 11 months ago

Honestly, their comment reads like copy pasta. That first paragraph is chef's kiss.
I initially thought they weren't being sincere, something something Poe's law...

(' v ')/

[-] wols@lemm.ee 11 points 1 year ago

That number is like 20 years old.

Today it's around 60 billion.

[-] wols@lemm.ee 12 points 1 year ago

Extra steps that guarantee you don't accidentally treat an integer as if it were a string or an array and get a runtime exception.
With generics, the compiler can prove that the thing you're passing to that function is actually something the function can use.

Really what you're doing if you're honest, is doing the compiler's work: hmm inside this function I access this field on this parameter. Can I pass an argument of such and such type here? Lemme check if it has that field. Forgot to check? Or were mistaken? Runtime error! If you're lucky, you caught it before production.

Not to mention that types communicate intent. It's no fun trying to figure out how to use a library that has bad/missing documentation. But it's a hell of a lot easier if you don't need to guess what type of arguments its functions can handle.

[-] wols@lemm.ee 11 points 1 year ago

I can't for the life of me figure out how your proposed method helps in the described scenario.

Maybe I misunderstood it, can you elaborate?

[-] wols@lemm.ee 15 points 1 year ago

Yup.

Spaces? Tabs? Don't care, works regardless.
Copied some code from somewhere else? No problem, 9/10 times it just works. Bonus: a smart IDE will let you quick-format the entire code to whatever style you configured at the click of a button even if it was a complete mess to begin with, as long as all the curly braces are correct.

Also, in any decent IDE you will very rarely need to actually count curly braces, it finds the pair for you, and even lets you easily navigate between them.

The inconsistent way that whitespace is handled across applications makes interacting with code outside your own code files incredibly finicky when your language cares so much about the layout.

There's an argument to be made for the simplicity of python-style indentation and for its aesthetic merits, but IMO that's outweighed by the practical inconvenience it brings.

[-] wols@lemm.ee 12 points 1 year ago

Yes, correcting hyperbole with relevant information is bad, actually.

[-] wols@lemm.ee 5 points 1 year ago

As always, the dose makes the poison.
A common scenario is people picking the wrong species and then not just eating a small bite, but cooking an entire meal and eating that.

A small bite may not kill you, but just one mushroom (50g) can be enough to do it.

There are some toxic mfs out there and they can be mistaken for edible lookalikes by inexperienced foragers.

[-] wols@lemm.ee 7 points 1 year ago

Actually fruits are pretty great for us, if they aren't highly processed.
Better to eat an apple than drink apple juice, also better to eat an apple than just about anything from the supermarket that isn't fresh.
Of course, you still need a balanced diet, and you can't get nearly all the necessary nutrients from just apples. Still, assuming an otherwise nutrient-complete diet, it's a lot less healthy to eat a slice of frozen pizza than an apple or a banana. (the apple might even contain less available sugar than the pizza slice - people often overestimate how much sugar fruits really contain)

The "stuff removed" bit is more important than you seem to give it credit for. Take out all the fiber and water and sure it's still the same sugars that are left over, but we didn't evolve to consume large quantities of pure sugar, so it spikes our insulin and gets stored as excess fat.

Fruit juice is pretty unhealthy, because all the sugar is more available due to all the fiber being stripped out and you can consume a dozen apples' worth in a few minutes, which you wouldn't do with actual apples.

Sure, there's not that much fiber left in raisins either. But in the context of musli they can be combined with whole grains and nuts, so you get enough fiber back to make the sugar less quickly digested and thus more healthy.

A third of the entire cereal mix being sugar is definitely worse than musli with raisins (which comes to about 10g of sugar per 100g), especially considering that a good portion of the rest of the mass in the case of musli is made up of fiber, proteins and healthy fats.

Adding sugar isn't just "another big issue", it's the big issue. Eating fresh fruits is a non-issue, and usually so is eating dried fruits in moderation.

[-] wols@lemm.ee 5 points 1 year ago

Many of the programming languages that are regularly the butt of everyone's jokes don't just allow you to use them badly, they make it easy to do so, sometimes easier than using them well.
This is not a good thing. A good language should

  • be well suited to the task at hand
  • be easy to use correctly
  • be hard to use incorrectly

The reality is that the average software developer barely knows best practices, much less how to apply them effectively.
This fact, combined with languages that make it easy to shoot yourself in the foot leads to lots of bad code in the wild.

Tangentially related rant
We should attack this problem from both directions: improve developers but also improve languages.
Sometimes that means replacing them with new languages that are designed on top of years of knowledge that we didn't have when these old languages were being designed.

There seems to be a certain cynicism (especially from some more senior developers) about new languages.
I've heard stuff like: every other day a new programming language is invented, it's all just a fad, they add nothing new, all the existing languages could already do all the things the new ones can, etc.
To me this misses the point. New languages have the advantage of years of knowledge accrued in the industry along with general technological advancements, allowing them to be safer, more ergonomic, and more efficient.
Sure, we can also improve existing languages (and should, and do) but often times for one reason or another (backwards compatibility, implementation effort, the wider technological ecosystem, dogma, politics, etc.) old quirks and deficiencies stay.

Even for experienced developers who know how to use their language of choice well, there can be unnecessary cognitive burden caused by poor language design. The more your language helps you automatically avoid mistakes, the more you can focus on actually developing software.

We should embrace new languages when they lead to more good code and less bad code.

view more: next ›

wols

joined 1 year ago