Quote:
Originally Posted by Loriel
Hi I haven't logged into the game for years but I disagree with your entire post.
I'm a fan of explicit syntax for variable declarations (like `var`) and type annotation. Just putting a few words next to each other and hoping for the best leads to a C++-style "long typedef int const unsigned volatile x;" mess, even before you get into pointers and function pointers and arrays and generics and whatever else gs3 might not get the same syntax freeform for. I mean I guess I'm not 100% married to postfix type annotations but it seems to get messy otherwise (`var(float) x`?) and there's piles of precedent for the `var:type` thing.
Also I believe parser-wise having a token like `:` that basically means "okay, there's gonna be a type here, not an expression" makes things a lot easier and cleaner, but I have no idea how that applies to gscript i particular.
|
It really is just personal preference and thats the style I'm used to. I will use whatever comes but again, the name:type just seems weird to me.
Quote:
I'm not familiar with any programming environment where visibility modifieres like `protected` are a security feature. C++ isn't memory-safe to begin with, in Java and C# or ruby or whatever you can circumvent visibility with reflection-ish APIs, and even in type-theory-obsessed Haskell you can just define a similar-looking type without the visibility restrictions and unsafely coerce between the restricted and unrestricted types. "Security" would need to be a fairly elaborate and orthogonal concern where you think about trust boundaries and all sorts of things that ugh it looks really complicated in java let's not do that. Can't people just be nice.
I'm of course all for a cool module system that lets you expose as little as necessary of your code to code written by your presumably incompetent shithead collaborators, instead of dumping everything into a huge dynamic object graph. We're probably halfways getting there with declaring global variables. I dunno.
|
Not so much language safety as environment safety, multiple developer safety. There are many instances where I'd like to prevent other staff members from altering certain values without needing to do some silly encryption or hide it somewhere else. Thankfully, we have no way to directly access memory
The other advantage is ensuring other developers will use your public functions rather then hack something together and have their system break when the internals of your system breaks. There are no professional teams as far as Graal is concerned so anything to bring consistency and abuse-prevention into this language would be great.
Quote:
Threads+mutable shared state is an evil combinations, the javascript folks are flipping the **** out at the prospect of doing unrestrained threads, and everybody is kinda trying to get away from that programming model towards some message-passing, share-nothing concurrency thing if they can. Python can't even thread because they figure people would just get it wrong. C++11 had to change around half the language to even have the words to specify what concurrency does.
Arguably people have run into the whole "hmmm, I need to do something computationally intensive without blocking the GUI or whatever, I guess I'm ****ed" situation before but I don't think preemptive multithreading is going to do anything but set your server on fire and confuse everyone even more.
Maybe some sort of "idle handler" that wouldn't run concurrently but between regular script events with some API that makes yielding after each iteration of your crazy pathfinding algorithm required or at least natural would work as a compromise...
|
I had suggested a priority variable to Stefan before, just a single var in a script to tell the backend this script should run at a higher priority but that would be a lot of changes as well.
We have an opportunity (Stefan pending) to add new functionality to the language. I have nothing against completely isolated threads but i think mutable shared state would probably be easier for most devs. Perhaps all locking can be automated for the developer, giving a simpler method of using threads. Of course, this could just make things god awful and worse than when it began.
Regardless of how simple (or damn difficult) the language made it, this would be advanced scripting so only devs who knew how to do it and what gains (if any) would be available. Would love to see some experiments to see if there is any potential benefit.