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 :) )
548 karma · joined January 3, 2015
Co-founder and CTO of Clovyr, a company that makes it easy to build and use decentralized applications
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 :) )
The Man From Earth is wonderful. The best ultra-low budget movie IMO.
Looks very, very nice for a solo project!
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.
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.)
By all means do a good job, but don't kill yourself. Your employer will not do the same for you.
(Nevermind that you can't change individual passwords or the master password at will with a deterministic scheme.)
With a password manager that randomly generates unique passwords, you don't have that problem, but you do have to synchronize the data.
Shameless plug: https://patrickmn.com/security/storing-passwords-securely/#n...
Have had several apu1d4 OpenBSD routers running 300mbps+ connections for years with no issues.
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 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.
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.
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.)
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.)