• If you haven't already, check out the Pragmatic Programming Language for the Future discussion going on in the Software Engineering forum. There's some absolutely excellent feedback coming together from this thing, and I think that with some real effort, we might actually have a winner on our hands here. I firmly believe that someone can produce The Next Killer Language if they pay attention to real life issues while doing so, and it's frankly kind of cool to be a part of an attempt at such a project. Hop on board, even if you have no particular interest in programming language theory... customer feedback is good, too
  


• Household cleaning chores suck. That is all.
  


• I'm developing some kind of perverse addiction to bulleted lists lately. Meheh. Bulleted.
  


• If you haven't already, go read Zen and the Art of Motorcycle Maintenance. Read it now. It's a fascinating read, even if some of the concepts presented are a bit debatable, and it'll make you think about all manner of things. It isn't so much profound or deep in and of itself, but it's a very effective mental stimulus. It's definitely a "brain-must-be-on" work, which I almost always enjoy.
  


• My knees hurt. Anyone know any good physical therapy exercises for strengthening knees? Especially stuff that's good for building up durability for someone planning on taking a lot of repeated impacts on the knees in the near future? (Yeah, yeah, yeah, wrong forum, I know.)

• Utter control over bindings between application layers.
  If I develop a suite of tools called Quux in C++, and want to access it from PHP, I have to build an extension to the Zend engine. That's a waste of time. If Quux is written in low-level Foo, and my web logic is written in high-level Foo, the bindings already exist: the interface for Quux just needs to be imported (via a Java/.Net style system) into my web logic, and I now have access.
  


• Consistency of semantics across layers.
  If Quux returns a value that may only range from -1 to 3, that contract can be expressed in Foo. Foo can then expose that contract to the web logic. I have now used a contract to help kill bugs in Quux, and now without any additional effort, my contract can help kill bugs in the web logic, too. Imagine the implications for things like web security. SQL injection would become a distant memory. Buffer overruns, covert data manipulation, and data-execution would all go away.
  


