[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: S.W.O.T analysis
- From: Dimiter 'malkia' Stanev <malkia@...>
- Date: Wed, 19 Oct 2011 11:08:39 -0700
I feel you are mistaken about "draining professional programmers".
I've been professional game developer for most than 10 years, and been
through 20+ languages, a lot of them still used daily.
Game written in C++, scripted with custom script language, possibility
of using lua, in the past one our games integrated flash solution for
the UI. We used to have another scripting language.
Then python for almost all new (and some old) Autodesk products,
specifically melscript (Maya), maxscript (Max)
CSharp for new tools, mainly because of Windows.Forms. Non-programmers,
such as scripters are pretty good with VB and write lots of small tools.
Perl, Python used a lot for plumbing as external tools. Perl integrated
for our main launcher app where everything is starting.
SQL (MySQL, SQLite, Microsoft SQL) used a lot. Batch files, even shell
scripts from a previous developer (cygwin ones). Makefiles too, whole
makefile system, but also leftovers from jam (another make system), etc.
We had a sharp guy, that was using F#. Lost battle though, as much as I
like the language.
So at least in my industry (console video games) what drives what
language is being used is support for the said platform in terms of SDK,
Most of the APIs are "C", some "C++". Lots of tools are popping out
extended through .NET, some older used to be COM.
So drawing your conclusions that programmers have been drained by a
specific language is bit misleading. It takes quite a lot of time and
effort to train your people to pick that language.
Haskell for sure can't be used for console video games, due to lazy
evaluation, but languages close to it ocaml, but more likely F# might
be, but only for indie titles.
There is no single language to solve it all. Where performance really
matters, C/C++ might be a good choice, and even DirectComputer/OpenCL or
old school graphics shaders.
Where iteration and safety matters - scripting language of any choice
might be a good fit, as long as it fits the game runtime.
Python for example is not very good, because it's not easy to have
multiple python interpretters (yes there is stackless). Also it's quite
big - 1.8-2MB runtime.
Lua interpretter can fit on single PS3 SPU processor, which has only
256kb of memory. It can probably DMA the rest from the main memory
Forth is still used for places where memory is constrained, yet speed
not that important, and possibly a prompt for programming (REPL).
I've spent few years learning Common Lisp, and it helped me understand
macroses, closures, better exception mechanisms (conditions), and that
syntax does and does not matter, and that's what's important about it -
when it does, and when it does not.
I find lua the classic, if I can say buddhist approach, very balanced
in every way, and unique in others.
On 10/19/2011 5:31 AM, Patrick Mc(avery wrote:
I did not mean to imply that Haskell was for non-programmers, quite the
opposite! I think it's power is a threat if it drains away
professional-programmers, while Python has the potential to become the
"Walmart" of programing languages, swallowing up family-sized ones. I
could never have understood Lua's prototype-like object system without
having understood Python's plain class based object system first. I know
saving CPU cycles is always a concern and Lua has the edge today but if
savings CPU cycles did not save Forth, then in the long run it might not