miffy900

Interesting that use of Objective-C/C++ is still climbing at a seemingly unchanging, linear rate.

Look, Swift's a great language and all, but it's become grossly sophisticated and complex to the point of being a bloated pig; I wonder if people at Apple are still using Objective-C purely because editing it in XCode is still faster than Swift with respect to autocomplete and compilation speeds.

They acknowledged the exact date in 2022 just before Windows 11 was released: https://learn.microsoft.com/en-us/lifecycle/products/windows...

But even then, what point are you even trying to make? Windows 10, like previous releases before it, when its support end, will mean it was supported for a solid 10 years. I mean, that's a lifetime in tech; 2015 was the iPhone 6s.

No it couldn't have been, from wikipedia:

> The process required at least 60 kilograms of coal per kilogram of synthetic butter.[23] That industrial process was discontinued after WWII due to its inefficiency.

Umm, I guess technically it is? We've known about Windows 10 EOL date for a long time now, since it was first released in 2015.

Say what you will about Microsoft, but they have consistently supported Windows for a MINIMUM of 10 years since Windows XP (2001). That's absolutely a solid record when you compare it to the computing half-life of support that other tech companies usually give. Look at Samsung, or even Google. Hell even Apple maxes out at 7.5 years for it's longest supported device.

What's so ugly about them? I don't code in F#, but I do in C# and after reading about them I wish C# had something similar.

True, but I don't think loss of tone would've mattered much here; almost all of the content of the video itself seems deliberately overwritten; it could be condensed to a tweet or post less than 100 words.

Yep, people forget, but Azure launched as Windows Azure in 2010 - they dropped Windows from the name a few years later, but it was obvious what it was trying to be at launch.

This ignores how feast-and-famine tipping is; there's a high ceiling for potential earning, but it's not always a reliable income; and this also ignores how only those working in front-line service roles benefit.

Are you the kitchen hand washing dishes? Are you the chef or cook who makes the meals and food that the customers eat? Are you a cleaner mopping the floors after business hours? Nope - none of you get a tip, unless the restaurant has a policy of collecting all tips and redistributing them to all employees. But how often does that happen? It's really easy to just pocket the tip and keep it for yourself.

It's supposed to be webpack plugin-and-API compatible, so if you already use webpack, hopefully not (much).

But is this constant turnover getting ridiculous in the web dev & JS ecosystem?

Yes. I simultaneously credit and blame facebook for starting it with yarn; after yarn, the trend of re-writing build tools seemed to become much more acceptable and trendy, especially since yarn (at the time) was multiple times faster than npm; you could argue it was worth it. But now we've reached a stage where the diversity of tools like npm, yarn and pnpm, now tools like ni (https://github.com/antfu-collective/ni) are emerging to manage the diversity.

I think this is getting out of hand, now there are n+1 of them.

From the history page:

> JSON Schema is a constraint system which is designed to validate JSON data. Such a constraint system is not great for code generation, with TypeSchema our focus is to model data to be able to generate high quality code.

Well, types themselves are another type of constraint; specifying something like the type (number) of a property (Age) is a constraint on the possible values for that property.

> For code generators it is difficult to work with JSON Schema since it is designed to validate JSON data

There's lots of features in JSON Schema, but if you're writing a code generator, you don't actually to have support all of them. Some languages like C# don't have native lang support for AllOf, but do support OneOf or AnyOf.

> JSON Schema has many keywords which contain logic like dependencies, not, if/then/else which are basically not needed for code generators and really complicates building them.

So isn't the whole point of code generators for OpenAPI/JSON Schema is that they generate code to map foreign data sources in a target programming language so that the programmer doesn't have to write all this mapping code by hand? The vast majority of all programming languages support if/then/else and even modelling dependencies like what JSON Schema supports. So why is it a bad thing if a schema language like JSON Schema supports these constraints? Wouldn't having support for this in the schema language and a code generator mean less handwritten code and more time saved?

If a schema constrained Person.Age to be an integer always greater than 0, I would actually really love for that validation code to be generated for me. Chances are, if such constraints exist in the schema, then the vendor/original author probably has good reason to include them; having it code generated automatically means I don't have to worry about writing it myself.

I mean if you want to generate the code for only defining data structures & their properties, you can still do that, and just stop there. A whole new schema language in JSON seems wholly redundant. It seems like maybe the authors should've started with writing their own better code generator for JSON Schema rather than their whole new schema language and code generator.

