If people can take your product and walk without paying, they will, its human nature. If them doing that robs you of your livelihood, then the solution is change the product.
Wow, I've seen some stupid statements around here before but that one is extreme. You just claimed that the vast majority of businesses that make things and then sell them have to "get their business model sorted". Why should video games have to use a different business model to food, clothes, car, electricity or TV companies?
DRM is developed and used because the world is full of people who just don't pay for things, as you astutely observe. The solution is not to try and work around that by eliminating single player games. It's to make it difficult to use the software without paying for it!
Yes it does. Well implemented DRM/copy protection on video games delays the time-to-crack on high-end titles by months, which is sufficient to make a big difference to sales. Macrovision et al have lots of statistics on this.... or what, do you really think ALL the big game publishers are spending money on something that provides no ROI?
I don't remember mentioning synchronization. I mentioned activation. Why do I need iTunes to activate a phone? And why I am only allowed to use iTunes to sync with an iPhone?
Obviously no I wouldn't complain, because then I wouldn't have to use one irrelevant product to use another. I mean, Internet Explorer was tied to Windows because it's jolly handy to have a rendering engine as part of the platform API, but it's also a rather good technique to put your competitors out of business.
Yeah the guys comment is way off. Microsoft at least let you write stuff for the Xbox 360 using a free SDK. It's not as good as "the real thing" because you have to write using.NET and the JIT compiler they provide is shitty, so you won't be producing competitive 3D engines anytime soon. But the API is all there and you can do some pretty cool things with it nonetheless.
Pretty much any smartphone is going to be more open than the iPhone. Symbian phones have an SDK you can write apps for. J2ME phones have an SDK you can write apps for. BlackBerries and Palms do as well. Some advanced features require code signing if you want to distribute them, but anybody with time and money can go through that process, it's not exactly locked down to the powers that be.
Video cards have always been programmable using OpenGL. I guess he means the hardware interface, but I don't see why that's some fundamental issue of freedom rather than simply one of engineering. Anybody can write software that uses their full capabilities.
The time to fix core issues in the SDK was before they shipped a phone that supported it, with an App Store full of apps written using it. Come on. There must be a reason for this, but it's hard to imagine what it might be.
Apples surge in popularity is mostly with the "man on the street", really. All the things you listed with the exception of record labels are only relevant to developers, and to be frank weren't all that popular with them either.
"A switch to a UNIX based operating system with modern APIs" you say? Some people might think that's a good thing. All I see is a crappy, creaking OS base made by some frankestein combination of BSD and NeXT - not exactly sprightly even back then. Don't get me wrong - I'm typing this on an OS X 10.4 box. But innovation would have been something like Microsoft Singularity: identifying a real problem computer users faced, and coming up with some real innovative solutions to it. Stuff we'd never seen before. Instead we got the 70s in new makeup.
The switch to Intel hardware was a giant PITA for developers and mostly invisible for end users. They did it because it was necessary to move forward, not to win popularity.
Adopting open source for parts of the OS is really a giant red herring. Using open source is not inherently virtuous, lots of companies do that. Giving back is. Apples own open source contributions are pretty lame IMHO - Safari is closed source, even though web browsers are a commodity and there's nothing especially innovative in there. WebKit is open source because they based it on KHTML but I remember when it first came out, the KHTML developers were pretty frustrated by Apples minimal-compliance unusable patch dumps.
Yeah, it's silly that they haven't lifted the NDA yet
So when will they? The obvious time to lift the NDA would have been the release of the iPhone 3G, but it seems it's still in effect. That's a pretty major oversight if it's a mistake. If it's not a mistake.... erm.... what the hell are they thinking?!?
You want to allow product tying for non-monopoly players, but disallow it for the monopolies. That's good governance
Er, what? How is that good governance. I'm trying really hard to think of why we should allow artificial product tying... and failing.
How is society served by requiring iTunes to activate an iPhone? How does the free market benefit when Apple abuse their iTunes install base to install Safari for Windows?
I can swallow "natural" tying.... like the iPhone SDK to a Mac.... because implementing the SDK in a cross platform fashion is hard and that shouldn't be an aspect of law. But Apple actually had to go out of their way to make the iPhone depend on iTunes and I'm just having a really hard time seeing why that kind of crap should only be illegal when you're a monopoly. Because to me it seems inherently bad.
Lastly, hating a company means that you're defining your reactions by them. It's precisely as valid as loving a company. Neither are logical or even sensible.
Another non-sequitur. A company is just a group of people. It's not illogical to dislike a company, anymore than it's illogical to dislike a group of bullies at high school, or a band, or a political party. Companies don't get a special "get out of emotions free" card through virtue of being incorporated.
D'oh. I'm a Googler but seriously, nobody is meant to understand compiled JavaScript. Good thing then, that GWT provides a mode in which it does not minify the code, so if something does go wrong in the generated JS you can track it down in the human readable version.
There are a lot of GWT myths floating around here. I don't work on it but I did adopt it for a project of mine recently, and it's worked out pretty well so far. Myths I saw reading this thread, in no particular order:
Content can't be crawled: well, GWT is meant for applications rather than websites, but you can embed anything you want in the bootstrap HTML which will be crawled just like normal. If you have an app in which you want to expose a giant database of things to a crawler then whilst you can still do that with GWT, you don't get as much of the benefit.
Can't use "traditional" frameworks like jQuery: a lot of the better JavaScript frameworks have equivalents in GWT actually, for instance, GWTQuery does what jQuery does (let you select nodes from the DOM using CSS selectors) - but it uses the GWT compiler magic to produce optimal code for each browser. For instance, it can compile your CSS expression into an XPath query for browsers that support that, or do things the long winded way for browsers that don't. Thus your user gets a maximally efficient app.
I suspect you'll see GWT used more and more in future. It's such a radically different approach it takes some getting used to, and whilst it does support evolving an existing codebase towards it, it's still easier if you start from scratch. Still, I do believe that GWT is one of the nicest open source things Google has released for a long time. It's very well thought out and is designed to be very efficient, which is important for any non-trivial web app.
Dudes, don't bite my head off. Nobody ever said teenagers couldn't do kernel hacking, they said that shouldn't be how they are introduced to it. And that's totally right!
Here are some aspects of kernel hacking from a beginners perspective (and really this is what it's about - being a beginner, not being a teenager):
Abstract: concepts like scheduling algorithms are way too removed from achieving useful results
Unforgiving of mistakes: Messed up? Time to reboot. This is amazingly frustrating for professionals, let alone novices.
Way too limited: kernels are written in C. C does not teach you modern software design, in particular, object orientation. Knowing this stuff inside out is crucial if you ever want to get a non-shitty job writing non-shitty software.
Here are some attributes of video game programming:
Immediate: you can see the results of what you do.
Forgiving of mistakes: if you make a mistake, you get a backtrace showing where. You fix the problem and continue. Fast turnaround time on mistakes is crucial to learning.
Many possibilities for learning: even a basic video game will involve complex data structures, maths, non-trivial algorithms, file and network IO, designing data formats, user interfaces.... you name it, video games need it.
Nobody is trying to insult you by saying teenagers should start with video game programming instead of kernel programming. Believe me, I'm 24 so it wasn't that long ago I was a teenager. After I finished with that video game I moved on and by 18 I was debugging race conditions in Wine. But doing that video game was some of the best experience I ever had - it let me practice object oriented design, high performance coding, memory management on a large scale, user interface design, OpenGL, and implementing complex algorithms like A* pathfinding.
I think that assumption is pretty sound actually. Otherwise the problem would have already been noticed when ridership/revenue figures became skewed.
It's a very common mistake to believe the bad guys are equally as competent as the good guys in security. In reality most of the people capable of doing this sort of work are already employed in the mainstream economy and getting paid good money for it. There's a long history of the bad guys bringing cracks to mass-market only after the "white hats" figure out how to do it and publish their results.
Probably, fixing the vulnerability would take years and involve a full recall of the cards. That's why NXP wanted to suppress the information. This isn't like some program where it's one auto-update away from being secure again. Now these researchers are going to release the information, chances are good that London will be flooded with cracked cards used by freeloaders. And it will take years to clear up no matter what NXP do. Not sure that's worth the release of an academic paper, to be quite honest. Unless the purpose of all this is to punish people who make mistakes?
That's not "writing them off", that's being realistic.
When I was a teenager learning to program, I wanted to write video games. And I did. It was my first exposure to open source - a Delphi 3D MMORPG project. It was hopelessly over ambitious for our little team but it was fun, and taught me a hell of a lot about programming. And actually the maintainer/founder of that project went on to work for Ubisoft, so it worked out OK for him.
Now the problem is that writing video games is actually pretty hard. Writing simple web apps is much easier. It also has the HUGE benefit that you can show your friends. I was very rarely able to show my friends what I'd written but when I did, it was a great feeling, because my friends intuitively understood that making a 3D world was hard.
So I think writing web apps is not a bad place to start. The main problem is that web apps aren't video games, and all teenagers want to write video games. If our kernel hacker isn't too hung up on Freedom, I'd strongly recommend getting an Xbox360 and setting him up with the XNA framework. It's very much oriented towards hobbyist and beginner programmers.
There are lots of tutorials, you write software in C# which is straightforward enough for novices but won't limit him, and the result can be uploaded to XBox Live or played when his friends come round. Importantly, it looks a whole lot more cool and professional (imho) if your work is running on a real games console.
There is also a full, free 3D engine available (TorqueX) which can help him get started with writing simple 3D games without needing to master trigonometry and Direct3D. Back when I was doing this stuff, you had raw OpenGL or Crystal Space if you used C++ and were feeling brave.
The Google style guide is generally pretty good, but the 80 character limit is something I wouldn't adopt if writing my own guide. It invariably forces breaking the line in weird places, meaning you can no longer easily use indentation of lines to glance structure out of the code. It leads to a lot of redundant work if you don't notice you went over the limit and reviewers make you go back and fix it. The rationale is so you can view lots of files side by side or in xterms, but IMHO the uglifying effect on the code is enormous. The other thing I'm not so keen on is the tails to indicate private members. I don't tend to find that helpful, but I guess some people do. And finally minimizing use of vertical whitespace tends to result in quite hard to read and intimidatingly dense blocks of code, but again, I can see the rationale for having as much code on screen as possible.
Saying the 360 is more open because it's been hacked is a little unfair, Microsoft in no way helped or guided anyone to hack it, it just so happens someone found a problem with the DVD-Rom's firmware that could be exploited fairly easily.
The DVD firmware hacks don't make the Xbox open, they just let you play pirated games... uh, sorry... I mean "backed up" games. There was a hack that let you run Linux on it but that was sealed pretty quickly, a long time ago.
The XBox is probably the most open of the consoles today, because Microsoft provided a supported path for people to write their own games or software for it, and they'll publish it on XBox Live if it passes some minimal quality bars (like not crashing or being full of porn). Anybody can download the XNA SDK and write their own game, and many people have. Despite the rather limited toolkit some of the results are very impressive. It's just too bad that they insist on you using a shitty C# compiler that couldn't optimize its way out of a wet paper bag, but nonetheless, the compiler/API is there and it's fully supported.
Yeah, Linux uses tons of text files in random unpredictable locations, which vary by distribution, which all have their own grammar, comment style, and which also aren't removed when you uninstall software (check our your dotfiles some time).
I really don't get why people love to rag on the registry so much. Perfect it ain't, but seriously, the registry provides a fast random access database with a standard API, integrated security and robust toolset for administrators. Why do you think GNOME created their own registry work-alike 10 years later? It's because the registry actually has a lot of advantages for managed networks and app developers that UNIX fans don't like to admit.
As a bonus, it's accessible from kernel mode so you can configure drivers with it as well. The equivalent on Linux is..... well there isn't really an equivalent. Drivers are configured using a collection of random config files, scripts that read those random config files and then poke state into the kernel through yet more bizarre custom interfaces that are made up on the spot. In Windows, you set some registry keys, the driver reads them... done.
Being able to run Python or Quake inside a Flash VM sounds useful at first blush, but it seems you'd lose most of what makes webapps nice for both developers and users. In particular, C based apps are not designed to be streamed, whereas Flash or AJAX apps usually are (to some extent). Nobody wants to browse to a "web app" and then spend 5 minutes twiddling their thumbs whilst 20 megabyte of Python runtime or Quake is pulled down over the wire. Web apps just have a different DNA to desktop apps.
I can see this being used to accelerate computation-heavy subelements of a regular Flash app though. I wonder how much of this is being driven by a desire to run a Photoshop subset inside Flash?
Yeah, I am not expecting this to be a pill that magically makes programs concurrent. In particular, writing programs to be trees of transforms would be quite hard in some cases and potentially very inefficient, as you trade parallelism for lots of extra load on the GC. The days when a compiler does it automatically are some way off I think, but I can imagine this simplifying the task of doing some calculations concurrently when used properly. It won't replace STM or locked threading but is another useful tool in the toolbox - and available quite cheaply.
I don't know about looping through the filesystem. That's shared state that the compiler probably can't perceive, and thus an evasion of the type system. But it'd be a pretty weird thing to do anyway. It can certainly prevent side-effects within the realm of the type system, for instance, pure functions can allocate memory using "new" but can't change any existing memory on the heap, or read global state that isn't also marked invariant.
Yes you can, that's the point of the "pure" keyword and transitive invariance. If the someTransform function is defined pure you know it will not change item, and the compiler can enforce that.
Yes, D is very young and has problems. But then again, what language didn't? It's easy to forget but Python was first released in 1991. It took many years before it became mainstream (and some would say it's still not there yet).
The post-mortem is an interesting document, but I disagree with the authors conclusions. The compilers are buggy, well, C++ had exactly the same problem for a long time but still was a huge success. In particular, the trend seems to be basing new compilers on LLVM, which has a pretty robust optimization core. Frontend bugs are by comparison pretty trivial and easy to fix. Another few years and I think this problem will be licked - and besides, lots of C++ code has workarounds for compiler issues. Same thing for class libraries.
You're right about C-level FFIs. However D provides a simple C++ FFI which as far as I know is unique. Such a thing would be very useful for a company like Google which has a lot of C++ code, as it'd simplify binding considerably (I don't mean to imply anything about the future direction of the codebase, by the way).
The argument about parallelism is a more interesting one. But I disagree with that too:) D provides exactly what is needed for automatic sharding of work across cores (or machines). Specifically the combination of transitive invariance, reflection and purity enforcement is a very powerful one.
Essentially, if you can write your code to consist of non-trivial trees of pure functions, then it's perfectly safe to parallelise something like this:
If someTransform and anotherTransform are both pure, by implication their parameters are transitively invariant, and thus they can both be invoked in parallel (because the compiler knows "item" can't be changed). What's more both calls can be invoked simultaneously as well.
Once the compiler knows these things, making this code run in parallel is simply another compiler optimization. That's the whole theory behind how functional languages can be super easy to parallelize. But in fact the key concepts can be applied to imperative languages as well, with the advantage that you can still have temporary mutable state within the function scopes - you just can't modify the heap, or anything reachable through your arguments.
D has keywords that let the compiler know and enforce function purity.
Now as it happens I doubt that any D compiler today implements this optimisation - it's sophisticated and transitive invariance is newly introduced in D2. But all the pieces of the puzzle are there. This also lets the compiler do calculations on data structures available at compile time.
Well, OK. Most functional languages I know require immutable state, but I'll look more closely at OCaml. How though, is it better than v2 of D, which appears to offer most things that functional languages offer (except perhaps an easy pattern matching syntax) but also a whole lot more?
Wow, it's not often I strongly criticise articles around here, but that was total garbage.
For the smart ones that didn't RTFA, here's a quick summary:
I like Erlang.
Big companies like Google and Amazon make things fast by using concurrency.
Erlang supports (one type of) concurrency.
Thus Google and Amazon are [probably] using Erlang.
Thus everyone should learn Erlang.
For the record, I work for Google and we don't use Erlang anywhere in the codebase. Google Gears restricts you to message passing between threads because JavaScript interpreters are not thread-safe, so it's the only way that can work. Visual Basic threading works the same way for similar reasons. It's not because eliminating shared state is somehow noble and pure, regardless of what the article would have you believe, and in fact systems like BigTable use both shared-state concurrency and message passing based concurrency.
The article says this:
Architects (but also university-professors for that matter) still think they can build current and future industrial-grade and internet-grade systems with the same technologies as they did 10-15 years ago.
But in fact the Google search engine, which is one of the larger "industrial-grade, internet-grade" systems I know of, is written entirely in C++. A language which is much the same as it was 10-15 years ago. Thus the central point of his argument seems flawed to me.
Seeing as the article is merely an advert for Erlang, I'll engage in some advocacy myself. If you have an interest in programming languages, feel free to check out Erlang, but be aware that such languages are taking options away from you, not giving you more. A multi-paradigm language like version two of D is a better way to go imho - it supports primitives needed to write in a functional style like transitive invariance, as well as a simple lambda syntax, easy closures and first class support for lazyness.
However it also compiles down to self-contained native code in an intuitive way, or at least, a way that's intuitive to the 99.9% of programmers used to imperative languages, unlike Erlang or Haskell. It provides garbage collection but doesn't force you to use it, unlike Java. It doesn't rely on a VM or JIT, unlike C#. It provides some measure of C and C++ interopability, unlike most other languages. And it has lots of time-saving and safety-enhancing features done in a clean way too.
Actually, Gears doesn't use Erlang either. What he means is that Gears threading doesn't allow for shared state (is it really threading then?). Instead threads communicate back to the browser by message passing.
It's remarkably deceptive indeed to even imply that Gears and Erlang are connected. Message passing based concurrency isn't exactly new or limited to Erlang, and can be implemented in any language.
I'm not sure what the point of this piece is. I've looked at Erlang and didn't see much of anything to get me excited. It's a functional language, which like most of them have unnecessarily weird syntax and force immutable state. I don't really see what this buys you over a language like D 2 (or hell, even C++) in which you can write in a functional message passing style if you like, but then still use imperative shared state whenever useful, convenient or performant.
If you see two different versions of libstdc++ loaded at once (not like above), there's your problem. This caused no end of problems for me with Firefox crashing all the time, but it's actually not the fault of Firefox, Flash or C++. It's a problem with the way ELF is designed.
Slashdot Mirror
Wow, I've seen some stupid statements around here before but that one is extreme. You just claimed that the vast majority of businesses that make things and then sell them have to "get their business model sorted". Why should video games have to use a different business model to food, clothes, car, electricity or TV companies?
DRM is developed and used because the world is full of people who just don't pay for things, as you astutely observe. The solution is not to try and work around that by eliminating single player games. It's to make it difficult to use the software without paying for it!
Yes it does. Well implemented DRM/copy protection on video games delays the time-to-crack on high-end titles by months, which is sufficient to make a big difference to sales. Macrovision et al have lots of statistics on this .... or what, do you really think ALL the big game publishers are spending money on something that provides no ROI?
I don't remember mentioning synchronization. I mentioned activation. Why do I need iTunes to activate a phone? And why I am only allowed to use iTunes to sync with an iPhone?
Obviously no I wouldn't complain, because then I wouldn't have to use one irrelevant product to use another. I mean, Internet Explorer was tied to Windows because it's jolly handy to have a rendering engine as part of the platform API, but it's also a rather good technique to put your competitors out of business.
Yeah the guys comment is way off. Microsoft at least let you write stuff for the Xbox 360 using a free SDK. It's not as good as "the real thing" because you have to write using .NET and the JIT compiler they provide is shitty, so you won't be producing competitive 3D engines anytime soon. But the API is all there and you can do some pretty cool things with it nonetheless.
Pretty much any smartphone is going to be more open than the iPhone. Symbian phones have an SDK you can write apps for. J2ME phones have an SDK you can write apps for. BlackBerries and Palms do as well. Some advanced features require code signing if you want to distribute them, but anybody with time and money can go through that process, it's not exactly locked down to the powers that be.
Video cards have always been programmable using OpenGL. I guess he means the hardware interface, but I don't see why that's some fundamental issue of freedom rather than simply one of engineering. Anybody can write software that uses their full capabilities.
The time to fix core issues in the SDK was before they shipped a phone that supported it, with an App Store full of apps written using it. Come on. There must be a reason for this, but it's hard to imagine what it might be.
Apples surge in popularity is mostly with the "man on the street", really. All the things you listed with the exception of record labels are only relevant to developers, and to be frank weren't all that popular with them either.
"A switch to a UNIX based operating system with modern APIs" you say? Some people might think that's a good thing. All I see is a crappy, creaking OS base made by some frankestein combination of BSD and NeXT - not exactly sprightly even back then. Don't get me wrong - I'm typing this on an OS X 10.4 box. But innovation would have been something like Microsoft Singularity: identifying a real problem computer users faced, and coming up with some real innovative solutions to it. Stuff we'd never seen before. Instead we got the 70s in new makeup.
The switch to Intel hardware was a giant PITA for developers and mostly invisible for end users. They did it because it was necessary to move forward, not to win popularity.
Adopting open source for parts of the OS is really a giant red herring. Using open source is not inherently virtuous, lots of companies do that. Giving back is. Apples own open source contributions are pretty lame IMHO - Safari is closed source, even though web browsers are a commodity and there's nothing especially innovative in there. WebKit is open source because they based it on KHTML but I remember when it first came out, the KHTML developers were pretty frustrated by Apples minimal-compliance unusable patch dumps.
So when will they? The obvious time to lift the NDA would have been the release of the iPhone 3G, but it seems it's still in effect. That's a pretty major oversight if it's a mistake. If it's not a mistake .... erm .... what the hell are they thinking?!?
Er, what? How is that good governance. I'm trying really hard to think of why we should allow artificial product tying ... and failing.
How is society served by requiring iTunes to activate an iPhone? How does the free market benefit when Apple abuse their iTunes install base to install Safari for Windows?
I can swallow "natural" tying .... like the iPhone SDK to a Mac .... because implementing the SDK in a cross platform fashion is hard and that shouldn't be an aspect of law. But Apple actually had to go out of their way to make the iPhone depend on iTunes and I'm just having a really hard time seeing why that kind of crap should only be illegal when you're a monopoly. Because to me it seems inherently bad.
Another non-sequitur. A company is just a group of people. It's not illogical to dislike a company, anymore than it's illogical to dislike a group of bullies at high school, or a band, or a political party. Companies don't get a special "get out of emotions free" card through virtue of being incorporated.
D'oh. I'm a Googler but seriously, nobody is meant to understand compiled JavaScript. Good thing then, that GWT provides a mode in which it does not minify the code, so if something does go wrong in the generated JS you can track it down in the human readable version.
There are a lot of GWT myths floating around here. I don't work on it but I did adopt it for a project of mine recently, and it's worked out pretty well so far. Myths I saw reading this thread, in no particular order:
I suspect you'll see GWT used more and more in future. It's such a radically different approach it takes some getting used to, and whilst it does support evolving an existing codebase towards it, it's still easier if you start from scratch. Still, I do believe that GWT is one of the nicest open source things Google has released for a long time. It's very well thought out and is designed to be very efficient, which is important for any non-trivial web app.
Dudes, don't bite my head off. Nobody ever said teenagers couldn't do kernel hacking, they said that shouldn't be how they are introduced to it. And that's totally right!
Here are some aspects of kernel hacking from a beginners perspective (and really this is what it's about - being a beginner, not being a teenager):
Here are some attributes of video game programming:
Nobody is trying to insult you by saying teenagers should start with video game programming instead of kernel programming. Believe me, I'm 24 so it wasn't that long ago I was a teenager. After I finished with that video game I moved on and by 18 I was debugging race conditions in Wine. But doing that video game was some of the best experience I ever had - it let me practice object oriented design, high performance coding, memory management on a large scale, user interface design, OpenGL, and implementing complex algorithms like A* pathfinding.
I think that assumption is pretty sound actually. Otherwise the problem would have already been noticed when ridership/revenue figures became skewed.
It's a very common mistake to believe the bad guys are equally as competent as the good guys in security. In reality most of the people capable of doing this sort of work are already employed in the mainstream economy and getting paid good money for it. There's a long history of the bad guys bringing cracks to mass-market only after the "white hats" figure out how to do it and publish their results.
Probably, fixing the vulnerability would take years and involve a full recall of the cards. That's why NXP wanted to suppress the information. This isn't like some program where it's one auto-update away from being secure again. Now these researchers are going to release the information, chances are good that London will be flooded with cracked cards used by freeloaders. And it will take years to clear up no matter what NXP do. Not sure that's worth the release of an academic paper, to be quite honest. Unless the purpose of all this is to punish people who make mistakes?
That's not "writing them off", that's being realistic.
When I was a teenager learning to program, I wanted to write video games. And I did. It was my first exposure to open source - a Delphi 3D MMORPG project. It was hopelessly over ambitious for our little team but it was fun, and taught me a hell of a lot about programming. And actually the maintainer/founder of that project went on to work for Ubisoft, so it worked out OK for him.
Now the problem is that writing video games is actually pretty hard. Writing simple web apps is much easier. It also has the HUGE benefit that you can show your friends. I was very rarely able to show my friends what I'd written but when I did, it was a great feeling, because my friends intuitively understood that making a 3D world was hard.
So I think writing web apps is not a bad place to start. The main problem is that web apps aren't video games, and all teenagers want to write video games. If our kernel hacker isn't too hung up on Freedom, I'd strongly recommend getting an Xbox360 and setting him up with the XNA framework. It's very much oriented towards hobbyist and beginner programmers.
There are lots of tutorials, you write software in C# which is straightforward enough for novices but won't limit him, and the result can be uploaded to XBox Live or played when his friends come round. Importantly, it looks a whole lot more cool and professional (imho) if your work is running on a real games console.
There is also a full, free 3D engine available (TorqueX) which can help him get started with writing simple 3D games without needing to master trigonometry and Direct3D. Back when I was doing this stuff, you had raw OpenGL or Crystal Space if you used C++ and were feeling brave.
The Google style guide is generally pretty good, but the 80 character limit is something I wouldn't adopt if writing my own guide. It invariably forces breaking the line in weird places, meaning you can no longer easily use indentation of lines to glance structure out of the code. It leads to a lot of redundant work if you don't notice you went over the limit and reviewers make you go back and fix it. The rationale is so you can view lots of files side by side or in xterms, but IMHO the uglifying effect on the code is enormous. The other thing I'm not so keen on is the tails to indicate private members. I don't tend to find that helpful, but I guess some people do. And finally minimizing use of vertical whitespace tends to result in quite hard to read and intimidatingly dense blocks of code, but again, I can see the rationale for having as much code on screen as possible.
The DVD firmware hacks don't make the Xbox open, they just let you play pirated games ... uh, sorry ... I mean "backed up" games. There was a hack that let you run Linux on it but that was sealed pretty quickly, a long time ago.
The XBox is probably the most open of the consoles today, because Microsoft provided a supported path for people to write their own games or software for it, and they'll publish it on XBox Live if it passes some minimal quality bars (like not crashing or being full of porn). Anybody can download the XNA SDK and write their own game, and many people have. Despite the rather limited toolkit some of the results are very impressive. It's just too bad that they insist on you using a shitty C# compiler that couldn't optimize its way out of a wet paper bag, but nonetheless, the compiler/API is there and it's fully supported.
Yeah, Linux uses tons of text files in random unpredictable locations, which vary by distribution, which all have their own grammar, comment style, and which also aren't removed when you uninstall software (check our your dotfiles some time).
I really don't get why people love to rag on the registry so much. Perfect it ain't, but seriously, the registry provides a fast random access database with a standard API, integrated security and robust toolset for administrators. Why do you think GNOME created their own registry work-alike 10 years later? It's because the registry actually has a lot of advantages for managed networks and app developers that UNIX fans don't like to admit.
As a bonus, it's accessible from kernel mode so you can configure drivers with it as well. The equivalent on Linux is ..... well there isn't really an equivalent. Drivers are configured using a collection of random config files, scripts that read those random config files and then poke state into the kernel through yet more bizarre custom interfaces that are made up on the spot. In Windows, you set some registry keys, the driver reads them ... done.
Being able to run Python or Quake inside a Flash VM sounds useful at first blush, but it seems you'd lose most of what makes webapps nice for both developers and users. In particular, C based apps are not designed to be streamed, whereas Flash or AJAX apps usually are (to some extent). Nobody wants to browse to a "web app" and then spend 5 minutes twiddling their thumbs whilst 20 megabyte of Python runtime or Quake is pulled down over the wire. Web apps just have a different DNA to desktop apps.
I can see this being used to accelerate computation-heavy subelements of a regular Flash app though. I wonder how much of this is being driven by a desire to run a Photoshop subset inside Flash?
Yeah, I am not expecting this to be a pill that magically makes programs concurrent. In particular, writing programs to be trees of transforms would be quite hard in some cases and potentially very inefficient, as you trade parallelism for lots of extra load on the GC. The days when a compiler does it automatically are some way off I think, but I can imagine this simplifying the task of doing some calculations concurrently when used properly. It won't replace STM or locked threading but is another useful tool in the toolbox - and available quite cheaply.
I don't know about looping through the filesystem. That's shared state that the compiler probably can't perceive, and thus an evasion of the type system. But it'd be a pretty weird thing to do anyway. It can certainly prevent side-effects within the realm of the type system, for instance, pure functions can allocate memory using "new" but can't change any existing memory on the heap, or read global state that isn't also marked invariant.
Yes you can, that's the point of the "pure" keyword and transitive invariance. If the someTransform function is defined pure you know it will not change item, and the compiler can enforce that.
Yes, D is very young and has problems. But then again, what language didn't? It's easy to forget but Python was first released in 1991. It took many years before it became mainstream (and some would say it's still not there yet).
The post-mortem is an interesting document, but I disagree with the authors conclusions. The compilers are buggy, well, C++ had exactly the same problem for a long time but still was a huge success. In particular, the trend seems to be basing new compilers on LLVM, which has a pretty robust optimization core. Frontend bugs are by comparison pretty trivial and easy to fix. Another few years and I think this problem will be licked - and besides, lots of C++ code has workarounds for compiler issues. Same thing for class libraries.
You're right about C-level FFIs. However D provides a simple C++ FFI which as far as I know is unique. Such a thing would be very useful for a company like Google which has a lot of C++ code, as it'd simplify binding considerably (I don't mean to imply anything about the future direction of the codebase, by the way).
The argument about parallelism is a more interesting one. But I disagree with that too :) D provides exactly what is needed for automatic sharding of work across cores (or machines). Specifically the combination of transitive invariance, reflection and purity enforcement is a very powerful one.
Essentially, if you can write your code to consist of non-trivial trees of pure functions, then it's perfectly safe to parallelise something like this:
foreach (item; list) {
fooResults[item] = someTransform(item);
barResults[item] = anotherTransform(item);
}
If someTransform and anotherTransform are both pure, by implication their parameters are transitively invariant, and thus they can both be invoked in parallel (because the compiler knows "item" can't be changed). What's more both calls can be invoked simultaneously as well.
Once the compiler knows these things, making this code run in parallel is simply another compiler optimization. That's the whole theory behind how functional languages can be super easy to parallelize. But in fact the key concepts can be applied to imperative languages as well, with the advantage that you can still have temporary mutable state within the function scopes - you just can't modify the heap, or anything reachable through your arguments.
D has keywords that let the compiler know and enforce function purity.
Now as it happens I doubt that any D compiler today implements this optimisation - it's sophisticated and transitive invariance is newly introduced in D2. But all the pieces of the puzzle are there. This also lets the compiler do calculations on data structures available at compile time.
Well, OK. Most functional languages I know require immutable state, but I'll look more closely at OCaml. How though, is it better than v2 of D, which appears to offer most things that functional languages offer (except perhaps an easy pattern matching syntax) but also a whole lot more?
Wow, it's not often I strongly criticise articles around here, but that was total garbage.
For the smart ones that didn't RTFA, here's a quick summary:
For the record, I work for Google and we don't use Erlang anywhere in the codebase. Google Gears restricts you to message passing between threads because JavaScript interpreters are not thread-safe, so it's the only way that can work. Visual Basic threading works the same way for similar reasons. It's not because eliminating shared state is somehow noble and pure, regardless of what the article would have you believe, and in fact systems like BigTable use both shared-state concurrency and message passing based concurrency.
The article says this:
But in fact the Google search engine, which is one of the larger "industrial-grade, internet-grade" systems I know of, is written entirely in C++. A language which is much the same as it was 10-15 years ago. Thus the central point of his argument seems flawed to me.
Seeing as the article is merely an advert for Erlang, I'll engage in some advocacy myself. If you have an interest in programming languages, feel free to check out Erlang, but be aware that such languages are taking options away from you, not giving you more. A multi-paradigm language like version two of D is a better way to go imho - it supports primitives needed to write in a functional style like transitive invariance, as well as a simple lambda syntax, easy closures and first class support for lazyness.
However it also compiles down to self-contained native code in an intuitive way, or at least, a way that's intuitive to the 99.9% of programmers used to imperative languages, unlike Erlang or Haskell. It provides garbage collection but doesn't force you to use it, unlike Java. It doesn't rely on a VM or JIT, unlike C#. It provides some measure of C and C++ interopability, unlike most other languages. And it has lots of time-saving and safety-enhancing features done in a clean way too.
Actually, Gears doesn't use Erlang either. What he means is that Gears threading doesn't allow for shared state (is it really threading then?). Instead threads communicate back to the browser by message passing.
It's remarkably deceptive indeed to even imply that Gears and Erlang are connected. Message passing based concurrency isn't exactly new or limited to Erlang, and can be implemented in any language.
I'm not sure what the point of this piece is. I've looked at Erlang and didn't see much of anything to get me excited. It's a functional language, which like most of them have unnecessarily weird syntax and force immutable state. I don't really see what this buys you over a language like D 2 (or hell, even C++) in which you can write in a functional message passing style if you like, but then still use imperative shared state whenever useful, convenient or performant.
People should check the following command:
$ grep libstdc++ /proc/`pidof firefox-bin`/maps /usr/lib/libstdc++.so.6.0.7 /usr/lib/libstdc++.so.6.0.7
45919000-459e6000 r-xp 00000000 08:01 2917741
459e6000-459eb000 rw-p 000cd000 08:01 2917741
If you see two different versions of libstdc++ loaded at once (not like above), there's your problem. This caused no end of problems for me with Firefox crashing all the time, but it's actually not the fault of Firefox, Flash or C++. It's a problem with the way ELF is designed.