I personally find the characters very sympathetic and laughing at the BBT characters is like laughing at myself. It's refreshing to see the extreme qualities which other shows merely caricature be shown in the context of fully fleshed out human beings.
BBT doesn't flesh out those characters. Most other shows I watch do.
Ben Wyatt on Parks and Rec comes off as a much more realistic nerd than any of the characters on BBT.
Abed Nadir in Community is also a whole lot more fleshed out than the characters in BBT.
The BBT characters are the epitome of stereotypical, caricatures of nerds. None of them are ever shown to have interests other than the traditionally nerdy kind.
If by "fully fleshed out human beings", you mean they happen to be main characters, sure. But by any other definition of "fully fleshed out" vs "caricature", they're much closer to caricature.
I'm not familiar with LKML or any of the developers, but Sarah is very impressive in this thread. Every time someone else tries to shift the topic, she brings the conversation back on course. She's right about a minimum standard of civility being crucial in email. Even if no one on the list is personally affected by the language (a big if for a large list), a single vitriolic email can poison the atmosphere for days.
Thanks for that link :-D Was wondering a size comparison earlier while reading a HN post about Tesla superchargers (Texas vs Netherlands(my home) http://mapfight.appspot.com/texas-vs-nl)
That may or may not be true - they have open-sourced several large projects. Flex (http://www.adobe.com/products/flex.html), for example is a big software product that Adobe switched to open source in 2007.
From an article back then:
"Ward outlined the transition as having the following steps:
Today - Creation of Mailing List for Discussion
Summer 2007 - Public Bug Database and Daily Builds
Second Half 2007 - Flex 3 Released
December 2007 - Read Only SVN Access, Patches Welcome
2008 - Committers with Write Access, Creation of Possible Subprojects "
Flash is also a runtime for code and supports video decoding. Fireworks on the other hand is a utility application built around the PNG graphics format (which is not patented, but Adobe/Macromedia has extended it for Fireworks metadata).
But even if it is a more suitable candidate to open-source, I just don't think there's much in it for Adobe. It'll just cost a lot of money with the lawyers involved and the whole code-base will need to be reviewed.
yup, Adobe has been in the business of buying up competition for years. They aren't just going to give away a system that will take share away from their products.
I think the question might be better put this way:
Pick 5 random points on an infinite plane. Draw lines between all of them. One of those lines will contain another integer point. Prove this is true for every set of 5 random points.
I've had the same experience as Tesla, though not so extreme as to cause problems. For as long as I can remember I have enjoyed extremely detailed "daydreams" where I explore worlds and meet people inspired by the books I read. I suspect this is fairly common in children, but I did it right through high school, university, and several years in the workplace.
The real question is: how much benefit does having a strong and well exercised imagination have for a technical career? (I assume it's very useful for artists).
I've found that software development gets a large boost. The more of the design you can hold in your head on once, the better the coder is able to anticipate the consequences of their decisions. When debugging, the programmer is able to see the entire state of the application that must have predicated it, experiment with a range of fixes, all before writing any code.
I love this quote from The Tao of Programming[1]: "Sometimes there are difficult problems. I see them coming, I slow down, I watch silently. Then I change a single line of code and the difficulties vanish like puffs of idle smoke."
I'd imagine a strong imagination is great for the concept and design parts of engineering, but not entirely necessary if you're just building to a spec.
You need to explain more - for example what do you mean by a "partial"? A quick search for "partial functions" gave me several links to mathematics articles. When I followed the links to the composition modules I got more of the same impenetrable context-less style.
What I did get from the article is something that works a lot like promises:
- async functions return type of "eventual" data (in your case, a function you pass a callback to)
- various other functions that can operate on that eventual data type to return more eventual data
What does this style offer that standard promises doesn't?
> You need to explain more - for example what do you mean by a "partial"? A quick search for "partial functions" gave me several links to mathematics articles.
The magic phrase you were looking for is "partial application." (Partial functions are a different, even more esoteric thing.) Basically, partially applying a function means you create a new function that calls the original with some of the arguments already filled in. For example, you could write this:
var getUserList = partiallyApply(jQuery.getJSON, 'http://example.com/user-list');
and getUserList would then be a function that takes a callback and calls
I believe that using basic functional programming tools is a much more powerful way than using promises. The main issue with promises is that the code you write will be less replaceable, and less compatible with other code.
Their target audience is non-expert consumers. These new features are perfect examples of what their target audience wants. Any feature that requires editing a configuration file will probably never be implemented.
Ok, then don't make it configurable through a configuration file. This feature (the ability to ignore certain files or filetypes) could be configured similarly to how Dropbox currently handles selective sync.
His arguments triggered a sense of deja vu. I've made those same arguments with clients who want a system to process a specific product differently to all the others, and colleagues who think our framework should have special code to handle a rare use case.
Those arguments are valid - from the perspective of the architects. Maintaining and learning to use such a system is incredibly difficult, and resistance against special cases is healthy and helps promote simplicity.
But the purpose of law is to promote quality of life not quality of law, and life is messy.
