miffy900

'The world' in this case also includes a large portion of java programmers; it takes years for Java programmers to adopt new language features, if they do so at all. They're almost as bad as C++ devs.

And if you consider the history of Java as a language since the 1990's, it has historically had very slow feature releases. If you review the release history of Java, almost half of major relases and changes to the language came after 2014+. var in Java came out in 2018, record was introduced out in 2020 - feaures that were copied from other languages that already had them for years. Java as a language is still is playing catchup here.

> How do the costs of running the .NET 7 codebase compare with running something open?

.NET has been open source since .NET Core 1 in 2017. The source code is on GitHub: https://github.com/dotnet/

> Also, one might hope that a freeware GUI editor will see the light in not too long.

Have you tried Inkscape for editing SVGs? It’s more of an Adobe Illustrator wannabe but it’s not half bad.

I took a look at rescript's facillities for migration from JS and at step 1 (https://rescript-lang.org/docs/manual/latest/converting-from...), it tells you:

> First, copy the entire file content over to a new file called src/Main.res by using our %%raw JS embedding trick: > %%raw(`const school = require('school'); etc. `)

I stopped reading there - I'm sorry but that is horrifying. Wrapping JS in in a big backtick string?! No. That's even worse that Dart-JS interop.

I think it's better to put aside the 'who' and focus on the 'what'. Knowledge, wisdom/insight can be found in any person, regardless of who they are, their credentials, their geography/location, or their ethnic background etc.

Yeah, the vast majority of content out there is not worth your time, but if you're here then you probably regularly browse Hacker News, and chances are the author does as well, so the author probably wanted to get his blog out there to people who at least shared that one thing in common.

Now putting aside the 'who', in this particular instance, judging the article entirely on its content: it's bullshit. It reads like someone bought into bullshit one year then was proven wrong, but only partially repented the next year. The fact the author arrived at such ludicrous conclusions about sleep in the first place leads me to conclude they're an idiot.

> I don't understand why Flutter's creators are so seemingly religious about Dart

I think Dart's history might be relevant here. Flutter was unveiled at a 2015 Dart programmer conference (https://www.youtube.com/watch?v=PnIWl33YMwA) and it was originally called Sky. Dart doesn't exist because of Flutter, it's the other way around.

Dart was originally intended to be a replacement for Javascript back in 2011, but it utterly failed to gain any adoption because about a year later in 2012, Typescript came out. Typescript being a superset of JavaScript I think completely destroyed any chance Dart could catch on for its original web development goals, since you didn't have to dump JS entirely, just rename .js to .ts and gradually start type-hinting code. Even within Google, they abandoned Dart for Angular and went all in with Typescript.

In a way it's refreshing to see Google re-tool an existing language, rather than invent a whole new langauge for cross platform app development, seeing how often as a company, they kill off projects quickly and start whole new ones.

No Maui doesn't support Linux desktop and Microsoft engineers have specifically acknowledged this and so far there are no plan to support Linux desktop.

https://github.com/dotnet/maui/discussions/339

> Except virtually everyone I spoke to was unaware of what his final posts on social media on jan6 were, they were not covered,

And who are these people you've been speaking to? Clearly they're living under rocks.

> and they were lied about for years with no way for the public to see that in fact he called for people to go home peacefully on jan6.

"no way for the public to see" ??? This is nonsense - he first called for people to go home on Jan 6 via a televised announcement, then repeated that on social media, before being banned. The TV announcement was covered and broadcast by multiple TV networks.

Just 3 seconds of Googling brings up this youtube video: https://www.youtube.com/watch?v=3_JxN9CwIMU

Oh and it's CNN coverage, of all networks!

Trump: "I’ve known Jeff [Epstein] for 15 years. Terrific guy, He’s a lot of fun to be with. It is even said that he likes beautiful women as much as I do, and many of them are on the younger side."

Apparently Trump is OK with pedophiles.

> Again, the reason for TypeScript's success is a separate topic, but node is the go-to backed if you intend to build with typescript. All things being equal in the interpreted scripting language world, typescript's type system sets it far ahead of php/python/ruby.

Absolutely. The sad thing for PHP is that they had the opportunity to pioneer static typing in web development that TypeScript has made so popular, and finally break from all the quirkyness and crappyness of the language in the early 2010's when Facebook released Hack and XHP (https://docs.hhvm.com/hack/). At the time I worked as a PHP dev and desperately wanted to use XHP (there was a regular PHP extension for it) but couldn't get employer buy-in as they didn't see the point in it.