Finally, reading the spec https://typeschema.org/specification, I can't see support for optional values or null/nullable types. I'm hoping it's just an oversight (seeing as how the spec itself is incredibly brief), but if it isn't, then bluntly, then this isn't ready for release.

I recall there was research some years ago that predicted when entangled particles are measured, their wave function collapses (and entangled particles' properties take on definite values between each other) at a speed which the lower bound was supposed to be about 10,000x light speed (c). https://www.science.org/content/article/quantum-physics-gets...

But this seems to measure the speed at which particles can become entangled in the first place, which I always assumed would've been on the scale of Planck time, but 232 attoseconds is pretty long compared to 10^-43 seconds.

Honestly, including an ORM as a built-in 'feature' of a web framework seems like a quaintly reasonable idea at first, but I'm 90% certain that eventually it's going to become either (or both):

* it's own project because maintaining it will take up so much of your time.

* be decoupled from the web framework because users will want to use another because your own doesn't have abc feature.

From observing the ecosystems in .NET, Java and PHP, lots of people have lots of opinions on how ORMs should work.

Not a fan of YAML at all myself, but it's interesting that you like 'Yaml-like object structuring' yet then loathe 'Signifiant whitespace'? I mean that's basically YAML.

This is the embarrassing bit; this is version 4 of a book that predates ChatGPT by years; knowing that probably most of it is written by humans makes me cringe.

For me it's the last sentence: "Once identified, runtime errors are easy to fix." Well no not really - it depends on the issue; sometimes a solution isn't 'fixing' it, sometimes choosing what to do next after identifying the root cause is it's own task. Maybe it's working around it, like amending the return value with amended data, or patching the API itself by wrapping it in an intermediate API and swallowing exceptions. Guidance on addressing runtime errors should never presuppose that 'fixing' it will be easy - it will always depend on the context. Just get rid of that last sentence and it's a better statement.

Imagine instead it's for criminal defense lawyers: re-word it to be advice for attorneys defending their client against a prosecution. "Once [all exculpatory evidence against your client] is identified, defending them against a guilty verdict is easy to do"

It sounds like it's written by someone who has never practiced in the real world.

So at the start of each chapter, the book has a table of abbreviations and their definitions, called 'Acronyms'. To whoever wrote or edited the book: please lookup the definition of the word 'acronym': "an abbreviation formed from the initial letters of other words and pronounced as a word (e.g. NASA)." Not all of the abbreviations listed are acronyms! Most are just plain old initialisms.

Since when has anyone ever tried to pronounce 'GPS' as anything other than G-P-S? Also "ECS" = "Ecosystem"? Maybe I'm just crazy but I've never heard or read anyone abbreviate ecosystem as 'ECS'. I've come across ECS as entity component system in video game engines, but never as just 'ecosystem'. Also it's defined exactly once in chapter 5 and then never used again in the book. Why even bother to mention it then?

Oh and publish it as a PDF, but then have no actual page numbers?

I see at a few models (3 models in MMMU) that score lower than Nvidia's. But putting that aside, they at least get points for apparent objectivity. At least they probably aren't fudging numbers.

What on earth does any of this have to do with sports gambling?

My thoughts exactly; I recall stumbling across libgen back in 2018 - it even had a user forum; back then it was clearly just a one-person operation. I got the impression it was someone who liked collecting, organising and sharing PDFs that interested them. And then with time it, the site blew up in popularity.

It's quite funny you use the term 'low effort' to describe comments here, when you've clearly not done enough research to realise that your idea is not at all novel. Not to mention the youtube video is just a longwinded advertisement, and the article you've written is very poorly articulated.

There are multiple sentences in it that make me think this is all a big joke:

Like: "Languages must be homoiconic", but then you immediately show a language that is NOT homoiconic.

And also "Microprogramming works incredibly well with LLMs. It is easy to mix and match microprograms written by humans with microprograms written by LLMs.", but then show nothing to actually demonstrate that; no demo or even example code. Did you fine tune a model yet? You don't even mention a possible LLM model by name.

And finally: "If the microprogramming trend becomes as big, if not bigger, than microservices, I would not be surprised." I'm sorry but this is hilarious, especially because the vast majority of software out there is not written as a set of microservices, because it's simply the wrong model for most apps, like mobile apps for instance.

You conveniently leave out that same Wikipedia article on Microcode says: "The act of writing microcode is often referred to as microprogramming, and the microcode in a specific processor implementation is sometimes termed a microprogram."

People are just responding to the article which points out the hypocrisy from C-suite level execs.

> It's a big part of why Apple is so fucking rich. Should only Apple be permitted to make real money? I don't think so.

Apple is rich because they've optimized the hell out of their supply chain and through some clever marketing have convinced (rightly or wrongly) people that it's somehow reasonable to charge $200 for 64GB flash storage upgrades on their devices that only cost them ~$20. They are probably the only company in the world that have consistently run 20%+ profit margins on selling hardware ALONE. Their services revenue from streaming and arcade are puny in comparison. Even throw in the cut they take from app store sales, compared to hardware it's relatively small.

That's true but that has absolutely nothing to do with types in programming languages; it has more to do with MS's culture of always favouring backward compatibility and never culling any features in every version.

> Giving up tests and versions, I ended up with a much better program.

This is one of those sentences that is clearly an opinion but stated as if it were some undeniable, incontrovertibly true statement of fact.

In your opinion, you have a better program - but give the code or repository to another dev or a group of devs and I'm sure you'll hear very different things...

> Most of us who were there remember it differently. True open source advocates will find little to refute in what I’ve said.

> Like I said, honest open source advocates won’t take issue to how I framed their position.

Yet you've failed to provide even a single point of evidence to back up your claim.

> "honest open source advocates"

You've literally just made this term up. It's meaningless.

I'm sure you mean well, but it's not going to be most programmers or devs who will need to apply a fix for this, it'll be sysadmin/network/SREs who'll be doing this and they're not going to download Go to build this random github code repo. Because it affects only Windows systems, it'll be way better writing a bat or powershell script that can non-programmers can read and comprehend before they execute anything in production/live systems.

> Meanwhile, more people around the globe classed as Generation Z (those born between 1997 and 2012) seem to be embracing highly traditional religious affiliations, such as traditional Catholicism or Judaism.

There isn't a reference provided for that sentence in the article, but it's something that seems true to me, from my own experience. I'd really love to see some hard research confirming or denying this.

> Or like read the Mueller Report which paints him squarely as a villain

That's simply not true, Mueller investigated Assange, but declined to prosecute due to lack of evidence that he was complicit or culpable in any crimes. He also didn't totally clear wikileaks or Assange, but noted there were 'factual uncertainties'.

I find it nauseating that Assange is being valorized as some champion of free speech/journalism, but with respect to Mueller, Assange was far from being a 'villian'.

https://www.buzzfeednews.com/article/jasonleopold/new-muelle...

The entire article itself presents incredibly poor reasoning or no reasoning at all for its points.

It's really hard to appreciate it now because CSS (along with JS+HTML) has been extended and upgraded gradually over the years, but CSS is incredibly good for styling and formatting DOCUMENTS - which have a very specific definition, especially back in the 90's when it was first conceived. This is what is was originally designed for.

In that sense the complaints about CSS are perfectly reasonable: why are we using a document styling language for building arbitrarily sophisticated web applications when it was clearly not originally designed for that? You could say the same with HTML and JS really.

> Quit acting like CSS is some giant-ass mistake that needs fixing. A group of people who were collectively smarter than us wrote those specs. They didn’t make mistakes. Assume you are making the mistake, not them.

So what year again was the CSS standard was first published? Checks google quickly -- oh it was back in...1996. HTML was...1991. And JavaScript in...1995.

Yes, it's well known that people in the 1990's were much smarter than people in the 2020's! It's not like there's been decades of progress since then! CSS is utterly fit for purose and bereft of any flaw or defect! Absolutely nothing new needs to be invented or discovered about front-end web development in 2024! There's no point in trying to improve things!

OK, it's hilarious the author rails against things like SASS, and CSS is now being updated to incorporate many of the same features that SASS introduced:

- CSS nesting: https://www.w3.org/TR/css-nesting-1/

- Scoping (no more global): https://developer.chrome.com/docs/css-ui/at-scope

- Not to mention things like CSS variables, calc() etc.

Usually people whine about the status quo or things staying the same for too long and in response, try to improve things. This article almost seems like a big whinge about how things should stop changing and regress or go back in time? That's not happening. If people had the author's sensibilities or attitude back in the 2000's we'd never move past `float: left` for positioning or tables for multi-columnar layouts. Utterly bizarre.