fizzynut

It ignores my scroll wheel most of the time if I try to scroll multiple times in a row.

The scroll is delayed significantly from when I scroll to when it actually scrolls.

The amount scrolled is inconsistent, sometimes it scrolls a very slowly a tiny amount because the page doesn't fit on the screen by an unknown tiny fraction, but if I scroll again because it is scrolling both slowly and with delay it now scrolls an entire page.

If I want to scroll past one of the demos I have to wait

If I drag the scroll bar on the side slightly it often snaps backwards.

It feels like I'm interacting with a phone/tablet screen on a computer, there's a reason why windows 8 failed.

A pedestrian has priority on the road, that doesn't mean you should walk into the road with your eyes closed wearing noise cancelling headphones.

10k in 2hrs is 1.5 lines of code per second for 2 hours straight without spending any time to make comments, think about what the code is doing, etc.

In pre-ai era that is just skimming and trusting the person who wrote it or the code changes are largely auto-generated or there exists an exceedingly simple test suite that is incredibly verbose.

Post-ai you are ruining your code base, I probably have to spend 3-5x longer reviewing ai generated code, the code they write tends to be too verbose, mediocre, filled with subtle bugs, adds unnecessary comments, etc. If someone gives me 10k loc pr it's a sure thing they've just let the ai run loose and I'd just tell them what they need to change in general terms instead of wasting days of my time reviewing junk.

I find difficult to know how serious the issue is, if it is even an issue.

LLM constantly confidently giving me this same sounding script with a "the root cause" and how it "is simple" while being completely incorrect.

Every decision has trade-offs. The best design is often the simplest, which can mean combining layers/responsibility in small or throw away projects.

The step above that is to make the simplest design that is extendable.

Often newbies doing "Best practice" results in more code that is overly complex, it splits understanding across too many functions and tries to create too many "reusable" functions that often mean the architecture is often extendable in useless ways but harder to extend when you actually need to do it.

You can usually notice when interacting with these battle scarred pieces of code, if the author is still there there is usually a story for why things are the way they are.

Even if you fixed the initialized data problem, this code is still a bug waiting to happen. It should be a single bool in the struct to handle the state for the function as there are only two states that actually make sense.

succeeded = true; error = true; //This makes no sense

succeeded = false; error = false; //This makes no sense

Otherwise if I'm checking a response, I am generally going to check just "succeeded" or "error" and miss one of the two above states that "shouldn't happen", or if I check both it's both a lot of awkward extra code and I'm left with trying to output an error for a state that again makes no sense.

Unfortunately it was and still is. https://en.wikipedia.org/wiki/Safari_(web_browser)#Version_c....

MacOs is slightly more forgiving in that the last 2 versions can get the latest safari. However, people tend to keep a computer a lot longer than a phone and many don't or can't update macOS, so it's not much better.

Honestly I gave up trying to support apple products a while ago - the fact that iOS and Mac lock the browser version to the os version makes it such a royal pain in the ass to support.

High end machines which can easily pull 100W+ are just bad in general for portability - running at max will last less than 1Hr, will the sleep mode actually work reliably and not drain battery? - this is an issue in most OSes/laptops. Will video playback in the browser not be properly hardware accelerated and drain the battery super fast? yes linux has issues here.

Framework were explicitly ruled out, so: Integrated Oled - you really want some integration, If you can't set the brightness, goodbye lifespan, oled also have many different subpixel layouts which can make the text blurry/fringe, maybe you wont notice but then why buy an oled in the first place for work? While a monitor will definitely have pixel shift/burn in protection built in, if integrating a panel into the laptop without putting in any work, that support might not come out of the box

Even if it was a framework, everything is distro specific, but I think you only need to know that a "dock megathread" exists to realise that "perfectly working" is a stretch and a lot of people have hardware they can't connect and doesn't work.

That said if I was to buy a laptop - a mid end framework I just do the basics with would probably be great.

The memory is shared for the GPU, so you should probably compare with desktop GPU, so 1-2TB/s.

Honestly if you actually need high end specs then you should just build a PC.

"16 core Zen 5 CPU, 40 core RDNA 3.5 GPU. 64GB of LPDDR5X RAM @ 256 GB/s + stunning OLED" - Easily done as a pc build.

