Is this related to the point cloud generation feature modern compositing programs use, like Nuke? Example/tutorial video: http://vimeo.com/61463556 (skip to 10:27 for magic)
With 10+ years of being a professional programmer I think you will automatically get the insight of being agnostic is really the only way of surviving and keep your passion for your work.
Those who fail at this will stop working as a programmer, move out in the woods, build a cabin and live happy as a farmer.
When you're young you will inevitably always have an attraction for styles that ring the most true to you. You have one single hammer you have learnt to use or even worse, have heard really good programmers at Hacker News prefer to use, and therefore you use this hammer for everything.
You are a poser.
Most programmers have been there. Posers can be extremely sharp and useful if they get to do what they're good at, but they are posers nevertheless and at the start of a humbling journey to agnosticism - getting shit done instead of bickering and posing.
You're missing the point. The purpose of this post was to illustrate how silly little differences in coding style cause lots of unnecessary work. The agnostic's version was the best in this illustration because they knew what the requirements were. You can easily adapt the ascetic's, the librarian's, and the purist's version into the "right" code as well.
The point is that we each have our own different style of doing things, and frankly, I'm a bit incensed that you're using this post to hold up your way of doing things as the "one true" way of doing things while calling everyone else a "poser". I think this comment is exactly what the author is trying to say is bad.
Sure, but these guys each have the benefit of being King of their Kingdom. Most people writing code have neighbors they need to get along with and cannot rule by fiat.
Not only the benefit, but the responsibility. By mandating a certain "way" and ending the discussion, they essentially nip "the narcissism of small differences" in the bud. As the leader, this is one of the useful things only they can do.
My opinion: there isn't one single good way to do programming. Often, you want your interfaces to be referentially transparent (stateless). Usually, it's best for source code to be in the functional style as well-- but not always. Sometimes, mutable state is exactly what you need. But it shouldn't be the default, unless you're working at a very low level.
There are, on the other hand, a lot of bad ways to do programming: FactoryFactory nonsense, software-as-spec systems, waterfall methodology. We've seen them several times in our careers and have a hair-trigger sensitivity to stupidity, because we've seen it cripple or kill projects.
Great programmers tend to be unforgiving in their condemnation of the bad ways of doing things, but hesitant in accepting one programming model-- even a very good one like Lisp-- as being the One True Way of doing things. As soon as you have a One True Way, some very smart people disagree with you-- and that's a good sign that you're at least partially wrong.
In other words, it's good to be passionate about using the right tools for the job. It's a problem when people think the same tool is right for every job.
It seems that in saying that having a One True Way attitude is wrong, you've developed a Not True Way attitude. Waterfall methodology might work just fine in some situations, software-as-spec works on smaller applications moving to a different platform, and I haven't found one, but I'm sure that the FactoryFactory nonsense can work to keep order in extremely large codebases (I work on a large codebase, and haven't found a need for super abstraction, but that's just me).
Calling these unequivocally bad is counter to the argument you're presenting (which I happen to agree with).
software-as-spec is out of vogue now? I may have misunderstood, but I thought software-as-spec is the same thing as test-driven-development, which I could have sworn is still lauded.
Can you explain why you think they are the same? SW as spec is problematic because whatever the sw does is interpreted as being what it is supposed to do. So how do you identify bugs? At least with TDD the tests serve as some kind of documentation.
I'm no fan of either, generally, but I also don't work on "move fast. break things" type projects.
Note: This is a created dilemma, with one horn being a strawman (with namecalling of those who chose that horn), and one horn occupied by the chosen "good position". This is a rhetorical device used to force decisions to the chosen "good position".
I couldn't find a source that he said that. Wikipedia says it's not sourced, just a variant of:
> [I do not] carry such information in my mind since it is readily available in books. ...The value of a college education is not the learning of many facts but the training of the mind to think.
I haven't got the book yet but I'm planning to get it soon. As written in Q&A - The techniques I learned, and used in the memory contest, are great for remembering structured information - this might be great for learning languages. I remember grabbing a lot of new vocabulary by studying by heart lyrics of songs, quotes, jokes or whole sequences of dialogs from movies.
Just a head's up, this books reads more like a novel than a How-To. There are other books that are better for actually learning the memory techniques discussed in _Moonwalking_.
I don't mean to imply that _Moonwalking_ isn't worth buying; I think it's a really good book and was a very fun read, but at the same time, it was FAR less instructional than I had expected (though I did learn while reading it).
This is presumably based on the theory that your mind has a certain amount of "free space" and that you don't want to fill that space up with a bunch of trivia. Anyone know whether cognitive science supports this theory? Bonus points for references.
When I do this with a Project STAR spectrometer and my cameras and point it to a candle I get two distinct dips in the spectral distribution. It should be even like a blackbody. I have made a parser for the RGB-picture to turn it to a B&W power distribution and I thought I'd might do a simple software filter to make it completely even, like a calibration of sorts. Like so: http://www.flickr.com/photos/defdac/7874867702/in/photostrea...
I use the power distributions coupled with lumen and wattage-specification as input for my home made spectrally based global illumination renderer to calculate PAR in aquariums.
Do you think this will work?
I'm currently learning Blender. It's an open source 3D-modeling program with one of the most non-intuitive GUIs ever created. It's like the Vim/Emacs of 3D-creation.
Being able to just grab a 3D-object with your hands and kneed it to the shape you want would be freakishly amazing.
The thing with unity is that it's almost so easy to grasp that when you sit down with it, it's almost not necessary. You can spend time thinking about actual implementation details while Unity does all the "boring" stuff. That said - when I started searching for specific problems I had the community had all the answers and then some. Another awesome thing is that you can do really complex stuff, like intricate shaders, if you want. Completing a full featured 3D-game have never felt so close to me.
"Did you help somebody solve a problem? Write it down. Did you connect with a colleague or friend? Write it down. Did you make somebody smile? Write it down."
This sound more like pride/fulfillment rather than gratitude?
