ebooksgratis.com

See also ebooksgratis.com: no banners, no cookies, totally FREE.

CLASSICISTRANIERI HOME PAGE - YOUTUBE CHANNEL
Privacy Policy Cookie Policy Terms and Conditions
Talk:Comparison of programming languages (basic instructions) - Wikipedia, the free encyclopedia

Talk:Comparison of programming languages (basic instructions)

From Wikipedia, the free encyclopedia

Why not just mark as stub? I'm sure it'll be a good article in a few time, when it will be expanded. Furthermore Wikipedia is full of comparison articles. Bh3u4m 17:34, 1 December 2007 (UTC)

I would like to show that once this page will be enlarged and completed, it might be very useful as a reference for people willing to learn a new programming language. Bh3u4m 18:14, 1 December 2007 (UTC)

Contents

[edit] Fortran

Any views on whether or not to add Fortran examples to this page? I know it's an old language, but it is still widely used in engineering and for scientific calculations. Murray Langton (talk) 09:13, 11 December 2007 (UTC)

Pascal is more old and out of date than Fortran, so Fortran is OK, every programming language is OK. Bh3u4m (talk) 10:28, 18 December 2007 (UTC)
Pascal dates from the late 60's/early 70's, while Fortran dates from the mid/late 50's, though Fortran is still being regularly updated. OK, I'll add some Fortran 77 examples to start with (which is what I'm familiar with) and then see about later versions of Fortran. Murray Langton (talk) 11:23, 18 December 2007 (UTC)
Note that Fortran versions up to and including FORTRAN 77 had the programming language name in capital letters, while versions from Fortran 90 on only capitalised the first letter. Also, up to and including FORTRAN 77, only one case (capitals) of letters was legal, though many compilers would accept lower case and quietly convert it to upper case. The examples I have provided (or will provide) are capitalised or not accordingly. Murray Langton (talk) 11:54, 18 December 2007 (UTC)

Also, FORTRAN 77 does have a while loop. Just go look at the article. --208.138.31.76 (talk) 18:29, 21 December 2007 (UTC)

The Fortran article points out that the while loop is part of MIL-STD-1753 defined in 1978, and is not part of the FORTRAN 77 standard (it is part of Fortran 90), even though it is in fact implemented by many FORTRAN 77 compilers. Murray Langton (talk) 21:29, 21 December 2007 (UTC)


[edit] Update Needed

Ever since I started editing this artice, nobody has been contributing. Can I have some contributions here? --Btx40 (talk) 20:57, 4 April 2008 (UTC)

Items needed:
  • Variable types
    • Character: Python, S-Lang, FORTRAN 77
    • Boolean: Python, S-Lang, FORTRAN 77
  • Control flow
    • Select case: Python - doesn't have one, but FORTRAN 77 has a computed goto
    • Foreach: Pascal
  • Typeconversions
    • String to integer: C++
    • String to long integer: C++, Pascal, JavaScript
    • String to floating point: C++
    • Integer to string: C++
    • Floating point to string: C++
--Btx40 (talk) 20:57, 4 April 2008 (UTC)

[edit] Array examples

I intended the array type table to show how to declare an EMPTY array because not all languages support pre-filled ones. --208.138.31.76 (talk) 18:29, 21 December 2007 (UTC)

by EMPTY, I presume that you mean an array who's elements do not have any particular defined values. In some contexts, 'EMPTY' can mean NULL or 0, while in other contexts it could mean an array with no elements. I have reworded the article to avoid the word 'EMPTY'. Murray Langton (talk) 21:38, 21 December 2007 (UTC)
Yes, that was what I intended. In addition, a pre-filled multidimensional array would probably require more than one statement to pull off. --208.138.31.76 (talk) 14:12, 27 December 2007 (UTC)
Why doesn't python have an example for array declaration, e.g. array = []. Technically, these are called 'list' types, but aren't they the same?
67.87.98.164 (talk) 03:29, 19 March 2008 (UTC)
Fixed that --Btx40 (talk) 21:00, 4 April 2008 (UTC)

[edit] Exception handling?

I was considering adding exception handlers to the Control flow section. Would this be a suitable addition? I appreciate everyone's contribution to this page. --208.138.31.76 (talk) 18:02, 21 December 2007 (UTC)

Exception handling is very important, more so IMO than some other things on this page. —Preceding unsigned comment added by Ty8inf (talkcontribs) 17:42, 17 January 2008 (UTC)
That would definitely be suitable but, we should divide the control flow section up so it doesn't get too wide. Mike92591 (talk) 01:33, 18 January 2008 (UTC)
Split control flow section. --208.138.31.76 (talk) 19:26, 25 January 2008 (UTC)
Added exceptions to the control flow section. Thanks ;) --208.138.31.76 (talk) 18:43, 29 January 2008 (UTC)

