On Thu, 28 Apr 2011 20:13:05 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
Hi,
I just noticed the change[1] in wording of the set filetypes menu which was something that had (slightly) bothered me before, since I personally consider most of the scripting languages as programming languages as well.
This is why I changed it, scripting is programming.
I'm not sure that the word "Compiled" is the best choice though, since it's kind of vague:
Is Vala a compiled language because it's compiled into C code? Is Python *not* compiled because it's compiled into bytecode? Is Java a compiled language?
I'm sure you can see what I mean, there's a lot of gray area using the term Compiled, since many languages can either be compiled to machine code, interpreted by a VM/runtime, compiled then interpreted, compiled to one format then another, compiled just in time, and so on.
Obviously all source code is compiled at some point. The Compiled group all have one thing in common - separate compilation is normally required before execution. This is still true for Java. Python compiles on the fly, and is obviously thought of as a scripting language rather than a compiled one.
Unfortunately I don't really have much for alternative terms, but a few possibilities for better categorization could be:
- By the current categories, but putting filetypes under each one they
fit in.
that depends on how you interpret compiled.
- By changing Scripting to Interpreted and then shuffling some filetypes
around to reflect the way the languages are usually compiled/run.
D can be interpreted or compiled, but not scripting. It's normally compiled, but the point is this categorisation is not much better than the status quo.
- By the current categories, no change, since users will get used to
where to find their languages pretty quickly.
- By Static vs Dynamic Typing
Some are both e.g. Haxe.
- By programming language paradigm (ie. oop, functional, etc), and then
each programming language could fall below more than one menu item if they are multi-paradigm.
I think this is too complicated.
- By just Programming Languages, so that the Compiled and Scripting
menus get merged. This could make the menu long/scroll. SciTE does this but with fewer languages.
I really don't see what's wrong with the current separation, after a first glance at each it should be easy to understand.
- By alphabetic order, with a menu item for each letter of the alphabet
unless no filetypes fall under a letter, then don't show it. This could be ugly in terms of code/i8n and appearances. IIRC another editor is doing this (Notepad++?).
filetype names are not translated IIRC. Not sure this proposal is better.
There's also a few other quirks I've noticed in the 'Set Filetypes' menus:
- I generally wouldn't consider CSS a markup language, but it probably
technically is. IMHO it would be more apt to put it under Miscellaneous.
I agree, I think there is little overlap with CSS and document languages like HTML.
- I believe LaTex, Markdown, and reStructuredText are Markup Languages.
Good point also, and txt2tags.
I don't know COBOL but I think it's a programming language isn't it?
NSIS and CMake files, while domain-specific, are still
scripting/programming languages.
Ok.
- 'SQL Dump file' seems a bit odd, since it's a file containing language
constructs and is "run" by the db engine, maybe it should be 'SQL file' or 'SQL source file'. I know a file containing SQL is often the result of dumping a database, but is it the only time you would end up with such a file?
- The wording 'Miscellaneous Languages' makes you think the contents of
the submenu will contain (programming) Languages, but a config, diff, or gettext file for ex, doesn't really seem to be a language. The word 'Languages' could be removed from that menu item, which would imply that the contents of that menu will be 'Filetypes', more generally.
I could be wrong on these, they're just my observations. None of these are a big deal, but it was something I questioned probably even the first time I opened Geany and every time I select a filetype since.
Agree also on all these points.
Regards, Nick