422 karma · joined October 16, 2013
Thanks for the pointer
Given a well-implemented hash-table, the performance differences generally seemed negligible as well. I didn't understand why it wasn't taught this way to begin with.
This stackoverflow answer only gives vague statements about how tabulation may be more performant than memoization, recursion overhead can generally be avoided with an iterative implementation (not always easy). Does anyone have concrete examples of when tabulation would be preferred?
Something like the equivalent of `pip freeze`
I wonder if there'd be a way to maintain consistency, something like a requirements.txt file that got spit out to describe what the results of the search terms mapped to when the code was run.
It could just contain the search term and link to the chosen question. Although you'd still run the risk of the answer itself being edited. The code itself would have to be cached in whatever this file was.
This will of course depend on your definition of "horrible code" but in general I don't agree with this. From the standpoint of horrible code being non-readable there exists many constructs in python that don't lend themselves to readable code despite being very useful and expressive. Not that an experienced practitioner cannot invent patterns to make these constructs as readable as possible (list comprehensions are top of mind here).
I think the key here is for the practitioner to invent the patterns that make constructs like macros usable. In the right contexts, they're incredibly powerful and can increase the productivity of an individual, and when used right even a whole team.
> The point here is that if a language feature is mostly known for it's negative effects, maybe it's not a good feature?
I would counter that it's likely not a feature for beginners, rather than being a bad feature.
I think that it could get to a state where if the debugging was figured out, and the abstractions/usability became nicer that it could be have some serious use though. Mostly the intention with this was to get something working, that can be iterated on if it makes sense.
Thanks for the link.
I thought of lisp after making this and thought it would be nice to build some python abstractions that can make this feel a little more usable. For the moment it does seem challenging, and I agree it will likely never be as simple as lisp.
I didn't see a real benefit to sticking it somewhere else, why do you think that is more desirable?
Really great resource here.
Taking a look at the source (https://github.com/yhat/rodeo) it appears to be in all python.
I was under the (perhaps mistaken) impression that native referred to code which compiled to assembly.
The implications for teaching are great too. Having this physical reference would really cut the learning curve in computer architecture.
Paying to make software for someone else seems entirely unreasonable and in bad taste in the organizers part.
I don't understand why you'd say that is group think.
It reduces the usable screen area by only a little and is hardly intrusive to the experience.
But in all seriousness, getting to a point where the game is playable takes 2 or 3 failed games at worst (assuming you do some reading). The game just continues to offer complexity you can explore.
In Java, you can take this a stop further, and use enums basically as enumerated instances of a class. Example:
public enum Stuff { Stuff1(param1), Stuff2(param2);
private Object param;
private Stuff(Object param){
this.param = param;
}
public getParam(){
return this.param;
}
}Now you can call Stuff1.getParam();
I'll be paranoid every time my 4G slows down for no reason now.
I'm wondering if multiple solutions can exist and the game will only accept one.
If Self-driving cars become available but are unaffordable (due to very expensive equipment onboard), Uber will be in an excellent position to make an investment in these cars where the average taxpayer will not.
Uber will then be rid of it's largest cost, human drivers. They will have the dispatch system in place to organize their self-driving vehicles and will be able to offer their service at an incredibly low price compared to the price of buying a self-driving car. Uber looks at a massive upside.
If self-driving cars are offered affordably, Uber can still offer it's services way cheaper and nothing changes on the consumer side. People still have cars. Theoretically, the demand for their service would still increase.
Interestingly if these same bots were capable of making real purchases and were run by ad companies this behavior may be sustainable because some people are making money. Almost like wall street.
I think you could do some really exciting stuff with an SDK or an API. Even just the ability to tie actions to custom grammars would open it up for some cool hacks.
Really disappointed that privacy isn't even touched on. This thing will be listening to everything you say 24/7 and its not like you know who won't have free access to that data. For that reason I don't think I could ever buy it.
A user can be prompted to update flash or chrome itself and then be served a (somewhat) legitimate looking file from the respective website.