gracenotes
Trucks on last mile delivery are invaluable for some deliveries, as you mention, but then... why else does any other vehicle need to use most streets? Is it reasonable for someone who orders a truck to pay 33% of the cost of that truck on the road? What about 0%, or 100%? Which is best?
In cases where alternatives to trucks or cars are less costly overall in some situation, or additional efficiency can be achieved with batching, how much of that is ignored because of these accidentally created incentives? Not even mentioning the indirect cost to communities (walkability, clean air, autonomy of disabled people).
I don't have the answers, but I think these are good questions to be asking. For the specifics of policies, we need to base that on data ofc.
If this is in fact the case, I don't think it's a bad thing. The problem in that case comes from double standards, where the ground-level understanding of how society operates includes costs incurred by individuals/businesses which effectively disappear into a vacuum rather than being directly paid/passed onto customers, yet is used as evidence of the completely natural and inherent utility of cars over alternatives.
For a different doc more directly about who pays for roads, I've found this one useful. Made by a so-so thinktank, but seems well-sourced and rigorous.
https://uspirg.org/sites/pirg/files/reports/Who%20Pays%20for...
Anyone's productivity in programming can be enhanced by taking a mathematical outlook, although I suppose the beauty of programming is that you don't have to.
To throw in a Dijkstra, "The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise." What do you do when certain semantic levels require some mathematical background - do you choose a less precise abstraction or do you just require that background? I'm not sure what the answer should be for this kind of blog post, but at least intro-to-programming materials should be as accessible as possible.
https://visualstudio.uservoice.com/forums/121579-visual-stud...
As GP mentions, Haskell is a great example of achieving both superb type safety and superb type expression with type erasure. That said, sometimes you don't want superb type safety - things like dependency injection and mocks are examples of frameworks you can use in languages with some amount of type reification without restructuring your entire codebase. Java/JVM achieve a decent balance here imo.
For instance, I'd like to have a quadraped skeleton with the ability to apply a movement vector. Unfortunately, in the Actor->Pawn->Character hierarchy, you cannot have movement (applying vectors, walk/jump/fall state) without a capsule root component - which is the only one respected for collision - so either I have to rewrite all of the movement code or somehow make the capsule vestigial and carefully maintain its state.
In short, in some cases it's useful to say that a Pawn is an Actor with a set of extra features, or that a Character is a Pawn with a set of extra features, but even there, the way inheritance forces you to adapt an exact set of extra features and no others and also those features are not piecewise reusable elsewhere is a pretty big structural problem.
I've already done enough arguing about OOP for one career in programming, I think, but the more I see what's out there, the more that I think the real enemy is any use of class inheritance - even the TAPL formalization of OOP uses interfaces only.
So if "bad things happen to good people for no reason" is unpalatable and it's the narrative for mass transit, and "bad things happen to drivers for reasons in their control" is the easy narrative for cars, I'd say "bad things happen to good people for reasons that are in our control but we still do nothing" is closer to the true narrative for cars, but it is also unpalatable. There is an element of this in many risk-related scenarios, but it is especially clear here.
https://terrytao.wordpress.com/career-advice/theres-more-to-...
I recommend reading the entire post - it's not too long, and links to other great materials - but this is a good relevant quote:
> The point of rigour is not to destroy all intuition; instead, it should be used to destroy bad intuition while clarifying and elevating good intuition.
As far as progressing even further into DSP, especially for audio processing, I've found https://www.dsprelated.com/freebooks/filters/ to be a good map of the territory. But as someone with a CS degree rather than an engineering or math degree, it's all pretty overwhelming.
Rather than refuse to understand how someone could have gotten there, let's try to understand the assumptions they made along the way. Then rather than pretending we're unaffected by the culture around us, let's see if we share some of those assumptions. If we want to fix things rather than be blindsided by them, these are at least the first steps.
I'd like to think that, for the most part, trying to address a societal problem like [1] is better than denying that any action is needed, even if the increased visibility causes strife—[2] is of interest here—or we don't get it right the first time. It's hard to discuss because many Americans begin on vastly different pages with vastly different experiences.
[0]: https://policy.m4bl.org/platform/
[1]: http://www.benjerry.com/whats-new/systemic-racism-is-real
[2] https://www.africa.upenn.edu/Articles_Gen/Letter_Birmingham....
> Some of these articles are implying a size of an effect that is completely ridiculous, there is just no way that diversity "could increase revenue by 41%" - we'd see way more diversity in work places if this was true.
This seems to be rejecting data and substituting and a handwave. From the original study, 41% is the actual coefficient, controlling for a ton of things. Likely there are latent factors that make workplaces both gender-diverse and performant, so just swapping out half of a workplace would not hit all of these, which the paper acknowledges. We are seeing more diversity thanks to studies like these and explicit diversity initiatives, but given all of the biases that can exist in hiring pipelines, I can't think of any reason why it would happen naturally.
The paper you link is trying to measure firm productivity (could not 100% figure out what this means) based on data from Denmark, mainly non-white-collar jobs. It notes that demographic diversity promotes "better problem-solving abilities and more creativity and knowledge spillover" and can be a "substantial competitive advantage", limited by people not trusting/communicating with each other (i.e. integrating effectively).
It does seem like age-based discrimination would have a negative effect on psychological safety, as with any discrimination due to conscious or unconscious biases. Regarding perspective, an experienced individual could either bring in valuable insight from their experience or constantly veer towards the status quo, partly depending on how you want to look at it.
I think the answer is: it is complicated. You now have my ideas on why diversity is valuable. Does age fit that model? (Even if not, of course, age-based discrimination is not good.)
[1] https://news.mit.edu/2014/workplace-diversity-can-help-botto... [2] http://www.nytimes.com/2016/02/28/magazine/what-google-learn... [3] https://hbr.org/2013/12/how-diversity-can-drive-innovation [4] https://www.fastcompany.com/1841060/redefining-diversity-new... - bonus
Bloom's taxonomy[1] is useful here I think. Assessment ideally shouldn't stall at 'understand' or 'remember'. I do agree it is important to know about a large variety of things. The more specialized the job is, the more important it is for a candidate to do a decent subset of it on day 1. But sometimes you can explore a candidate's knowledge through 'apply' (use X to do Y) or 'analyze' and 'evaluate' (do Y), such as in a system design question, to see the structure of their thought process rather than something more scattershot.
Finally, regarding skipping a question, sometimes you can sense that a candidate's knowledge is limited in some area, which is a good time to just move on and try to go deep on something else. Not everyone has been afforded the same opportunities and has the same amount of experience. Software is a job where the potential to grow can do you better than a fixed skill set, especially if you see hiring as similar to making an investment.
[1] https://cft.vanderbilt.edu/guides-sub-pages/blooms-taxonomy/
Separately, minimizing diffs with the codebase is not just easier for the reviewer, it also makes 'blame' and resolving problems with existing code easier. You shouldn't break your back to minimize diffs, but as a form of hygiene it is not without merit.
Your definition of continuous integration is interesting in that I haven't seen it used in that way, or rather with that emphasis. Smaller syncs-to-master than "this is the entire feature" are great, but their effectiveness depends on automated testing, building, and deploying. When code under review is a coherent, high-quality, and tested thing, this can be a boon for CI because you get a small chunk with clear before and after states, which you might not get from just winging it. You can also work on code while other code is under review, especially with a Scrum/Kanban-type task system.
That said, if your goal is to make a quality product, you shouldn't have to choose between code reviews and continuous integration. You shouldn't have to choose between code reviews and code coverage, or manual QA processes. These are all widely regarded as best practices and if implemented "correctly" and appropriately to the team their combination forms a virtuous cycle for code health and team culture.
Unless you mean these grammar rules: http://chronicle.com/article/50-Years-of-Stupid-Grammar/2549...
As you mention, you could also see specific usage patterns as shows of "professionalism" (again in quotes... it's a word that I think should be used carefully re systemic biases). But it's perhaps a little reductionist to view informal contexts as not-caring-about-correctness at one end and professional contexts as caring, because there are many aspects of communication in both that are "incorrect" for different reasons. Usage patterns in work environments are not strictly more correct, then.
As the article proposes, being bothered by ungrammatical language is more often just an issue of sensitivity to stimuli. At least in conversations, those of us with the good sense to be descriptivists can hopefully tell when additional clarity would be helpful and when it's just putting other people down to try to look smart.
Obviously both browsers are developed by highly talented software engineers (disclaimer: biased Google employee here, not in Chrome, speaking for self). But I think type of website and upfront ecosystem investment have some effect on where the most development pain comes from. My naive guess is that rich content consumption sites are easier to do in Safari, more app-like long-tail-of-features stuff easier in Chrome. If this is true, why? My guess is that Apple has its own idea of which general-purpose platform it'd prefer to most invest in.
I'm pretty sure that is part of the job description of marketers.
> Treat nonlogged in users as second class citizens. By always giving logged out always cached content Akamai bears the brunt for reddit’s traffic. Huge performance improvement.
I have ended up using this philosophy in a website I've been working on lately, where people can post puzzles from The Witness. This includes simplifying decisions such as not tracking solved puzzles unless you have a user id, and not allowing navigating to a random puzzle either, as this routine depends on stored solves and upvotes. Supporting not-logged-in users just means extra code for me.
In general, I don't think this is a bad attitude for a website to have.
It is perhaps different in the case of GitHub, a highly depended-on and well established website which is actually removing functionality here. I would still assume good faith about the reason. And mobile login rates are a problem for everyone, I'm pretty sure, not just GitHub.
It's still a genuine social exchange, but the point is that humor has empathy as a key component, and it helps us bond. If you were to convey the same concept in a tone of anger or disappointment, most listeners won't laugh. So maybe humor and rants are two sides of the same coin: socialized salience.
But like any other social contract, it can be abused. If you frame a sentence in the cadence of a joke or rant, you're expecting the listener to respond. If you rant for a very long time, people stop listening. If you make jokes 24/7, the social activity of joke-telling is no longer a two-way street, and people stop laughing. If you deliver nonsense like a joke, you may get the knee-jerk social laugh, but not the witty-idea laugh (unless nonsense is the witty idea). If it's inappropriate to bond in a situation, and you tell a joke, you might not get a laugh, let alone an acknowledgment.
For various reasons, patients described in the article only have pieces of this whole system, and struggle with the social aspect or the witty-idea aspect.
Maybe one major difference between playing a game and forming a personality is that these early important interactions don't just adjust wirings in the cerebral cortex, the part of the brain most responsible for general intelligence. It goes straight to our emotional memory bank in the limbic system, which is all about learning an incredibly important objective function: to survive. But very high level features formed by unsupervised learning can do this, not just reptilian predator detection routines. Being scolded or corrected can have a powerful effect on future motivation. Suffice to say, artificial intelligences don't currently worry about this.
Supervised learning may be how it looks from the outside, but consider that out of the >6,570,0000 waking seconds of a child's life up to age 5, there maybe only a few dozen instances of supervised adult instruction per day. Besides those, what do neurons do the remaining 99.99% of the time?
Part of the problem might be that comparing supervised and unsupervised learning 'effectiveness' is a bit apples-and-oranges. Their effect together is highly collaborative. Children have to develop abstractions on their own before you can supervise them on those abstractions. It is probably fair to say that a key part of human general intelligence is creating high-level representations of low-level stimuli. It might also be fair to say that this is what the brain is doing 100% of the time.
So if I may hand wave a little: while supervised learning can make a child better maximize objectives on those high-level representations (objectives they may be aware of through unsupervised observation), for the most part it does not fundamentally change the structure of those things in the child's brain. This makes unsupervised learning almost all of the cake to me.
My post has the caveat that children undergo a lot of other objective-based learning besides explicit instruction from adults, and all of this maps only fuzzily to supervised vs unsupervised learning in AI, which is the issue from the submitted post.
In particular, the initial input to the neural networks is a 19×19×48 grid, and the layers of this grid include information like:
- How many turns since a move was played
- Number of liberties (empty adjacent points)
- How many opponent stones would be captured
- How many of own stones would be captured
- Number of liberties after this move is played
- Whether a move at this point is a successful ladder capture
- Whether a move at this point is a successful ladder escape
- Whether a move is legal and does not fill its own eyes
Again, before the neural nets even get involved. Some of these layers are repeated 8 times for symmetry. I would say for some of these, AlphaGo got some domain-specific help in a non-general way.
It is of course still groundbreaking academically. The architecture is a state-of-the-art deep learning setup and we learned a ton about how Go and games in general work. The interaction between supervised and reinforcement learning was interesting, especially how the latter behaved worse in practice in selecting most likely moves.
disclaim: Googler, not in anything AI.
Higher-order functions are a simple and powerful form of abstraction, but not much else. I could imagine something which has the software engineering benefits of an FP language without HOF, although maybe it wouldn't culturally be one.
I think getting enthusiastic about higher-order functions and trying to use them in OO languages can range from good to neutral to bad. On the plus side, code is usually shorter. On the negative side, it's not necessarily more readable, and types still usually expose the same amount of information about their inputs/outputs, which is "call me, anything can happen" (plus plenty of opportunity for lazy side effects, the most confusing kind).
Let's assume there is a platonic ideal for REST, or for OOP. Just talking about REST over HTTP (methods, response codes, URIs) clouds that ideal, making it hard to learn about and even harder to talk about with other programmers. The same could be said about OOP with classes, structs, prototypes, etc... or as some of this article's quotes do, about OOP in Smalltalk. Over time you could look at this in terms of SCOT theory[1] and I think it would be fascinating. You could look at all of the marketing, conflict, and the effects of collective perspective shifts where things are considered "solved" but they aren't really.
My own opinion about the platonic ideal of OOP is close to Chapter 18 of Pierce's Types and Programming Languages, which suggests these attributes: 1. Multiple representation 2. Encapsulation 3. Subtyping 4. Inheritance 5. Open recursion.
To me the kernel of OOP is mainly just #1 and #2. If you don't have #3, you should have a damn good alternative. I don't attach #4 and #5 to the core definition but certainly the former should imply the latter. Another favorite is "On Understanding Data Abstraction, Revisited"[2], which contrasts objects and ADTs in a different framework.
[1] http://en.wikipedia.org/wiki/Social_construction_of_technolo... [2] http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf
The sublogarithmic result is constructive, though, and my understanding of it is like this: We can split up a decision problem (take in a string, give a yes/no answer) over many workers by splitting up the input string into sqrt(n) chunks of size sqrt(n) each and using a shared working space. The first worker handles the first chunk with a blank working space, the second worker handles the second chunk with finished working space from the first one, etc. until the last worker handles the last chunk, with the second-to-last's working space, and gives a yes/no answer. This can be parallelized into a single MapReduce round by instead having every worker process their chunk using every possible configuration of the shared working tape. This sounds like a lot of work, but if shared working area is sublogarithmic in size, calculating such a table fits within polynomial time and sqrt(n) space. This means that one final "reduce" step can take the working space from the first input chunk, pass it through the second input chunk in constant time, and so on until it can make a decision.
I can't think of any practical sublogarithmic space problems off the top of my head but evidently there are some good ones in graph theory. If you tried to implement the above in practice, you could imagine that the final reduce step could be intelligent about combining the processing stages so workers don't need to calculate every single configuration.
What is unclear to me is whether all Turing machine deciding languages in sublogarithmic space can be chunked in this way. The usual definition of an input read head is that you can go left or right whenever you want, but having access to the entire input means that the workers can't be cleanly chunked. You could say the input is one-way like a DFA/PDA, but is there a result that these are equivalent with sublogarithmic scratch space?
https://www.youtube.com/watch?v=3_zW63dcZB0
The whole talk is stimulating, but the parts relevant to Sonic Pi are its Overtone (http://overtone.github.io/) lineage at about 9:05, a demo at about 17:36, and the experience using it in schools (http://www.raspberrypi.org/sonic-pi-live-summer-school/) at about 26:48.
What I got out of it was that it's a language which is meant to be both fully featured and easy for kids to pick up, to get interested in music, programming, or both. Maybe not so much programming as just "computational thinking". It has less incidental complexity than EDSLs (like Overtone) or traditional tools which expose more of the synthesis pipeline. Compared to most video game/graphics frameworks, which are also used in education, you can get to more polished content faster.
After an hour or so, the largest tile is 524288, 2^19: http://i.imgur.com/Yk758sx.png
While I was writing this comment, it collapsed down to the next largest tile, 1048576, 2^20: http://i.imgur.com/PVPCvUC.png