[edit] Complex Number Types?

A number of languages provide native support for complex numbers. It would be nice to see this added to the data-type table. —Preceding unsigned comment added by Ty8inf (talkcontribs) 19:23, 19 January 2008 (UTC)

The 'Data Types' section is getting quite wide. To make room for 'complex' etc., would it be helpful to split this into two subsections (Numeric and Non-numeric)? Murray Langton (talk) 21:24, 21 January 2008 (UTC)
I split the Data types section. I am not so sure that complex numbers are a suitable addition because they are complex, and only basic instructions are dealt with here. --208.138.31.76 (talk) 15:17, 25 January 2008 (UTC)
Well, in FORTRAN (66 onwards), COMPLEX data types are actually just as simple as floating point data types; such an addition would show an area in which FORTRAN is probably better than most of the other languages mentioned. Murray Langton (talk) 20:19, 25 January 2008 (UTC)
Don't see any .NET support, but C++ STL has a <complex> header. I might just add this after all. --208.138.31.76 (talk) 17:21, 29 January 2008 (UTC)
What is the meaning of the integer column in this table? If it means an integer-valued complex number, then the S-Lang entry should be blank because S-Lang provides no support for complex integers. --Ty8inf (talk) 17:57, 29 January 2008 (UTC)
Unsupported features are ref-ed instead of being blank. A blank cell indicates that the information has not yet been contributed. The integer column was added for those programming languages that make the difference between complex integer and complex floating point (such as C++). --208.138.31.76 (talk) 18:06, 29 January 2008 (UTC)

[edit] Named constants

Some programming languages (e.g. C++ but not C) make provision for named constants. Should this feature be added as a separate section, or as another column to some existing section? Murray Langton (talk) 16:20, 14 February 2008 (UTC)

[edit] Standard Input and Standard Output: Client-Side JavaScript

alert () and promt () dialogs are not I/O streams, but they are standard input and output methods in Client-Side JavaScript. Alik Kirillovich (talk) 21:01, 31 March 2008 (UTC)

The Standard Input and Standard Output section only discusses I/O using the standard streams. Other forms of input or output are not discussed here. --72.252.194.115 (talk) 16:27, 2 April 2008 (UTC)

[edit] New article

I am planning to start a compaison article for object-oriented programming features. I will use these languages and features to start the comparson tables.

Languages Features
C++ Object creation
C# Constructors and destructors
Java Class declaration
Visual Basic .NET Fields
Python Properties
Windows PowerShell Inheritance

Any suggestions for other languages or features are happily accepted --Btx40 (talk) 15:35, 7 April 2008 (UTC)

Article started --Btx40 (talk) 15:38, 8 April 2008 (UTC)

[edit] Loop statements

I don't think the recent changes to the foreach column are an improvement. Using language specific comment syntax like /*do something to item */ instead of the generic instructions makes this column harder to read and inconsistent with the other loop statement examples. Suggestions? Ghettoblaster (talk) 17:19, 17 April 2008 (UTC)

[edit] Python Indentation

We should use a consistent way of expressing Python indentation, either '\t', 'tab' or '    '. There is a mix of both '\t' and 'tab' in the current article, but I suggest using four spaces instead, as specified by the Python style guide PEP 8. 124.169.94.84 (talk) 01:05, 20 April 2008 (UTC)

I think so too, but with non-breaking spaces (&nbsp). Word wrap may cause problems (like with the VB examples). I am also thinking of a way to mark optional elements, such as else and finally blocks, without using square brackets. --Btx40 (talk) 03:42, 20 April 2008 (UTC)
That's what I use strike-through text for. Mike92591 (talk) 16:13, 20 April 2008 (UTC)
That's fine but, that means we definitely should change how it looks, it's not a good idea for one to stick out. Mike92591 (talk) 16:13, 20 April 2008 (UTC)
1 2 3
if condition:
    instructions
else:
    instructions
