I like the alpine-ajax API. You specify one or more targets and it swaps each of those elements. No default case or OOB, just keeping it uniform instead.
As for Datastar, all the signal and state stuff seems to me like a step in the wrong direction.
I really like Clojure, it's the language that finally made FP "click" for me. It was my go to for hobby/side projects for quite a while.
Dynamic typing is why I eventually switched. Haskell scratches the same itches that Clojure did, but the compiler and type system are immensely helpful, and keep saving me from tripping over my own feet.
Somewhat off topic: My problem with Haskell is that every time I've tried to read the documentation, I've felt like I needed a PhD in type theory to understand all of the terminology. As a practitioner (not a researcher), I just want to know how to do things, but the documentation has always been a roadblock to me. So, after a number of attempts at learning to use Haskell, I've decided its not for me. Not because of the language itself, but because of the traditions around it.
This. I think I understand the basic concepts, but you get a first big slap with doing your first curl to some other service. Ergonomics of the libs is often times horrible. You are in this constant loop, oh I can't do this I need algebraic derationalizer to align those types. Several hours later your curl request works. You start looking at wall to decompress. Curl is a pretty good example its a complexity that has been made super easy in a lot of languages.
I am very much waiting for some "extremely" constraint subset/flavour of Haskell that gets some adoption(I do not think I am alone in this lobby). No crazy stuff, no "just read the types", no "its just a small extension".
But I also know that it is not really feasible without breaking the IO enforcements.
For one thing, new games on Linux should no longer be targeting a platform that should have been phased out before Steam even launched on the OS.
And people will no longer need a duplicate set of libraries on their machines, all the way down to the gfx drivers. New software, and old stuff with 64-bit support, should have a lot less compatibility issues.
Actually, AMD's latest design, the RX 4x0 series, measures up really well to NVidia's mid and low end cards, especially for Vulkan/DX12 apps. They're not a contender in the enthusiast market, but will be releasing high-end cards using a refined design in the first half of 2017.
As for drivers, AMD has pledged to open source their Vulkan and OpenCL implementations. While that release has been pending "legal review" forever now, alternative open source drivers are making great progress thanks to Vulkan's simpler driver model.
While NVidia's generally had the "better" driver, both from adhering less strictly to the spec and having the manpower to routinely fix application bugs in their driver, that's all changed with Vulkan/DX12 being significantly closer to the hardware.
No thanks. I can see this kind of legislation turning any online presence into a horribly expensive bureaucratic nightmare while accomplishing fuck-all security-wise. (At best.. Given current governments' track record, any privacy act would be all about stomping on people's privacy.)
I'd rather not be subjected to (and pay for) more security theater, or see every small business out there drown in a paper mill suitable for the fortune 500s.
As someone who has worked in multiple regulated industries, including with HIPAA, what they accomplish is rarely the intended goals.
Regulation is a weapon to be used by powerful interests to bash competitors. For example, utilities love regulation as it gives them a de-factor monopoly and predictable income.
The medical industry widely ignores HIPAA in a holistic way. Ask any practice you visit about their handling of medical records, IT security practices, etc. Heck, ask them if they still use Windows XP.
> For example, utilities love regulation as it gives them a de-factor monopoly and predictable income.
This is kind of nonsense argument, because most utilities are monopolies by design. The idea is to give utilities a predictable income stream in return for agreeing to abide by certain public interest policies.
I get that that is the idea. The reality is that most utilities pass along their expenses, whatever they are, into a "rate case" with a percentage tacked on top. That is opposed to every other business where more efficiency == more profit and decreasing prices due to competition.
Models of efficiency, they are not, to the point that their inefficiency severely hinders their ability to serve "the public interest." They also tend to use their size to squash any potential competitors in their space (see power companies with private solar and the telecom industry versus VOIP).
> I get that that is the idea. The reality is that most utilities pass along their expenses, whatever they are, into a "rate case" with a percentage tacked on top.
Again, that's by design. The public authority sets rates at some fixed cost plus reasonable rate of return on capital. The idea is to encourage potentially very expensive capital investment without the perceived danger of subjecting a critical utility to the ups and downs of market pricing.
And utilities act to squash competitors because lack of competition is the whole quid-pro-quo of being a utility. Utilities don't make Twitter-like 30% margins with double-digit growth. The reason private capital is willing to sink money into them is that they get their consistent 10-15% return on a regular basis. Competitors not only upset the arrangement, they can quickly jeopardize that margin.
I'm not defending regulated utilities. I think they're mostly a bad idea, but judging by the discussions around here where people talk about the wonderfulness of water utilities, lots of people are on board with sanctioned monopolies with guaranteed rates of return. But the flaws you're pointing to aren't "abuses of regulation"--they're a conscious bargain between municipalities and utilities.
> Do you honestly think patient information would be safer without HIPAA?
Quite possibly; the privacy and security portions of HIPAA were included to mitigate the risks associated with the push for electronic systems and standardized data that were more central to HIPAA -- and the enhanced privacy and security features added later in amendments to HIPAA were furthering that in the context of increased standardization and automation that was being promoted in the same legislation; without HIPAA, you might not have as much formal protection of patient data, but you also might have a lot less data in forms that were easy to compromise en masse in the first place.
(Of course, that would also have consequences for administrative efficiency and quality of care, and without HIPAA and the related subsequent acts that included those patient protections as mitigations to potential negative effects of their primary functions, the US might have the least efficient health care system in the developed world by an even larger margin than it currently does, which, even if HIPAA does net some increased risk to patient information, might not be worth the cost.)
> I can see this kind of legislation turning any online presence into a horribly expensive bureaucratic nightmare while accomplishing fuck-all security-wise.
One of the sources of a push for federal standards is frustration with multiple conflicting state standards doing the same thing.
Why do you want to learn C or C++ if you can't think of something you'd like to use them for? I've written a fair bit of assembler and occasionally still do tiny projects in C or C++, but my language of choice (by far) is the highest level general purpose one I've come across.
IMO you don't need to know either C or asm to be a great programmer. Read a book on operating systems instead and you'll know all you need to about hardware. Add a thorough coverage of algorithms and data structures, and you're in a better position to write effective software than many I've worked with.
As for Datastar, all the signal and state stuff seems to me like a step in the wrong direction.