HN user
https://patrickmn.com/ | @pmylund
Co-founder and CTO of Clovyr, a company that makes it easy to build and use decentralized applications
You can literally do whatever you want with any library you use in your own codebase and have a consistent convention in your own code regardless of what your dependencies' authors preferences are. In other words, if the library authors used camelCase but you want to use snake_case in your code, you just do it.
It's very strange at first, and I had the same reaction as you, but it's actually quite nice. (I say that as somebody who strongly dislikes snake_case :) )
never even heard of that kind of bonus. it sounds like it's designed to work exactly this way.
You are practicing eastern philosophy :)
The Man From Earth is wonderful. The best ultra-low budget movie IMO.
Hahah this gif https://ufincs.com/assets/images/features-autocomplete-5B771...
Looks very, very nice for a solo project!
What's the best example of modern Datalog?
Readers may also be interested in LiquidHaskell:
https://ucsd-progsys.github.io/liquidhaskell-blog/
https://ucsd-progsys.github.io/liquidhaskell-tutorial/01-int...
The Python hypothesis package strikes me more like a dynamic version of Haskell/LiquidHaskell than Haskell/hedgehog.
Honestly, it's shocking that this came as a surprise. It's like they don't know why they made Gitlab self-hostable.
not
The article is about Laetiporus sulphureus. The article clearly states that amateur foragers mistakenly eat Laetiporus gilbertsonii and Laetiporus conifericola and experience gastrointestinal problems.
I have not heard many companies really conceptualize their “supply chain” exposure from the myriad of scripts/dependencies injected via tag managers and other software.
I made a thing called "TrackerMap" that allowed people, mostly Fortune 500 web/risk/compliance people, to do just that: https://www.crownpeak.com/products/monitoring-solutions/tag-...
(It has since been acquired, and I have no affiliation.)
You might be interested in Tahoe-LAFS: http://tahoe-lafs.readthedocs.io/en/tahoe-lafs-1.12.1/archit...
I like your thinking :) https://github.com/patrickmn/define
For the blockchain projects, please email quorum_info@jpmorgan.com
Related discussion: https://news.ycombinator.com/item?id=14587357
This is really excellent advice. Too many people work too hard for too long before learning this the hard way.
By all means do a good job, but don't kill yourself. Your employer will not do the same for you.
It's not the same issue. With your approach, a compromise of the seed is catastrophic and reveals everything. With a regular password manager, you also need access to the vault encrypted using that master password. That's not a given -- most password managers either store their vaults locally or offer 2FA when synced.
(Nevermind that you can't change individual passwords or the master password at will with a deterministic scheme.)
All such deterministic algorithms are seeded by something. This is their basic flaw. Guess the seed and you get all the passwords.
With a password manager that randomly generates unique passwords, you don't have that problem, but you do have to synchronize the data.
Highly recommend using Argon2id/Argon2d/scrypt/bcrypt/PBKDF2 (in that order of preference) for password authentication/"storage." While SHA-3 might be slower than other fast hash functions, it's not at all designed for the same purpose. Functions suitable for password authentication are not merely CPU-intensive, but also memory-intensive.
Shameless plug: https://patrickmn.com/security/storing-passwords-securely/#n...
Yeah, the security track record of post-Vista Windows is far better than OS X.
Have had several apu1d4 OpenBSD routers running 300mbps+ connections for years with no issues.
Not to mention most juice is loaded with fructose.
Wiping memory was already a part of Go crypto libs a few years ago, but was taken out because it gave a false sense of security (the secrets can be copied all over memory.)
I hope everyone enables TLS particularly now that LetsEncrypt has made it so easy. If you're worried about latency, put your server in the region of the world with the most traffic, and Don't Worry About It unless you see measurably different bounce rates across regions, at which point the solution should be to set up another server, not stripping TLS. That aside...
I'm curious if there's a difference between latency-related bounces on the initial page load vs. the first interaction on the page. Take Google for example: They lose users if search results come back slowly. But is the same true if the front page loads in 500ms?
On that note, do non-technical users even realize that when they click a link, they are waiting on the destination server to respond?
I don't disagree that somebody who knows OOP but not FP needs a lot more information than I gave. Where we disagree is on the notion that I need to explain everything in detail when there are fountains of material out there. If anything, the purpose of my comments is to make you think, "Is it hyperbole, or is he on to something? Maybe I should look into this further."
I was an imperative programmer for a decade before I looked at functional languages, and it was because of glowing but unfamiliar praise that I looked deeply in the first place. Now I know that a lot of that praise was warranted. Everyone's different!
Also, as I noted in another comment, the "elementary school" comment was not meant to imply that it's simple--alas, one of my main gripes with OOP is that it isn't simple in the ways it needs to be--just that it's something you're almost certainly exposed to early on, so it quickly becomes what's familiar.
Nothing we do is easy for most people... that's why we're highly sought after.
What I meant was not that it's easy to do something, rather that it's something that often comes early, and is mandatory, in your journey of discovery. The concepts you learn early on, while not easy to fully grasp, stick, and make other paradigms seem alien.
There are libraries like https://hackage.haskell.org/package/repa that make some of these tasks much easier to do. (Write your program/algorithm in terms of these arrays and all operations on them are seamlessly parallelized.) And there's really no reason you can't wrap something by making a new data type that includes the original arrays and an index.. it's just not a class.
While it's worth mentioning that Haskell does allow you to get pretty low level, it nonetheless has a GC, and the code you end up writing often looks more like C than FP. Rust is a great alternative that combines a lot of the raw performance and control over memory of C/C++ and good stuff from FP (e.g. sum types/pattern matching.) (Or even better, use something like Haskell and FFI with Rust for performance-critical parts.)
They also use Haskell (and the Haxl library) for their anti-spam engine.
A great way to get a taste of FP, but as others noted, not the best way to really learn FP (Haskellbook and SICP are great.)
This kind of sweeping unsupported assertion is actively harmful for FP evangelists. Anyone who isn't already a fanboy is most likely going to read that and say “clearly this person has no idea what they're talking about. [close tab]”.
That seems as much an unsupported assertion (i.e. opinion) as what I wrote.
I don't think it's useful to try to write a comprehensive essay with no ambiguity every time I comment, and I don't have the time. Doesn't mean I don't believe the things I say. :)
If you decide to close the tab because I said functional programming languages are much better at abstraction, that's too bad, but it's not exactly an unsupported assertion--and I'm not trying to sell you anything anyway.
If it helps, most of my FOSS stuff is written in Go, a language Haskell fans generally vehemently dislike for "ignoring 30 years of PL research." I actually like Go for a similar reason I like FP: It does away with a lot of the bad abstraction (classes) and emphasizes the good (interfaces.)