XHP was basically what React/JSX is now to JavaScript, except for PHP. And Hack is what Typescript is to JavaScript, except for PHP, a sensible, and partial superset of PHP with static type checking. But for years, Hack and XHP languished to get any PHP-dev attention. Why? Ten years ago I couldn't figure it out at the time, but now in hindsight, I believe it's because no one in regular PHP-land at the time recognised the genuine engineering improvements Facebook had just ushered in, because most PHP devs don't approach their work with an engineering mind-set. Could be wrong but that was my experience - a lot of PHP code is just crappy, even in a post-PHP 7+ world, and the only explanation seems to be crappy devs.

> but at the time when node was picking up steam, the php composer experience was terrible, whereas npm set the standard for stupid easy package management

Yes, this is an understatement. Running composer on a Laravel project once, it regularly hit 1.5GB memory usage. This was in the mid-2010's, at a time when Macbooks had like 4GB of RAM. Though granted, npm had the same problem, but with disk space, not RAM.

Generally agree here. However the Apple icons of the pre-flat-design-era, even the really skeuomorphic ones, were always pretty great; I always thought they summed up most of their respective apps pretty well. For instance, for Gamecenter, the icon for it before iOS7 was quartered, with a chesspiece, baseball bat, rocket ship and dart board in each quadrant.

They really didn't need to change it. It's now just 4 coloured bubbles, which symbolises...what? I always thought it was just so...random. It's the most irreverent icon of the iOS home screen since iOS7.

> However, you built your something with a foundation out of your control.

The trouble isn't this necessarily; a lot of business models don't exist unless another company does. The App Store is a good example of this; if Apple just disappears then so many other businesses disappear with it.

The trouble is the fact that the relationship between these two parties is so one-sided. Unless these third party Twitter clients have some sort of contractual foundation to stand upon, then yeah, what they've enjoyed so far is basically akin to an ad-hoc, at-will support, that can be terminated at any time with no notice, for no reason.

> Modern day hieroglyphs? They aim to not confuse or offend anyone, and end up impressing noone. They aim to speak all languages and end up speaking nothing. They aim to inform everyone and end up informing noone.

I would disagree as to the supposed 'aims'. Most flat designers don't aim to do anything - they just kept mindlessless repeating the mantra of 'minimalism' to the point where everything looks the same.

Your use of the word 'hieroglyphs' I think is very apt - because that's what they are: hieroglyphs, and NOT icons, as earlier versions of Windows had them.

Seems so.

I often wonder what things would be like if Apple had improved upon Objective-C by fixing up the underyling C language. Yeah it'd no longer be a superset of C, but so what? Neither is Swift. Swift is great but I wish it was closer to Objective-C in spirit by deliberately being a more lightweight language. It's language spec is gargantuan - they've pretty much succeeded in making it a language as complex as C++.

Merely adding generics and better typing akin to TypeScript's, to Objective-C would've worked wonders and made the transition less abrupt.

If you're talking about "don't full-on wash them in the dishwasher on the 1 hour wash cycle every time you see a breadcrumb drop on the plate and just rinse in warm soapy water and towel dry" then yeah.

In my experience the overhead is only noticeable if you use Entity Framework Core to interface with Sqlite.

The native Sqlite wrapper libraries such as Microsoft's Microsoft.Data.Sqlite have faster performance than EF, but because you're forced to pass around SQL strings, most .NET dev's don't prefer to use them.

> Whenever I have to do code generation in my language of choice, I feel that the language should be able to do that without having to generate code.

A good use of code generation is to relieve yourself the burden of hand-writing repetitive mapping code, especially when modelling the database structure in application code. This is a perfect use case for that. Same is true for generating a client to some external API.

Otherwise I'm inclined to agree with you. A few times, I've written code generators before and realised I could've gotten away with some generic programming.

But that has its own set of gotchas and caveats. Though go has support for some generic programming now.

Most courts try to limit the scope of their rulings as much as possible though. If the case before them only concerned the question of race/ethnicity, and the issue of gender or sex never came up, then Kavanaugh could probably find enough wiggle room to justify joining the other conservative judges and striking it down.

> and I am even okay with going as far as saying "walking into a convenience store, talking to a clerk in a human language to retrieve items in exchange of paper currency" is an API.

This is more apt to call a protocol than an API. An API could conform to this protocol though, in a manner of speaking.

More people commenting here need to pick up on this; this is how it's supposed to be.

The author also mentions:

> In effect, we are shifting complexity from end-developers to library developers.

This is not a valid complaint. This is obvious and self-evident; and also true for any lib developer in any language - you can't avoid it. Libraries exist to abstract away complex logic so those devs consuming the library don't have to worry about writing their own implementation - an app can delegate functionality to a library and this has the benefit of reducing the app's maintenance burden and speed up dev time by re-using another developer's work. And for lib devs, this inevitably requires they spend effort to make their library easier to use.

