- The last link is broken. GitHub repo: https://github.com/howerj/muxleq
- From the article:
> At this time an open source HDMI 2.1 implementation is not possible without running afoul of the HDMI Forum requirements.
I wonder on what basis. Perhaps an obligation to ensure the software resists reverse-engineering?
- > different people need different levels of explanation
> the further a person is from understanding how the Linux kernel works, the more iterative the explanation will need to be
Good points. Reminds me of how science is communicated. The target audience of a research paper is other researchers. If the target audience were broader, it would have to be more akin to a textbook.
- > optimizing for speed
You presumably mean prioritizing development speed, which is essentially the opposite.
- That's a little vague, I'd put that more pointedly: they don't understand how the C and C++ languages are defined, have a poor grasp of undefined behaviour in particular, and mistakenly believe their defective code to be correct.
Of course, even with a solid grasp of the language(s), it's still by no means easy to write correct C or C++ code, but if your plan it to go with this seems to work, you're setting yourself up for trouble.
- I realise it's not a very substantial point, but it makes me wonder why ARM went with AArch64 rather than just officially naming it the obvious choice of ARM64. ARM64 is both snappier and much clearer as everyone immediately knows you're talking about ARM.
- Agreed, and Google developers can probably be trusted to 'act responsibly', but too often people forget the distinction. Some Rust codebases are wildly unsafe, and too often people see written in Rust and falsely conclude it's a memory-safe codebase.
- > I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation.
It would need to be written in the Safe Rust subset to give safety assurances. It's an important distinction.
- Some Blu-Rays have major spoilers in their menu animations, and some have unskippable ads, some of which may contain major spoilers. [0] It's also a criminal offence to create a backup, thanks to the DMCA.
On the plus side, all UHD Blu-Rays are free of region-locking.
- Inventing a Star Trek-style teleporter would be quite something, but I don't see how it would advance the philosophy in any way. We already know the teleportation subjects would report 'feeling just the same' as before. If they didn't then by definition it's not a functioning teleporter, as it accidentally modified the subject in transit.
- Assuming you use Qt Widgets.
As far as I can tell, Qt Quick doesn't have anything like the same set of polished widgets that integrate nicely into the target platform. It's been this way for years, they just don't seem interested in implementing them.
- > Surely you can see that an inner implementation of the icon class requiring a special hidden order
In practice, programmers don't find it easy to keep in mind that certain functions might throw. This is a real problem with unchecked exceptions and with C-style error codes that sloppy programmers might ignore entirely.
> [...] on which properties to set first can happen in any language
A carefully designed library using a statically typed functional language, especially a pure functional language, might sometimes be able to eliminate such hidden ordering bugs.
Rust used to have a feature to help the compiler detect invalid ordering of imperative operations, called typestates. This feature has since been mostly removed, though, as it saw little use. [0]
> isn't related at all to whether you use try-catch handling or error values as return codes
I guess Chen is assuming a reasonably diligent programmer who makes a habit of never discarding status/error values returned by functions. C++'s [[nodiscard]] can help ensure this.
(Of course, outside of C++, those aren't the only options. Idiomatic Haskell and Zig code forces the programmer to explicitly handle the possibility of an error. Same goes for Java's checked exceptions.)
> What he seems to be saying is that "obviously in C I would be checking the icon handle for being non-null so clearly error value handling is superior"
I don't think he's exactly arguing for the C-style approach, he's more just criticizing exceptions, especially unchecked exceptions. I agree the C-style approach has considerable problems.
> It's just that exception based code doesn't pretend that it cannot panic somewhere where you don't know.
With checked exceptions, you know precisely which operations can throw.
> Unchecked exception handling is the best way to fit that paradigm, you should not have to care about every single line and what it does and constantly sort of almost obsessively check error values of all the APIs you ever use to have this false hope that it cannot panic because you did your duty
You do need to care about every line, or your plausible-looking code is likely to misbehave when an exception occurs, as Chen's post demonstrates. Unchecked exceptions deprive the compiler of the ability to ensure good exception-handling coverage. There is no error-handling model that allows to programmer to write good code by pretending errors won't arise.
(I presume that by panic you mean throw an unchecked exception.)
- > don't have to write code for that exceptional behavior, except where it makes sense to.
The great Raymond Chen wrote an excellent blog post on how this isn't really true, and how exceptions can lure programmers into mistakenly thinking they can just forget about failure cases.
Cleaner, more elegant, and harder to recognize https://devblogs.microsoft.com/oldnewthing/20050114-00/?p=36...
(ctrl-f for taskbar to skip to heart of his point.)
- Agreed. In Java land, if I understand correctly the OpenJ9 JVM can (or at least could) beat HotSpot in memory consumption, while being slightly behind in execution times. It still sees only limited adoption. This may be just because it's seen as an 'alternative' option, less trustworthy than HotSpot, but it also seems to indicate the HotSpot developers aren't prioritising memory consumption.
https://bell-sw.com/announcements/2022/06/28/hotspot-vs-open...
https://eclipse.dev/openj9/performance/ (non-impartial source, of course)
- > nobody else besides the manufacturer could write the drivers for it to extract the most performance out of it
Let's not go too far here. Reverse engineering and independent development of usable drivers are not impossible, they're 'merely' extremely challenging. Alyssa Rosenzweig in particular had great success reverse engineering the Apple M1 GPU and writing drivers for it, and that was just a few years ago.
- > I was a big fan of a good keyboard-driven git TUI like magit, neogit, lazygit, etc... (as long as you learn the CLI first and understand it).
How about tig?
- ziml77's point is about the behaviour of the C# language. You seem to be talking about implementation concerns. They're not relevant.
- > I'm Irish and have a common firstname.lastname@gmail.com
At the risk of nitpicking, @gmail.com email addresses use a dots don't matter policy [0] so really you have a common firstnamelastname@gmail.com and are free to add dots wherever you like.
- I agree that's a poor way to teach matrix multiplication. This topic arose last year. [0]
Don't introduce any clumsy nonstandard transformations like 'rotating' a matrix, just highlight the relevant row and column. [1]
[0] https://www.hackerneue.com/item?id=41402224
[1] https://www.mathsisfun.com/algebra/images/matrix-multiply-a.... (from https://www.mathsisfun.com/algebra/matrix-multiplying.html )
Regarding WASM at least, it seems to depend. https://arewefastyet.com/