I definitely feel this. I'm only 24, but already I can feel the effects of being in a chair for 8-16 hours a day. It's sad that it is happening so quickly, but it has really made me realize how much I need to break the cycle and start thinking about this now, rather than just deferring it till when I have time.
Also I deeply feel the mental bubble that forms around me when i'm programming. It makes it scarily easy to just start withdrawing from other people and the world around me.
I do still love programming, and I'd like to think i'm pretty damn good at it. But do I want to be doing it as a job in 30 years time? I'm not so sure anymore.
I've been through one software job at the very loose-and-fast end of software development, but the pace (and a huge amount of overtime) burnt me out. I got to the stage where I couldn't get myself out of bed to go to work the next day. Over time I recovered somewhat, but I just wasn't enthusiastic about the work anymore.
My current job is at the complete opposite end of the spectrum. Medical software development is very slow, conservative, and methodical. To be honest I can see why most of the companies in this industry are at the thousands-to-tens-of-thousands scale; you literally need that critical mass in terms of staffing to deal with all of the overhead associated with a medical product. Reports, standards, committees, meetings, audits. And yet this company is doing it with less than 10 people.
It's really feel-good work, but it is really easy to get bogged down in the day-do-day drudgery and overhead, to the point where you completely miss the big picture of helping save peoples' lives. Do I want to be doing this when i'm 50? I don't think so.
In general in software development there's a couple of things that I've realized you have to work really hard at to have as a software developer. I've also discovered that both of these are much more important to me than I used to think:
-- Physical health and fitness: if you're sitting statically in a chair for 8-16 hours a day you have to really watch your diet and make continuous conscious efforts to exercise at every opportunity: it's going to catch up with you eventually (especially by the time you get to that 50 mark).
-- Varied and changing environments: both of my parents have "desk jobs", but both have extensive trips out of the office to visit customers or other sites. As a programmer I don't get this variety (the spice of life), so it's very easy to get bogged down and forget the big picture. I think this also leads to getting stuck in mental and emotional loops, due to a lack of external stimulus (kind of like what people who work from home report).
Nothing prepares you for actually being in a 9-5 programming job. At university it was obvious that there were people who were able to pass tests well enough, but would obviously struggle to code their way out of a paper bag. What about the people like myself, who are competent and practical, but are not prepared mentally to handle the rigors of 9-5 programming? Maybe that's why there is a shortage of labour in this sector: not only are we struggling to find people who are excited about programming and skilled at it, but we also struggle to find people who can handle working in these commercial scenarios?
There are also a number of companies that aren't like the examples above, especially in SV. But the problem with that is that not all of us are, or want to be, in Silicon Valley. Could I start my own company? Maybe, but that's not where my competencies or passions lie, at least currently.
Some deep thought is required about where exactly I will go next, given the time and effort I've invested up till this point into electronics, computers and programming.
I think he's not so much against having Minecraft run on Windows 8 at all (i'm sure if Java support it, it'll run), I think he's just more averse to serving it via Microsoft's store.
I think Notch is overreacting in this case because he's already supported Microsoft's platform monopoly with Minecraft on the Xbox 360 (which is completely closed), so this stance seems kind of contrary.
Possibly there's some sort of clause in Microsoft's contracts that says an Application on the Windows Store can't be sold outside the store or something which he's actually getting up in arms about.
I'm not particularly crazy about Windows 8 either, but Notch probably needs to be a little more specific with his protests (then again, it is just a twitter post).
This may just be me picking on one small part of the entire post, but I have a serious technical problem with some of the author's claims, not least of which is his feelings that FPGAs will somehow revolutionize personal computing.
Anyone who has programmed with an FPGA will understand the sort of tasks they're best for; hand-optimizing particular algorithms and processes into parallel pipelines and execution units.
Running a general-purpose OS on a CPU built in software on top of an FPGA is just not feasible; the yeild of transistors to logic units is very low for FPGAs compared to conventional microprocessors; and there's matters of efficiency, layout, and cost-effectiveness to think of. There has been some success using an FPGA-type programmable gate array in combination with a standard CPU, but the CPU itself is usually a proprietary core made to coordinate and assist the FPGA. These sorts of FPGA co-processors are only ever used for very specialized aplications currently. They won't be replacing general-purpose dedicated CPUs anytime soon (if ever).
FPGAs are perfectly suitable for any special-purpose functions they've been programmed for: but I think in terms of desktop and mobile computing, having a farm of parallel execution units in the form of a modern GPU will also yield acceptable results for any parallel consumer applications without the need for as much investment as with dedicated reprogrammable FPGA hardware.
The other technical concern I have is mesh networks; we don't currently have the technology to create and maintain large-scale mesh networks, but even if we did, there is a point there the communication required just to maintain the network outpaces the node-to-node bandwidth, or even the global bandwidth available. You also have to deal with privacy concerns around data storage and transmission at nodes while it is en-route to a destination, and circle-of-trust issues, etc. These issues bring the pendulum in a full circle.
I agree that the pendulum does seem to be in a state of change at the moment, and all that is keeping it from swinging back (and probably giving it more overall momentum in the progress) is government and business interests.
I think the issues we face, and that we have always faced, are not so much technical as they are social and societal. By the time we solve the issues around the commons, ownership, and governance; the technical issues will seem trivial.
A very comprehensive list of the organizations using Go; I think it's kept reasonably up to date, but new ones are popping up on the mailing list from time to time.
For example, not to long ago we had the maintainer of pool.ntp.org asking some questions as he was rewriting some of the infrastructure for the pool from Perl to Go.
I've been looking at making a 2D game library for Go based on some older Go code, and various people have made similar efforts, but there's nothing yet that's full and complete. The best option in most cases is to use bindings to OpenGL/SDL/SDL2 for 2D, or bindings to a 3D game engine (Horde3D bindings are available, and there's at least one engine built largely in Go)
There's prorbably more stuff around, but this is what I have collected so far. The biggest concern when making games is the GC; you'll either get a choppy framerate from occasional GC runs, or you'll get a consistent overhead from running the GC every frame. If/when the GC becomes concurrent this situation will vastly improve for games.
I think in real usage (in my experience), this is very rarely the case. The only thing Generics are really extremely useful for is writing data structures that you can re-use with multiple data types.
Also, I tend to appreciate Go's approach of writing more code in these situations, because in general the code is still far more readable than a C++ Template (for example).
The Go creators have not ruled out adding Generics, they are simply being very careful about how they implement it. I would rather have this situation than something like a generic Java/C#/C++ style generics implementation rammed in because it is demanded by people who have hardly touched the language (or refuse to touch it until said feature is added).
The great thing about Go as a web language is that alot of the bones are already there - templates and HTTP handling are already waiting for you in the standard library.
The most popular web frameworks i've seen for Go so far are Web.go (a Web.py clone) and Revel (a Play clone). Frameworks will develop organically over time. The only reason they're not very strong at this stage is because as I said; most of the batteries you need for web development are already included in the standard library.
To be fair, this will change as go becomes more popular and mature, I don't even know why people keep bringing it up.
Is "C" any more searchable? If C was 3 years old, search results would probably be dominated by pages on the letter "C". I remember search results when C# first came out: most search engines presumed you were talking about musical notes. Java searches kept showing me pages about coffee suppliers and distributors.
None of these languages have this problem anymore because they are mature, and the context around them is firmly established.
The accepted name for the language when doing searches is "golang", and Google does a great job at optimising results around this term. Also there's the IRC channel and Google group if you can't find what you need.
First of all; Go is compiled to binary form, it doesn't run on a VM (yet?).
Second of all; the words you're looking for are "get" and "For", not "gets" and "Fore". Sorry to be a grammar nazi, but I'm just calling it as I see it, and this isn't Reddit or 4chan (yet?).
For others wanting to know more about Go's garbage collection, it used a conservative GC up until recently, but heaps of work has been done to make the GC precise, so we don't get leaks on 32-bit platforms. As far as I know this GC change has yet to be released (current release is 1.0.2, and the changes should be in the next release).
That said, if you clone tip and build from there (it's remarkably stable) you should be able to see the differences.
I've had very similar concerns about GC vs. Manual memory management for games. It's good to finally see some sort of quantitative research and investigation, rather than people throwing around their opinions.
It's interesting that GDC is so much faster than DMD, especially given DMD is supposed to be the reference implementation. But then he is using plenty of optimization flags with GDC.
I don't know what sort of GC D uses, but incremental or generational garbage collection would probably be better for smoothing out differences in framerate due to GC rather than running an entire GC cycle every frame.
It's actually a pretty impressive game for only 3 months; I'm sure I couldn't code a 3D game with particle effects and that sort of lighting from the ground up in 3 months.
Overall for a performance hit of 4ms per frame, It would probably be worth using a GC when you consider all the errors and issues it would eliminate from game development. For me personally it would totally be worth it developing small independent games. Maybe not so much for AAA games where performance matters.
I think alot of these examples use esoteric or just plain "bad" C code just in order to create pits for programmers to fall into. In real life you would avoid writing code like this precisely because of these problems. The author even mentions for at least one of the examples that he had to disable or ignore compiler errors/warnings to run the code.
Sure, it can be important to know what these problems are and how to identify them if you should have to read through some terrible code written by someone else. Still, I think the author goes a bit far; it should be more important that you hire a programmer who doesn't produce this sort of code in the first place.
In the end I think there is no "best way" to technically test programmers; you're better off covering as many bases as possible with a bit of programming, a bit of documentation/explanation, some debugging, etc.
If everyone dictated their own hierarchy for their code base, utilities like go build and go get wouldn't work.
The guidelines are just guidelines - you can still do whatever the hell you want, but don't expect the standard tools to automatically handle all your own personal preferences for project structure.
Go had has this structure ever since the Go 1 release - your source goes in $GOPATH/src/$YOUR_PATH, and the go get/build tool will compile any main packages to $GOPATH/cmd, and all packages to $GOPATH/pkg/$YOUR_PATH.
If you really want to isolate the code for a specific application/project, why not use a folder structure like $GOPATH/src/$PROJECT/$PACKAGE or $GOPATH/src/$PROJECT/$EXECUTABLE. I had problems initially adjusting to the Go 1 workspace changes, but it's really not a big issue once you adapt a little (like anything in Go).
Just thinking of a specific case, but what do you think about subscription games that promise a lifetime membership (e.g. Star Trek online), then end up going F2P anyway?
I would postulate that this is a similar issue, as you are now being charged for the game _again_ via the F2P model. That said, it seems like it would be a harder one to solve; would the paid content have to be available to the lifetime subscribers for free? Would you stop the game from going F2P to uphold the lifetime/unlimited advertising limitations?
In the latter case I'm sure companies would just stop offering unlimited plans for games like this. I think it also sends the wrong message: if you're offering "unlimited" plans at launch, you obviously don't have that much faith in the longevity of your subscription game.
I agree that companies need to stop offering unlimited use of a product or service where their costs keep scaling with use. Companies always need to base this sort of pricing on the maximum possible natural lifetime of the product, not on when they can pull it if they get into hot water. We had the same thing here in New Zealand when the incumbent ISP offered "unlimited" ADSL plans. Their network of course got clobberred, and they backtracked on it and paid out all customers who'd been on the plan after a complaint to the government about false advertising (they started surreptitiously shaping traffic after some months). They later bought the plans back, but with much more fine print, and much more traffic shaping and regulation on the connections.
Image processing and machine vision is a big one. Part of the skeletal tracking algorithm for Kinect is implemented as a set of shaders on the Xbox's GPU.
That's just one example, but anything that involves image processing is a prime example of something that can be optimized for GPGPU.
EDIT: To add another couple of examples:
- Digital effects; rendering, etc. Digital effects studios like Weta Digital are using GPGPU for speeding up their photo-realistic rendering [1].
- Physics simulations for games; games can now move resource-heavy activities like physics simulation from the CPU to the GPU, not only freeing up CPU resources, but also increasing the number of particles, etc. that can be simulated (look for n-body simulations as an example).
To be fair, no programming language has really taken a first-party approach to those specific problems.
SIMD and GPGPU both fairly difficult low-level concepts as they stand: I think there would definitely be some valuable postgrad research in looking at how to create higher-level interfaces to graphics acceleration and GPGPU/SIMD that are as simple and effective as Go's goroutines.
The main problem is that SIMD and GPGPU (even hardware accelerated graphics, to a lesser extent) are bolt-ons; they're not a core part of every computer, which is why they don't usually form a core part of any programming language. At best languages might choose to integrate this functionality into the standard library, but i don't think it will ever come built-in for a general-purpose language (maybe for a domain-specific language?).
I've actually been attempting to write a GPGPU interface between Go and OpenCL[1], so it's certainly not impossible to do GPGPU or SIMD in Go (via cgo), but it would require writing your own 3rd-party libraries or making additions to the go runtime/compiler to develop a novel interface to this functionality like goroutines that can run on the GPU (a dream many people in the Go community share).
This is an interesting counterpoint to the original time post; it's better to think about the amount of energy and focus you're putting into something, because in the end these resources are much more finite and variable than time.
Time is a known quantity, and at any one time you know how much time you or your employees have available (more or less). You can burn through energy and focus at very different rates depending on how you spend it. It's also not as measurable as time, which is why people like to just equate time to effort/focus, and then just measure effort based on time spent.
In reality, some people are better at spending their effort in short sharp bursts over a longer period of time, while other people prefer to spend it all once until a task is done or they run out of energy, and there's all sorts of people in between. This also highlights the importance of taking time to recharge, and making sure you have a reasonably balanced life.
I think this is the big reason for the success of some implementations of hammock driven development and paid company holidays in increasing the value generated by employees. In the end it's important not only to consider time spent, but also to consider productivity. A focus purely on time spent is what gives us 40-hour work weeks chained to a desk. Because logically the more time you spend at your desk, the more work you'll get done, right? We all know the fallacy of this type of thinking.
This reminds me of the movie In Time[1]. The movie itself isn't particularly amazing, but I definitely resonated with it's underlying themes around the value of both time and money, and how they are inextricably linked.
It's a hard idea to communicate across to your average layperson though, that their half hour of diligently shopping around for the best deal actually cost them more than they saved. It's all conjecture though until you're actually using your time to earn money, or you are being paid for your time. But even if you aren't directly making money from your time, you can argue that the time spent will still offset/reduce the amount of time you do earn money from.
There are definitely limits on this type of thinking, and how seriously you should take it.
I'm in New Zealand, and ordered mine about the same time as you (NZD $55). The ETA when I ordered was 8-9 weeks, and it's been 3-4 already. Much like you, I haven't heard anything from RS in the meantime, which is a bit disappointing; a weekly or by-weekly update just to let me know what stage of production my orders at would be great, even just to know they are aware of it.
Kind of annoyed that I held off my order for a couple weeks after I got the notification. In the two weeks I waited from the time I got my notification to when I ordered the backlog went from 6 weeks to 9 weeks. If i'd ordered earlier i'd probably have my Pi by now.
Might order a second one from Farnell, but I hear they're still pretty backed up too.
Also I deeply feel the mental bubble that forms around me when i'm programming. It makes it scarily easy to just start withdrawing from other people and the world around me.