In a world where you can get this laptop with Linux, there's a new set of trade-offs -

- be prepared for a LOT of things not working because the size of the market for extremely expensive configurations with high end CPU + GPU + RAM + Monitor + Linux is practically zero.

- when closing the lid and walking to the coffee shop will the battery be dead before you finish your coffee? probably

- will a new GPU/GPU architecture be a headache for the first X years...yes, and if you want to replace every 2 years, I guess you will have a permanent headache.

- will updating graphics drivers be a problem? yes

- is the text in your "stunning oled" going to be rendered correctly in linux? probably not

- will the wifi chip work in linux? maybe

- will all the ports work/behave? probably not

- will your machine perform worse than a high end PC that cost 1/2 as much from 3 years ago... yes.

Doing that will increase input latency, not decrease it.

There are many tick rates that happen at the same time in a game, but generally grabbing the latest input at the last possible moment before updating the camera position/rotation is the best way to reduce latency.

It doesn't matter if you're processing input at 1000hz if the rendered output is going to have 16ms of latency embedded in it. If you can render the game in 1ms then the image generated has 1ms of latency embedded in to it.

In a magical ideal world if you know how long a frame is going to take to render, you could schedule it to execute at a specific time to minimise input latency, but it introduces a lot of other problems like both being very vulnerable to jitter and also software scheduling is jittery.

This would get an error message in C, what are you talking about?

The huge plus of the internet is that you can be disruptive on a global scale on a somewhat even footing to the giants.

If you place a giant burden such that before you even do anything of value you need to conform to 100s of different laws/regulations from 100 different countries you create a world where only large companies can exist and everyone else is pushed out.

A new feature that fundamentally changes the way a lot of code is structured.

A group of features that only combined produce a measurable output, but each one does not work without the others.

A feature that will break a lot of things but needs to be merged now so that we have time for everyone to work on fixing the actual problems before deadline X as it is constantly conflicting every day and we need to spend time on fixing the actual issues, not fixing conflicts.

The depth is 32 bit, not the index into the file.

