Talk:Categorical list of programming languages

From Wikipedia, the free encyclopedia

You have new messages (last change).

This page is missing languages like applescript and hypertalk and others. I don't know what categories you would want to add, such as fifth generation languages perhaps, or beginner-friendly languages (basic variants belong there as well).

(suggests adding markup languages) (runs from flack) --24.126.30.46 00:25, 27 November 2005 (UTC)

Something went wrong with the formatting when I tried to edit! HELP! -- RTC 22:10 Apr 9, 2003 (UTC)

Is that what you want it to look like? Make sure when you bullet things that stuff in the same category isn't seperated by a line break. -- goatasaur

Yes, that looks more like the original. All I did was edit the page and change a couple items. I have no idea what inserted all that "trash", I've never seen it happen before! -- RTC 22:17 Apr 9, 2003 (UTC)

I did some tests, and found that I had to go back at least 2 revisions before the one I edited to avoid getting the format scrambled like that in a preview of the edit (without changing a thing). Must have been someting "hiding" in that revision that my browser did not like, I guess. -- RTC 22:26 Apr 9, 2003 (UTC)

What about the Rebol language? It's more than a scripting language, but I don't know quite enough about all this to know where to put it. --Marj 18:21, 4 Jan 2004 (UTC)

Aren't batch and scripting languages the same thing? Evil saltine 06:45, 8 Jan 2004 (UTC)

You are sooo young :-) Good question -- bad title. I'm just about to replace subtitile "batch languages" "CLI languages (batch languages)", meantime you read Command line interface Mikkalai

Some so-called 'scripting languages' are not 'batch processing' languages in the strict sense of the term (compare sed and python for example; sed is very much a batch processing language, whereas python is full featured enough to write complete systems with). While you *can* use them in this way - just about any other language for that matter can be used in a 'batch' processing mode. A language is a language - plain and simple. I think the term 'scripting language' has been used too often to deprecate the subject language as 'not a real' programming language - i.e. 'it is a useful toy for small tasks' - but not much use for any 'real' large application/system programming utility. Modern languages such as Python, Ruby, and Perl argue against this characterization.

Contents

[edit] C# Editorialized as "a version of C" or "an attempt at C"

In my opinion, C# listed in these various categories should not have an editorialization in parenthesis afterwards. These editorializations are opinionated, inprecise, and entirely unnecessary (if one wanted to know more about C#, they would simply read the entry for C#).

I'm new here, so instead of just taking a whack at it, I'll check what the more experienced here have to say.

Samrolken 10:29, 18 Jan 2004 (UTC)

Most certainly, C# is not "C for .NET project", and there is no ".NET project" in this context — correct me, but I have never heard these words in this combination referring to anything but a project file in MS Visual Studio and #Develop. C# is much much closer to Java than to C, and arrogantly strict in typisation — in the biased eye of a C++ hacker, indeed :) — to remind of Pascal and its Delphian variety, especially given that both the latter and C# were designed by the same team.
-kkm 21:49, 31 Jan 2005 (UTC)

[edit] Does Ruby belongs to Curly Brace family?

Isn't Ruby is also a Curly brace programming language? I am a layman, but I want to help. -- cow_2001 12:21, 4 Sep 2004 (UTC)

Ruby can use braces to delimit a code block that is to be provided to a method. In other words, they are used for a very specific feature, but not for method definitions or for/while/etc. blocks. Ruby programs frequently use braces, but not in the sheer numbers seen in C. I'd say it doesn't belong in the family. --Yath 04:11, 5 Sep 2004 (UTC)

Compared to python it belongs in the curly brace family. Perhaps it should be added with a caveat?

I don't think Ruby qualifies. To delimit syntactical blocks, it doesn't use curly brackets, but keywords (if/while/do/def/..., end). The {|params| body} syntax is roughly just a shortcut for do...end: it specifically declares an anonymous function, instead of acting as a generic syntactical grouping, like other curly bracket programming languages.
In other words, the point of talking about "curly bracket programming languages" is to contrast them against languages which use other approaches of delimiting syntactical blocks, such as keywords (Ruby) and whitespace/indentation (Python).
--Piet Delport 16:46, 24 February 2006 (UTC)

[edit] Perl is Interpreted language

