I have had better luck with physical impedances, and don't bother with tech ones now unless they're simple (uninstalling distracting apps). Like you say most software is easily circumvented.
502 karma · joined October 4, 2012
I have had better luck with physical impedances, and don't bother with tech ones now unless they're simple (uninstalling distracting apps). Like you say most software is easily circumvented.
It would also be interesting to see a large market event that causes many people to move bitcoin at once. (What happens to transaction costs? Does this affect perception of bitcoin as a safe store of value?)
You're better off buying a smart TV and not using its smart features. I've never connected mine to the internet.
[0]: Actually I do not know the history here. What started the rush for mechanical keyboards? It feels like there was a point in time where they became fashionable, I assume it had to do with advertising campaigns but it could have been organic interest too.
Robustness. Speed. Simplicity. Easiness. Conciseness. Writability. Readability.
Hard to tell which are independent vs correlated, let alone how they factor into productivity. And productivity is also a function of the kind of problem you work on.
https://doc.rust-lang.org/stable/rust-by-example/error/iter_...
This is easy to miss if you are mainly reading reference docs. I probably read the getting started guide at a time before there was a section on it.
My other comment in this thread comes to mind https://news.ycombinator.com/item?id=24300057
Rust is a good example of functional lang without exceptions (panics aside).
In Rust there are many cases where I could use FP but opt not to because it can make error handling more awkward. For example to collect the result of a map operation to a vector, and if there is an error along the way you want to abort the entire operation. In functional this means collecting to a Result<Vec<T>>. Not sure if I'm just tired today but I can think of how to do it in 5 seconds with a loop. I suspect functional solution would be uglier.
Rust is great but I waste a lot of cycles thinking about how to structure the code instead of the actual problem. What is cleaner here using a loop or a higher order function? Should I use if let to make the code a little shorter? Should I use that question mark trick to propagate the error? Do I use the expression or statement form of ifs?
Do all of the features in your language really make you more productive, or are the gains offset by the cognitive burden of dealing with them? And what is the cost of having many ways to do things in the context of a code review? What about when reading other people's code? What about when writing automatic tooling?
OnLive was released when most internet connections were still crummy, and before HD capable computers were embedded in TVs, smartphones and tablets. Despite all of that it still worked pretty well, but at that time I thought if I can run the game on my desktop why bother? Nowadays I don't have a gaming desktop capable of the newest games, so I think about it differently.
The project isn't quite where I want it to be, but it's getting close. The next thing to improve is support for banks that only allow users to download an N month window of transactions. Probably I will save each download to a timestamped file then merge them in-memory before the next stage in the pipeline. The source code for all of this is here: github.com/tmerr/bank_wrangler. I don't expect it to be useful for anyone else verbatim but it might give you some ideas or something to fork from. Disclaimer: banks might not be happy about web scraping / using undocumented APIs, so don't mindlessly fetch data without understanding that risk.
def all(xs, predicate):
for x in xs:
if not predicate(x):
return False
return True
Similarly, def any(xs, predicate):
for x in xs:
if predicate(x):
return True
return False
You say "Ex falso quodlibet" which makes it sound like you believe such a system leads to contradictions, but this would come down to the choice of rewrite rules.Example: a rewrite rule from "NOT all(xs, predicate)" to "any(xs, NOT predicate)" would lead to contradictions. Reasoning:
A. all({}, predicate) is true by def of all
B. any({}, NOT predicate) is false by def of any
C. NOT all({}, predicate} is false follows from A
D. applying the rewrite rule to C, any({}, NOT predicate) is true, which contradicts B.
However, in first-order-logic, that same rewrite rule is fine since sets always contain elements. It doesn't seem like to much work to go from Python-esque any and all to ∀ and ∃. For example "all(xs, predicate)" could be rewritten to: "¬P ∨ (∀ xs. predicate)" where P is a new proposition variable for whether xs contains elements. This relies on the semantics including short-circuiting evaluation (which may be cheating, I don't know).Or maybe the above is what you already meant when you said "following the embeding..."?
Companies already price by predicting what people are willing to pay, by theory and experimentation. I wouldn't expect them having perfect information change much other than quicker convergence to the prices they would set anyway.
I think with 1 sender and 1 receiver the common solution in Rust is the same, to copy (or maybe move) the values sent... the type system provides some safety guarantees but I doubt it would be much different for performance. You wouldn't be able to send an immutable reference over a channel in Rust, since the compiler wouldn't know where the reference's lifetime ends. You could resort to refcounting, but you would probably only put in the effort if the data structure was large enough that copying was prohibitively expensive.
<meta name="robots" content="noindex"/>
Maybe try https://support.wix.com/en/article/enabling-search-engines-e... ?Absolutely. I was surprised by the number of proposed changes in Go 2, especially regarding error handling. Curious whether old code will be migrated or left behind.
>That's not an issue with Java, but how the GC is tuned
Good point, I haven't done much GC tweaking personally but that sounds worth learning more about. However I think language might have something to do with it: In Java almost everything is a referenceable object, while in Go one can put values directly inside structs. So Go has less work to do. Without that advantage I doubt it would seem competitive with Java GCs.
Java is a victim of its own success: it has lived through style evolutions which have lead to fragmentation in the ecosystem. Some code uses mutable datastructures with for loops, others immutable datastructures with the stream API. Some code uses dependency injection, while some doesn't. As a result it takes more time to mentally calibrate to the style when pulling up a .java file. Another imperfection: GC pauses can cause request timeouts and are annoying to debug.
Python's not perfect either: aside from the obvious performance issues, use of the awkward retrofitted type system makes me wonder why a statically typed language isn't being used to begin with. The lack of good static analysis is especially annoying at Google where the tooling is quite good.
Just my 2c