Re: S.W.O.T analysis

[Dimiter 'malkia' Stanev <malkia@...>]

	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, 
compiler, debuggers.

	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
	http://www.slideshare.net/hughreynolds/sony-lua-rj-michael-scea

	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:
> {snip}
> Hi Steve
>
> 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
> save Lua.
>
> Thanks