1,329 karma · joined January 8, 2016
I mainly work with .NET and I did a search for the term "prompt engineering" on one of the biggest website for job adverts in my country. Out of almost 800 offers only 9 mention the term "prompt engineer". Changing that to "AI" produces around 200 results, but many of these are typical throwaway lines like "our company uses the newest AI tools" that doesn't mean anything.
Maybe it's different in other regions or tech stacks, but so far I am not seeing anything that makes me feel I need to take any of this seriously.
It's absolutely fair to mock them for not releasing these games and keeping radio silence all these years. They managed to dethrone Duke Nukem Forever.
There were multiple times in which the internet was hyped for Episode 3 and where it would make sense to release even a basic game like they've did with Episodes 1&2 just to wrap things up. I'm sure plenty of people that make up various explanations to why that happened but the end result is that Valve has chosen to disappoint the fans who have been waiting for the conclusion to the story. It's not like doing that would prevent them from releasing an another new entry in the series that uses revolutionary new technology or whatever.
GIMP is a great example. For decades anyone asking about "open-source Photoshop" would be redirected to GIMP even though GIMP is nowhere near as good as Photoshop. Years pass and some simple things that are a no-brainer in Photoshop are still a nightmare to do in GIMP. Text stroke is one of such examples, there's no easy way to do it with GIMP and the method you can see online looks bad and can't be easily changed afterwards. Why? Or something as simple as picking a size of a brush - why is selecting small sizes such a pain while selecting gigantic brushes that hardly anyone uses is not? Shouldn't it be the other way around?
Desktop Linux is an another example. It's always presented as an alternative to Windows (or even better than Windows) and when someone tries it out and it doesn't work for them the end user gets blamed for using the wrong distribution, having wrong hardware, not being able to solve issues right away despite being a beginner or even hit with the legendary "works on my machine". It's always the user who is in the wrong and never the software.
All of this gives OSS a bad name. There are always a bunch of small, annoying problems that affects end users and which often go unfixed for years. Whenever one of these end users brings up these problems they either get told to use a bizarre workaround or get a snarky response about submitting a PR or something. This kind of contempt towards the end user seems to be surprisingly common in OSS circles.
I don't think this is fixable. It would require the OSS community as a whole to change and this will never happen.
I think that's because it seems to be primarily trained on reddit and therefore mirrors everything reddit stands for. Not a good thing considering just how overrun the site is with bots and political activists of all kinds.
I agree, part of why I detest frontend and its' ecosystem is because these things seem to be always in motion and there never seems to be a solution that is just "good enough". This seems insane to me on a conceptual level because in the end it's just putting things on display on the internet which is something we've been doing for decades. And it's not like things have got better for the end user anyway seeing how so many websites written in these frontend frameworks are abysmally slow.
I wouldn't have much issue with the state of things if I was just a hobbyist making my own website for fun but I do mind when the job market constantly demands something different. I'm glad that React is the de-facto winner because this is what I need to know to get a job but I still see positions that require Angular or Vue.js and I don't even bother with sending my resume because I know I will be rejected. From my experience most companies do not care that you have worked with a different framework in the past, they expect the exact one they've listed.
Because the script is embedded and requires the runtime of that proprietary legacy application and there's no way to make it run outside that runtime. Think of it as trying to add unit tests to Excel macros.
* write your new code somewhere outside the main solution and call it from the old solution
* automated tests are pretty cool and you should write these whenever possible
I found the book to be close to useless when I was working with actual legacy code. How do I write an unit test for an application that has an embedded Visual Basic script support with dozens of scripts that are thousands of lines long? The book does not answer this question at all because the author assumed I have the luxury of working with Java or an another language that supports the object-oriented paradigm and can be endlessly extended with no limitations whatsoever.