dpc_pw

From my PoV, FIPS is bureaucratic nonsense and people trusting in it deserve what they are getting.

It might have had sense a long time ago, to ensure that vendors don't do something ridiculous and call it a day. It does mandate certain thing that are common sense and good practice, yes. But you can't really mandate security via a checklists from 10 years ago. Government can't keep up with cryptography, software bugs being discovered, new threats and so on. It's just too slow, and requires more than just going through a checklist.

The exact details of how things are done at the lower level are simply insane. It's very common that the FIPS-certified product has security strictly lower than non certified one, e.g. because the certified FIPS base had bugs, that are known, trivial to get fixed (3-liners, etc) but can't because that would take months/years and hundreds of thousands of dollars to re-certify the whole codebase being patched.

The whole thing was probably created by lobbyists to create another corrupted channel to monopolize and overcharge government and related institutions, just like many other nonsensical laws in the US.

Not sure why all previous comments are all negative. I can read this article just fine, it has nice examples, and presents the vision I also agree with - I don't want strict Dev vs DevOps split, I want Devs to be more in charge of the infrastructure of the application, and as a primarily-Dev I don't want to be dealing with bunch of half-assed DSLs that break under any complexity. I want to write a piece of code in my language of choice and use it to generate the infra description.

BTW. I very much doubt V8 is OO, other than having to support "JS objects" as a part of it's own data-orientation.

> Steelmanning is realizing that you can write data oriented code in OOP projects.

It's going to be arguing about names and definition, but I can't accept that it's OOP, when that put qualifiers on all "4 tenets of OOP", etc. Something like:

    - Abstraction(*)
    - Encapsulation(*)
    - Inheritance(*)
    - Polymorphism(*)

(*) where useful, when necessary, but ... generally avoid.

If someone could tell me which book is "The BEST OOP out there, then I would be happy to read it and then argue with it" :D