• Control over execution models.
  In an ideal world, Foo should allow me to run in many ways. I should be able to compile suitably low-level Foo into machine code. That wins us portability, because now Foo frameworks are easy to port to new OSes and hardware. (That's why C and C++ are so ubiquitous even outside of Windows, while .Net, despite all of its awesomeness, is unlikely to do anything on other platforms any time in the visible future.) I should be able to JIT-compile Foo for performance and to insulate against changes in supporting library code, similar to the way the JVM and .Net models work. I should also have the option of interpreting Foo on the fly to allow for dynamic and self-modifying code at high levels of abstraction. There is no reason why any one language should be bound tightly to a particular compilation/execution model. We simply need to make sure that programmers are aware of the caveats of each.

• The minimal level of abstraction should be highly concrete.
  It is my belief that C++ (and C before it) has had success largely because it allows freedom to build software close to the hardware. Sure, both languages allow the expression of abstract concepts - C++ much moreso than C - but there are far superior languages for expressing the abstract. It is not uncommon to embed languages into applications (especially games) so that abstract logic can be done in a language more suited to such things than C++. The longevity of C++ in particular has nothing to do with its abstract expressivity - it has everything to do with its ability to be concrete and unabstract. That's why C++ remains (incorrectly) synonymous with "performance-critical code" for many programmers.
  
  A new language must realize this, and capitalize on it. If a new tool is to have any kind of penetration and staying power in today's language market, it will have to allow programmers to work in highly concrete terms. This is critical for two reasons: first, it allows the New Language to affect many problem domains, like 3D graphics engine development, where concreteness is important. Second, it allows easier portability. If some useful subset of the language can be used without runtime dependencies (like those of Java or .Net languages), the language will have a much quicker transition to platforms other than the one it was born on. Computers have changed a lot since C++ was designed, but we still use it, because C++'s concreteness allows for portability.
  


• Maximize the ability to express semantics in both abstract and technical terms.
  We need a combination of C++'s ability to be very precise about data storage (unsigned 32 bit integers), and the ability of any reasonable high-level language to ignore those technical details. We need a way to be very specific about the way data is handled in hardware, when such things are appropriate. (This also ties in with having a low level of minimal abstraction inherent in the language; low-level programming is impossible without technical semantic expressivity.) At the same time, productive programming demands that we be able to quit worrying about stupid problems like overflow and signedness.
  
  We need ways to think about data types more richly than "numeric" and "string." We need a combination of dimensional analysis, flexible type definition, and rigorous storage/behavior semantics. Allowing types to be validated implicitly would be ideal. We need a language that lets us express the fact that milliseconds-numbers are not interchangeable with pixels-numbers, and so on. The use of explicit conversion functions should let us forget, for once and for all, stupid things like measurement units (inches vs. kilometres, et. al.). However, it is unacceptable to have such functionality at the expense of control over the representation of data in hardware.
  
  I have deposited more detailed thoughts on this concept here.
  


• Encourage the use of nested layers of abstraction to build domain-specific "dialects" on top of the base language.
  I've burbled extensively about my feelings on abstraction before, so I'll refrain from repeating those thoughts. In essence, though, what we need is a way to define a sort of "sandbox" inside the language itself. That sandbox should be highly abstract, have a well-defined interface to lower levels of abstraction, and yet be highly domain-specific. Talking across domains should be forbidden. Talking to other layers of abstraction must be forbidden.
  
  Languages like C++ let us define layers of abstraction via things like class inheritance trees. Yet they also allow us to talk between any two layers of abstraction at will. Any code can, with sufficient pressure on the compiler, talk to any other level of abstraction in the program. This is bad because it allows violations of encapsulation and modularity. By contrast, domain-specific languages are good because they do only what they need to do, and there is literally no way to do other stuff. You can't send network packets from a LaTeX document.
  
  However, creating a DSL for every possible domain is not really practical. Embedding languages has some potential, but it also has a cost: you have to have two distinct languages. In some cases, the binding mechanisms required for this are highly nontrivial, and can even result in a net loss of both coding productivity and runtime performence. Clearly, the solution is not to add to the proliferation of languages.
  
  Instead, we need a language that allows us to build little dialects of functionality and domain. Enforcing abstraction and encapsulation has proven good effects. I think the implementation of this might end up looking vaguely like Java packages or .Net modules, but it needs to be approached from the ground up with the express intent of restricting inter-module interaction, rather than promoting it.
  


• Provide highly expressive compile-time contract support.
  Design By Contract is a very good thing. In general, we need a language that lets us express contracts, in a way that is inherent in the language itself, and verified as much as possible by the compiler as well as at run-time. We need contracts on data types. We need contracts on functions. We need contracts on objects.
  
  We need to be able to specify the exact limits and expectations for every aspect of our code, and make sure that those contracts are obeyed. One of the great benefits of functional programming is the ability to validate code at many different levels, simply by validating that a function does as expected. We can have this benefit easily in imperative-style programming provided sufficiently expressive contract definition and enforcement mechanisms.
  


• Provide a high degree of introspective capability.
  Code should know that it is code. Code should know that it runs alongside other code. Code should be able to express concepts in terms of other code.
  
  This is really a multi-sided issue. On the one hand, we need the ability to do things like comprehensions, wherein a data structure knows how to traverse itself. We then need the ability to tell a structure to traverse itself, and do some operation on each element, or maybe on select elements based on some discrimination criteria. However, it goes deeper. We need to be able to look at a data type and see what we can do with it (ala concepts). We need to be able to ask a function what its semantics are and what sorts of data it can operate on. We need a way to think about objects and what they can do, at run-time.
  
  We need to escape academic fluffery and jargon. The term "currying" needs to never be seen in the language's documentation. We need to keep an emphasis, when designing introspection features, on real life uses. If an introspective feature cannot be justified with an example that immediately reveals, to a moderately experienced imperative-language programmer, the benefit of that feature, then the feature is crap and should be axed. We should prefer to piss of the academics for not using the "right terminology" in favor of not pissing off people who still have never been told why they should care about these notions.
  


• Escape from stupid and counterproductive conventions.
  The idea that functions should only return 0 or 1 values is stupid. This is a pointless convention that makes no sense. In real-life programming, multiple-return-value functions could save a lot of time and code complexity.
  
  The notion that objects are only "of" certain types, defined by a rigid hierarchy of inheritance, is stupid. We need a sort of fuzzy model that lets us work in the realm of concepts and capabilities. Sometimes objects are best expressed in terms that are not definable by "is-a" and "has-a."
  
  In general, both OO and procedural programming are too weak to really work. Procedural programming doesn't scale nicely to massive code bases with complex data entities. OO doesn't work nicely when the boundaries between object types are fuzzy. Attempts at generic-OO capabilities have been sort of successful, but still are mostly ugly hacks and have plenty of drawbacks. Existing paradigms for organizing logic and data are insufficient.
  
  Entire modes of thought that worked great in single-thread universes will cease to be useful as multiprocessing technology becomes more widespread. Dealing with synchronicity and parallelism is going to be a major responsibility for languages in the future, and a new language must understand multiprocessing concepts deeply in order to remain a viable option. However, as with other areas, it is important to avoid extremes - the language must not forget that a lot of code still makes sense in a single-thread model.

• I'm just venting here. I don't honestly believe I have a solution - yet.
  I've brought most of this up just to lament. It's self-indulgent, angsty, and more than a bit frivolous. But it's my opinion, and I feel like getting it out into the open. I don't pretend to know how to resolve this situation, although I'd like to believe that a solution exists, and I'd definitely love to be a part of the solution if one ever becomes apparent. For now, though, I'm not looking to lay blame, assign targets, draw lines in the sand, or rally the troops for the final battle - I'm just bitching
  
  Rightly or not, I feel like an innocent victim here. I feel like a kid who just wanted to go out and play Frisbee, and accidentally found a land mine. I shouldn't have to get caught up in this at all. Yeah, complaining about it is rather pointless, but I still feel like I should get to say my piece.
  


• I absolutely support the customer's right to avoid crappy copy protection.
  Heck, as far as I'm concerned, the consumer doesn't get near enough respect these days. The DRM craze is just plain idiotic at this stage. Game copy protection is, if anything, even worse. The Sony music-CD rootkit fiasco was old hat to those of us who have been dealing with the likes of StarForce for years already in the PC gaming realm.
  
  When I complain about consumers excercising their rights, I don't mean to suggest that they shouldn't be allowed to boycott or even avoid that which they find distasteful. Avoiding things we don't like and don't agree with is a fundamental freedom that I fully support. However, I think it is important that, in all things, we understand the consequences of that avoidance.
  
  Say I dislike the fact that I cannot fly, and thus choose to avoid the reality of gravity. It's an extreme analogy, to be sure, but that's the point - ignoring gravity is not going to let me fly, it's going to make me a grease spot on the sidewalk.
  
  Boycotting evil copy-protection systems is not just going to change the copy-protection arena. It's going to encourage these companies to produce ever more restrictive systems - the arms-race escalation I mentioned before. More importantly, it's going to cause collateral damage.
  


• Yes, it's the publisher's fault. No, that doesn't mean I can fix it.
  At my place of employment, we develop a niche game. We're all acutely aware of that fact. Sometimes we've had to settle for suboptimal publishing deals just because that's the only way we can get anything published at all. Changing publishers is not really an option; getting the ones we have was hard enough. Anyone with real experience trying to publish a niche game knows the realities of this. We either accept publishers with controversial and arguably "poor" choices in copy-protection, or we work at McDonald's. Considering that I haven't spent 90% of my life dreaming about flipping burgers, the only real option here is Door Number One.
  
  I don't speak much for groups like Stardock that can manage to wrangle CP-free publishing arrangements. I speak for those of us (in the minority as we may be) that don't have the luxury of telling our publishers they're making bad decisions. As much as I wish it could be different, that's the reality of the situation, and that's part of what makes this so annoying.
  
  Publishers are, by and large, ignorant of or unwilling to face the fact that bad copy-protection costs sales. The only reason such systems are used at all is because publishers still believe they help sales in the long run by preventing piracy. For niche games, this is just plain moronic. The number of sales lost to piracy will never, by sheer virtue of the game's obscure nature, outweigh the sales lost to savvy consumers who are avoiding bad copy protection.
  
  Net result: we, the small-time game developer, lose. We become collateral damage. We have no bargaining power: our niche game is a small part of the publisher's own bottom line, and losing us over a copy-protection fight only kills us, not them. We have none of this supposed leverage to force a change.
  


• Changing the publishers is not easy, and never will be.
  First and most importantly, there's a little thing called a contract. Leaving a contract agreement with a publisher is a Huge Deal, and has drastic financial consequences. So in a lot of cases, it isn't that there's no alternative publisher out there - it's that we literally can't change at this point. But there's also more than just that to consider.
  
  It's a pretty well-documented phenomenon that people will go to great things to bend reality to fit what they want to believe. Let's look at this from the publisher's perspective:
  
  • I want to make money selling games
  
  
  • Piracy undercuts sales
  
  
  • I can invest a lot of money into anti-piracy systems
  
  
  If sales go down, I'm going to think of it in a certain way. I don't want to believe that I made a dumb decision; in all likelihood, I believe that copy protection was a good decision. So if sales go down, I am naturally left to one of two conclusions: either the game sucks, or piracy is still running wild. If I conclude the second, I'll probably go looking for stronger copy protection - and you better believe that the CP industry is just going to love that. They're going to want to encourage that conclusion in my mind, because it means I buy more CP software.
  
  I don't want to paint publishers as The Evil Empire here. I appreciate the real necessity of the publishing industry. Hell, one of our publishing partners is absolutely superb in what they've done for us as a small-name niche group. I don't believe that publishers are unintelligent, foolish, or naive. They just see things differently, and that's natural - that's a side effect of the business they are in.
  
  Put yourself in the publisher's shoes: you've made a huge investment into supporting Copy Protection Scheme Foo. Now your customers and developers tell you it sucks. Are you going to sacrifice your credibility by renouncing Scheme Foo? (Yes, I know that 99% of us would love it for Foo to go away. That's not the point. The publishers do not see it that way, and fairly so.) You don't want to give up copy protection in general - your numbers seem to show that it helps sales overall - so what else do you turn to? Say Scheme Baz exists, but Baz sucks much harder than Foo, and is cracked five thousand times faster. Does it even remotely make business sense to use Baz over Foo? Not on paper, no.
  
  You have to remember that publishing is a business, too. They've got their numbers and figures, and it's going to take a lot more than "people think you suck because you use Scheme Foo" to get them to see things differently. Actually, a few people in the publishing biz already see it that way - but lack the clout to do anything, either.
  
  Change is not easy. Big change is especially hard. There is a lot of inertia to fight here, and historically, you don't beat corporate inertia by steering the boat. You blow the boat up and build a new one, and hope it sails in the right direction.
  

dev.RenderState.FillMode = FillMode.Solid;
dev.TextureState[0].ColorOperation = TextureOperation.SelectArg1;
dev.TextureState[0].ColorArgument1 = TextureArgument.TextureColor;
geo.Render();

dev.RenderState.FillMode = FillMode.WireFrame;
dev.TextureState[0].ColorOperation = TextureOperation.SelectArg1;
dev.TextureState[0].ColorArgument1 = TextureArgument.Constant;
dev.TextureState[0].ConstantColorValue = 0xffffff;
geo.Render();

Form foo;
foo = new Form();
foo.Text = "Habanero";
foo.SetBounds(0, 0, 225, 150, BoundsSpecified.Size);

Application.Run(foo);