If you are nesting 2 Billion times in a row ( at minimum this means repeat { 2 billion times followed by a value before } another 2 billion times. You have messed up.

You have 4GB of "padding"...at minimum.

You file is going to be Petabytes in size for this to make any sense.

You are using a terrible format for whatever you are doing.

You are going to need a completely custom parser because nothing will fit in memory. I don't care how much RAM you have.

Simply accessing an element means traversing a nested object 2 billion times in probably any parser in the world is going to take somewhere between minutes and weeks per access.

All that is going to happen in this program is a crash.

I appreciate that people want to have some pointless if(depth > 0) check everywhere, but if your depth is anywhere north of million in any real world program, something messed up a long long time ago, never mind waiting until it hits 2 billion.

Yes, it can be quite brand/technology specific, but chunk sizes of 4/8/16/etc MB usually work much better for SSDs, but the only data I've found to read/write that easily lines up with those chunk sizes are things like video/textures/etc or cache buffers you fill in ram then write out in chunks.

Ai generated slop. Constantly summarising various parts of the memory hierarchy, graphs with no x axis, bad units, no real world examples, the final conclusion doesn't match the previous 10 summaries.

The big problem is that it misses a lot of nuisance. If actually try to treat an SSD like ram and you randomly read and or write 4 bytes of data that isn't in a ram cache you will get performance measured in the kilobytes per second, so literally 1,000,000 x worse performance. The only way you get good SSD performance is reading or writing large enough sequential chunks.

Generally random read/write for a small number of bytes is similar cost to a large chunk. If you're constantly hammering an SSD for a long time, the performance numbers also tank, and if that happens your application which was already under load can stall in truly horrible ways.

This also ignores write endurance, any data that has a lifetime measured in say minutes should be in ram, otherwise you can kill an SSD pretty quick.

You should probably just use a quad tree to put your objects into and traverse that with a path finding algorithm.

From zooming into your clip both ASCII and Unicode are wrong:

- ASCII is off center ~43/50 pixel margins

- Unicode is off center ~20/25 pixel margins

- Both have different margin sizes

- The button sizes of both are the same.

- The Hide button is offset from both 8/10/16 selector and ascii/unicode buttons

- Even if everything was correct, because there is no contrast between "Off" and background, it's going to look wrong anyway

Is it possible to get rid of all the macros TO_FIXED, FROM_FIXED, mult, etc and replace them with a class with the correct constructors / operator overloads?

Then your code doesn't ever need to be aware of the special fixed point math and horrible syntax everywhere and everything just works?

I'm curious why you think Javascript should be on the list, I see a lot of issues:

Javascript generally runs on a website in a browser: The browser must be continually updated on the client side every few weeks at the very least.

Your software must work on all future browsers in 50 years time.

Security patches/privacy/laws/etc deprecate/change API calls regularly.

The website must continually update certificates, maintain payments to providers / keep valid credentials / not get hacked for 50 years.

Most javascript applications have a billion dependencies, and people rewrite using a new framework over updating if it's been a few years, never mind decades.

Keeping dependencies up to date for 50 years is a lot of work.

I don't know of any instances of anything javascript that has run continually for 20 years to date?

Intel basically made the same CPU for about 6 years straight because of 10nm process issues.

They had to keep pretending the next gen "Lake" CPU was substantially different from the last, so they just took last gen product, made some minor tweaks to break compatibility and called it a new generation

An M5 ultra would be the best ai chip for a data center in the same way it would be a good idea to use an array of the best laptop speakers to power a music concert.

If everything you do stays in the rails of QT you're going to be fine. But you try to do something simple like load a 2GB file and everything starts to fall to pieces, then you're going to assume the people that wrote this are super clever and that a 2GB file is too complicated, too niche, too hard of a problem, it needs to be "highly optimised", etc.

The reality is QT/whatever program/framework is doing 100 things you don't care about when loading/rendering a file. If we only care about 1 thing we can do that much better because we don't care about the 100 other things our naïve code we wrote in 5 minutes outperforms the standard element by a factor of 1,000.

Maybe the user wants to do real time exposure/color correction, so you want to minimise the number of frames from the moment of the input to seeing the output. To do it properly the user also would want to see analysis graphs on the screen on the same frame that's being displayed? And do this for 10 cameras at once?

Maybe your definition of "fast" for a large text file is War and Peace, and mine is multiple 1/10/100 GB text files that you want to search/interact with in realtime at a keystroke level.

I've probably written 100+ completely different "very specific examples" in very different industries, because that's where you can create much better experiences.

Generally your expectations are based around what you get as standard from the library, but if you want to get a much better experience then it immediately becomes a lot more difficult.

When you write your own UI, you get used to quickly + easily being able to create custom elements that do/behave exactly as you want and even iterate on those elements to get the best user experience.

Lets say I want to control pan/tilt/zoom/focus/aperture/etc of a remote camera. If I ask lets say an expert in UI framework Z to do it, it will take them 10x longer to create a very painful experience using standard elements with poor input latency, so someone actually trying to setup a camera over/under shoots everything, but it technically "ticks every box". The path to create a better experience just isn't really there and it is difficult to undo/change all the boilerplate/structure, so version 1 isn't improved for years because it took so long to create the first iteration.

If ever you work at a place where the software does not make money or is treated as such then you should consider leaving. You will be treated like a cleaner, i.e. it doesn't matter how well you can clean the office if it has zero impact on revenue, they just want the cheapest.

Everywhere else, your worth is the value you generated multiplied by the number of people it interacts with.

The closer or more direct the path is from the work you do to the value generated, the more you will be valued in that company. This is why Sales can be valued so highly, but if you implement X to win contract Y worth Z where Z is a very big number, your worth is quite clear and it's obvious you should move on if you're treated as a cost in such cases.

I think the author has discovered memory bandwidth. When you have a simple function and just scale the number of cores it's easy to hit.

It is a common use case.

Every time you buy a computer it is generally going to be "bleeding edge" to various degrees and it's unlikely to work properly for X months/years.

It is only because people keep their machines for several years that the "average" machine running linux is several years old, yet it seems like a rite of passage for people to blame the user for having the audacity to buy a laptop that isn't 10 years old with X and Y but avoids Z wifi chipset.