4,603 karma · joined March 5, 2008
https://benchmarksgame.alioth.debian.org/u64q/go.html
However, perhaps as you indicate these are including JVM startup time and thus tainting the results. For some reason I had gotten it into my head that Go was faster than Java, but it's been a couple of years since I've used either one, so I definitely may be off on that point.
c) is speed essential? d) are you doing systems programming as opposed to CRUD webapps?[1] These might lead you to Go.
[1] I know you can do the latter in Go, but it's unclear that it's as easy/productive as in other langs currently (nor have I directly compared, say, Revel to other frameworks, so someone else is probably better qualified to answer this question.)
http://www.danielsusskind.com/research
The depressing conclusion: " In a static model, increasingly capable machines drive down relative wages and the labour share of income and force labour to specialise in a shrinking set of tasks. In a dynamic version of the model, labour is driven out the economy at an endogenously determined rate, forced to specialise in a shrinking set of types of tasks, and wages steadily decline to zero."
The more interesting case is allocation of memory which is not in practice reclaimable (as described in the first answer.)
The former seems pretty trivial to understand, but if the original interviewers meant the latter I doubt I would have been able to come up with a good example off the top of my head.
Question about this: if we're to take the above to heart, doesn't that imply that we may implement some common functionality multiple times? It seems there's a real tension here between "code re-use" as a generally laudable goal and the need to avoid sychronization of testing/deployments.
I'm curious how others out there have dealt with this particular issue.
WP: Some of the lack of mobility is due to high rents in cities, which keeps many people out, right? You cite some research that shows if it was cheaper to move into American cities, GDP growth would be much higher, and the economy would be more dynamic.
Cowen: Enrico Moretti’s estimate is that GDP would be 9.5 percent higher. That figure is hard to estimate, but it’s not a tiny effect. Right after WWII, adjusting for inflation, an apartment in Manhattan cost $530 a month. That’s unimaginable today. It’s a big reason why mobility has become problematic.
[0] https://www.washingtonpost.com/news/wonk/wp/2017/02/28/upper...
% big hairy command here # foo the bars!
Socialism: there are two snakes, and the 10 points for eating an apple gets split between them.
Communism: the game starts as Capitalism with two snakes, but then the game switches to Socialism, and the 50$ (or remainder) gets expropriated and split between the two snakes.
Late Communism: Starts like Communism, but more and more points for apples get allocated to the AI snake (and fewer to you) because it's a member of the communist party.
Late Late Communism: Like Late Communism, but eventually no more apples appear. Game implodes and turns back into Capitalism, but the party member snake has all the money.
Platonism: another game runs in parallel alongside this one, but the snake is perfect and the highest possible score is obtained.
A Model of Technological Unemployment http://www.danielsusskind.com/research
In any event, it doesn't really matter what the original intent of the GoF book is because in practice, people treat design patterns as, well, what the word "pattern" would suggest: "something designed or used as a model for making things <a dressmaker's pattern>".
This is further indicated by the term "anti-pattern," which basically means, "something you should avoid." If you should avoid the "anti" then it stands to reason you should follow the "pattern."
For even more demonstrations of this fact, look at subsequent design patterns book, like one by the Head First. These explicitly treat patterns as improvements to be made over some previous attempt at a coding problem. Or hell, check out this description from https://sourcemaking.com/design_patterns -- "Design patterns can speed up the development process by providing tested, proven development paradigms." " Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns."
Whether it was the original intent of the GoF or not, design patterns are mostly perceived to be _good things_ that should be adhered to.
Now, as many have suggested, the wisdom of reaching for design patterns has been increasingly viewed with skepticism, and rightly so. It'll be interesting to see over time how much weight they carry and where the equilibrium lies. My guess is that certain patterns will essentially fade from relevance (if your language has first class methods, do you really need Strategy, for example?) While some (adapter, facade) remain useful ways of handling various problems.
Perhaps a broader reason is that 3d seems to encourage filmmakers to go for visual spectacle over good storytelling.
Also in Java if you use intellij then you'll probably get 'person' as an autocomplete, which actually makes it roughly as easy to type out as 'p', (and a better choice if your entire team has standardized on intellij.)
That said, iirc, someone often helpfully posts the text of the article in such cases. Why go through the effort of banning something when either a) someone will continue to do that, or b) interest/upvotes in paywalled stories will die naturally?
Yeah, once you get that deeply entrenched in Oracle, it's almost impossible to get away, and after that experience I vowed never to work at another Oracle shop.
In any event, to add to the anecdata, someone below recommends not resting your arms/wrists on anything and letting your hands float above the keyboard. I've tried this, and the small muscles in my back that keep the arms lifted would become sore bundles of fire that eventually would spread pain throughout my back/neck/arms/wrists.
I found, paradoxically, that totally resting my arms splayed wide on my desk combined with a Kinesis Freestyle so I can keep my wrists straight (this wouldn't work with a regular keyboard) is the ideal setup for me.[1]
Not saying this would work for everyone.
[1] I have a standing desk combined with a high chair oriented such that the desk comes a bit higher on my chest than a sitting desk would, such that I can just rest my arms on the desk. The keyboard is not elevated and is basically flat to the desk surface, and is separated and angled such that my wrists are not bent.
http://www.slate.com/articles/news_and_politics/kausfiles_sp...
Choice quote:
"But why should we expect the deadlock to be broken at all? Think of it in ... well, cheap Darwinian terms. Imagine that we have a two party system, and each party is a collection of status-seeking individuals looking for power by winning a greater "market share" of the vote. Imagine that they each have their ideological principles --one is more to the left, one more to the right -- but these principles are quite flexible in the face of imminent or repeated failure at the polls. Over time, as each party crafts its message to maximize its appeal -- and adjusts its message after each election to regain any lost share of the votes -- wouldn't one expect the system to reach a roughly 50-50 equilibrium, in which every election was a cliffhanger?"
select t1.col1,
t2.col2,
t3.col3
from table1 t1
join table2 t2 on t1.col2 = t2.col1
join table3 t3 on t1.col3 = t3.col1
and t3.col2 = something_else
where t1.col1 > 0
and t2.col2 <> t1.col4
order by col2
limit 100
select *
from blah b
where b.whatever in (
select blah
from c
where c.whatever = in (
select blah
from d
where d.whatever = 'foo'
)
)
Meditations on Moloch is one of my favorites:
So, for a short lived variable, I'm personally ok with it being short, as in, some random bit of python:
# strip the last char from everything in a list
some_list = [s[:-1] for s in some_list]
Conversely, variables that live a long time and/or operate globally are better off with a longer name.
However, I would observe that your example might suggest a coding issue, the tipoff being 'and'. If a single variable is handling two chunks of state, then perhaps it's doing too much and you might be better off with something like:
val documentSavedOnDiskJsonStates...
val pdfSavedOnDiskJsonStates
document = Document.getFromDisk()
document.jsonStates()
Another mentioned in this thread -- if you have distinct groups within a team who are working on mostly separate projects, don't combine their standups. Otherwise, you just encourage half of the attendees to tune out (exacerbating the situation above.)
Having taught music and dancing at various points in my life, I've noticed that -- at least in these sorts of fields that require some sort of body mastery -- the best teachers often weren't the most naturally gifted. They often had to struggle and reason their way through issues in ways that the most gifted/natural musicians/dancers didn't. And because of that, they were often vastly superior teachers simply because they had learned how to think about and articulate a given subject. They could translate the wealth of techniques they had developed to learn the subject to others.
And perhaps, having struggled themselves, they would be more patient.
True, that's all ad hoc theorizing on my part, so I wouldn't promote that as some sort of universal truth, but it's something that I've heard from lots of musicians.
(All of the above is tangential to the OP, btw, which I don't necessarily find that compelling.)
2. The Pragmatic Programmer -- a classic. Reminds me that I need to re-read it.
3. Effective Oracle by Design, by Tom Kyte -- Not that I use Oracle any more, thankfully, but really provided a lot of insight about how databases function and how it pays to deeply understand their internals when writing webapps.
I recall reading about someone (was it Spolsky? IDR) who looked for candidates with certain niche languages on their resumes, because it served as a quality signal. If they're interested in learning Clojure, for example, they may just be more generally curious and/or have a desire and interest in learning about different paradigms.
That said, at a practical level one has to balance competing demands. If you have someone on your team working on a project in X and they're the only X developer you have, you're at risk because if they leave, you may be screwed. Plus, they won't be getting quality feedback on their work because no one else can understand X.