Het weglaten van accolades maakt iets wat in praktisch alle talen irrelevant is, whitespace, opeens wel relevant. Als je per ongeluk (bv omdat je op een andere pc werkt), een tab teken in plaats van 4 spaties oid gebruikt, dan is het indentation level niet meer gelijk en verslikt Python zich erin,
...en als je per ongeluk een accolade of een puntkomma vergeet in een taal als bijv. C krijg je ook een syntax error van de compiler.
of doet dingen die je niet verwacht.
Zoals?
Hetzelfde geldt waarschijnlijk ook (al heb ik dit niet getest) voor newline characters die op Windows \r\n moeten zijn en op Unix slechts \n. Als je dit mixt boeit het voor de compilers van andere talen helemaal niets, alle whitespace wordt geskipt. In Python kan dat dan weer onverwachte resultaten geven.
Python kan gewoon omgaan met een mix van LF en CR+LF.
(Ik gebruik hier expres niet \n, omdat de betekenis hiervan context-afhankelijk is. Zo is bijv. \n gedefinieerd als een newline in C, niet als linefeed.)Het weglaten van de puntkomma aan het einde van elk statement doet wederom hetzelfde; ik moet trucjes met line continuation characters doen om mijn statement over meerdere regels te splitsen om het leesbaar te houden.
Dan zijn je regels te lang. Daarnaast zijn er bepaalde constructies in Python die geen eens line continuation characters nodig hebben (namelijk de constructies die (), [] en {} gebruiken).
De mogelijkheid om strings te enclosen in dubbele of enkele aanhalingstekens maakt het minder overzichtelijk en resulteert in code die door meerdere personen geschreven wordt in gebrek aan consistentie.
Die mogelijkheid stelt je in mijn ogen juist in staat om overzichtelijkere code te schrijven aangezien je escaping in bepaalde gevallen kunt ontwijken. In het volgende voorbeeld hoef ik in Python niets te escapen: 'deze Python string bevat "quotes" die niet geëscapet hoeven te worden'.
In C++ geeft dit duidelijk het verschil tussen characters en strings aan.
En Python koos ervoor om geen chars te hebben. Guido vond dat je daarvoor strings ter lengte 1 kon gebruiken.
En waar zijn essentiele operators zoals ++ en -- in Python (zowel prefix als postfix)?
Die zijn niet essentieel. Als je in Python iets wilt verhogen, dan gebruik je +=1.
Waarom is de syntax van de ternary operator in Python zo ondoorzichtig en tegenintuitief?
Wat is er niet intuitief aan het volgende?
print x/y if y != 0 else 'Cannot divide'
(Lees het eens hardop voor)
Waarom moet in een taal, die claimt leesbaarheid van de code voorop te hebben staan, elseif of else if, vervangen worden door elif?
Je hebt dan zeker ook problemen met het kunnen lezen van #elif van de C preprocessor?
Waarom moet er een dubbele punt voor een block staan als de indentation al genoeg is?
Staat in de Python FAQ.
Dan hadden ze net zo goed accolades kunnen gebruiken, dan was het einde tenminste ook zichtbaar.
Je kan het einde toch zien als je een stuk code tegenkomt dat minder ver is ingesprongen?
Waarom is na 10 jaar van invoering, unicode nog steeds niet het standaard string type maar moet je er nog steeds een u voorzetten om je upper en lower functies goed te laten werken? Granted, dit is in C++ ook niet zo, maar dit zou juist een van de sterke punten van een nieuwe high-level programmeertaal moeten zijn.
Python 3Ook is de invloed die je hebt op wanneer variabelen en object gekopiëerd worden veel te beperkt in Python, tov C++ waarin je door middel van pointers dan wel references daar volledige controle over hebt en je dus nooit voor verassingen komt te staan.
Het model van Python is echter heel simpel. Alle variabelen verwijzen naar een object en alleen verwijzingen worden gekopieerd (bij assignment en function calls).
En dan is bijvoorbeeld al een functie copy om dictionaries in Python te kopieren, maakt die weer alleen een kopie van de dictionary zelf, maar de values blijven naar dezelfde dingen wijzigen zodat de kopie nog steeds niet onafhankelijk is van het origineel. Nee, dan moet je er weer een extra package bijhalen om een deepcopy te maken.
Als je deepcopy nodig hebt, dan denk ik dat je opnieuw naar je probleem of je programmeerstyle moet kijken. Probeer bijv. een oplossing te vinden die functioneler van aard is.
Zo kan ik nog wel even doorgaan, maar mijn punt is wel duidelijk denk ik. Dingen die C++ juist zo onzettend handig maken missen gewoon van Python. Over C# kan ik weinig zeggen, hier heb ik me nog nooit aan gewaagd.
Dingen die Python zo ontzettend handig maken mis ik daarentegen in C++.
Ik heb op zich niets tegen scripttalen of andere high-level talen, maar je hoort regelmatig dat ze de heilige graal van het programmeren zijn en daar ben ik het niet mee eens; het is heel erg een kwestie van smaak en ook van toepassingsgebied.
C++ heeft zeker een toepassingsgebied, maar dat gebied is lang niet meer zo groot als het vroeger was. De kracht van andere high level talen is juist dat je geen/minder rekening hoeft te houden met low level details waar je in bijv. C++ wel rekening mee moet houden.
Overigens kun je in C++ ook functies behandelen als variabele (zij het van type pointer).
Voor de introductie van lambda's waren functies in C++ nou niet echt bepaald first-class citizens. Hoe zou je de volgende Python functie implementeren in C++ zonder C++0x's lambda's?
compose = lambda f, g: lambda x: f(g(x))C++ doet echter wel garanties over de argumenten die deze variabele moet accepteren, terwijl Python dat niet doet.
Python is dan ook wat dynamischer ingesteld dan C++. C++ is meer gericht op het geven van statische garanties, terwijl Python flexibeler probeert te zijn door deze niet te geven. Het flexibelere aspect is niet geheel zonder gevaar, maar er zijn ook onveilige dingen in C++ te vinden (die niet in Python voorkomen) waarbij de compiler je ook geen statische garantie kan geven.
Tuples als return type zijn wel handig, maar in principe kan je daar in C++ net zo goed een vector oid voor gebruiken.
Tuples zijn hier in Python vooral handig i.c.m. unpacking. Zonder unpacking zou het minder aangenaam zijn geweest.
[Reactie gewijzigd door RayNbow op maandag 28 maart 2011 14:47]
...en als je per ongeluk een accolade of een puntkomma vergeet in een taal als bijv. C krijg je ook een syntax error van de compiler.
Correct. Maar het gebrek van de accolade kan je zelf zien. Het vervangen van tabs door spaties zie je niet en kan dus erg frustrerend werken.
Wat is er niet intuitief aan het volgende? print x/y if y != 0 else 'Cannot divide'
(Lees het eens hardop voor)
Intuitief zou het zijn als de juiste syntax was:
print x/y if y != 0 else print 'Cannot divide'
Zoals het moet in Python, is het krom Engels. Verder is het gebruiken van if als vorm van toekenning gewoon ontzettend raar voor iedereen die ooit heeft leren programmeren in een andere taal.
Op het moment dat je gewoon de ? operator gebruikt zal iemand die de constructie niet kent denken, goh, wat is dat, laat ik dat eens opzoeken. Bij het gebruik van if moet je tien keer opnieuw kijken wat er nu precies bedoeld wordt en opzoeken gaat je sowieso al niet lukken omdat de term 'if' in de context van programmeren dan nogal ambigu is.
Die zijn niet essentieel. Als je in Python iets wilt verhogen, dan gebruik je +=1.
En iets in deze trant dan?
size_t lines = 0;
while (file >> line)
cout << "Regel " << ++lines << ":" << line << endl;
In Python moet je dan voor het prefix ophogen van het regelnummer een apart statement gebruiken. Omslachtig.
Dan zijn je regels te lang. Daarnaast zijn er bepaalde constructies in Python die geen eens line continuation characters nodig hebben (namelijk de constructies die (), [] en {} gebruiken).
Het gebruik van een beetje descriptive variabele-namen dan al gauw 'te lange regels' op.
Je hebt dan zeker ook problemen met het kunnen lezen van #elif van de C preprocessor?
Die gebruik je toch aanzienlijk minder vaak dan de elseif if een gewone constructie. Als je veel preprocessor statements in je code gebruikt ben je wat mij betreft verkeerd aan het programmeren.
Je kan het einde toch zien als je een stuk code tegenkomt dat minder ver is ingesprongen?
Tenzij de regel ervoor ingesprongen is omdat het een vervolg is op de regel ervoor mbv een line continuation character. Daarvoor zijn de accolades dus handig.
Het model van Python is echter heel simpel. Alle variabelen verwijzen naar een object en alleen verwijzingen worden gekopieerd (bij assignment en function calls)
Het model is inderdaad heel simpel, dat is toch precies het probleem wat ik aankaart? In sommige situaties is het wel degelijk nuttig om kopieën van data te maken zonder dat expliciet met een statement te moeten doen. Neem bijvoorbeeld een implementatie van een minimax algoritme om de volgende set in een bordspel te bepalen. Om de bordsituaties te evalueren zul je een kopie van het bord moeten maken omdat je de uitgangssituatie niet kwijt wilt raken voordat er een beslissing genomen is.
Dingen die Python zo ontzettend handig maken mis ik daarentegen in C++.
Die dingen zijn er ook zeker. Maar da's nog geen reden om dan C++ maar af te schrijven.
Voor de introductie van lambda's waren functies in C++ nou niet echt bepaald first-class citizens. Hoe zou je de volgende Python functie implementeren in C++ zonder C++0x's lambda's?
We hebben het hier toch juist over een nieuwe norm van C++ die wel lambda's introduceert? ;-)
[Reactie gewijzigd door MadEgg op maandag 28 maart 2011 15:41]
Het vervangen van tabs door spaties zie je niet en kan dus erg frustrerend werken.
In elke fatsoenlijke editor / IDE krijg je een waarschuwing als je een mix gebruikt van tabs en spaces, en kan je met een simpele menu-functie of hotkey alles omzetten van tabs naar spaces of andersom.
En iets in deze trant dan?
size_t lines = 0;
while (file >> line)
cout << "Regel " << ++lines << ":" << line << endl;
(ervanuit gaande dat f een file object is:)
for i, line in enumerate(f.readlines()):
print 'Regel %d: %s' % (i + 1, line)
En ik vind het eigenlijk ook niet elegant om het uitlezen en het ophogen in 1 statement te combineren. Ik weet wel hoe het werkt, maar je moet toch altijd even nadenken. Heb dat ook heel vaak fout zien gaan bij beginnende programmeurs. En de ++ operator is al helemaal niet essentieel, aangezien je het nog altijd anders kan noteren of desnoods in meerdere statements. Ik merk daarnaast ook dat ik hem in Python zelden mis omdat for loops daar anders werken (op die plek gebruikte ik hem het meest in C/C++ e.d.).
[Reactie gewijzigd door Hiub op maandag 28 maart 2011 16:41]
Mensen,
Het is niet heel erg nuttig om op zulk een kleine schaal naar de verschillen tussen C++ en Python te kijken, aangezien dit meer op voorkeur en gewenning aankomt dan dat het echt een wezenlijk verschil is. Dat bepaalde low-level dingen in Python niet direct(!) kunnen, zegt weinig omdat het gebruik van die constructs nooit een doel op zich is.
Wat wél nuttig is, is kijken hoe lang het duurt voor je een werkend stuk code hebt, en hoeveel moeite het kost voor een ander om je code te begrijpen. En daar wint Python het gewoon met afstand van C++. Dat ligt aan de hoeveelheid syntaxfouten die gemaakt worden in C++, de omvang van de beschikbare bibliotheken in Python, de vrije coding style in C++, de omvang van de uiteindelijk code in verhouding tot de leesbaarheid ervan, noem maar op.
Als snelheid geen issue is, en het probleem niet in het bijzonder C++ of Python bevoordeelt, wil ik mijn had ervoor in het vuur steken dat een vaardige C++ programmeur het altijd aflegt tegen een vaardige Python-programmeur.
@HetMes:
Mits je het hier over project van enige omvang hebt en niet over een triviaal probleempje, ben ik overtuigd van het tegendeel. Een "hello world"-type applicatie heb je in Python inderdaad eerder voor elkaar.
Ik ben ervan overtuigd dat ik sneller een uitwerking in C++ voor elkaar heb dan een Python-guru in Python en dat de code ook nog minstens net zo goed leesbaar is (voor iemand die C++ kent natuurlijk). De resulterende binary zal ook nog eens sneller draaiden dan het Python-script.
Challenge accepted! Ben benieuwd...
Ik heb een Python generator functie waarmee je kunt itereren over alle permutaties van een string of lijst:
def permute(vector_a):
__if len(vector_a) == 1:
____yield vector_a
__else:
____for vector_b in permute(vector_a[1:]):
______for i in range(len(vector_b) + 1):
________yield vector_b[:i] + vector_a[0:1] + vector_b[i:]
En als dit nog onder 'triviaal' valt, waar gaat C++ dan de winst behalen?
[Reactie gewijzigd door HetMes op maandag 28 maart 2011 17:24]
Dit noem je een project van enige omvang? Ik dus niet. Je hebt het hier over een concept wat in C++ niet bestaat dus je kunt wel op je vingers natellen dat de C++ uitwerking iets langer wordt.
Ik bedoel dus niet een simpele functie, ik bedoel een programma wat daadwerkelijk iets nuttigs doet.
Nee, dus waar gaat C++ winst behalen? Als het niet op kleine schaal is, waar dan wel? We hebben al vastgesteld dat Python meer standaard-bibliotheken heeft, dat Python een krachtigere taal is door het onbreken van bepaalde concepten in C++, we hebben het nog niet eens over metaclasses, function inspection, function decorators, tuple unpacking gehad.
Sterkte met je C++.
Challenge accepted! Ben benieuwd...
Challenge accepted. In C++ heb je gewoon de functie std::next_permutation(), die de volgende permutatie geeft gegeven een iterator range.
Overigens is deze hele discussie nutteloos. Beide talen hebben hun voordelen en nadelen. Er zijn gebieden waar C++ veel geschikter is dan Python, en andersom.
Tuple unpacking kan overigens gewoon in C++ 2011.
[Reactie gewijzigd door .oisyn op dinsdag 29 maart 2011 01:11]
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
10:05
16:42
Door 
.![[show]](http://tweakimg.net/g/if/comments/button_down.png "Reactie uitklappen")
