You mean, the iPhone 6S camera is horrible as well? Because the SE and the 6S share the same sensor...
Sure, it doesn't have the AI-powered features of newer camera software and it also isn't a dual camera system, but I reckon it's still good. I prefer the Pixel 2 for photos to any iPhone anyway (still waiting for the new iPhone Xr/Xs features, fake bokeh effect et all, it may lives up to the Pixel's standards).
Yeah, saying Amazon does not have a .se (or .pt in my case) website is disingenuous. I can buy stuff from amazon.es easily, and have free shipping on orders over €20. It will automatically apply the Portuguese VAT as well, so I usually pay a bit more for stuff sold by Amazon than the initially marked price obv.
You're both right. The big difference so is wether there is a dedicated logistics network for a given market in place or not, kind of physical backbone if you like.
On the contrary, nil punning seems exceptionally well suited to a dynamic language. In general, I'm only burned by nil propagating into Java, almost all Clojure code seems to handle nil appropriately.
I'm unsure of a good way to represent optionality in a dynamic language without a static type system. Or rather, doing so with the tools available -- core.match vs real pattern matching -- seems rather un-ergonomic.
I'm curious about your thoughts of what would be better.
You are right regarding the dynamic language, well, dynamic. I haven't put any thought into it and I can't come up with a viable solution of eliminating nil without some type system strategy (Maybe/Either Monads in Haskell, Option in Rust, etc). It's kind of a bummer, because I love the Lisp dialect of Clojure, but really appreciate software projects that I've written in the past that don't crash due to a forgotten potential nil value handling.
Yeah, I think many Clojurians would mildly agree some changes to how nil is handled would be nice... but this is such a fundamental behavior that it's very hard to justify modifying the language at this point for just a minor benefit.
I love the clojure community efforts, but clojure.spec is so confusing and bloat-y to me. :(
It reminds me of Frama-C and specification of C programs, which isn't exactly what I would want to do all the time to have some safety guarantees on my program. I feel that a strong type system would provide way more benefits.
Much as I love Clojure, I agree that clojure.spec, while very powerful, has a mess of a UX. That's why – shameless plug – I wrote Ghostwheel [1], which, to me, turns it into a whole other thing, especially when gen-testing, spec-instrumentation and tracing are used together.
Having inferred types in addition to this would be even better, but types are no replacement for generative testing or vice versa.
They really complement each other quite nicely, but also have a large overlap in terms of how much they can reduce the need to do manual debugging and enable clean changes/refactorings with minimal effort.
I think you are kinda missing the point. The blockchain would define a secure protocol for voting, which you could independently verify. In such a distributed trustless system, you could even vote with your own device, provided you have the "keys"/"id" to submit your vote. See my other post in this thread for my opinion in this subject, if you want to further understand what I'm trying to say.
Disclaimer: In no way do I claim to be an infosec engineer, security expert, elections expert or any kind of expert that is relevant for this discussion. My knowledge limits itself to distributed systems, cryptography and development in general as a software engineer and elections as a voter.
From the point of view of a voter, I can summarize what I care about in an election as follows:
- My vote is counted in the final tally ("verifiability")
- Every vote counted was cast by an eligible citizen, with no duplicates (validity & uniqueness)
- Every vote cast was properly counted into its correspondent candidate tally (integrity)
- The final count results from the sum of all the votes that meet the above requirements
Now, paper ballets do all of this pretty well. But I should stress the "pretty" part, as plenty of shenanigans can happen at a local level that put these properties at risk.
The thinking goes that since voting, especially in the US, is pretty decentralized, the final tally ends up trending towards a true result. Also, records are kept so that if the results are put into question, they can be verified.
However, that has not stopped elections from being rigged in many parts of the world. In fact, even in the US this has happened previously [1], albeit not public elections per-se (but still politically-relevant ones).
Now, I'm not saying that the magical blockchain can fix all of this. Clearly, when it comes to validity, things can quickly get increasingly difficult to tackle. For instance, proving your citizenship provides a single point of failure vulnerable to government malfeasance if such is desired. If a government entity is responsible for issuing voting rights, they can simply make up a law or straight up strip you of your voting rights, therefore censoring you. I would tackle this by making voting an inalienable right, but clearly that is not the case in some countries (e.g. felony disenfranchisement in the US and other places).
Another problem is the recovery of lost/stolen/phished voting "keys"/id (in a hypothetical blockchain environment). I would tackle this with a revoke/reissue mechanism, but again, the central entity that can revoke and reissue a key/id for you can be a point of failure. So clearly blockchain does not fix everything.
Now there are some things that I believe "the blockchain", or some system that is "cryptographically" secured and verifiable, can help. Mainly, in the insurance of the integrity and uniqueness of the vote and the final tally. I would love to be able to check, if I had the private key, that my vote counted towards a particular candidate/party, whilst retaining my voting privacy. In this particular use-case, there are concerns of stolen keys being used to lookup voting histories, but I much rather tackle this problem than simply disregard such a system altogether. Clearly, there is a level of trust that I have to have on the current top brass at my local institutions if I want to cast a vote to throw them out. I'm simply not confortable with paper ballets in such instances, although I obviously prefer them to "voting machines" that have no devised threat model whatsoever.
I know cryptocurrencies have created a space that relishes on get-rich-quick stories, scams, buzzword parties and other sad sights, but I like to always chose the cautious path of not throwing the baby out with the bathwater. To extend the saying, we might need both the baby and the bathwater badly in the future...
