A Postcard from Debugging Hell

ApochPiQ · 2 months

Shoot me a PM; if you've got good stuff to demo we can work something out :-)

ApochPiQ · 2 months

Fair question!

I worked for 2 years for a network security company a (long) while ago, then went on to ship 3 game titles (not including 2 more which never shipped) before moving on to ArenaNet to work on Guild Wars 2 as a senior server engineer. I've logged about 10 years in the game industry all told.

ApochPiQ · 2 months

A fair question - but that's not quite what I'm going for.

I'm interested in people who have shipped stuff. There's a big gulf between being interested in game networking and actually having enough experience to make a meaningful contribution to discussions etc. I'm open to people with good networking experience outside of games as well, but it's primarily with a gaming focus, hence the entry bar.

I've seen this model used in other game-related disciplines and it's remarkably effective at maintaining a high signal/noise ratio.

djdonnell · 2 months

Or we could, y'know, design a language to do it right from the beginning.

</shamless_plug>

ApochPiQ · 3 months

This is a good point.

What I'm uncertain about at the moment is how best to display this; Epoch is intended to be a fairly different experience from, say, C++ - but the challenge is that many of the planned features don't even have a syntax that I've settled on yet. I have copious notes (most of which are on paper, which doesn't help with sharing them) about various syntax options and possibilities, and plenty of ideas for features and such.

What I don't have is a concrete implementation of most of that stuff to point to yet. So going forward this is excellent advice, but for the time being I only really feel comfortable showing off what actually works.

A nice middle ground might be writing up some wiki pages for my speculative ideas; that'll give people the chance to look at the future scope of the language and even help refine some of the stickier points.

ApochPiQ · 3 months

Ah, I see. I'm not sure how I feel about that, but I'll certainly sleep on it. Thanks for the suggestion!

ApochPiQ · 3 months

As I said, I really am open to suggestions for the variable declaration syntax. I agree that the ambiguity is a problem, especially for user-defined types. I'm all for improving it, I just don't have any good ideas as to how yet.

ApochPiQ · 3 months

Yes, that's exactly what it means. There is a feature for registering code that has full access to both the AST and the VM execution metadata, which is invoked at compile time.

Presently this feature is only accessible through the underlying implementation; i.e. you can't write compile-time Epoch yet. But I intend to add that capability in the future, via function tagging.

So for instance you would write code like this (just an example):

construct_foo : identifier(varname), compilecontext(context) [compiletime]
{
    context.lexicalscope.AddVariable(footype, varname)
}

This would be equivalent to the current implementation-local code which creates variables based on compile-time calls. The same mechanism could be used for auto-vectorization, cross-compiling to OpenCL, or any number of other possibilities.

ApochPiQ · 3 months

I'm aware that it isn't a new approach. In fact a large part of this approach was inspired by languages like the Lisp family and the idea of compile-time macros. I personally feel like just because previous efforts have been less than successful does not indicate that this is a bad route to take, although of course only time will tell.

I don't intend for the average Epoch programmer to be writing this kind of code, for the record; it's specifically aimed at people who want to write libraries that enable higher-level abstractions over the concepts of computational models. So for instance efforts like ConcRT, OpenMP before it, and so on could succeed without needing compiler-end support. It's more about enabling rapid acquisition of features as hardware continues to evolve than requiring in-the-trenches programmers to master some obscure way of thinking.

I liken it to features like C++11 variadic templates, for instance. The average guy writing applications code has very little cause to care; but for libraries and people who want to extend the power of the language, it's a godsend.

ApochPiQ · 3 months

One of the great things about releasing early is that I can remain responsive to feedback on fundamentals like syntax and naming. So I appreciate your frankness; getting real reactions to the language is critical to making it better.

To address your questions:

I called it entrypoint because that's what it is. The entry point. "main" doesn't seem especially evocative to me, and it's a convention with little merit as far as I can tell. Why keep it?
debugwritestring was a mistake. In my defense, I called it that to emphasize the fact that it's a temporary wart in the language and shouldn't be used for production purposes. It will be going away soon, I promise.
Because in Epoch, declaring a variable is calling a function - a compile-time function which modifies the local lexical scope and adds a named binding to the scope's reserved stack space. I'm open to changing the syntax of variable declarations but I haven't heard any alternative suggestions that I really like yet.
Structures and primitives should share identical syntax; I'm not sure what you're referring to here.

As for how the language is better than the competition - at the moment, it is patently not better than much of anything. The point is to release early and often so that I can react to community feedback (such as this!) and craft something that really is better than the alternatives. I consider it very important to remain flexible in the early stages of language design.

Thanks again for taking the time to write this; every little bit helps in making the language what I hope it will become.

ApochPiQ · 3 months

In brief: the language provides mechanisms for libraries to extend the control flow and semantics of the language. This is unusual because typically extending control flow is something compiler/VM implementers must do.

I will get into this further later in the series; it's a complex problem, as you rightly note, and has a fairly sophisticated solution. I wish it was easy enough to explain in a proggit comment :-)

ApochPiQ · 3 months

Garbage collection is thoroughly optional, and the syntax is a hell of a lot different than C. About the only similarity to C is the use of curly braces to denote scopes.

ApochPiQ · 3 months

A fair criticism :-)

Although, in my defense, it's hardly been five continual years of work. If I coalesced the time into 40 hour weeks, it's more like five months of full-time effort. For the amount of actual wall-clock time I've spent working on the project, I'm pretty happy with how far it's come.

ApochPiQ · 3 months

D already has input from some exceptionally good language people. I'm not an exceptionally good language person. I doubt my radical re-envisioning of D would be popular in the existing community.

And as for the title: "A pragmatic language for the future" was the title of the original GDNet forum thread I started years ago to discuss this very idea. It's a historical reference, not karma whoring.

ApochPiQ · 3 months

I will grant that the wishlist doesn't dive into much detail about what I meant by each of those points; I'll probably dig deeper into that in the next part of the series.

For now, though, here's my quick responses:

D's typesystem seems good for the kind of "low level when needed, high level everywhere else" abstraction I want to see. As a matter of fact, I've taken a fair bit of inspiration from D, particularly around concepts like mutability.
I disagree that D's parallelism vocabulary is as rich as I imagine Foo's to be. That's probably just because I did a bad job of communicating my imagination, though!
Epoch has (technically had) functioning support for automatic GPU targeting in a prototype release from a while ago.
Reusing code is not the same as interoperating with code. I haven't seen D-ObjectiveC interfaces, for instance, even though D and C are highly compatible.
No comment :-)
Another place where I took some inspiration from D, as it happens.
This is obviously a tough area to judge. Tool ecosystems take a huge amount of time to grow and prosper, and D is young enough that it can't really be blamed for not having better tooling to some extent. Any new language is just going to have it worse here. So I see this more as an attitude question than anything: do the language developers care about creating exceptionally good tools?
Maybe I'm just overly anal retentive about the differences between execution models, but that doesn't seem like particularly great points on D's side to me :-)

ApochPiQ · 3 months

My thoughts on this are twofold.

First, I'm not trying to "cover everyone's use cases". I'm content to create a language that plenty of people hate, and don't want to use - as long as there are more people who do find it useful.

Secondly, I agree entirely that the prevailing attitude can be damaging to efforts like this. Most people think there are too many new languages. I personally think there are too many mediocre new languages. Yes, call it a bit of hubris to imagine I can do any better, but I at least would like to try.

ApochPiQ · 3 months

Can you offer me examples of how D specifically fulfills each of the "wish list" items described at the end of the article?

barsoap · 3 months

Am I the only one for whom the audio fails to play after the initial "Good Morning"?

This is making me unhappy, because I really want to watch the talk, but the slides are all but impossible to follow without the audio track.

ApochPiQ · 7 months

Tests can't capture everything.

ApochPiQ

TROPHY CASE

you'll need to login or register to do that

create a new account

login