Thread: Gs3
View Single Post
  #69  
Old 05-08-2013, 11:11 PM
Loriel Loriel is offline
Somewhat rusty
Loriel's Avatar
Join Date: Mar 2001
Posts: 5,059
Loriel is a name known to allLoriel is a name known to allLoriel is a name known to allLoriel is a name known to all
Hi I haven't logged into the game for years but I disagree with your entire post.

Quote:
Originally Posted by Twinny View Post
but I agree with the notion that the current declarations look messy. Would prefer the much more standardised,
PHP Code:
float pi 3.14;
baddy sterrence = new Baddy(); 
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.

Quote:
Anything new and exciting happening on the backend? Considering you're making these changes for the data types, perhaps also add the ability to use protected vars? Any form of language security would be great considering the currently open and abusable state it is in now.
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.

Quote:
Not related to language syntax but wouldn't it be amazing if you could start adding the ability to run a function on a new thread (intensive long-distance pathfinding anyone)? I hate the fact that a single intensive function (or badly written script) can bring the entire server to a halt..

[...]

Ideally, you could have an event called from within the thread to let you know it's finished rather than using a loop to check but yeah!

The other added advantage would be putting core running systems on a separate, higher-priority thread so it doesn't get as interrupted during high loads.
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...
Reply With Quote