if (condition) {instructions} else {instructions}
if (condition) {instructions} else {instructions}
I strongly agree that there need to be changes made so that the formatting of all examples on this page is consistent and easy to read. Maybe I'm the only one here, but I don't like any of the recent changes using Bold and Strike-through. Using italics for the placeholder text seems more appropriate to me. I'm not sure what might be the best way to mark optional elements, though. Maybe we should try colors? I don't know. For Python indentation I would suggest using <tab>. Ghettoblaster (talk) 16:17, 20 April 2008 (UTC)
I'm not a big fan of it either but italics and colors are problematic. Italics are more difficult to distinguish. Different hues aren't helpful for some color blind people (depends on the type), however we could probably use a different shade like gray. It may also help to use guillemets or something. Mike92591 (talk) 22:06, 20 April 2008 (UTC)
Ok, I can accept the point regarding different hues and color blind people, but Strike-through is definitely hard to read for non-color blind people and for color blind people as well. Another issue is that optional elements cannot be nested this way while this was possible using square brackets. IMHO this is just wrong. Ghettoblaster (talk) 19:57, 22 April 2008 (UTC)
I personally didn't find that hard to read at all but it was more of a test anyway. The only problem with brackets is it collides with something that is often used, I think there would more confusion in that case. Although strike through has problems too. I think guillemets would be better although not by much. Mike92591 (talk) 00:05, 23 April 2008 (UTC)
1 2
if condition:
    instructions
«else:
    instructions»
if (condition) {instructions} «else {instructions}»
Guillemets sound OK, but they are not on a standard US-English keyboard, which is both an advantage and a disadvantage. Most programming languages only use standard ASCII symbols found on the US-English layout. Until this article expands to include ALGOL or something similar, that could be a viable solution. --Btx40 (talk) 14:16, 23 April 2008 (UTC)
I agree. Your example already looks much better. While working on some other articles I found Microsoft's TechNet formatting legend [1](at the bottom of the page). They use bold for non-optional elements and they also use italics for user supplied elements. I think this is a good idea, because italics are used for user supplied elements in many code examples throughout Wikipedia. The fact that guillemets are usually not used in programming languages is a big advantage here. Maybe we should also avoid the typewriter font, because bold letters don't look much different than non-bold letters in this font. Here is my suggestion. I use wikisyntax for indentation etc. Ghettoblaster (talk) 14:59, 23 April 2008 (UTC)
1 2

if condition:

instructions

«else:

instructions»
if ( condition ) { instructions } «else { instructions }»
BTW <tab> is not a valid HTML tag (I tried it on the sandbox). Did you mean Ctrl+Tab (which does not work in IE7)? --Btx40 (talk) 15:25, 24 April 2008 (UTC)
I know that '<tab>' is not a valid HTML tag. I suggested it as an alternative placeholder similar to '\t', 'tab'. I thought it would be easy to identify, but on the other hand angle brackets are also already used in programming languages. I think a better solution is using wiki-style indentation colons as I tested in my table example here. This will only work at the beginning of a line, but AFAIK the tab is only used at the beginning of a line anyway (at least in Python). However, I did not test how this will affect word wrapping in lager examples.
I also think that the keypress template you suggested is an even better idea. Also, we don't need Ctrl. All we need here is the Tab. I tested it and it works fine in IE8 beta. I suppose it is safe to use it here, since it is already in use in other Wikipedia articles. Ghettoblaster (talk) 16:08, 24 April 2008 (UTC)
Are you sure it does not work in IE7? It does work with IE7 emulation mode in IE8. Ghettoblaster (talk) 22:04, 24 April 2008 (UTC)
When editing, Ctrl+Tab inserted a literal tab character on IE6. The shortcut changed to switching between tabbed browsing windows in IE7 (and maybe IE8, who knows). --Btx40 (talk) 13:23, 25 April 2008 (UTC)
Oh, I see what you mean. I did not know about this feature. I thought you suggested using Tab as a graphical representation for the tab character in the code examples. Ghettoblaster (talk) 12:05, 28 April 2008 (UTC)
I'm not to crazy about using the colon. It looks bad. The keypress thing is okay I guess. Mike92591 (talk) 23:11, 26 April 2008 (UTC)
Ok, so everybody agree on using something like this then? Ghettoblaster (talk) 12:08, 28 April 2008 (UTC)
1 2

if condition:
Tabinstructions
«else:
Tabinstructions»

if ( condition ) { instructions } «else { instructions }»
I agree, it's good enough. Mike92591 (talk) 19:10, 29 April 2008 (UTC) Never mind, the gray looks horrible.Mike92591 (talk) 22:10, 29 April 2008 (UTC)

[edit] Common Lisp

I guess a functional language example was needed here. --Btx40 (talk) 18:32, 24 April 2008 (UTC)

CL is a littile confusing, could someone help out? --Btx40 (talk) 20:54, 24 April 2008 (UTC)

[edit] Unlimited precision in Python

A dip into the article was interesting, but one thing stood out for its absence. Python automatically and transparently converts an overflowing integer to an L integer, which has unlimited precision. This makes life easier for many programmers. But, I don't want ot derange the tables, so have kept free of the. They're fascinating and I don't want to gum them up. Perhaps someone who does table might make the necessary changes? ww (talk) 09:13, 29 May 2008 (UTC)


aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -