paniq303

Thank you. It's not a grift (or is that what a grifter would say - oh god I hope it isn't). I didn't want us to overpromise and become the next No Man's Sky (which has by now fully redeemed itself) so I never spent much time on advertising and trailers. As a result, we didn't get much money. People were skeptical from the beginning, which was expected. What we got in support largely came from a handful of friends who wanted to see it done, and most of their names are going to end up in the credit roll. 99% of our present funding comes out of our own pockets and from Sylvia's illustration business.

Oh no, we are on Hacker News. ;-)

Hi, this is the yak shaving developer in question speaking. I was worried we'd get grilled hard over our slow progress, but I'm relieved to read that most of you understand how perilous and long-winded gamedev can be. Our backers are also very patient with us, and I don't want to destroy this relationship, but keep being as open and forthright as I can with our progress.

I don't mind the jokes (after all, yes, the whole undertaking is a bit ridiculous), but just want to make sure the facts are understood as they really are:

* Yes, the premise of Nowhere continues to be that it's an alien life simulator (as in: simulating the everyday life of an alien).

* The game is being developed by not just one, but two people: My wife Sylvia Ritter[1] is responsible for the concept art that drives the procedural design (she has given me a lot of work), and I am responsible for programming and direction. We both have a hand in the game design.

* Yes, development is still going strong, and will continue to do so, until the game is done or I keel over, whichever comes first ;-)

* Yes, I am absolutely yak shaving, and there's definitely some sunken cost thing going on here, but there is still no project I'd rather work on than this one. When we launched the crowdfunding, I had a hunch that this would end up taking us 10 years. Now we are on the far side of it and I had to start cutting features and workflow improvement ideas in order to have a chance at making it in time.

* Yes, I developed a programming language for the game, because the art is procedurally driven, and that requires both fast turnaround in prototyping (close to Scheme or Python) while providing C level performance at the same time. There simply was at the time that I started, and still is, no adequate solution available. Originally, I didn't want to do it, but we rationalized that innovation of technique requires innovation of tooling, and hence worth the effort, provided we'd open source everything we made in pursuit of our goal.

* No, Scopes' string implementation is complete for several years already, the recent commits are all touch-ups, augmentations and small fixes for the userbase that has grown around the language, which were quick to do and cost me no significant time. We have in fact other, much larger, support problems that I can not adequately cover because the game is main priority, and the language exists to service the game.

* Yes, I developed a pure functional reactive language on top of Scopes for our game engine that I wrote a few examples with, in the intent of finally merging the CPU and GPU models so we save 90% of pointless and repetitive boilerplate code for CPU/GPU resource management. It's a fantastic idea that is going to go places, but after realizing how much more I'd have to write to get it all the way to its final, visual programming oriented form, I aborted the prototype and focused back on the game.

* What else have I spent my time on? I spent most of those years writing a bunch of prototype shadertoys to explore possible technology used for the game and also teach mathematical concepts to other developers, and they're all released here[2]

* What's going on right now? After streamlining package management[3] for both Scopes and Nowhere, I am presently working on our sculptable terrain engine. There is a by now somewhat outdated video demo[4] of one of its earliest incarnations. The LOD stitching has been fixed, and we have occlusion culling now, but I still have to rewrite parts of it to get a rock solid sub 10ms per frame performance. It would have been more fun to do all that with FRP instead, but tooling is never quite where you want it.

Thanks for reading all that,

Leonard

[1] http://sylvia-ritter.art/

[2] https://www.shadertoy.com/user/paniq

[3] http://majoreo.rocks

[4] https://www.youtube.com/watch?v=5JOzqsJZmCo

> Because I think it's a lot harder (both for you and for your users) than you thought at the time, and I hoped you wouldn't waste your time (and your users' time) on it.

I believe it is possible to offer such a feature without declarative baggage. If it's not, then I don't want it ;-)

> Personally, I think GC is the way to go to keep your (programmers') sanity. If you worry about GC pauses in time-critical sections, provide for a way to turn off the GC temporarily for such sections.

It might be even possible to leverage Scopes' support for compile-time introspection to write contextual GC's from within the language. I haven't explored that yet. In games development we usually prefer to allocate in frames, stages or on custom stacks, so that's also a way to do it.

Installing a GC at the lowest level is a brutal choice that precludes many other possible ways this could go, so I'm cautious.

unconst can't be the default because there is no way to re-const a value once it's been turned into an unknown. The most "automagic" behavior is to tie branch conditionals to their exit values (there's a helper function called tie-const that does this for the manual case). If the conditional is unknown at compile time, then the continuations that exit the branch will mark their arguments as unknown. That also stops loops from unrolling (they'd typically unroll for i=0, but then stop). But, as I mentioned before, that completely kills constant folding at the exit points, something that is at times desirable.

Another reason loops are unrolling by default is that there are many situations where constexprs have to completely fold at compile time, and you need a guarantee that they do. A common example is handling keyed varargs. You need to be able to iterate through the keys and build local variables from that without any code being generated.

If a compile time unroll takes forever, there's practically no clean way to debug that.

> That code does indeed automatically delete some entries from some collection, and it does use garbage collection terminology, but it doesn't appear to be full garbage collection for the whole language. Hard to tell in the complete absence of comments and a commit message.

It's very old code from two years ago, when the language was still being prototyped. I did have a form of GC for a while that I threw away again because I couldn't make it work right.

I recommend not taking any commits before the first tagged release seriously.

> Fortunately, it doesn't look like he ever tried it.

I tried, but I'm completely paralyzed here. As long as I can't see a straightforward way to integrate support into the typechecker, I won't write a single line.

Also, why "fortunately"?

> as if the developer did think of these as opposites

Not opposites, just not aligned with each other. The demands of Scheme's runtime model inherently conflict with realtime performance. There's nothing wrong with that, but that sets it apart from C.

With this sentence, I hoped to address Scheme users who wish they could generate faster, tightly-constrained assembly while not having to give up on hygienic macros and nested evaluation contexts. No insult was intended.

S-expressions are not a special case of the syntax, S-expressions are the syntax. There are two notations, one is naked, python-looking, and one is traditionally braced, lispy-looking. It is possible to enter from one notation into the other at any point, depending on what suits the situation best.

Scopes has no garbage collection. There will be garbage collection for compile time symbols at some point, but the runtime is completely manually managed. That is a big difference to Scheme, although Scheme has been a major influence to Scopes design, and features that I believe to set Lisp/Scheme apart from other languages have been adopted.

Scopes is statically typed, but type signatures are not elementary to function definitions and value declarations, as with Scheme. It is a little limited with its compile-time closures though, whose application as first class values is limited.

I don't know what those are, but Scopes is designed to make it easy for users to implement their own meta-programming abstractions. It might be possible to build such mechanisms from within the language. I certainly want to hear of the instances where it is not.

Hi, glad to hear you like it. I'm using Scopes to build a game engine called Tukan, which is for an ambitious game called Nowhere that is in development hell for four years. :-) I don't really know what I want from the community to be honest. I guess I just want to collect first impressions, see what people like, what they struggle with, what things they need and what ideas they come up with.

I do think that Scopes is uniquely suited for monolithic multimedia applications like games and media authoring and that would be the direction I'd like to see it go. But there's technically no reason why it couldn't go another way.

Regarding "unconst", we need to have a discussion. There are ways to make it implicit, namely by tying the return continuation of `if` to the constness of the conditional, but then one loses the ability to specialize the return continuation for constant results.

Named `let` is the most primitive form of loop, suitable for use in runtime and compile time (constexpr-style) context. There are more convenient, less versatile and compiler-friendly versions like `for ... in` and `while`. It is possible to design your own loop structures, and even build an auto-unconsting `if`, so I was hoping that the community would innovate here within the language.

Partial evaluation is user-controlled. The rules are deterministic: the system guarantees that constant expressions are always folded. The error message would not exist if we could solve the halting problem. There is no way to tell in every instance if a loop or recursion ever terminates, so I went for the simplest rule, which is that if a label is reentered the 32th time, we abort compilation. It's a cautious limit because constant folding is interpretation (slow), and I don't think that programmers want big loops to unroll. This can and should be discussed. I certainly don't have all the answers.

> I understand that it's the underlying label/goto abstraction leaking through

Scopes' abstractions aren't leaking, they are offering their innards to you. You can generate and inspect IL from within the language. Everything has been made so that you can build your own abstractions on top of them, which is only possible when the internals aren't hidden. The philosophy is that a compiler is a servant, not a framework.

stuff that I can imagine would be unbearable to read with an "everything is possible" 20 year old mind, but actually quite helpful when you're 35, nearing your wits end and the exit moves closer than the entrance.

I'm sorry you've been running into trouble. The practical problem was that neither Bitbucket nor github offer a lexer for the language on their site, and the markup doesn't allow custom styling. So I just screenshotted the editor.

do you have more information on that?