Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)M
Posts
45
Comments
309
Joined
3 yr. ago

  • I’m trying to understand Git, but it’s a giant conceptual leap.

    In that case, I suggest learning Mercurial first. Its underlying design is very similar to Git, but the interface is more consistent and does a much better job of presenting the concepts to humans (especially those already familiar with traditional version control). Then, once you're comfortable with the concepts and commands in Mercurial, learn Git, since it's everywhere nowadays.

    Consider learning at least one new language, if not immediately (since you're in a hurry) then in your free time. Java is only one of many (and not even a particularly nice one IMHO). Try to find a language that you enjoy using; your programming life will be better for it. If you want something flexible and productive, consider Python. For more structure than that, maybe Go. If mobile apps interest you, there are Kotlin (Android), Swift (iOS), and Dart (both). If web development appeals to you, along with lots of job openings and lots of competition for those jobs, JavaScript. If you fancy the esoteric (and well-paying), Elixir and Erlang are worth a look. Lower level languages are in demand as well (e.g. C++, Rust) but they come with various kinds of pain that I wouldn't recommend to someone in your situation.

    Above all, please make sure you're reserving time for things that make you happy, sleep, and (if still possible) some kind of exercise. Your own physical and mental health are important. If you endure a bad working environment or wear yourself thin for too long, you will burn out, which won't help you provide for yourself or anyone else.

    Take care, OP.

  • One pattern I've noticed is people seeking a language that's better than {JSON,XML,INI,etc} at wrangling their slightly complex configuration files, noticing the additional features and type support offered by YAML, and assuming it will be a good solution.

    Then, as their configs grow ever larger and more complex, they discover that expressing them in YAML requires large sections of deep nesting, long item sequences, and line wrapping. The syntax style that they saw working well in other places (e.g. certain programming languages) breaks down quickly at that level of complexity, making it difficult for humans to correctly write and follow, and leading to frequent errors.

    YAML doesn't suck for small stuff, IMHO. (But it is more complex than necessary for small stuff.)

    For things likely to grow to medium-large size or complexity, I would recommend either breaking up the data into separate files, or looking for a different config/serialization language.

  • I almost ignored that link because most of the opinions I've seen from Sweeney have been self-serving and/or misleading, but it turns out he raises some good points in that slide deck. It gets relevant to this discussion around page 27: Reliability. Thanks for sharing it.

  • no long-term OS support

    IMHO, we need well-enforced laws requiring manufacturers to do both of these things:

    • Provide service manuals and reasonably priced parts for a sensible period, much like existing requirements for replacement car parts. (Perhaps 5 or 7 years minimum?)
    • Put into escrow all the information needed for community support of these devices, to be publicly released when the official support period ends. (The easiest way to satisfy this might be in the form of source code, but data sheets and API documentation could suffice if they are reasonably complete.)

    Some people have argued that the second point is impossible because phones are made with components that don't come with specs or source code themselves. That might be true today, but if large economies start requiring it, then those component manufacturers will either fall into line or lose the market to competitors who do meet the requirements.

    and not easy to load an alternative OS on.

    This is another big one. We need to be able to unlock our bootloaders, install an OS of our choice, and re-lock our bootloaders. (Without permanently disabling any of the hardware features; there must be a way to fully revert to stock.) The only major brand smartphones I know of with a reputation for doing this right are from Google, which is kind of embarrassing.

  • The cool kids in systems programming are using Rust now.

    Can you explain what you mean by "the cool kids"?

  • no one yet Jonathan blow’s unnamed programming language (people call it jay).

    I guess you missed my comment. ;)

  • Also, I don't think Go is generally considered a systems programming language.

  • What new direction is D taking that has you worried? Maybe I should watch out for it, too. :)

    one of the features I dislike the most in C/C++ is the super slow and super obsolete precompiler with its header files,

    Are you sure you should lump those two languages together? In my experience, C++ preprocessing can be slow (especially when you use templates), but not C. I shudder to think what preprocessor shenanigans the C libraries you've used might be doing to make compiling with them super slow. (LLVM isn't exactly known as a speed demon, though; maybe you've run into that?)

    In any case, I guess that rules out transpiled languages like Nimskull (work in progress) and its parent language.

    Have you looked at Odin?

    Maybe Vale?

    There is Jai (work in progress), though I haven't looked closely enough to know if it fits your needs. (I'm not sold on Jonathan Blow's judgment.)

    I suspect there are few languages well suited to both system and game programming (unless you mean game engine programming) that avoid all the things you seem to dislike. If you find one, I hope you'll write about it here. If not, there's always the option of using two languages.

  • The "especially in gaming" bit is encouraging. That might mean they are finally, after 26 years, addressing the demand for good quality, low latency, multichannel, full duplex audio...

    ...but I won't hold my breath. They seem to think gaming means playing on hardware like this.

  • Oops.

    Since you're using sudo, I suggest setting different passwords on production, remote, and personal systems. That way, you'll get a password error before a tired/distracted command executes in the wrong terminal.

  • I appreciate that you're articulating your thoughts pretty well without resorting to the adversarial nonsense I've received elsewhere in this thread, so thanks for that.

    It's still clear that I haven't been understood, but I'm exhausted from trying. (Again, mostly not from you, so please don't take it personally.) Time for me to put lemmy away for the day, I think. Take care.

  • All of those things are implemented in modern Android.

    No, they are not all implemented on any version of Android that I've seen. I don't know about iOS.

    Well, almost.

    Right. We don't need just a few pieces of what I listed. We need them all.

    an OS popup asks you if you want to give the app permission to use the feature.

    That's not a bad interface, but it doesn't address what I wrote: Individual control.

    Why should email address, sexual orientation, and home address be lumped all together into a single permission? Lumping installed apps and search history together isn't much better. Why should a music player, which obviously needs access to music files, be also granted access to biometric data like voice recordings?

    This is impossible? The OS can either let the app use the mic or not,

    Of course it's possible. The OS can record the file and then hand it off to the app. No microphone access required.

    Android always shows a green indicator on screen (upper right corner) when any app is using the microphone

    That alone is better than nothing, but not enough. How is a user to know if something was captured when the screen was off?

    These things are indeed improving as new versions come out, but at a glacial pace. Heck, it was ages before Android stopped letting apps spy on each other's log messages. It's now at version 15 and still doesn't have basic controls like restricting network access.

  • If your app touches the camera and mic, it will show up on that screen that it does so.

    Showing up on that screen is no substitute for what is actually needed:

    • Individual control (an easy and obvious way to allow or deny each thing separately)
    • Minimal access (a way to create a sound file without giving Facebook access to an open mic)
    • Visibility (a clear indication by the OS when Facebook is capturing or has captured data)
  • Pretty sure that qualifies for that permission.

    I don't know what you mean. Existing behavior does not provide the control or visibility that I described.

    One important difference is that the "permissions" in the screen shot are effectively all-or-nothing: if you don't agree to all of them, then you don't get to install the app. They're not permissions so much as demands.

    (Some OS do have settings that will let you turn them off individually after installation, but this is not universally available, is often buried in an advanced configuration panel, leaves a window of time where they are still allowed, and in some cases have been known to cause apps to crash. Things are improving on this front with new OS versions, but doing so in microscopic steps that move at a glacial pace.)

  • if you record a video with sound, then the FB app has to have permission to record your audio.

    I can't tell if you're trying to explain how it currently works (which I know very well, thanks) or asserting that the current behavior is necessary in order to record with sound.

    It really doesn't have to be as it is. The OS can provide a record-video API, complete with a user-controlled kill switch and an activity indicator, and the app can call it. The app doesn't need direct access to the microphone to allow the user to create a file with sound.

    Edit to clarify: I'm not saying that the "permission" doesn't work as advertised. I'm saying that recording an audio file doesn't have to require a permission system as coarse and disempowering to users as it is today. I guess the people clicking the downvote button misunderstood.

  • Nobody said it was the same thing as listening in the background. It's still relevant and important.

    I trust that most adults understand the implications of an exploitable permission and a strong incentive to abuse it, as well as the track record of corporate denials.

  • "Meta does not use your phone's microphone for ads and we've been public about this for years," the statement read.

    Meanwhile:

  • Also f*ck Fahrenheit, we have Celsius and Kalvin for that,

    Who is Kalvin? Did you mean kelvin?

    One drawback of celsius/centigrade is that its degrees are so coarse that weather reports / ambient temperature readings end up either inaccurate or complicated by floating point numbers. I'm on board with using it, but I won't pretend it's strictly superior.

  • It blows my mind that MPEG 1.0 Layer III is still so dominant.

    Count the number of devices in use today that will never support Opus, and it might not blow your mind any longer. Also, AFAIK, the reference implementation still doesn't implement full functionality on hardware that lacks a floating point unit.

    These things take time.

  • ISO 8601 date format. Not because it's from a standards body, but because it's simple, sensible, clearly defined, easy to recognize, and very effective.

    Date field placement in any order other than most-significant-digits-first is not only counterintuitive, but needlessly complicated to work with. Omitting critical information like the century is ambiguous and confusing.

    We don't live in isolated villages any more. Mixing and matching those problems by accepting all the world's various regional and personal date styles, especially with no reliable indication of which ones apply in any given case, leads to the hodgepodge of error-prone date madness that we have today.

    The 2024-09-02 format should be taught in schools and required in official documents. Let the antiquated date styles fall into disuse outside of art and personal correspondence, like cursive writing.