• 1 Post
  • 16 Comments
Joined 1 year ago
cake
Cake day: June 19th, 2023

help-circle
  • That’s quite interesting.

    Although it would need access to an already configured and fully functional environment to actually run this.
    I don’t think we’re quite at the point yet where it’s able to find the correct script, pass it to the appropriate environment and report the correct answer back to the user.
    And I would expect that when integration with external systems like compilers/interpreters is added, extra care would be taken to limit the allocated resources.

    Also, when it does become capable of running code itself, how do you know, for a particular prompt, what it ran or if it ran anything at all, and whether it reported the correct answer?


  • Thanks for responding, that makes a lot of sense.
    I think generally what one gets used to has a big impact on preferences.

    I’ll say, an easily accessible, reliable gesture for side menu sounds nice. It feels like this was either abandoned on Android or left up to developers who mostly abandoned it. I remember struggling to get the side menu to trigger instead of back navigation and it not working near reliably enough. So I’ve been trained to always use the hamburger buttons that, ironically, are hard to reach in the top left corner in most apps. To be fair, I feel like I hardly use one menu interaction for every 100 back actions, so the latter being ergonomic is a lot more important to me.
    On that point, swipe from left to go back seems quite annoying. I go back all the time, and having to move my thumb across the entire screen is a pain. I almost never need to go forward, so having that be the more accessible gesture seems weird. I’ll concede that having a gesture for it at all is useful and Android should add the option.

    I never felt like the swipe to go back is too sensitive, and if you accidentally trigger it, you can simply move your finger back towards the edge before letting go to cancel the action. You can also configure the sensitivity in the settings. The feedback that you’re about to trigger the action is probably not as obvious as on iOS though, and likely less elegant.

    I think both Android and iOS would do well to let users customize these interactions more to their own needs.


  • Could you elaborate on the gestures part?
    I remember the opposite, having hated navigating my iPhone for work. I specifically remember swipe to go back not working reliably at all (many apps seemed to just ignore it, others I think configured other actions on that gesture - WTF), so I got into the habit of using that stupid little hard to reach, hard to hit, tiny back arrow that at least worked consistently when you managed to hit it.
    I’ve been enjoying Android navigation gestures pretty much ever since I found out they existed.

    It might have been a user issue in my case with iOS since I didn’t use it as much, and therefore maybe was simply using it wrong/was unaware of better ways. But I don’t see anything wrong/missing with gestures on Android.



  • wols@lemm.eetoProgrammer Humor@lemmy.mlGot no time to code
    link
    fedilink
    arrow-up
    1
    arrow-down
    1
    ·
    3 months ago

    Bonus: good tests can also serve as technical documentation.

    Though I have to disagree with the notion that documentation is as important or more so than code.
    Documentation is certainly near the top of the list and often undervalued. I’ve worked on a project where documentation was lacking and it was painful to say the least.
    Without documentation, changing or adding features can be a nightmare. Investigating bugs and offering support is also very difficult. But without code, you have nothing. No product, no users, no value.

    There are (inferior) substitutes for documentation: specialized team knowledge, general technical expertise. These alternative pools of knowledge can be leveraged to create and improve documentation incrementally.
    There’s no replacement for the actual functionality of your applications.


  • Ditto on the no text part. That is an accessibility failure that’s way too widespread.
    Sometimes I’m afraid to even push a button: does this delete my thing, or does it do some other irreversible change? Will I be able to tell what it did? Maybe it does something completely different, or maybe I’m lucky and it does in fact perform the action I’m looking for and which in my mind is a no-brainer to include?

    And it’s infected interpersonal communication too - people peppering their messages with emojis, even professional communications. It not only looks goofy, but is either redundant (when people just add the emoji together with the word it’s meant to represent - such a bizarre practice) or, worse, ambiguous when the pictogram replaces the word and the recipient(s) can’t make out what it depicts.
    The most fun is when it’s a mix - the message contains some emojis with accompanying translation, some without.


  • 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!



  • This works as a general guideline, but sometimes you aren’t able to write the code in a way that truly self-documents.
    If you come back to a function after a month and need half an hour to understand it, you should probably add some comments explaining what was done and why it was done that way (in addition to considering if you should perhaps rewrite it entirely).
    If your code is going to be used by third parties, you almost always need more documentation than the raw code.

    Yes documentation can become obsolete. So constrain its use to cases where it actually adds clarity and commit to keeping it up to date with the evolving code.


  • wols@lemm.eetoProgrammer Humor@lemmy.mlIn case you forgot.
    link
    fedilink
    arrow-up
    13
    arrow-down
    1
    ·
    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.eetoProgrammer Humor@lemmy.mlMy poor RAM...
    link
    fedilink
    arrow-up
    5
    arrow-down
    2
    ·
    1 year ago

    The point is that you’re not fixing the problem, you’re just masking it (and one could even argue enabling it).

    The same way adding another 4 lane highway doesn’t fix traffic long term (increasing highway throughput leads to more people leads to more cars leads to congestion all over again) simply adding more RAM is only a temporary solution.

    Developers use the excuse of people having access to more RAM as justification to produce more and more bloated software. In 5 years you’ll likely struggle even with 32GiB, because everything uses more.
    That’s not sustainable, and it’s not necessary.


  • I think they meant the only language we transpile to for the express reason that working with it directly is so unpleasant.

    Java is not transpiled to another language intended for human use, it’s compiled to JVM bytecode.

    People don’t usually develop software directly in the IR of LLVM. They do develop software using vanilla JavaScript.


  • You don’t need to correct something everyone already knows is an exaggeration (and I agree it doesn’t seem very socially aware to do so) but this is a political discussion on the internet, so

    1. Everyone does not know the original figure is an exaggeration, especially by how much
    2. Providing the actual information ads value to the conversation and in this context this is more important than whether the commenter comes off as smarmy or socially inept

    What if they said “Hey I know you’re being hyperbolic, but for anyone who’s interested, here’s the number estimated by experts…”?
    The only difference here is tone.
     

    I’m not sure why they only shared numbers for minke whales, as these don’t seem to be hunted anymore in Iceland in contrast to fin whales, whom the article was about.

    Global fin whale population was estimated in 2018 by IUCN to have been around 100000.
    https://www.iucnredlist.org/species/2478/50349982#population



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


  • wols@lemm.eetoMEOW_IRL@sopuli.xyzmeow_irl
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    There’s something almost dreamlike to this picture.

    He looks weightless yet somehow at the same time really heavy.

    Trapped in a nightmare of man’s creation, he’s a prisoner in this absurd dimension, forever cursed to run but getting nowhere, inert and lost, desperate but powerless, unable to satiate his urgent need for freedom.

    Truly a testament to the state of this society.


  • I haven’t used a different browser in a good while, so I’m not sure that these issues don’t exist elsewhere, but here’s a few:

    For a very long time after the rework, reordering tabs was not possible. Only recently was this added again. But there seems to be no acceleration, so moving an old tab to the front takes forever. Even worse, this feature is still not available for private tabs (since you can’t select those at all).

    Quite often when I switch to the tab overview, it doesn’t automatically scroll to my current tab so I need to do that manually.

    I’m also not a fan of the “jump back in” view that shows up every so often instead of the content of my tab. Why they would assume I’m interested in anything besides what I intentionally opened is beyond me.

    Creating a new tab is more cumbersome than it needs to be. I think you were able to do that by scrolling to the right on the address bar of the rightmost tab. A dedicated button would be even better.

    I think it’s a great browser, and pretty much the only one I use, but in my experience everything does not work perfectly.