uninitialised variables to 0. Stays. Beginners need this. It's just easier for them if it's there.
That option doesn't make a novice's life easier any more than an automatic syntax error fixer would. Errors that should have been reported directly would need to be discovered via observations with the debugger. This would increase the debugging load for novices and those who help them as well.
begin/end/then etc. all stay. GML is simple to get into because it understands many syntaxes. However... I'm starting to think we need an option to selected various syntaxes. Lax, Pascal, C, C#.. etc.. (just examples!)
Won't having to adapt to several syntaxes on top of each other in the same language confuse a novice even more? Look, nowhere in the manual did it say that we can use and, or and xor as boolean operators, begin and end as block delimiters and then as part of if statements. These aren't even in the standard to start with, so they should go away.
Does anyone use the printer stuff?
Not me. But since it is implemented as an extension, there's the option of leaving it out of finished games. That's fine with me.
The same cannot be said for the cd_*() functions, because it's built into the runner. Although I still have a couple of CDs, I don't play them with GM and the code for it just takes up space in the runner. Feel free to put them in extensions, but I don't want it in the main runner.
Triggers - I can see this being a performance hit somewhere in the runner. I don't want to see them added again; alot of people find them useless.
I would vote for trigger to stay. Rusky has already posted the reasons for why they should stay from page 3, see for yourself. Besides, it was originally implemented for a request for custom events that automatically trigger --- what will fill that void?
My most recent game uses a trigger-based pausing mechanism which allows me to selectively pause certain step activities with the change of a single global variable. Inheriting these activities over an object hierarchy is where triggers shine over step-checks.
As for a short list of things that need to go:
- All deprecated functionalities, except for instance deactivation. (It's about time they go for real.)
- All GML constructs not present in the GM manual, including the use of = for equivalence checking. (Keep the standard consistent.)
- mplay_*() (DirectPlay's fallen from grace, and so should this.)
- script_get_text() (I don't see any useful applications of this.)
- secure_mode (Really, who doesn't use external files and DLLs nowadays? It doesn't work when GM isn't running, either.)
- score, lives, health, show_score, show_lives, show_health, caption_score, caption_lives, caption_health (Please, just make the novices learn about variables, it's not that hard.)
- sleep() (Too easily mistaken for freezing.)
- sound_set_search_directory() (I don't think anyone would use this, given the presence of sound-playing DLLs and tracker formats.)
- Simple mode (Many settings and properties that still have effects, such as views and scripts, get hidden this way --- just trash it.)
- Game Information (Looks ugly, limited in functionality, kill it.)
- solid (Causes lots of issues with collisions.)
- "Treat unitialized variables as 0" and "Show all errors" checkboxes (There is only one good setting for these things.)
- execute_string() and execute_file() (Inefficient, opens up potential security threats and prevents GML from being compilable)
- set_program_priority() (NPT has explained why pretty well.)
Things that can stay but should be moved into extensions:
- cd_*(), MCI_command()