GameMaker has its own GameMakerLanguage and many other games and programs have their own proprietary scripting language. Do you find this to be useful and effective or do you feel that it would be better if so many software development firms just made APIs for general-purpose languages like Python? Discuss the benefits of having a custom-built language in your software versus conforming to a general-purpose, widely adopted language. Assume we are talking about any type of scripting or API-like functionality.
I agree whole-heartedly with Arpit Mohan: the era of having proprietary languages is behind us. I've seen the following scenario play out a half-dozen times in my career:
In the 21st Century, the likelihood that zero existing scripting languages will meet the demands of your product is pretty small, so... the most responsible approach, in my opinion, is to try (partially) integrating at least three existing scripting languages before giving up. This page provides a list of likely candidates. If you're not sure where to start, just pick these three:
Choose a common, high-value scenario and add scripting support for it using these three scripting languages. Evaluate the results, then pick the one the team likes best and add more thorough bindings to your API. At the end of the day, you will probably find that it works fine for your needs. If not, the exercise will, at a minimum, expose the pain points of existing languages, and provide data to justify development of a home-grown scripting language.
I'm pretty biased on this after getting burned a few times by well-meaning colleagues who got permission to design their own 'pet' language and then disappeared, saddling the rest of the team with the burden of supporting their 'Franken-script'. I'm sure there are cases where a home-brewed scripting language is justified, but... I've not personally run into them in my neck of the software development woods...
I think the era of having proprietary languages is behind us. Most companies in the last decade or so have burnt their fingers by ignoring or not incentivising the developer community. If you expect people to pay for your programming language, growth will be hard. If you expect people to learn a new language in order to operate your software, growth will be hard and will take a lot longer.
While creating these walled gardens may sound great in the first few years for the business, it's a losing strategy in the long run. In the long run, developers will pick some other software (even if it has fewer features) if it helps them get up and running in a familiar language and environment. I know I would. Plus, if I can't re-use this language anywhere else in my life, why should I invest time and energy (unless I'm desperate for a job). Else, the upside generally isn't worth it.
If businesses need to cater to the non-programming crowd, that should be done either via UI interfaces or simple DSLs, definitely not complete scripting languages. Creating & promoting a programming language is a lot of work. Just ask DHH at Basecamp. Hoping a new language will be valuable to developers is just another problem in your business that you artificially created and could have done without.
If the business does decide that they need a new programming language, they should have some really really really good reasons. "But, but .... how else will I massage my ego?" is not a valid reason.
It really depends on why it was done.
Sometimes a generic existing language simply has excess bloat that gets in the way of the task. This is particularly true in interpreters since as a rule of thumb the more functions you have, the slower the language unless you have a bytecode compilation stage -- and even then it can be an issue.
Likewise it often helps to pre-build common tasks or have functions/instructions/opcodes specific to the program that really would feel shoe-horned into an existing language.
You also have that not all game developers are in fact programmers. Most of your skilled content creators -- ACTUAL professional writers, artists, musicians, and so forth are NOT going to be able to sit down and start working with C, so a simpler "script" language is often in order just to address that problem.
But as others mentioned, sometimes there are cases where larger development houses just do it out of spite -- so that anything you learn working for them is useless elsewhere, locking you into being their bitch for life.
Sometimes it's about creating the right tool for the job instead of shoe-horning in an existing solution, sometimes it's about making wage slaves... I've seen it done for both reasons.
I've generally assumed companies do this to lock devs into their ecosystem. In theory you may get situations where a company does something so incredibly specific that they need a DSL, but even then from a dev's point of view I'd prefer a really great framework in a more popular language.
The purpose should be to enable fast, high-quality development in the ecosystem. So if the proprietary language is really easy to learn and makes it really easy to get things done... fair enough. Those are some pretty big "if"s though.
If one can get good integration between the existing language and the tool, and have the right features (not too few or too many), then that would be best. People can transfer the knowledge, and the developer can save time.
Of course, on a cynical note, not all companies may want skills to be transferrable - that would mean users can easily leave.
I imagine that many have their own languages because 1) in the beginning, they want only a few features, so a full langauge is overkill, and 2) making languages is fun (and 3, the cynical point above).
I believe Lua is a popular language in the scripting-for-other-projects space:
What do Adobe Photoshop Lightroom, Angry Birds, Apache HTTP Server, Apache Traffic Server, the Firefox web browser, MediaWiki, and World of Warcraft all have in common? They are all extensible using the cross-platform Lua programming language
In the particular example of GameMaker and Python, it's worth noting that GameMaker is pretty old (1999) - Python 2.0 wasn't even out yet. (It even existed under another name before that, but I don't know if it had GML). I'm not sure GML has always been proprietary and I can't find it - it at least used to be free to use.
(Note that as a user, you should prefer a non-proprietary langauge - GameMaker used to be free, but its 100$ now, while Python is still, and will probably stay, free.)
10Q
I prefer non proprietary scripting languages but it does not really bother me if a game engine uses its own language as long as they have good docs and examples.