174 karma · joined March 31, 2011
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'm currently 24.
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 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).
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.
Ahem...
http://golang.org/pkg/html/template/
It doesn't have its own equivalent of RoR or Django yet because most of the batteries needed for web development are built-in.
There have been a few people making games in Go. Games: http://www.kickstarter.com/projects/2066438441/haunts-the-ma... http://blog.iandavis.com/tag/amberfell/ https://github.com/iand/amberfell http://www.pokemon-universe.com/ http://code.google.com/p/pokemon-universe/
Engines/Libraries: http://code.google.com/p/gohorde/ https://github.com/genbattle/Go2D https://github.com/DeedleFake/sdl https://github.com/Agon/baukasten https://github.com/chsc/gogl https://github.com/foobaz/egl
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.
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 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.
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.
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.
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.
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.
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).
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.
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).
[1] http://blogs.nvidia.com/2010/01/nvidia-collaborates-with-wet...
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).
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.
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.
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.
That said, Microsoft didn't create a competitor to canvas and many other new web APIs (but I don't know how standards-compliant they are these days in terms of Javascript, Canvas, SVG, etc.).
WebGL would have to have a killer app on mobile for Microsoft's lack of mobile presence to hurt them. Currently all WebGL Demos I've seen have assumed a desktop-level of graphics performance, and no phones are "officially" capable of WebGL yet.
I just tried the three.js examples from my Galaxy Nexus (running 4.1) and couldn't get any of them working in either Chrome for Android or the default browser. That said, I know it's possible with some hacking and tweaking. From what I hear iOS has about equivalent support at this stage. That said, Apple and (to a lesser extent) Google could roll out this support pretty easily in an update, but I maintain my initial reservation; that phone hardware will not be performant enough to make WebGL a viable replacement or complement to native OpenGL development on those platforms.
Microsoft is known for their embrace, extend, extinguish strategy. I think given the chance, they would do the same to WebGL. But at this stage they don't see WebGL as a serious threat: if they do, expect to see WebX, or DirectWeb, or something like that. I think Microsoft is 10x more likely to implement their own 3D Javascript API than to implement WebGL in Internet Explorer.
The only thing i'm concerned about is whether they can get even the hardware they've committed to in a $99 budget. Consider that this has the same hardware as the HTC one X, but without the screen, battery, and 3G connectivity. So they have to not only get the Tegra3 for $99, but also the case and power supply. Even if they manage to get those parts down to $99, they still have to add the controller, which will need it's own processor/controller to track and send the inputs over bluetooth to the console. Not to mention the cost of the controller hardware itself, particularly the touchpad.
The other thing that worries me is the Android base. Is the OS still going to lock code to using the Dalvik/Java-based API? If so then I have no hope of creating any games for the platform in my favourite language, Go. What about native-development, new experimental native game engines or languages? Hopefully they'll open the platform up a bit in this respect and allow some native development through a C API or something.
I definitely hope they pull through and deliver on this project, although I can imagine it not making it's way down to the southern hemisphere very quickly, if at all.
I would recommend you also look more specifically into where in New Zealand you want to live, or at least what sort of lifestyle you want. You can easily find a technology job in Auckland or Wellington (startups also tend to gravitate towards these cities), but that comes with higher costs and a certain degree of the rat-race lifestyle. There are small local companies and startups in the provinces, but pay (and costs) will be lower and opportunities are much fewer and far between.
I myself just moved out of the provinces into Wellington, and so far i'm enjoying being in a bigger pool of developers and having more things to see and do in general, but I know people who have made the opposite move as well.
Feel free to contact me if you need more info.
EDIT: Of course if you manage to get a remote job, it won't matter much where you live, provinces or otherwise :-)
I changed my default editor at work to be Vim, and started doing all my dev work at home through Vim. I started off just using the arrow keys to move and just using insert mode to edit text the normal way. Each day I tried to add one new command to my repertoire; I learned about how to structure vim commands (c-change i-in w-word, etc.) and move using hjkl and the higher order movement commands like w and b. Now I can maneuver my way around vim quite confidently, and although when I started off I was much slower in Vim than other editors, I now find that Vim is just as fast or faster for most tasks, particularly where I can make use of Macros.
At the moment I still have to get my head around markers and a few other concepts, but I've definitely become proficient enough for it to be worth the effort and time invested so far.
My tips for anyone learning to use vim for everyday development would be some common tab commands: :tabnew <path> to open a file in a new tab, :tab sball to show all currently open buffers in separate tabs, gt and gT to jump to the next/previous tabs.
The Go authors should be very receptive and informative on such an issue.
For the calculations that don't work well on the GPU due to small data sets, simple calculations, or bandwidth constraints we could just run the code in parallel across multiple cores/multiple goroutines.
I think eventually (and this seems to be the direction companies like AMD are headed in) we'll have a couple (maybe up to 4) big cores right next to a bunch of smaller whimpy GPU-like cores which handle SIMD, making SIMD on big cores all but redundant. We're not there yet but AMD and Intel are both working on trying to get their on-chip GPUs to share memory with the processor directly. At the moment the focus for this is mainly gaming performance, so textures, etc. don't have to be copied from main memory to the GPU; the same functionality will greatly benefit GPGPU though. Once we have this heterogeneous architecture and newer faster memory technologies, the problems with using the GPU for SIMD will disappear.
But for the moment, with the real-world technology constraints we have, you're absolutely right on the limitations of GPGPU.
To be honest my personal viewpoint is that we're better off reducing our dependence on SIMD CPU instructions and using GPUs for this sort of highly-parallel processing instead. Most Processors sold these days come with a GPU built-in, so why not make use of these SIMD units, rather than duplicating them on the CPU? This is just my opinion though, and is sort of irrelevant to the question.
Go has an excellent interface to C (cgo) built in, and SWIG can also be used to wrap C/C++ libraries so they are usable in Go. If your aim is core-for-core speed, then your best option is probably to take some highly optimised C/C++ library and create a wrapper that allows you to access it from Go. This route would be at least as performant as any python implementation using the same technique, if not much faster. If your goal is having a highly-concurrent and safe implementation, it is better to implement such libraries from scratch in Go; this is the method most Go libraries use.
Just as with benchmarks, I don't think anyone can give you a non-subjective answer on whether Go will be faster (so take mine with a grain of salt).
[1] http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...