C developers are denying sad reality of obsolete archaic ideas, poor ergonomics, crappy tooling, security nightmare, unreliability, and language that is impossible to scale in a bigger team settings (don't bring up Linux; I am a kernel dev; Linux kernel is relative small, carefully engineered core, and majority of the weight are a leaf nodes of device drivers, implementing small and carefully engineered interfaces).

True. Though I guess I don't have a chance to reverse the river made out of a constant stream of developers produced by universities and bootcamps, who think "Cat extends Animal and makes_sound with "meow" and Dog extends Animal and makes_sound with "woof".

I'll try to keep it in mind if I'm ever to make a book or something like this about this subject.

Oh. I find subject-verb-object interface another dimension of debate altogether. Usual it's being mentioned by FP devs, since they are usually very aware of that aspect since they don't get to use it. :D

It's not only that SVO is more suited from linguistic reasons. Selecting the "object/doer/subject" first is just a better UX in all sorts of human-interfaces (e.g. games). It allows narrowing down the context naturally, improving discoverability (like auto-completion). Big part of the reason why I switched from Vim to Kakoune.

Subject serves the purpose of being a mini namespace/module and context for operations.

In a way, I blame FP community for being so stubborn in their mathematically-inclined notation, and not experimenting enough with trying to achieve similar human-friendly notation. But maybe I'm just missing all the historical attempts or something.

One of the most interesting spins on the topic is "subject-oriented programming" from Hoon (which is native PL for Urbit OS), where every expression is always evaluated in ever-present implicit subject context, and results in a new subject which will be used for the next expression.

From my experience, the modern Java-style OOP that I've worked with (some of which I produced myself) through all these years leads to terrible code, and all the data-oriented code I've seen and produced seems much, much better in comparison.

Other programming styles are often orthogonal. One can have mostly functional OOP and mostly functional data-oriented software, or imperative OOP vs imperative data-oriented software and so on.

I'm mostly focused on OOP vs data-orientation. OOP means a fixation on modeling everything as "a graph of encapsulated objects with associated bits of logic calling each other" while data-orientation means: "pure logic decoupled from data, and a data stored and passed in mostly non-abstract, concrete ways to support required computation".

The success of OOP is dubious: mostly judged by it's popularity, which is mostly driven by it being a default methodology tough to people in school. When you look at the actual industry, most of the fundamental, long-lasting software is actually written in some form of data-orientation. From kernels, system tools, things like redis, other databases, etc. Though one could tell that it's because fundamental software is usually system software, and not business-logic software and that's true.

I don't have evidence, and it's all just my experience, reasoning and intuition, and I'm intellectually open for debate here, but IMO fundamentally splitting data into small encapsulated chunk that form a graph of native references to each other is just a terrible way to organize any form of computation. I don't want to repeat myself, so please see my reddit post that I linked before for more details.

That's a very interesting observation, that is very much aligned with my own views, but I'll need some time to absorb the details here.

I'm myself on the quest to fully understand what is really wrong with OOP and then try to share it with more people. It's actually very hard because it's a complex topic, ridden with subtleties, and even the exact definition of "what is OOP-code" is elusive. I've just recently made a reddit post that you (and other's who find your post interesting) might also enjoy: https://www.reddit.com/r/rust/comments/ju5oqp/how_to_avoid_r...

I wish there was some "OOP-deniers" community, where we could discuss things like that with an open mindset. Usually discussing OOP degenerates quickly and it's impossible to even establish some shared understanding.

Yeah, sorry. That's just a bit of unwarranted speculation because I've just seen something like this: https://theconversation.com/covid-19-vaccines-could-go-to-ch...

What would you expect from a crowd of people who routinely test their code in production "because run fast, break things, yada yada". :D

"I've run my unit test 10 times and it always passes! Rock-solid. Deploy to prod! Why do you want to waste our time executing it on staging env?! What are you, some kind of a unit-test denier?! There's a production issue affecting customers, there's no time for that. Anything goes wrong, we're just restore the prod DB from the last good backup."

The way I see it... if the vaccine creates some long lasting complications in 0.1% of people who took it, than it is not going to be much better than the disease itself, given that it shifts the problems from the older population to the younger one. This wouldn't be a problem if the vaccine was rolled out at a normal pace with plenty of controls to figure out any issues and put breaks on it if any unexpected problems were detected.

But it looks like the crowd is already set on mass delivering it ASAP, starting with the kids. So, oh well... YOLO.

BTW. Funny how "big oil" and "big tabaco" "evil, greedy, corrupting science", but "big pharma" ... "real scientists! our noble saviors that can do no wrong, and make no mistakes motivated by financial gain".

Ah... Factorio. The best job you'll ever have.

Languages like Java (which was THE statically typed language around that time) were extremely verbose and inexpressive. It's hard to write anything in Java without metric tons of boilerplate and repeating the type of every value over and over and over again.

On top of it, with OOP languages it's very easy to box the code in deep layers of ridiculous inheritance taxonomies, making it pretty much impossible to refactor anything after business requirements changed. Barely any escape hatches and absolutely no flexibility.

And type-safety is kind of pointless when everything is of a given type "OR NULL".

I was always proponent of typing but after working with Java, I can totally see why so many people back in the day considered static typing as not worth it.

> I love that there are so few limits in "software world." No pesky laws of physics.

Actually...

Laws of physics are very important to software engineering. Stuff like speed of light and ability to disperse heat have a tremendous influence on how computation can and is done, and how we design software systems.

Then there are laws entropy and complexity, math laws & cryptography, social laws (how do people cooperate), game theory, economic laws and legal laws. And bunch of other stuff that I forgot about now. All greatly limiting / shaping the way we can create software at scale.

Software engineering is one of the most (if not the most) complex forms of engineering out there. A lot of people don't realize it, since they routinely work with tiny parts of the whole picture. Writing a typical REST API backend, or making a RPi blink an LED is like civic engineer building a popsicle stick bridge. Sure it's fun, but that's not "the whole field".

Stop pretending that there's an easy empirical answer to everything, and accept the nature of complex domains.

Are you worried about Sweden too?

https://www.youtube.com/watch?v=MljLpcD0VWM

Deaths flat in case you were wondering: https://www.google.com/search?hl=en&q=sweden%20deaths%20coro...

Realistically speaking social media companies should be regulated as public utilities. That's just recognizing the fact that they are natural monopolies. Saying "delete your account, and practically ostracize yourself from public discourse into irrelevance" makes as much sense as saying "you don't like your water company? just use another one". Technically we could live in a society in which this is true, but in practice we don't.

Ethereum is only used for PKI, and it will eventually be replaced by a different system. Urbit is really not a blockchain-y project.

10? Huh. Feels like at least 50.

Blockchain as a data-structure gives you tamper-evident, append only database.

Blockchain as a system (datastructure + PoW) solves consensus & trust between agents in a trust-less and censorship-resistant way (without introducing a trusted party).

The original poster is right. Blockchain solves distributed trust. Scarcity is a particular rule, and blockchain is solving a problem of trust in that everyone are obeying that rule. You can have a blockchain that enforces completely different rules, where scarcity don't matter. And you can have scarcity in a system where trust is not a problem (trusted central party).

Seize the means of personal computation, switch to Urbit.

Exactly. Employment and benefits requirement will completely eliminate part-time and flexible-hours workers, and other people that were really benefiting from this type of work.

I take it as a "no". You nor California's government have no better options for them.

> The alternative scenario...

Another scenario is that Uber hikes prices, people cease to use their services because they are too expensive, and the company fails, and all these drivers lose their jobs, and customers lose the service, which will double-hurt the working class because rich people can afford their own cars and/or expensive taxis.

The drivers are not exploited. Had their have better options, they would be working elsewhere. You want to help them, give them better options, make opening business easier and so on. Not kill their options.

Ehh... I'm wasting my time... Socialists are the worst enemy of the people the claim to want to protect.

Is not being able to work for Uber and being unemployed more fair? Or do you or California's government have any more fair deal to offer these people?

> here is decades of system development behind the C/C++ ecosystem and coming onto a C/C++ thread (about a package manager) and calling things a "shitshow" is not going to win people over.

But it is as shitshow. Pretty much everything in system programming is a shitshow. From the moment you boot up a computer, it's just continous stream of bad ideas, lack of foresight, incidental architectures, hacks, bugs and workarounds all glued together with a duct-tape. That's what system development really is.

Everything we do in mainstream system computing is a shitshow. The fact that people are afraid to put any computer to handle public Internet traffic is a shitshow. It's a shitshow, everybody knows it's a shitshow and we even have whole mature industries sucking out a lot of money out of economy to deal with that shitshow.

Anyone that can't see it's a shitshow can't really be "won over". They will happily live their lives being quite skilled at navigating this shitshow, and repeating stuff like "UB is not a problem", "security bugs are only problem of bad developers", "modern C++ is mostly-safe", and so on.

The biggest shitshow... the meta-shitshow here, is how many people in systems development can't see it's a shitshow. They never ventured to investigate ideas from outside of the Unix/C/C++ bubble and tried to incorporate it into systems programming.

And just to be clear... Rust is not completely shitshow-free, and is just a small pocket of almost-shitshow-free environment in a vast shitshow ocean.

I keep seeing this comments against Moxie and I have never seen any backing to them, and they seem like gross-over-representation of what he actually said.

It's still early, but it is all better than it ever was. No need to fire stars yet, IMO. Just get a planet or even a hosting plan on https://tlon.io/ (as soon as they open).

He was building circles around other languages. It worked great. All circles were nice, neat, perfectly round like Lisp parenthesis and inside those circles other developers using unenlightened languages were getting actual work someone cared about done.

1021 bytes of JS, and 6 million lines of browser code.

FTFY

These modern demos, using OpenGL and now the whole web browser that are mimicking the rules and sentiment of old 8-bit machines demos, or even later DOS demos, are not the same thing.

Oh, this demo has text being spoken ... how was it done ... checks source code ... SpeechSynthesisUtterance . Yeah right, 1021 bytes. :)