|
Gather round young coders while I tell you a little story. Way back when, far before you were born, we were building programs just like you are. After we trudged uphill barefoot in the snow, we went into a scorching hot room and we hit the plugboards with boundless enthusiasm, plugging switches in to “portable function tables” and doing arithmetic as it was meant to be done… slowly. We didn’t have any “stored programs” like you spoiled brats, we had blueprints! Punch cards! Stuff written on napkins! You kids download and app to your phone to calculate your food budget but we really earned our keep. Old programmers had to be more resourceful and inventive.
|
|
|
|
|
It is true that we can now use Google to help find solutions, but a lot of the technology that we have today is a lot more difficult since the concepts need to be understood, and that takes time. The old time programmers only had a few tools to learn. Basically just a few statement types. Now programmers have to learn the concepts of OOD, design patterns, SQL, LINQ, and a whole bunch of other things. Also programs were single threaded without events like have today. Things were a lot more linear. Dealing with threads and their complexities is not very easy.
|
|
|
|
|
Contrariwise, the lesser number of tools and options available to them required theyo be ever more clever in order to implement solutions.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "As far as we know, our computer has never had an undetected error." - Weisert | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I do not agree. It is a lot more work, but understanding complex tools requires more understanding. It is very easy to use a shovel, but a backhoe is more complex. However the you are much efficient. If you do not have good tools, you have to go more brute force. That of course leads to the possibility of many more errors and inefficiencies. But that is another story. Just like it is much easier to make a straight cut with a table saw than a hand saw, but the table saw requires more knowlege to operate.
|
|
|
|
|
Contrariwise:^,
Brute Force? The Backhoe and the Table Saw win out on that account. Try digging up a gas pipeline with a back-hoe or using a table saw to remove a tree branch.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "As far as we know, our computer has never had an undetected error." - Weisert | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
True a table saw would not work for a tree branch, but I would prefer digging up a gas pipeline with backhoe rather than just a shovel. If I was cutting a tree branch I would prefer a saw to an axe, and for a very thick branch a chain saw.
|
|
|
|
|
A [Yahoo! Geocities-style] theme for Twitter Bootstrap, from Divshot. Someone just won the internets.
|
|
|
|
|
That is amazing. We applied to a test environment for a site we have that uses Bootstrap
|
|
|
|
|
LOL!
Gryphons Are Awesome! Gryphons Are Awesome!
|
|
|
|
|
I just threw up a little, in my mouth.
|
|
|
|
|
I’ve worked in technology for twenty years, the past thirteen as a product manager. I’ve gained somewhat of a reputation for being effective at working with software engineers.... For years I’ve kept my secrets close to the vest. But no longer: today I will share with you my Ten-Step Plan for Working With Engineers. Or more to the point: how to make engineers do what you tell them to do. Free donuts works for me. What's your trick?
|
|
|
|
|
Donuts don't work on me (I have a fairly strict diet).
I have also been given movie passes, but haven't used any because I always print tickets with Fandango.
Gobs and gobs of money tends to work on me though.
|
|
|
|
|
Wow! That was close.
Disgust almost caused me to cease reading before I got to the afterword.
Make it work. Then do it better - Andrei Straut
|
|
|
|
|
Sure, every game has an ending of sorts. For a certain class of classic game, though, that ending was always of the "You Are Dead Ha Ha Ha!" variety. From Robotron 2084's ever-increasing robot hordes to Missile Command's memorable "THE END" explosion, you went into these games knowing that failure was not just an option, but really the only option. Then there are the games that seem like they should go on forever but, for one reason or another, just don't. Whether it's because of a coding error leading to an unintentional "kill screen" or a simple design choice stopping an otherwise never-ending series of loops, a lot of games that seem unbeatable at first glance can actually be conquered in one way or another. Thanks to these programming glitches, it's exception-ally hard to win.
|
|
|
|
|
I want to know how to beat this, which is a sort of mega-mini-game you'd get when you plugged one of the other Sonic games into the Sonic & Knuckles cartridge (I think there may have been other steps involved).
Basically, you navigate non-stop around a checkerboard that is wrapped around a sphere world. There are a bunch of blue dots you visit, which turns them red. You must turn each blue dot red to pass that stage. If you hit a red dot, you lose. The star dots bounce you around.
Each stage seemed to be procedurally generated, and I played hundreds of them before giving up.
|
|
|
|
|
Microsoft is no stranger to the concept of wrist-based computing, having worked with watchmakers to release a line of smartwatches starting nearly a decade ago. Ultimately, they didn’t catch on, and the watches were discontinued. Now, a new report from the Wall Street Journal says the company is thinking about getting into the market again, with a touch-based smartwatch of its own. The report comes amid rumors that Apple, Google and others are moving in this direction with plans for smartwatches themselves. Even a stopped clock is right twice a day... except when it's digital.
|
|
|
|
|
Moore’s Law states that the number of transistors on an integrated circuit doubles every two years or so.... But if an observer today was to measure this rate of increase, it would be straightforward to extrapolate backwards and work out when the number of transistors on a chip was zero. In other words, the date when microchips were first developed in the 1960s.... These guys argue that it’s possible to measure the complexity of life and the rate at which it has increased from prokaryotes to eukaryotes to more complex creatures such as worms, fish and finally mammals. That produces a clear exponential increase identical to that behind Moore’s Law although in this case the doubling time is 376 million years rather than two years. People aren't that good at floating point math, either.
|
|
|
|
|
In today’s installment of FlippedBITS, I want to examine a handful of common misconceptions about IMAP, a common protocol for retrieving email from a server. IMAP stands for… well, thereby hangs the first tale. IMAP’s inventor, Mark Crispin (who, sadly, died in December 2012), called the first version of his creation Interim Mail Access Protocol. Versions 2, 3, and 2bis were referred to as Interactive Mail Access Protocol, and version 4 — what’s in use today — is officially Internet Message Access Protocol. Although many Web sites claim that the acronym once stood for Internet Mail Access Protocol, I have found no credible references to back up that claim. You've got mail... probably thanks to IMAP.
|
|
|
|
|
|
Huh. Cool.
Gryphons Are Awesome! Gryphons Are Awesome!
|
|
|
|
|
So someone shoulder-taps you and asks you to explain the concepts behind JavaScript Inheritance to them. In my eyes you’ve got a few options.... Sometimes these analogies get pretty crazy in my head, and I start to think that maybe instead of trying to apply known examples in the outside world in order to help people understand, it’s often better to just let someone know why they might wanna use inheritance in their programs! 4 great ways to understand inheritance.
|
|
|
|
|
I've been doing this programming thing for a long time now (8 professional years), and during that time I have accumulated a lot opinions (some are right, some are probably wrong). In this phase of my career I am looking at what programming constructs can I use to make my life easier. One thing that sticks out to me as a sore point is the keyword void.... To state it simply, void is useful when I want to perform an action on an object and don't expect a result returned. In theory it sounds great, but if I don't expect a single result back, I am most likely going to want to inspect the object itself, or perform another action on the object. To void or not to void... what do you think?
|
|
|
|
|
Interesting. Not sure I totally agree.
For instance (no pun intended), what about a class that abstracts out logging? Would those methods really need to return the class instance? I don't really see what there is to gain there.
Gryphons Are Awesome! Gryphons Are Awesome!
|
|
|
|
|
I think void is a representation anything which is something.
The way I see it NULL cannot be void but the void can be NULL if that makes sense...
|
|
|
|
|
I didn't read it, but it seems to be something I agree with. There are many cases where I'd like to chain calls together but can't because the method is void.
|
|
|
|