I think Perl scripts are more interpreted then compiled. --Michal Jurosz 10:06, 6 Feb 2005 (UTC)

I think you're right.

Hmm... JIT compiled is still compiled. Strange conundrum -- perl itself jumps through hoops to simulate an interpreter while compiling and caching code. But it is possible to pre-compile perl into binary form to make it load and execute quicker. zowie 17:14, 13 December 2005 (UTC)

Perl is compiled into a kind of intermediate parse tree, then executed by dynamically interpreting that intermediate form. All syntactical checking occurs during the parsing phase prior to execution, so arguably it's a compiled language. On the other hand, it's a bit more dynamic/interpretive than, say, Java, in that it does not produce an executable binary or bytecode format. -Loadmaster 23:06, 9 June 2006 (UTC)

[edit] Python is both Interpreted and Compiled

Python compiles bytecode - very similar to Java - when it runs. Furthermore, the bytecode is deposited in a .pyc file alongside the source .py file. If detected at runtime, this compiled bytecode is used instead - making second and subsequent initialization loads much faster.

Also, my understanding is that both Perl and Python have utilities for generating binary executables (basically the virtual machine is encoded along with the bytecode in a binary). Does anyone have sufficient experience using these facilities to comment on them here?

Neither of those (bytecode complilation and interpreter bundling) qualify as true compilation, as its generally understood. However, PyPy (the self-hosting Python implementation) can currently compile an informal subset of Python (known as RPython) into native code: enough so that it can compile itself. That's still not enough to declare Python a compilable language, yet, but at the rate things are going, that day is probably not too far off. --Piet Delport 17:03, 24 February 2006 (UTC)

[edit] stack-based

Can we add a stack-based category? Stack_(computing) --213.48.248.121 21:28, 4 May 2005 (UTC)

[edit] assembly languages

I'm not sure on this so can anyone shed any more light? -> There's only 2 assembly languages listed here - What about the different assembly languages for each processor? e.g. x86 assembler, motorola assembler etc... I don't know enough on assembly languages specifically to really makes changes to this section.

[edit] Pascal supports generators?

Pascal is listed under Iterative languages ("Languages built around or offering generators"), but cursory research seems to indicate the opposite. Can someone more familiar with Pascal confirm this? --Piet Delport 13:29, 7 November 2005 (UTC)

Lacking evidence, i've removed Pascal from the list. --Piet Delport 11:26, 2 January 2006 (UTC)

[edit] Portability Categories

Could someone put lists for "Write once, run anywhere" and "Write once, compile anywhere". That's a crucial choice when choosing a language imo... --MatthewKarlsen 14:28, 27 December 2005 (UTC)

The problem is that it's non-trivial to find any useful definition of those terms, theoretical or practical. What (and which) percentage of the features of the language (and its core libraries) need to work across what percentage of which kinds of platforms, before it counts as "portable"? How fast does it need to be to qualify? (keeping in mind that you can trivially make anything 100% "portable" by running it on top of a sufficiently low-level (but slow) emulator, or compatibility library) --Piet Delport 12:25, 2 January 2006 (UTC)

I would answer that some are clearly trivial to identify --- e.g. java, python, perl for 'write once, run anywhere'; on the other hand 'write once, compile anywhere' is dependent upon having an assembly language, and then a compiler built for a particular cpu architecture - trivial if you stick to basic functionality that all CPUs are likely to have, but not trivial if you happen to use functionality specific to particular CPU's instruction set (c and c++ come to mind as languages that allow low level interaction with the cpu - but again 'it depends upon how you use the tool'). Finally, what do you consider 'compilation'? Does Java's, Python's or Perl's bytecode compilation count for this category? It is can be problematic - nonetheless useful in practice.