That's what makes the statement "no 'unknown unknowns'" a bit ridiculous though. How can you possibly assert that there are absolutely NO 'unknown unknowns'? You can never rule them out, and at best can only suspect there's a possibility either way, that they do or do not exist. You can never actually know with certainty.

> - no "unknown unknowns". it's so tried-and-true, there's no surprises

I've always been a fan of PHP too; it was my first programming language that I used to build a shipping application, but saying there are 'no unknown unknowns' in a language as quirky and old as PHP is akin to denying the sky is blue.

PHP 4 + 5 had so many weird quirks, and they lasted a long time because PHP 7 took so long to ship (note there was no PHP 6). When 7 hit, they followed it up with many minor releases to try deprecating/removing/correcting some of those quirks, which itself introduced more unknowns when refactoring legacy code. Suddenly the quirks you were used to for so long were now gone or behaving differently (or more sensibly at least), but this required even more refactoring to account for.

When a language is always changing or evolving you can never know in advance with certainty how new features or changes will change how existing code will work.

I 100% agree, the iPhone 5 form factor was and still remains the closest to the perfect phone.

> I’m hoping and praying that Apple will someday make a modern 5G phone with the dimensions and features of a gen 1. But until then this is my phone. It is literally perfect and there’s nothing on the market remotely similar.

That's probably not going to happen realistically; the mini and iPhone 8-form factor SEs are still pretty good phones.

I bet in the future though the current mini iPhones will probably end up being a future generation SE.

Even then, the OP mentioning that kids don't know about public libraries was NOT a criticism; you quoting Socrates is just bizarrely out of place as Socrates' quote was a strident critique on his perception of the behaviour of younger generations.

Weird you would re-surface that quote in response to that, since I don't think a reasonable person would interpret it as a criticism of younger generations, but of the changing times we now live in.

No one ever starts at a public library to study a particular topic, you almost always go to an internet resource first [usually Google]. And TikTok/the internet generally, has hijacked attention spans, but not just of children, but of adults as well.

> The world is aweful because the economic and political system is aweful. They're aweful because they're run by aweful people, who should spend time on something else rather than being a bad leader. And they're aweful because of the world is aweful.

Is there a reason you're spelling it that way?

I don't think anyone's tried benchmarking protobuf against EXI yet, but I've played around with a .NET implementation (Nagasena: http://openexi.sourceforge.net/) and it does outperform Gzip both for compression efficiency and decompression/runtime performance, so long as you use a schema-accelerated parser. It can infer a schema (turning it into a 'grammar' to use the EXI-specific term), but a properly constructed XML Schema will always be fastest/most efficient, especially in low memory systems.

XML's implementation for this is surprisingly intuitive. But to be fair, who tries to use JSON for modelling something like this? You're better off just embedding the XML in a JSON string:

{"markup": "<div>The <a href=\"https://www.json.org/\">JSON format</a> was invented by <em>Douglas Crockford</em>.</div>"}

Most JSON is consumed in the browser, which also has an XML/HTML parser engine sitting alongside the JSON one.

>Where is your engineering, inventor spirit? This seems snowflakish to me. You want everything handed to you on a silver platter. But the reality is there’s lots of data out there that has no schema and never will. And if you don’t have proper tooling, you’d quit? Why not MAKE your own tooling?

Oh I meant to say I feel the same the way as the OP ('similar sentiments'), but I wouldn't literally quit my job. You're right, there's always going to be data out there with no schema; CSVs are one example. But if in your day to day work you're constantly encountering data with no schema or the structure/format/schema is constantly changing, then chances are you're dealing with a crappy system or working in a crappy job.

And making your own tooling is fun and all for the first time, but there comes a point when after you accrue enough programming experience, you realise how redundant it is, especially if the data is in a format as old as XML for example. There's a massive amount of tooling around XML, from XSLT, XQuery, XPath and all of them have facilities for dealing with schema-less XML data, but if you were to use a schema (or the vendor/3rd party provides one), then 90% of issues (and sometimes even code) dealing with schema-less XML go away. And the same is true for JSON as well.

I find it incredibly funny that people heap scorn onto XML as being some horrible legacy thing to work with, but then will go on happily working with JSON/YAML/or whatever and then have to deal with ALL THE EXACT SAME ISSUES, all the while not realising XML-related tooling has already solved them.

The Carbon API has been obsolete for years now; there's probably no danger of anyone getting confused when they search on Stackoverflow or Google.