Well, I more or less just got home. I've stuffed a few things away and cleared out the spam that showed up in my mailbox since 2 AM last night (when I last checked it), but for the most part haven't had the energy at all to unpack or anything. Being trapped in a minivan with a hyperactive five year old for nine hours has that effect on me, I guess.
I technically should be catching up on work and such right now, but I just don't have the steam. I'll probably crash soon and put off everything until tomorrow.
That's about all the rational thought I can muster.
Moving furniture into a storage unit officially sucks.
My line of work is not, shall we say, physically demanding. I don't exactly haul around large heavy objects all day as a matter of course. No, see, my lazy pasty white butt likes to sit around on soft surfaces. The most action my arms see in an average day involves moving food and beverages from desks and tables into my mouth. Generally I try to keep these food and beverage items under a few pounds each.
So when it comes time to move well over half a ton of household furniture and boxes in the space of two days, my scrawny little body gets downright bitchy. I've heard rumours about these "muscle" things that are supposed to make manipulating large masses easier. I wish I had some of them, because I've been manipulating one heck of a lot of large masses, and it's starting to hurt.
My neck is stiff, my arms feel like they got run over by a truck, and my ankles are drowning their sorrows in a pub down the road. (I can tell this because the bastards "forgot" to invite me, and their absence has created an exquisite feeling of agony between my shins and my toes. There was also that trail of bloody footprints earlier, but I'm not sure if that was actually me, or just a sleep-deprivation-induced hallucination.)
Normally, after having to, y'know, use my body for something, I'd curl up like the soft little wuss that I am and sleep it off for about three days. Unfortunately, my employer does not approve of this practice, which means I have to stay awake. In fact, I have to perpetuate my state of sleep deprivation in order to "Get Some Work Done."
The ironic thing is that, being totally fuzzed out in the brain, I'm not getting much done. Last night I finally worked up the energy to open my laptop, boot it up, actually log in, and poke the keys a few times. Then I just stared at the pretty picture for a few minutes, decided that all this pretending to do work wasn't really all that fun, and went the hell to bed.
Tonight, against my better judgment, I have reverted to my old vice. Yes, weak and despicable man that I am, I have acquired high-caffiene beverages. I have no moral fibre at all. In fact, I have such a deficiency of moral fibre, you could say I'm morally constipated. I'd need some kind of massive injection of moral Metamucil to get me even back to "morally bankrupt" again. (See, this kind of idiocy is what happens when I work physically all day and then try to make my brain work for another few hours.)
I am armed with a four-pack of Sobe No Fear, one of which is partially gone already. I have a nice to-do list of simple documentation edits to make tonight, which I managed to hack out last night before I slumped over and drooled all over myself. I fully intend to procrastinate a little bit more and then do an item or two before falling asleep again tonight. If I get terrifically lucky, I might actually do three items.
I had been hoping to get in touch with some of my old crew from this area, but sadly it looks like I won't have time. Schedules just didn't work out, and what with all the moving, I barely have had time with my own family (who I'm supposed to be here for), so it'd be kind of dumb to go shred the last bit of time we have left and go partying. I'll have to try to come back down this summer; I still have a sister and two nephews in the area, so I have an excuse.
I moved around so much as a kid that I barely know what it's like to call something "home." To me, "home" just means "that place where I keep all my crap, and maybe sleep at once in a while." That definition has quite literally applied to my own car once or twice, which makes the notion of "home as a house" kind of alien to me.
Despite that, I'm finding it oddly sentimental to pack this house up. I only lived in it for a couple of years, and that was a while ago. Virtually all of my stuff has been out of this house for ages anyways. Most of my memories of the place are from sitting at my cheap, crappy knockdown desk and hacking into the early morning hours. Maybe the fact that I'm sitting at that desk for the last time right now has something to do with it. In any case, I'm starting to miss this place. I guess my sentimental streak is back causing its usual troubles again. A lot has changed since I left, but enough is still similar enough to prompt those little pangs of wistful remembrance.
I really wish I had more time here to meet up with all of my friends in the area. I don't even think they know I'm down here, which is really just as well since I won't have time to do anything interesting.
My laptop has a cheap integrated sound card, which is very annoying, because it picks up line buzz. With most headphones the buzz isn't significant enough to be noticed except in very quiet environments, and even then it is drowned out by even the softest actual audio signal. With my new noise-reduction headphones, though, the buzz is actually deafening, unless the noise-reduction is turned off. So I have to listen to music in a sort of muddy, blurry format (apparently the noise reduction system is also responsible for some minor amplification and signal balancing). I can also hear background noises like my laptop's CD drive, which makes my spoiled little eardrums very sad indeed.
Alright... time to quit putting off the inevitable, and get this work done.
The last two days feel like about a month. I've been running around fixing odd computer problems for all the friends-of-the-family in the area, which is always... interesting, if not actually fun. Today we took my five year old nephew and his four month old brother to the beach and hung out for a couple of hours. Huzzah for physical exercise, and such.
Crammed in between all that has been a monumental amount of packing and hauling and storing and all the other trappings of making a major move. So needless to say I'm fricken exhausted.
The "great" thing is I now get to spend a couple of hours working on all the stuff that I was supposed to be getting done this week, except I keep falling asleep early every night. So I'm not sure what the quality of this work will be, but at least it'll be "done." Sort of.
The FooLanguage thread has taken off again, happily. I just don't have the mental bandwidth to jump back into the discussion at this point, but I'll definitely hit it properly when I get home. Anyways, it is now by far the most popular thread in the history of the Software Engineering forum. So even if we totally fail to make history in any other regard, we've done something noteworthy. Huzzah.
Right... time to go wring out the last of my brainjuice into Work before I pass out entirely.
So tonight I have to shut down all my equipment and pack up for my trip down to Florida tomorrow. I'm actually already packed except for all the last-minute stuff like toothbrush and such. That, and I have to get my laptop set up with VPN connections and such so I can work on the road.
For the next several days, I will be unavailable to harass GDNet constantly. However, I'll still be online a short while every day, so I'll definitely stop by to be a nuisance when I get time.
The only sucky thing about this is that it isn't strictly a vacation, since I technically have to take a lot of work with me. It'll partly be design, but I also have to at least get a rough code skeleton ready by the time I get back. Huzzah. I'll be spending most of my days goofing around and being sociable, which means I'll be having a lot of late nights. Such is the way of things.
I'll try and hack up some notes on FooLanguage while I'm out. We're very close to having the single most popular thread in the entire history of the Software Engineering forum (yes, I'm pathetic enough to have checked) so it'd be a damn shame for it to die a quiet death at this stage.
(Six more posts and then it can die.)
Anyways... yarr, hilariously funny witticisms here, and don't miss me too much.
So today I dragged my sorry butt out of bed at the unholy hour of 8:45 AM. At 9, our meeting started, and it ran for over 3 hours. Virtually all of the issues that directly concern me (at least for the immediate future) were hammered out, which is good.
The topic of discussion today is a very hefty system that will, among other things, automatically generate little mini-cutscene sequences to illustrate various game events. The idea is that you feed the system a few objects, say "show this thing blowing up that other thing" (or whatever), and it figures out all of the specifics and shows it for you. This saves us an immense amount of work creating such scenes by hand, and with some nice gimmickery, we can actually have higher-quality cutscenes overall (ones rendered in-engine at least) just by adding some extra polish to the generator logic. It's a good idea, and not nearly as complicated or impossible as it may sound.
I always find it kind of funny to see the artists and programmers interact. The art team is concerned entirely with how things will look - where cameras will go, angles, FOV, relative object speeds, transitions between shots, etc. etc. By contrast, all of the programmers are concerned entirely with how to make it work. Since I've been heading up the code-side design of all this, I've spent a lot of time and effort identifying areas where we can reduce code complexity by treating two different things as special cases of the same basic concept.
For instance, I've drafted up a keyframe system that is designed to smoothly interpolate coordinates over time along a preset, keyframed path. The idea is that it can be used generically to control any movement and animation. It can generate coordinates that are absolute (i.e. world-space) or relative to a particular object. By treating all coordinates and positions as data for the keyframe system, we get immense control and flexibility, and the entire system is very simple - we only need one movement/animation system.
The artists of course don't see it this way. One of the recurring topics was whether or not to allow cameras to be positioned in absolute world-space at all, or to require that they always be relative to some object in space. The artists described, in great detail, the difficulties of knowing where to put a world-space camera if you don't know ahead of time the precise location of every single object in the scene. They have a very good point.
However, this led to the suggestion that camera positions be special cases that are only allowed to be relative to an object. This immediately makes the system more complex, because now camera positions have to be treated differently from all other coordinate data in the system. I eventually gave up trying to explain this [grin]
In general, the whole discussion took a rather concerning turn. It seems like we've got a minor case of technology toy obsession going on, and there's a tendency to add features and gimmicks to this system just because we can. I don't think the issue of actually creating content came up at all. It will be interesting to see how this plays out over time, but if we continue this obsession with technology for technology's sake, we're going to catch ourselves in a (sadly familiar) situation and find that we've got a small fraction of the development schedule left, a really nice shiny toy, and... no actual content that uses it.
I'm really hoping that this doesn't play out this way, and that I'm just being paranoid - but we'll have to see. For the time being I'm focusing on getting a working base implementation done first, and leaving features and fiddly little options until later. Hopefully that will at least help matters by getting content developed early on, even if it gets revised heavily later. We're going to be in unpleasantly hot water if this project ends up being a massive pack of new features but no actual game.
Eh well. Hopefully I'm just feeling skittish because I sacked out on the couch all afternoon. Getting up "early" is a hazard to one's health. I shall have to sleep in extra tomorrow to compensate!
There's too much stuff in my brain. I want to get some of it out. Sadly, I am not aware of a way to separate brain-stuff from actual brains; this means that, should I want to get brain-stuff out of my head, I would be required to also remove brains themselves. I am not particularly attracted to the idea of being separated from my brains. They do nice things like keep me breathing and make me believe that all the sugar I'm ingesting is enjoyable, rather than slowly rotting my body.
I don't want my brains to go anywhere. I kind of like them all smushed up inside the skull. It's a very cozy and convenient packaging solution for the age-old problem of where the hell should I put all these brains. Skulls are good, and skull integrity is important to not losing one's brains.
This puts me in an awkward position. My brain-stuff wants to go flying everywhere and nowhere at once, to break free of the chains of rational thought and just sort of blorp around, like Calvin's oatmeal. Yet, were it to do this, it would probably take some actual brains with it (since, as has been said, I don't know of a way to separate them). I do not relish the idea of my brains splattering around, nor going blorp.
I have a huge meeting on Monday morning, at some unholy hour, like 9 AM. This is because I live 6 hours away from my team, who will be sitting around belching loudly and feeling sleepy, having just come back from a large lunch. Being German, no doubt this lunch will consist largely of high-carb, high-protein goodies like potatoes and sausage, and probably a copious quantity of beer.
This will make for a very interesting meeting. I will be groggy, 90% asleep, and likely incoherent, having just dragged my arse out of bed. They will be groggy, 90% asleep, and likely incoherent, having just eaten, and wanting to haul arse into bed. Miscommunication should be rampant, and I sure as hell hope that they remember to duck away from the camera before belching upon it.
OK, yeah, I made all that up. I don't think of my team as uncivilized brutes who are going to burp sausage-chunks onto the camera during a videoconference. Yes, I've been to Germany. Yes, I know that's not what they really eat for lunch [grin] Hell, we're not even having a videoconference - pure IM. But you gotta admit, this mental picture is a lot more entertaining than thinking of a bunch of gamedev geeks sitting around in front of their computers typing away about camera angles and spline interpolation, no?
After that meeting, I will be forcefully coerced by the government to surrender a sizable portion of my finances to them, so that my money can be whisked away and applied to something terrifically beneficial to all of American society, like nuclear toilet seats. By this, of course, I mean to confess that yes, it's April, and no, I still haven't done my damn taxes. It doesn't even take that long (I use tax software now) but I still hate it, and being a lazy procrastinator, I usually leave the torment until close to the last possible moment.
Once I'm done being raped by the burly man that is Uncle Sam, I'm going to pack up and head down to Florida. It isn't really going to be a vacation per se, since I'll be taking a lot of work with me. However, my parents are also packing up and getting ready to move from Florida to Indiana, so I'll be down to take care of some of my last little cruft that they've been keeping in the house, and generally saying fond farewells to the ol' homestead. (By this I'm being utterly facetious, since I lived in that house all of two years, and generally have no powerful attachment to it, aside from the fact that me and my father once had to break in through my bedroom window after locking the keys indoors.)
Mostly it's an excuse to have a family get-together; my two sisters and all four nephews will be present as well. It should be chaotic and deeply traumatizing, if not slightly entertaining and sentimental. Then we'll set fire to the place as a nasty welcome to the poor buggers who bought it, and all drive off in a blaze of glory.
Alright, my signal-to-noise ratio has approached approximately Prolific Bullshit, so I'm going to quit burbling and go extricate my grey matter with a cordless drill.
Just a quick dump of thoughts here before I stumble off.
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 [smile]
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.)
Game Related Stuff
The design phase of the cutscene system is finally drawing to a close. We're having a meeting sometime in the next few days to try and sort out the last few areas of functionality that I can't really specify, since the art team (and not me) is the final user of the system, so they're the ones who know what it needs to do. It's annoyingly difficult to schedule meetings with a team that's six (currently seven, thanks to DST) hours apart, but that's life.
Once the feature requirements are set out, it's go time. I'll be planning up a complete roadmap for implementation, which I will start drafting tomorrow, leaving holes for the last few design areas that aren't locked in yet. That involves a comprehensive code architecture plan (how code will be structured to solve the requirements) as well as a preliminary division of labor (who gets to write what pieces of code). This kind of architectural engineering is one of my favorite parts of software development, so I'm really looking forward to it.
After the architecture is done (shouldn't take more than a few days all told) it's time to start writing code. I predict a few weeks to get a rough version going, enough to get a visible demo of the functionality and what the system is capable of. There's a chance we might try to demo some of this functionality (privately) at E3, so I have sort of a deadline to work under. Should be fun, though, and working under pressure always does good things for my motivation.
In the interests of keeping a relatively sane schedule, I'm off to read more Zen until I fall asleep.
Wow, that generated substantially more (and more positive) response than I had expected. I guess it shouldn't come as much of a shock to me that others are feeling the need for a better toolkit, but I would have expected at least some backlash against the heavy-handed pragmatism [grin]
Yes, there's a real risk here of hitting "linguistic bloat" and trying to do too much with a single tool. However, I think that we also need to be wary of panicking over "bloated" languages. Sure, if we try to do too much in one tool, we're going to end up with a tool that does very little well. The question, though, is what delineates "too much." I think Ruby is a shining example of a very rich language that is done right.
Issues like semantic expressivity, contracts, and multiprocessing are real issues. These are things that I know, from in-the-trenches experience, cause major trouble when using existing languages. Those are the challenges that are genuinely going to shape the next decade of programming.
Software quality is not going to rise significantly without the ability to express semantic and contractual behavior within a language. The managed-everything model of .Net has proven a reasonably effective counter to the manual memory-management nightmare of the C/C++ world, but there are many monsters left to slay. I can state with absolute certainty that, in my experience, 90% of run-time bugs arise from violations of semantics (discounting multiprocessing issues). In probably 85% or more of those cases, the semantics should have been expressible in the language itself; if that feature were available, a good third of the bugs could have been nailed before compile-time, and the rest would have barfed at run-time during unit testing, long before a serious problem arose in production.
When multiprocessing comes into play, shared-state languages like C++ are simply massive failures waiting to happen. They are impossible to validate automatically. They cannot be tested rigorously on every possible hardware configuration, which is bad, because every hardware configuration (and even some software interactions) might subtly change the behavior, and lead to synchronicity issues that otherwise would never have manifested.
Those areas absolutely must be addressed. Without fixing those problems, we are going to take one of two routes. Either we'll continue to try to patch the holes in C++, with increasingly bad results, or we'll proliferate a group of domain-specific (or at least domain-restricted) languages. Already this proliferation is beginning to occur. I have absolutely no disagreement with having multiple languages; indeed, every problem space has its ideal language, and this will always be the case.
However, my dream here is to see a single language, or at least a very tightly-knit family of extremely similar language dialects, be able to cater to a wide array of problem domains. C++, with its multi-paradigm support and ability to live close to hardware, is frankly the closest thing we have to such a language for the time being. We can do much, much better than C++.
I see no reason why languages in different domains must, by necessity, have vastly different philosophies and syntaxes. Yes, there are going to be edge cases where certain highly distinct domains need highly distinct languages. I'm not concerned with those fringe cases, because they amount to a tiny fraction of software development. The real bulk is in three main areas: consumer applications, business logic, and games. Those three domains should be easily unifiable under a single language family.
Instead of writing my web server in C++ and my webpage logic in PHP, I should be able to write my web server in Foo at a low level of abstraction, and then build webpage logic in Foo at a high level of abstraction. Foo should then let me make use of a flexible compilation/execution model to either compile the logic directly into a binary executable (for, say, embedded hardware or highly performance-critical scenarios) or let me use a JIT-compiled setup similar to ASP.Net or the Zend engine, where external users can upload script files that are executed dynamically by my server software. I shouldn't need two different languages here.
Having a unified language structure gives me three advantages.
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.
I'm certainly interested in continuing this line of thought. Acting alone, it would probably take me the bulk of my career to really ever get anywhere with specifying and implementing such a huge project. I think the success of this kind of an initiative is going to depend entirely on massive support from the development community and from existing vendors.
IMHO, Foo absolutely has to have a simple interconnect mechanism for talking to C-style APIs. That immediately makes it a viable contender for Windows and Linux development, which is absolutely critical to adoption. That also allows for more cool stuff, like bindings to C++, which can then marshal to managed code in .Net.
Foo will not survive if it tries to recreate the programming paradigms of the world from scratch. Foo will only survive and succeed as a parasite, drawing on existing, established code, and allowing a gentle transition from current modes of thought and coding to more productive and safe ones. That kind of interconnection requires big-league backing, and lots of people looking over things to make sure it all works.
A couple of people have suggested opening up a more broad discussion someplace. I'm all for this. I'll put together a quick set of links to my journal entries and post it up in the Software Engineering forum, since that will make things much easier to discuss widely. If anyone has any ideas for an even better location, please let me know, and we'll work something out.
I'm really starting to get interested in the notion of building a new programming language. Every language I've ever used has had some really glaring shortcomings and problems, even aside from the normal quirks and personality flakiness that any language is going to have as a matter of course.
Now, I have no formal training in PL theory. Some people might say that makes me a bad candidate for trying to design a language. Perhaps I'm foolish to do so, but I disagree. My view is that the academics have had plenty of chances to design The Perfect Language. Thus far, they haven't done such a great job. On the flip side, people who are concerned primarily with getting crap done seem to be far more successful: PHP, Java, C#, and (to a far lesser extent) Ruby all come to mind.
By nature, as a professional programmer, I'm intensely concerned with getting crap done. I really don't care what some guy in some university thinks is the best way to build a language. Existing theory and "best practices" don't mean much to me, personally. I live out in the real world, and in the real world, the only metric by which we measure the goodness of a tool is whether or not it helps us get crap done. C++ is a good tool because it lets us get work accomplished (mainly by virtue of its sheer inertia, but that's another matter). Malbolge is a bad tool not because it's weird, quirky, or obtuse, but because it gets in the way of doing stuff. It doesn't let us get things done.
A lot of people in the academic sphere are big on stuff like functional programming, aspect-oriented programming, and all this. I've read papers dating as far back as the early 1980s claiming that such concepts are, by necessity, central to producing good software. Yet here we are, smack in the middle of 2006, and we still write code in imperative languages like C++. Why? Because we can get stuff done in them.
However, anyone who has had even fleeting experience with those concepts understands their appeal. There's some good stuff out there. People like and use (sort of) the obscure academic languages for good, practical reasons. There are certainly gaping holes in our current toolset that are going to need to get fixed soon.
So, in the interests of being highly pragmatic, I think it's time we sat down and built a new language. This time, though, let's avoid the trap of doing what sounds good to the PL theorists, and keep a heavy emphasis on just getting crap done. At the end of the day, I really don't give a good goddamn whether I can use a higher-order function, a lexical closure, or currying. I can tell you how many times those terms have come up in the process of me trying to get stuff done: 0. I don't care about being a good PL theorist or a good academic. I want to get crap done.
The Pragmatist's Programming Language Wishlist
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.
These are just the beginnings of my thoughts here, and are admittedly rather fuzzy (which is a side effect of me not having a good sleeping pattern). I welcome any other thoughts, insights, and wishlist-items.