You might be in for a surprise if you think Java code can run "anywhere". :)
Just like you can't run C code on some target platform without writing/porting a working compiler to it, you can't run Java/Python/Perl code on some target platform without first writing/porting a working VM to it (which, in the case of JVMs, can be an extremely difficult undertaking: how many platforms have complete and conformant JVMs by now?).
Even assuming the availability of compilers/VMs on all target platforms, the "portability" of your program really doesn't depend on what language it's written in, but on how well you wrote it. It's just as easy to write unportable Java code as it is to write unportable C code: a language can only support portability, not enforce it. (The situation is further complicated by the fact that even the most unportable programs (regardless of the language) can be made portable again through appropriate compatibility layers (like Wine for Windows code), or dynamic recompilation/binary translation software.)
The situation with compilation (WOCA) versus interpretation (WORA) is not much different. It can become hard to find a meaningful distinction:
  • "compiled" languages can be interpreted (like CINT for C/C++)
  • "interpreted" languages can be compiled (like GCJ for Java, and PyPy for Python])
  • in languages like Lisp, Scheme, and Haskell, the concept of "interpretation" or "compilation" as two distinct processes begins to disapppear altogether: instead, depending on your implementation, you can get as much compilation, or interpretation, as you ask for at any given time
--Piet Delport 19:15, 24 February 2006 (UTC)

[edit] Point of this list?

Since this is a Categorical list of programming languages, wouldn't it be easier (and more maintainable in the long term) to simply create a bunch of Wikipedia categories for each category on the list, and add the listed languages to each of these categories? Then add each of the categories to Category:Programming languages, and the need for this list pretty much vanishes. Plus new additions to the "list" are handled locally. --Allan McInnes (talk) 16:44, 11 April 2006 (UTC)

It took a while to find the guidelines on this question: Wikipedia:Categories, lists, and series boxes and also Wikipedia:Lists (stand-alone lists). These might be helpful although I didn't get much out of them yet. Basicly, the first one says that there can be both a list and a category, and the second one mentions lists of lists. This page is so long it should be broken into several pages anyway. Category:Programming languages looks like people have been working on it but that it has been of too much work. Anyway, some of the lists already have a respective category that of course should somehow correspond to the info on this page. --TuukkaH 17:43, 11 April 2006 (UTC)
Well, I'm less interested in policy than in maintainability. This list is undoubtedly already out of date, and only likely to become more so as time goes on (I think it's also notable that there aren't that many links to this list to begin with). I suppose there might be something to the point about annotations in Wikipedia:Categories, lists, and series boxes. OTOH, there aren't that many annotations in the list (some parts more densely annotated than others). I suppose that one solution might be to break the list into separate articles, or more likely to simply merge the lists into articles that deal with the language category in question (for example, concurrent computing already contains an extensive list of concurrent programming languages — the only reason that this list has as many entries is because I updated it based on the concurrent computing list a month or so ago). --Allan McInnes (talk) 18:31, 11 April 2006 (UTC)
Right, I missed the maintainability issue. If any of the lists are retained, I suggest we prepend them by a link to the respective category, and only include significant languages in the lists itself. --TuukkaH 19:20, 11 April 2006 (UTC)
I think that sounds like a good suggestion. --Allan McInnes (talk) 20:04, 11 April 2006 (UTC)
I agree with Allan McInnes, just use categories and talk about them in articles about the language types. —Quarl (talk) 2006-04-12 09:25Z

[edit] Cleanup

This list could use a lot of cleanup, both internally and externally. Many of the lists contained correspond to categories, but they aren't listed; I've started to add a see also link where possible to rectify this. Often, these lists contain languages that are not categorized as being in the list; I've started to fix that, making sure that the languages are either in that cat or in an appropriate descendent cat. The categories contain languages that aren't listed on this page as well, but I figure that having the category links will make that tolerable enough; it would of course be better to update the list with everything listed in the categories, but I'm not doing that myself.

Not all sections have a corresponding category. I've already added one new category that seemed reasonable, but others I wasn't sure of. I figure that once I've finished doing what makes sense to me, I'll probably start posting questions about the stuff that I'm less sure what to do with—unless someone else deals with them first.

There was some discussion as to whether this list should be kept. If it ever is deleted, this kind of cleanup should be finished before the deletion.

If anyone has any comments, concerns, or suggestions on how to continue this effort, please share. – Zawersh 00:04, 3 June 2006 (UTC)

Indeed. The Assembly Languages section, for example, is almost an exact copy of the List of assemblers entry. Perhaps rather than listing a bunch of languages in each category, this entire page should simply list the categories, and within each category a link to the more specific category (which itself contains the canonical list of implementations) will suffice. -Loadmaster 23:20, 9 June 2006 (UTC)
Retrieved from "http://en.wikipedia.org../../../c/a/t/Talk%7ECategorical_list_of_programming_languages_c3ea.html"