Programmeer ergenissen top 10 :)

[.oisyn]

Op zaterdag 29 december 2001 16:43 schreef Thargol het volgende:

[..]

Talen die WEL casesensitive zijn nodigen uit tot onleesbare code. Ik heb diverse keren code gezien met variabelen x en X die dan inderdaad verschillende doen.

Ik persoonlijk vind de oplossing van VB wel aardig. De editor zet gewoon je code in de juiste case en je type het case-insensitive in. En ik kan je verblijden: in VB.net moeten variabelen gedeclareerd worden.

Dat zorgt dat je alleen maar consequent moet zijn! Je kunt in elke programmeertaal een zootje maken. Als jij x en X apart wil gebruiken moet jij dat weten, maar de leesbaarheid komt dat niet te goede. Als jij in een case-insensitive taal werkt en je gebruikt de ene keer x en de andere keer X ben je gewoon niet consequent bezig, wat alleen maar aangeeft dat je je hoofd er totaal niet bij hebt. Naar mijn idee moet je, of de taal nou casesensitive is of niet, altijd gewoon precies dezelfde variabelenamen gebruiken en consequent zijn in het hoofd/kleinletter gebruik ervan

De Visual Assist plugin voor VC++ 5.0 en 6.0 heeft trouwens ook een optie om de case automatisch goed te zetten

En in VB is er ook nog zoiets als Option Explicit (wat elke programmeur naar mijn idee gewoon aan het begin van z'n programma moet zetten)

[mbravenboer]

Hoofdlettergevoeligheid is geen enkel probleem als je gewoon netjes de conventies aanhoudt. In een taal met variabele declaraties is het sowieso al geen punt: de compiler zal bij een vergissing aan de bel trekken.

Ik ben er altijd een voorstander van om bepaalde coding standards ook vast te leggen in de taal: in Java bijvoorbeeld variabelen met een kleine letter beginnen, klasse-namen met een hoofd-letter en constanten in caps. Het zou (net als javadoc) best goed zijn als dit ook gewoon in de taal wordt afgedwongen.

Hoofdletterongevoeligheid is gewoon ranzig .

[.oisyn]

Ik ben er altijd een voorstander van om bepaalde coding standards ook vast te leggen in de taal: in Java bijvoorbeeld variabelen met een kleine letter beginnen, klasse-namen met een hoofd-letter en constanten in caps

Hier ben ik het niet mee eens, aangezien je dan de programmeurs een bepaalde stijl oplegt. Nou zou het natuurlijk wel fijn zijn als elke programmeur in de wereld dezelfde stijl aanhoudt (al dan niet gedwongen), maar das een fabeltje die denk ik nooit uit zal komen (misschien in het hiernamals van de programmeur )

Off the record: ik maak trouwens ook gebruik van die stijl

[mbravenboer]

OiSyN: Hier ben ik het niet mee eens, aangezien je dan de programmeurs een bepaalde stijl oplegt.

en daar ben ik het weer niet mee eens Ik had het ook nadrukkelijk alleen over variabele, methode en klasse-namen. Layout zoals newlines en tabs moet iedereen lekker zelf weten . De enige Java programmeurs die afwijken van de regels zijn echte beginners. Verder houdt iedereen zich aan deze naamgeving. Waarom dan niet vastleggen? Het zorgt voor beginners voor duidelijkheid en meer compiler-fouten, vooral dat laaste is natuurlijk prachtig .

Off the record: ik maak trouwens ook gebruik van die stijl

Juistum: wie niet? Je sluit gewoon niet goed aan op platform x als je andere naamgevingspatronen aanhoudt...

[^Mo^]

Op zaterdag 29 december 2001 17:36 schreef jhead22 het volgende:
* jhead22 heeft gewoon een bloed hekel aan programmeren.

Je bent uren bezig en vaak werkt t dan nog niet en als het werkt ben je uren bezig geweest om een klein flut progie te maken die al lang te downloaden was op t inet

Neen... doe mij maar Hardewaren, linux en andere electronica

Maar gellukig zijn er wel mensen die van programmeren houden... Die kunnen dan de progies maken zodat ik ze weer kan gebruiken

vind ik juist het leuke van programmeren... ben je een hele dag aan 't werk maar als het dan werkt .. is toch wel een lekker gevoel

[Verwijderd]

Ik heb case sensitiviteit in een programmeertaal nooit begrepen. Tuurlijk, initieel is het bedoeld om macro's als MAXLENGTH die ergens diep in een includefile zijn gedefinieerd, niet te laten clashen met een of andere gek zijn variabele maxlength.

Maar het schiet zn doel ver voorbij IMHO. Zeker in talen waar constants kunnen worden gedefinieerd. Ik ben een persoon die variabelen met prefixes en hoofd/kleine letters definieert, en in C++ maak ik soms nog wel eens een tikfout, door een hoofdletter te vergeten. Wat weer in een compile-error resulteert, kost alleen maar tijd.

Beter zou zijn de VB methode, die automatisch de case aanpast aan de gedefinieerde wijze. Zodoende krijg je minder compiler errors, kost het minder tijd en heb je meer tijd over voor dingen zoals testen.

(note: ik weet dat hier hele volksstammen witheet van woede over worden, neemt niet weg dat het voor 99.9999% van de projecten een overbodige 'feature' is, die alleen maar tijd kost).

[Verwijderd]

Op zaterdag 29 december 2001 17:57 schreef mbravenboer het volgende:
Hoofdlettergevoeligheid is geen enkel probleem als je gewoon netjes de conventies aanhoudt. In een taal met variabele declaraties is het sowieso al geen punt: de compiler zal bij een vergissing aan de bel trekken.

Wat tijd kost en dus geld. Om over de ergernis maar te zwijgen. Als alles compileert in 2 seconden is er niets aan de hand, maar soms duurt het even, krijg je een paar van die debiele errors, moet je de editor weer in, soms nog zoeken ook hoe je de variabele wel had gedefinieerd etc. En waarom? Waarom moet het case sensitive! Geef me 1 goed argument.

Ik ben er altijd een voorstander van om bepaalde coding standards ook vast te leggen in de taal: in Java bijvoorbeeld variabelen met een kleine letter beginnen, klasse-namen met een hoofd-letter en constanten in caps. Het zou (net als javadoc) best goed zijn als dit ook gewoon in de taal wordt afgedwongen.

Ik snap niet waarom een taal dit moet afdwingen. Ik gebruik hungarian coding, anderen vinden dat onzinnig, debiel, onleesbaar etc. Is veel voor te zeggen, voor die argumenten. Als een taal dat afdwingt kost het de mensen die er bezwaren tegen hebben, moeite om met die taal te werken. Ik vind het onzinnig om zonder hungarian coding programmatuur te schrijven. Doordat het NIET wordt afgedwongen door de taal heb je die vrijheid, sterker je kunt dat per project aan de deelnemers' voorkeuren afstemmen. Lijkt me wat pragmatischer.

Hoofdletterongevoeligheid is gewoon ranzig .

En waarom is dat? Ik vind persoonlijk het kleine letter gedoen bij java classes niet mooi, maar dat zal gewenning zijn.

Als ik intik:
int m_iCurrentPolygonID;

en ik geef op een gegeven moment in mn code in:
iID = m_iCurrentPolygoniD;

Dan is dat een error. Bedoel ik een andere variable? nee, want die is nergens gedefinieerd. Die compiler is dus spartaans bezig als hij daarover over de zeik gaat. De editor had hier (op zn VB's) die iD in ID moeten veranderen. Scheelt een error, ergernis en tijd. Maar jij mag dat fijn vinden hoor Ieder zn kicks

[mbravenboer]

Otis had een andere mening

Op zich zit er wel wat in (en nee ik ben niet woedend ) maar toch vind ik het aanzetten tot onduidelijkheid, inconsequentie en rommelige code.

Ik heb werkelijk nooit compiler-meldingen die het gevolg zijn van verkeerd hoofdletter-gebruik en het argument dat het onnodig veel tijd kost is daarom denk ik een klein beetje overdreven .

[chem]

sow, dit is wel een apart topic geworden zeg...

je ziet duidelijk wie zich 'professioneel' en 'amateuristisch' met programmeren bezighouden

(met stip op nummer 1: "Wat boeit dat nou weer, het WERKT!")

Een kansloze "PHP vs. Java" discussie is altijd leuk vooral omdat mensen bv. 100,000 keer "echo 'hello world'; " met "System.println('hello world');" gaan vergelijken... ff kort door de bocht: PHP heb je snel in elkaar geflanst, Java biedt meer lange termijn mogelijkheden...

[mbravenboer]

Otis: Wat tijd kost en dus geld. Om over de ergernis maar te zwijgen. Als alles compileert in 2 seconden is er niets aan de hand, maar soms duurt het even, krijg je een paar van die debiele errors, moet je de editor weer in, soms nog zoeken ook hoe je de variabele wel had gedefinieerd etc. En waarom? Waarom moet het case sensitive! Geef me 1 goed argument.

Ach komop, ik vind dat je nu toch wel een beetje overdrijft. Consequente naamgeving is gewoon een goede gewoonte zodat je niet bij het minste of geringste in de API documentatie hoeft te duiken (dat kost ook veel tijd). Ook consequent gebruik van hoofd en kleine letters dragen bij aan deze duidelijkheid. Je maakt mij niet wijs dat je je zo vaak vergist in hoofdletter-gebruik dat je dit serieus tijd gaat kosten. Code waarin variabelen die overal op dezelfde manier worden gebruikt leest prettiger en is duidelijker.

Je kunt bovendien nog aardige conflicten krijgen tussen variabelen die je wel anders bedoeld hebt: bijvoorbeeld met volledig in caps en volledig in lower-case.

Ik snap niet waarom een taal dit moet afdwingen.

Duidelijkheid, consequentie aanleren. Dit scheelt een hoop gezoek in API documentatie (vooral in een case-sensitive taal ).

Als ik intik:
int m_iCurrentPolygonID;

en ik geef op een gegeven moment in mn code in:
iID = m_iCurrentPolygoniD;

Dan is dat een error. Bedoel ik een andere variable? nee, want die is nergens gedefinieerd.

Zodra je een compiler de vrijheid geeft om maar een beetje te gaan zitten uitvogelen wat jij bedoelt, is het hek volledig van de dam. Volgende stappen zijn weglaten van scheidingstekens tussen statements, variabelen maar gewoon niet declareren enzovoorts. Ik vind persoonlijk dat er gewoon duidelijkheid moet zijn en die is er hier niet. Dit is gewoon een kwestie van smaak .

Ieder zn kicks

[^Mo^]

Op zaterdag 29 december 2001 18:17 schreef Otis het volgende:
Beter zou zijn de VB methode, die automatisch de case aanpast aan de gedefinieerde wijze. Zodoende krijg je minder compiler errors, kost het minder tijd en heb je meer tijd over voor dingen zoals testen.

dit is meer een IDE setting lijkt mij.. als je in VB een variable A hebt en je roept a aan (als de IDE dit al toelaat.. volgens mij niet), dan doet ie het ook niet.
Als je Visual Assist gebruikt i.c.m. VC++ dan maakt zet ie ook automatisch je hoofdletters goed (tenzij je natuurlijk x en X constructies gebruikt.. maar dat lijkt me niet zo handig). Kijk, als alles incase sensitive zou zijn, dan is x en X hetzelfde, maar door de compiler wel case-sensitive te maken verplaats je de verantwoordelijkheid naar de programmeur... 'tis een beetje soort van java vs. C+ verhaal ... als je in java een nieuw object maakt (dus met "new") hoef je je niet meer druk te maken over opruimen van de pointer... met C++ is dit dus niet en dat vindt ikzelf persoonlijk prettiger, zo heb je meer verantwoordelijkheid/controle over je eigen code.. 'tis wel foutgevoeliger

[.oisyn]

Op zaterdag 29 december 2001 18:35 schreef mbravenboer het volgende:
Zodra je een compiler de vrijheid geeft om maar een beetje te gaan zitten uitvogelen wat jij bedoelt, is het hek volledig van de dam. Volgende stappen zijn weglaten van scheidingstekens tussen statements, variabelen maar gewoon niet declareren enzovoorts.

Juist! Je ziet het bijvoorbeeld met microsoft's Internet Explorer. Die browser pikt gewoon alles, of je er nou "" omheen zet of niet. Volgende stap is dat mensen minder gaan opletten of het wel klopt. En waarom zouden ze ook? De browser pikt het toch wel... Andere browsers alleen niet, wat zorgt voor incompatible websites, omdat die mensen het gewoon niet goed aanleren.

Fouten zijn menselijk, maar dat is ook de plaats waar ze moeten worden opgelost: bij de mens zelf, en dus niet de computer die jouw code moet interpreteren. Dus zolang er nog geen neurale interfaces bestaan moet elke fout hardhandig worden afgestraft

[elnino]

Op zaterdag 29 december 2001 18:31 schreef chem het volgende:
ff kort door de bocht: PHP heb je snel in elkaar geflanst, Java biedt meer lange termijn mogelijkheden...

En daarom is PHP ook zo populair voor webpagina's, het is makkelijk, heeft geen goede OO-support, programmeren gaat snel, veel mag, declareren hoeft niet, oftewel ideaal voor beginners.

Nee, maar ff serieus, voor kleine websites zonder al te geavanceerde mogelijkheden is PHP goed. Als je geen ingewikkelde zaken wilt met XML enzo, is PHP goed.

En ik denk dat het meerendeel van de gebruikers PHP toch alleen maar als een datebase-systeempje gebruikt, waar je toevallig ook nog plaatjes mee kunt inkleuren.

Java biedt daarentegen goede OO-support (Java == OO), biedt geloof ik ook goede XML-parsers, etc. etc.

Ik wil hiermee zeggen dat PHP voor de meeste websites gewoon het beste is, en Java weer beter voor de iets complexere websites.

[mbravenboer]

elnino: Java biedt daarentegen goede OO-support (Java == OO), biedt geloof ik ook goede XML-parsers, etc. etc.

De beste en vaak de eerste .

1. Al heel vroeg was er een goede XML parser library met ondersteuning voor DOM en SAX methoden en de mogelijkheid om parser implementaties in te pluggen.
2. Apache's Xerces ondersteunt XML Schema's
3. Apache's Xalan is een uitstekende XSL Transformatie engine.
4. Apache's FOP was de eerste XSL-Formatting Objects implementatie
5. Apache's Batik was de een van de eerste SVG libraries/viewers.
6. Goede alternatieve DOM implementaties zoals JDOM
7. Uitstekende XPath libraries zoals Jaxen die zelfs werkt over verschillende DOM implementaties en ook op andere data-structuren kan werken.
8. Apache heeft al tijden een aardige SOAP implementatie.
9. Binnen het Java community process wordt er volop gewerkt aan specificaties voor libs tbv web-services, XML-RPC
10. XML-data binding is extreem makkelijk met JAXB
11. Java Beans zijn sinds 1.4.0 zeer goed te serializeren naar XML.

Java is erg goed in het oppakken van nieuwe systemen en slecht in het volledig herimplementeren van al bestaande technieken...

[ronaldmathies]

Op zaterdag 29 december 2001 23:31 schreef mbravenboer het volgende:

[..]

De beste en vaak de eerste .

1. Al heel vroeg was er een goede XML parser library met ondersteuning voor DOM en SAX methoden en de mogelijkheid om parser implementaties in te pluggen.
2. Apache's Xerces ondersteunt XML Schema's
3. Apache's Xalan is een uitstekende XSL Transformatie engine.
4. Apache's FOP was de eerste XSL-Formatting Objects implementatie
5. Apache's Batik was de een van de eerste SVG libraries/viewers.
6. Goede alternatieve DOM implementaties zoals JDOM
7. Uitstekende XPath libraries zoals Jaxen die zelfs werkt over verschillende DOM implementaties en ook op andere data-structuren kan werken.
8. Apache heeft al tijden is er een aardige SOAP implementatie.
9. Binnen het Java community process wordt er volop gewerkt aan specificaties voor libs tbv web-services, XML-RPC
10. XML-data binding is extreem makkelijk met JAXB
11. Java Beans zijn sinds 1.4.0 zeer goed te serializeren naar XML.

Java is erg goed in het oppakken van nieuwe systemen en slecht in het volledig herimplementeren van al bestaande technieken...

Kijk dat is wat ik nou ook zo leuk vind aan Java, als er een bepaalde techniek op de markt komt dan is het negen van de tien keer als eerste beschikbaar voor Java. Dat zie zag je heel erg met XML, Bleutooth ondersteuning, WAP ondersteuning en nog veel meer. Dat soort dingen worden in talen als PHP en VB pas veel later ondersteund, puur omdat de ontwikkel omgeving hiervoor aangepast moet worden (dit geld overigens niet voor PHP), bij Java is het zo dat de IDE gescheiden is van de core classes. Dit biet erg veel perspectief, in tegen stelling tot bijvoorbeeld VB. Waarom PHP dat soort onderdelen pas zolaat erna ondersteund weet ik niet, mischien omdat het onwikkelteam wat erachter zit veel kleiner is. (Het team dat PHP zelf ontwikkeld)

[Servowire]

source code waar men irritante variablen gebruikt

code:

int henk = 3;
int bier = 2;
int schaar =3;

int main(){
  schaar=henk-bier;
  return 0;
         }

Voorbeeld waar ik me aan erger

[.oisyn]

Op zaterdag 29 december 2001 23:48 schreef Servowire het volgende:
source code waar men irritante variablen gebruikt

code:

int henk = 3;
int bier = 2;
int schaar =3;

int main(){
  schaar=henk-bier;
  return 0;
         }

Voorbeeld waar ik me aan erger

ik irriteer me daar meer aan de oerlelijke code-stijl dan aan de variabelenamen (geen spaties tussen operatoren, accolade-openen bij functie op dezelfde regel, accolade sluiten op een hele vage plek, ...)

[elnino]

Op zaterdag 29 december 2001 23:31 schreef mbravenboer het volgende:

1. Al heel vroeg was er een goede XML parser library met ondersteuning voor DOM en SAX methoden en de mogelijkheid om parser implementaties in te pluggen.
2. Apache's Xerces ondersteunt XML Schema's
3. Apache's Xalan is een uitstekende XSL Transformatie engine.
4. Apache's FOP was de eerste XSL-Formatting Objects implementatie
5. Apache's Batik was de een van de eerste SVG libraries/viewers.
6. Goede alternatieve DOM implementaties zoals JDOM
7. Uitstekende XPath libraries zoals Jaxen die zelfs werkt over verschillende DOM implementaties en ook op andere data-structuren kan werken.
8. Apache heeft al tijden een aardige SOAP implementatie.
9. Binnen het Java community process wordt er volop gewerkt aan specificaties voor libs tbv web-services, XML-RPC
10. XML-data binding is extreem makkelijk met JAXB
11. Java Beans zijn sinds 1.4.0 zeer goed te serializeren naar XML.

Java is erg goed in het oppakken van nieuwe systemen en slecht in het volledig herimplementeren van al bestaande technieken...

Ik ben zelf geen goede Java-kenner, maar wat mij altijd zo opvalt is die benamingen van Java-technieken, J2EE, Swing, NetBeans etc (zie ook de quote). Die klinken allemaal zo 'commercieel'... een beetje Microsoft die met haar laatste Smart-tags en het .NET-passport-framework.

Dat wil overigens niet zeggen dat ik anti-Java ben, ik heb helemaal geen ervaring met Java, en zou de taal best willen leren, maar door die bomen zie ik soms het bos niet meer...

Disclaimer: Dus hierbij de 'no flame intended', javahova's...

[.oisyn]

uhm... doe jij dan eens een suggestie wat niet commercieel klinkt? Volgens mij klinkt alles wel commercieel...

(PS. ik ben bezig met een 3d engine genaamd Vertigo. Klinkt dat commercieel? )

[WoutF]

Dat compilers soms zulke algemene foutmeldingen geven. Iets gespecificeerder mag soms wel

[GiLuX]

reactie op mijn kansloze java/php/oo verhaal,
het is gebaseerd op hoe ik het j2ee verhaal geleerd heb: together/tomcat/jboss/ant/struts.

ik ben nog vere van guru op dit gebied, en er zal vast wel een andere manier zijn om MVC in java te bereiken maar op deze manier is het allerlei 'xml' files doorspitten om iets aan te passen.

een paar misvatting die zijn ontstaan,
ik noemde het xml files terwijl ze dat idd niet allemaal zijn (ant build files, struts config files, tomcat/jboss xml files).

met java bedoelde ik j2ee, omdat ik eigenlijk direct met j2ee aan de slag ben gegaan en java daarom ook op die manier bekijk.

wat mij een beetje irriteerd is dat er naar mijn idee best veel mensen roepen dat java helamaal "da bomb" is en dan ook vinden dat je meteen maar ook elke site in java moet gaan bouwen ongeacht de omvang of gewenste functionaliteiten omdat java superieur is.

nogmaals,
als je een mega project doet, doe het dan in java/j2ee en zorg dat je goede documentatie schrijft zodat je na een jaar nog steeds begrijpt hoe het in elkaar steekt.
als je niet een mega project doet doe het dan in php,
php is specifiek ontworpen en gestroomlijnd om sites mee te bouwen.

ik zie het zo:
java is een enorme tank waar je onwijs veel mee kunt,
dwars door een oerwoud mee jakkeren als je dat wil,
hij is alleen vrij moeilijk te besturen en moet minimaal een kwartier warm lopen
bestuurders liggen niet voor het oprapen en java is vrij zwaar voor het wegdek.
(ik heb wel gehoord dat er hard aan een sport stuurtje word gewerkt)

php is een dikke bmw uit de 7 serie, uitgerust met alle accesoires die een een auto liefhebber zich maar kan wensen.
ook de wegliggen is errug soepel en je kan het stuur bwvs met je pink bedienen.
je rijbewijs halen voor php is vrij eenvoudig.
daarintegen is php niet zo goed om door het oerwoud mee te jakkeren, al heeft php wel een mooie chrome 'pushbar'

maar omdat er over het algemeen meer asfalt ligt dan oerwoud kies ik dus in de meeste gevallen voor de bmw.

asp/vb loopt ook als een trein, maar dat is dan ook meteen het probleem, als er geen spoor ligt houd het verhaal op (rijd alleen op op MS certified tracks (ja, ik ken chilisoft railways)).

[.oisyn]

leuk verhaaltje maar ik zou wel eens willen zien hoe jij met een tank door het oerwoud baggert...

lukt niet echt naar mijn idee, met een tank rij je namelijk niet zomaar tropisch hardhout uit de grond

[Verwijderd]

Ik erger me vooral aan het feit dat programmeurs altijd denken gelijk te hebben

[.oisyn]

Op zondag 30 december 2001 00:58 schreef MrX het volgende:
Ik erger me vooral aan het feit dat programmeurs altijd denken gelijk te hebben

heb je er wel eens bij stil gestaan dat ze daadwerkelijk ook altijd gewoon gelijk hebben?

[The - DDD]

Op vrijdag 28 december 2001 23:22 schreef GiLuX het volgende:

..
en php is altijd toch nog een stuk sneller dan java...
dus waar is de snelheidswinst voor java?
...

Zulke uitspraken doe je niet zonder bewijs te leveren. Dus kom maar op.

[The - DDD]

Op zaterdag 29 december 2001 12:48 schreef ACM het volgende:

[..]

Die (zoals ik uit hun eigen voorbeelden haal) erg situatie specifiek zijn...

Die plekjes waar ik threads gebruik heb ik geen zin om er ook nog es over na te moeten denken dat ze eventueel kunnen deadlocken als ik een methode van de Thread-class aanroep... Laat Sun dan een betere implementatie maken van zoiets (die voorbeelden kunnen ze zelf dan toch implementeren )

Magoed, dat is dus precies wat ik bedoel
Er is iets, het wordt weggehaald en dan is het ineens minder makkelijk, of moet je het ineens zelf oplossen...

Heb jij enig idee waarom een multi threaded applicatie erg vaak geheugenlek is als een mandje? Omdat een oetlul van een programmeur te lui was om zijn zaakjes goed te regelen.

Multithreading is een heel krachtig middel, maar zoals met alle krachtige zaken moet je er voorzichtig mee omgaan.

Mijn grootste irritatie, andermans code moeten gaan debuggen omdat ze zelf niet door hebben dat ze iets fout doen.

[The - DDD]

Op zaterdag 29 december 2001 15:21 schreef MarcKonings het volgende:

[..]

Helemaal mee eens. Zelf ben ik een "veteraan" programmeur (20 jaar in het vak) en ik heb dus in het verleden efficient MOETEN ontwikkelen, omdat programma's anders gewoon niet liepen (of pasten in het geheugen ). Dit soort kennis heeft ook vandaag nog zijn voordelen.

De "programmeurs" van tegenwoordig klikken met VB wat in elkaar en denken dan alles ervan te weten. Efficient programmeren lijkt niet meer nodig te zijn door de hardwarespecs van tegenwoordig en velen denken dat daardoor ook gestructureerd programmeren niet meer nodig is.

Goed programmeren is een kunst, een gave, die niet iedereen heeft. Van mooie, efficiente algoritmes kan ik kippenvel krijgen. Maar het is een kunst die verloren gaat in de Visual Wereld van vandaag.

Heej, embedded systems. Moet je daar is mee bezig gaan. Wordt je midden in de nacht ook wel is gillend wakker om snel op te schrijven hoe je toch net wel je code in die (altijd te kleine) geheugenchip kan passen. 't Is soms best frustrerend, maar als het dan toch lukt.

[The - DDD]

Op zaterdag 29 december 2001 18:27 schreef mbravenboer het volgende:

[..]

Op zich zit er wel wat in (en nee ik ben niet woedend ) maar toch vind ik het aanzetten tot onduidelijkheid, inconsequentie en rommelige code.

Ik heb werkelijk nooit compiler-meldingen die het gevolg zijn van verkeerd hoofdletter-gebruik en het argument dat het onnodig veel tijd kost is daarom denk ik een klein beetje overdreven .

In Java gebruik ik hongaars... Vind het lekker werken, je kan behoorlijk snel zien aan de var waar je het over hebt. Nadeel, als je een type wijzigd. Maar dat is bekend.

[Verwijderd]

Op zondag 30 december 2001 01:10 schreef OiSyN het volgende:

[..]

heb je er wel eens bij stil gestaan dat ze daadwerkelijk ook altijd gewoon gelijk hebben?

/me lol
Ik zal je eens aan mijn werkgever en opdrachtgever voorstellen, een hoop dat jij dat aan hen kunt overbrengen

[The - DDD]

Op zaterdag 29 december 2001 19:13 schreef OiSyN het volgende:

[..]

Juist! Je ziet het bijvoorbeeld met microsoft's Internet Explorer. Die browser pikt gewoon alles, of je er nou "" omheen zet of niet. Volgende stap is dat mensen minder gaan opletten of het wel klopt. En waarom zouden ze ook? De browser pikt het toch wel... Andere browsers alleen niet, wat zorgt voor incompatible websites, omdat die mensen het gewoon niet goed aanleren.

Fouten zijn menselijk, maar dat is ook de plaats waar ze moeten worden opgelost: bij de mens zelf, en dus niet de computer die jouw code moet interpreteren. Dus zolang er nog geen neurale interfaces bestaan moet elke fout hardhandig worden afgestraft

Moet je voor de gein Visual Studio geinstalleerd hebben en dan met dat systeem gaan surfen. Je wordt ziek van de meldingen dat er iets niet klopt aan een string (meestal niet goed afgesloten). Als je IE door laat gaan, dan werkt het perfect, start je de debugger dan is het altij een " die vergeten is.

[Verwijderd]

Ik heb er maar 2:

1 - Vergeten te saven, programma crashed....alles aanpassingen weg|
2 - (en dit overkwam me dus vorige week) VIRUS!
Geen backups gemaakt van 2 van mijn nieuwste programma's.... ongeveer 20000 regels aan sourcecode weg

[The - DDD]

Op zondag 30 december 2001 00:23 schreef elnino het volgende:

[..]

Ik ben zelf geen goede Java-kenner, maar wat mij altijd zo opvalt is die benamingen van Java-technieken, J2EE, Swing, NetBeans etc (zie ook de quote). Die klinken allemaal zo 'commercieel'... een beetje Microsoft die met haar laatste Smart-tags en het .NET-passport-framework.

Dat wil overigens niet zeggen dat ik anti-Java ben, ik heb helemaal geen ervaring met Java, en zou de taal best willen leren, maar door die bomen zie ik soms het bos niet meer...

Disclaimer: Dus hierbij de 'no flame intended', javahova's...

Mag ik je erop wijzen dat van de genoemde zaken alleen Swing copyrighted is, maar de source is grotendeels wel beschikbaar. Netbeans is een GPL project (Sun brengt op basis van netbeans wel Forte for Java uit). J2EE is een open standaard dat door bedrijven geimplementeerd kan worden. Het proof of concept van het geheel is in source code te verkrijgen van de sun site (J2EE server die bij de api geleverd wordt). (IBM Websphere is 1 van de vele gecertificeerde J2EE systemen).

Verder durf ik te wedden dat van al de genoemde termen die je bold hebt gezet het merendeel opensource is.

Sun is commercieel, maar wel met een heel andere insteek dan Microsoft.

Je wil de taal leren? Begin bij het begin en leer wat jou interresant lijkt, bepaalde java technieken zul je waarschijnlijk nooit nodig hebben. Terwijl je andere gebieden wel veel nodig zult hebben. Bijvoorbeeld JNI voor een JSP developer? (JNI = Java Native Interface, JSP = Java Server Pages).

[mOrPhie]

Oplossingen:

Op zondag 30 december 2001 01:45 schreef anauta het volgende:
Ik heb er maar 2:

1 - Vergeten te saven, programma crashed....alles aanpassingen weg|

Bij elke regel die je typt even saven met de sneltoets. Bijvoorbeeld ctrl+s

2 - (en dit overkwam me dus vorige week) VIRUS!
Geen backups gemaakt van 2 van mijn nieuwste programma's.... ongeveer 20000 regels aan sourcecode weg

Een sourcedatabase-programma gebruiken, zoals Visual Sourcesafe.


Ik wil geen beter-weter zijn hoor, begrijp me niet verkeerd, maar deze aanpassinkjes hebben mij al heeeeel vaak uit de brand geholpen.

Mijn ergernissen:

1.
ASP heeft nog wel 'ns de neiging (vooral als je met includes werkt) in plaats van een goeie error gewoon neer te zetten: "500 Server error". Soms komt het er gewoon op neer dat je een verkeerde objectnaam gebruikte of zow. En soms geeft ie dat aan, en soms die rare melding dus.

2.
Meestal zijn arrays of objecteigenschappen zero-based. Maar sommige third-party objecteigenschappen zijn niet zero-based, maar beginnen bij 1. Dit is erg verwarrend als je bijvoorbeeld gewend bent met zero-based arrays te werken. Dan moet je steeds -1 je variabele doen bij wijze van. Ze zouden "zero-based" verplicht moeten stellen (ik geloof dat dit ook gaat gebeuren in de .NET programmeertalen)

3.
Je download ergens C++ code vandaan om is lekker doorheen te struinen en dingen van te leren misschien. Je wilt em compileren en wat blijkt: je mist een includefile. Vervolgens is het includefile nergens op mijn harde schijf of op het internet te bekennen.

4.
Je maakt iets en het werkt. Je test alles. Je onderzoekt of er bugs op kunnen treden en debugd waar nodig. Je installeerd het bij iemand anders, eerste de beste knop die de testpersoon op klikt veroorzaakt een fout of erger, een crash.

Nou, dat was het wel zo'n beetje. Ik heb er nog meer, maar niet relevant genoeg

[mbravenboer]

elnino: wat mij altijd zo opvalt is die benamingen van Java-technieken, J2EE, Swing, NetBeans etc (zie ook de quote). Die klinken allemaal zo 'commercieel'... een beetje Microsoft die met haar laatste Smart-tags en het .NET-passport-framework.

Tja, je moet toch een naam verzinnen . Swing vind persoonlijk wel leuk gevonden. Xerces, Xalan, Jaxen en Batik zijn gewoon namen van producten die volgens mij geen acroniem voorstellen. SOAP, DOM, SVG, XPath, XML-RPC zijn vindingen van het W3C. SAX is een industrie-standaard die ook niet specifiek voor Java is. JAXB en Java Beans zijn eigenlijk de enige termen die overblijven . JAXB bekt een stuk beter dan Java Architecture for XML Binding.

Dat wil overigens niet zeggen dat ik anti-Java ben, ik heb helemaal geen ervaring met Java, en zou de taal best willen leren, maar door die bomen zie ik soms het bos niet meer...

Tja, dat is meer een probleem van de hele branche en zeker van het W3C met XML en alle gerelateerde standaarden.

Disclaimer: Dus hierbij de 'no flame intended', javahova's...

Men denkt zich tegenwoordig wel in .

[mbravenboer]

GiLuX: met java bedoelde ik j2ee, omdat ik eigenlijk direct met j2ee aan de slag ben gegaan en java daarom ook op die manier bekijk.

Dat is naar mijn mening ook helemaal de verkeerde aanpak . Als je in een opleiding leert om gebouwen te bouwen begin je niet gelijk aan wolken-krabbers in New York, maar met kleinere constructies (hoop ik ). Bij Java is het precies hetzelfde: 'gewone' Java is basis-kennis voor J2EE. Als je dat niet volledig beheert raak je volledig de weg kwijt en snap je helemaal nergens meer iets van. Hetzelfde geldt voor XML en gerelateerde technieken: mensen beginnen op de verkeerde punten en snappen vaak niet goed waar ze mee bezig zijn. Het meeste commentaar en frustraties over systemen onstaat naar mijn mening omdat ze dus niet weten waar ze mee bezig zijn... .

wat mij een beetje irriteerd is dat er naar mijn idee best veel mensen roepen dat java helamaal "da bomb" is en dan ook vinden dat je meteen maar ook elke site in java moet gaan bouwen ongeacht de omvang of gewenste functionaliteiten omdat java superieur is.

Als je Java beheerst is er ook meestal geen enkele reden om niet Java te gebruiken. Als je Java niet beheerst heb je een probleem: de leer-curve. Wat ik weer fundamenteel fout vind is het aanbevelen van oplossingen als PHP voor elk mogelijk probleem. Mensen hebben teveel de neiging om de technieken die ze zelf al beheersen overal op los te laten. Andere technieken lijken vaak lastiger, maar dat komt vaak alleen maar omdat je daar minder kennis van hebt.

php is een dikke bmw uit de 7 serie, uitgerust met alle accesoires die een een auto liefhebber zich maar kan wensen.

. Grappige vergelijking. 'Alle accesoires die je je maar kan wensen' vind ik nogal zeer overdreven . Je uitkijken met het afspiegelen van jouw situatie op de situatie van anderen .

[Excrusiator]

Een dingetje wat ik irritant vindt in php is dat als je bijvoorbeeld 3 aparte php scripts (dus 3x <? ?>) in een php bestand hebt staan (met html layout er tussen) en je gebruikt in de middelste script een if, else, else if case'je met een exit de exit ook geldt voor het derde script als die exit wordt uitgevoerd.

Nu gebruik ik gewoon een lege else aan het einde van mijn case maar de eerste keer dat ik dit tegenkwam heb ik ff zitten te kijken wat er precies fout ging.

[elnino]

Op zondag 30 december 2001 00:30 schreef OiSyN het volgende:
uhm... doe jij dan eens een suggestie wat niet commercieel klinkt? Volgens mij klinkt alles wel commercieel...

Commercieel is hier misschien een beetje verkeerd woord, maar wat ik ermee bedoel, is dat al die verschillende termen voor beginners erg lastig is. Het heeft dan vooral te maken met die XML-gerelateerde standaarden, waar ik mezelf nog wel eens van af vraag waarom het nodig is (maar ik heb daar te weinig kennis van om daarover te kunnen oordelen).

(PS. ik ben bezig met een 3d engine genaamd Vertigo. Klinkt dat commercieel? )

Ja, dat klinkt wel commercieel (nu tevreden? )

Op zondag 30 december 2001 01:52 schreef The - DDD het volgende:
Verder durf ik te wedden dat van al de genoemde termen die je bold hebt gezet het merendeel opensource is.

Je wil de taal leren? Begin bij het begin en leer wat jou interresant lijkt, bepaalde java technieken zul je waarschijnlijk nooit nodig hebben. Terwijl je andere gebieden wel veel nodig zult hebben. Bijvoorbeeld JNI voor een JSP developer? (JNI = Java Native Interface, JSP = Java Server Pages).

Net zoals ik hierboven zei, commercieel is misschien het verkeerde woord. Trouwens, bedankt voor de tip.

[The - DDD]

Mijn grootste programmeer ergenis is nog altijd andermans code moeten debuggen. Je krijgt iets aangeleverd van iemand en vervolgens blijkt het wel te werken, maar als je even wat verder test, dan blijkt het zo geheugenlek als een demente bejaarde.

Vooral met C-type strings word veel aangekloot. Mij is aangeleerd dat je zoveel mogelijk je waarden in dezelfde scope weer moet vernietigen.

Dus je maakt een string, je gebruikt hem in een aanroep, en je vernietigd de string weer. Hoe vaak ik niet zie dat bij strings slechts de pointer wordt gecopieerd. Het is goede stijl om de string direct te kopieren naar een string met lokale scope. Zodoende voorkom je dat je string pointer gaat hangen als buiten die functie/class de string vernietigd wordt.

Of met STL vectoren. Wat voor eikel acties daarmee uitgehaald kunnen worden. Heb een keer gezien dat iemand de index ten opzichte van de vector opsloeg in de classes die in de vector stond. Werkt zeker heel snel en effectief. Maar je MOET GVD. WEL DIE INDEX UPDATEN BIJ EEN INSERT OF DELETE!! Anders vliegen de access violations je om de oren (onder win32 dan).

[Verwijderd]

Mijn grootste ergenis.. sinds ik webmaster was van phpfreakz staan er allemaal van die newbies in m'n icq lijst (no offense), en dan krijg je dit soort shit:

"hey hoe maak ik dit?"
moet je even daar kijken
"dat begrijp ik niet! kun je niet een voorbeeldje geven"
wat voor voorbeeld?
"nou ongeveer precies wat ik wilde hebben"

dat is gewoon zwaar irritant..

Om even door te gaan met de java discussie. Ik heb een tijdje geprogrammeerd in Java, en heb hier een stuk of 4 boeken liggen. Ik vond de taal in het begin heel moeilijk door al dat OOP e.d. maar merk nu ik met Delphi en PHP bezig ben dat het me wel heel erg heeft geholpen om dingen te begrijpen en secuur te zijn.

Ik ben er overigens niet mee door gegaan omdat het gewoon te langzaam was voor wat ik ermee wilde. Toen ik een java versie van Notepad schreef bij wijze van oefening duurde het al 2/3 seconden voordat het was opgestart, laat staan toen ik probeerde een e-mail programma in Swing te maken.

Het kan aan mijn PC liggen of het is allemaal verbeterd, maar de snelheid deed mij toch kiezen voor Delphi.

edit:
/me kan overigens ook niet tegen dingen zoals beschreven in sig

[mbravenboer]

YaZe: Het kan aan mijn PC liggen of het is allemaal verbeterd, maar de snelheid deed mij toch kiezen voor Delphi.

Laat ik het zo zeggen: ik gebruik tegenwoordig ook zelf Java programma's .

De herrinnering van 1.0 en 1.1 is het grootste probleem van Java.

Lees dit stukje bijvoorbeeld eens in de EETimes:
http://www.eetimes.com/story/OEG20011221S0026

Once seen as a performance dog, Java has turned into a fleet greyhound that's fast overtaking the factory floor.

Beetje overdreven, maar goed .

[curry684]

Op vrijdag 28 december 2001 22:34 schreef SPee het volgende:
Ook het verschil tussen de . en -> in c++ is vervelend. En al de dingen die ik nog niet weet en waar ik mee moet werken kunnen irritant gaan worden.

Wacht maar totdat je een smartpointer systeem hebt waarbij je de . gebruikt om de functies van de pointer te bereiken en de -> (logischerwijs) om het referred object aan te spreken.

Ennuh volgend op al het geemmer over de puntkomma bij C++ code die de compiler zelf zou moeten invoegen: NEEEEE!!!

Waarom denk je dat dat ding er is? Omdat ie overbodig is? Vergelijk de volgende 3 stukken code:

code:

while(array[i++]);
result += i;
result *= 2;

code:

while(array[i++])
result += i;
result *= 2;

code:

while(array[i++]) {
result += i;
result *= 2; 
}

Alle 3 zijn ze mogelijkerwijs nuttig en/of correct. Als je hier niet tegen kunt had je niet aan C++ of Java moeten beginnen maar bij VB moeten blijven.

[curry684]

Op zondag 30 december 2001 13:20 schreef The - DDD het volgende:
Maar je MOET GVD. WEL DIE INDEX UPDATEN BIJ EEN INSERT OF DELETE!! Anders vliegen de access violations je om de oren (onder win32 dan).

Of je het beestje nu segfault of access violation noemt, de essentie blijft hetzelfde hoor

[MWP]

Ik gebruik VB6 en ik erger me er dood aan dat ik de ene x wel button.visible = true kan doen en de andere x niet
foutje van de makers

[Verwijderd]

Op zaterdag 29 december 2001 19:13 schreef OiSyN het volgende:
[..]
Juist! Je ziet het bijvoorbeeld met microsoft's Internet Explorer. Die browser pikt gewoon alles, of je er nou "" omheen zet of niet. Volgende stap is dat mensen minder gaan opletten of het wel klopt. En waarom zouden ze ook? De browser pikt het toch wel... Andere browsers alleen niet, wat zorgt voor incompatible websites, omdat die mensen het gewoon niet goed aanleren.

Dit is totaal niet wat ik bedoel. Ik klop heel wat lappen C++, VB en T-SQL in een jaar en in de laatste 2 talen heb ik NOOIT problemen met dubbel gedefinieerde variabelen omdat ze case insensitive zijn. Ook geen problemen met 'ze pikken gewoon alles'. Bull. Waar ik nog wel eens problemen mee heb is tikfouten in C++, voornamelijk case sensitiviteit gerelateerd. (Mja, snel typen, af en toe de shifttoets niet hard genoeg indrukken..) Dit _kost_ _tijd_. En het is ONNODIG, want VB en T-SQL laten zien dat het niet hoeft.

Nu kan men beweren dat die tijd die het kost onzin is, of nihil, maar dat is niet zo. Elke error die ik krijg in C++ die de editor of compiler voor mij had kunnen fixen is er 1 teveel.

Dit is niet slecht of erg of wat dan ook, maar realiteit in andere talen/ide's/editors, dus waarom niet in C/C++? Voor C, nogmaals, kan ik het argument van de #defines in standaard headerfiles begrijpen, maar voor C++ niet. Voor Java al helemaal niet.

Als je veel vertalerbouwtrimesters hebt gedaan, weet je dat compilers met vrij simpele technieken, heel fouttolerant en foutcorrigerend kunnen zijn (desnoods mbv interactie). Waarom dit nog altijd niet is doorgevoerd in sommige talen ergert me tot op de dag van vandaag.

Ik praat niet over lappen code van max 500 regels. Ik praat over bakken code van 100.000 regels of meer. Leuk dat men loopt te ontkennen wat ik aan den lijve ondervind maar ik weet dat het anders is. Wat ik niet snap in de replieken is dat men maar berust in het feit dat typen fouten oplevert en dat je die maar zelf moet fixen. Code intikken is opzich al een raar iets, want het is relatief traag, foutgevoelig, geestdodend en schadelijk voor lijf en leden. Dat je dan zelf je fouten moet corrigeren, terwijl de compiler dondersgoed weet wat er fout is en het zelf kan herstellen (bv ';' vergeten, 'iD' ipv 'ID') of dmv het presenteren van een lijstje suggesties meteen de error kan fixen en de compile kan voortzetten, schijnt iets te zijn wat je niet mag verwachten van software. Men WIL het niet eens, zonder na te denken waarom je uberhaupt achter een computer zit.

Fouten zijn menselijk, maar dat is ook de plaats waar ze moeten worden opgelost: bij de mens zelf, en dus niet de computer die jouw code moet interpreteren. Dus zolang er nog geen neurale interfaces bestaan moet elke fout hardhandig worden afgestraft

Wat is dit nu voor onzinnige triestheid! Snap je wel wat je aan het doen bent wanneer je bv een messagehandler schrijft in C++? -> Onzinnige bezigheidstherapie! Je weet nl. al van te voren wat je wilt, je moet misschien wel 300 regels tekst intikken, zonder 1 fout, wat zou moeten doen wat jij wilt. In een voor de mens al gauw cryptisch wordende syntaxis waarbij er geen hulp mag worden verwacht van het apparaat wat notabene is uitgevonden om de mens te helpen. Wat zou je ervan zeggen als je die messagehandler code dmv een 2 schermige wizard kon genereren? foutloze code, veel sneller in elkaar gezet en je loopt minder kans op RSI, plus je testresultaten zijn wellicht beter.

Wat is de grondslag van de filosofie dat je bij het inbeitelen van spartaanse programmateksten GEEN hulp mag hebben van het apparaat waar je die programmateksten intikt? Nu weet ik het niet, maar als je dag in dag uit programmatuur schrijft wil je zoveel mogelijk het typen overlaten aan de computer, of iig zoveel mogelijk hulp bij je werk, zodat dat werk 1) sneller verloopt, 2) foutlozer verloopt en 3) afwisselender wordt, want je kunt je bezighouden met andere dingen dan puur het intikken van teksten.

_DAT_ was ook mn reden voor het vermelden van "Ieder zn kicks". Ik misgun niemand zijn genoegen wanneer hij weer 1000 regels tekst in heeft geklopt en denkt bezig te zijn met state of the art spullen. Maar ga aub niet aan het punt voorbij dat het intikken van programmateksten an sig iets is wat de zwakste schakel is in het gehele traject van analyze - ontwerp - bouw - testen - oplevering.

Ook tot op heden de meest ondergesneeuwde stap. In bijna elke andere stap gebruikt men tools om het werk zo efficient en zo foutloos mogelijk te verlopen. Grote databases worden niet meer ontworpen op papier, maar in case-tools die en de database voorgenereren incl. low level accesscode, plus foutcorrigerend en foutcontrollerend bezig zijn. Tot op een niveau dat je mbv het invoeren van businessrules je programmatuur uitgenereert.

Maar nee, laten we ons toch vooral zoveel mogelijk beknotten in het werk wat we allemaal zo geweldig schijnen te vinden: het inbutsen van teksten. Menigeen krijgt een vieze smaak in zn mond wanneer termen als RAD, intellisense en real time syntax checking naar voren komen, maar het zijn, THANK G*D, wel de 1e stappen op weg naar steeds krachtiger wordende tools die belemmeringen in talen en daaruit voortvloeiende beknotting in robuustheid van de bouw-stap in het ontwikkelen van software, op proberen te heffen.

Ik heb 2 jaar lang op groenbeeld vt100 terminals in vi in 80x24 schermpjes C code zitten bouwen. Dat heden ten dage doen lijkt bizar, maar als ik sommige reacties lees van bv ook braveboer dan denk ik... besef je wel dat je met je ideeen nauwelijks IETS bent opgeschoten vergeleken bij die terminal met 80x24 chars, no color coding, no intellisense, no in-editor-errorreporting, no makefile generation, no real time syntax checking etc etc?

WAAROM wil men geen hulp bij het bouwen van software? Ik kan me dat niet begrijpen. De computer is daarvoor, gebruik hem dan ook daarvoor.

[.oisyn]

Op zondag 30 december 2001 16:16 schreef Otis een verhaal

je kan ook overdrijven natuurlijk. En als je er echt zo'n last van hebt kun je ook gewoon naar een andere IDE gaan zoeken (VC++ + Visual Assist verbetert bijvoorbeeld ook de case, en zelfs . naar -> en andersom)

Maar persoonlijk maak ik nooit case-fouten (en tiepfouten) die ik niet opmerk... Maar ja, dat zal dan wel aan mij liggen

en zoals ik al zei: * .oisyn wacht nog steeds op een neurale interface

[Verwijderd]

Op zaterdag 29 december 2001 18:40 schreef _Mo_ het volgende:
dit is meer een IDE setting lijkt mij.. als je in VB een variable A hebt en je roept a aan (als de IDE dit al toelaat.. volgens mij niet), dan doet ie het ook niet.

Nee precies, maar ik krijg geen error wegens een tikfout. Het voorbeeld wat jij aanhaalt lijkt overigens plausibel maar is het niet. Ik praat hier niet over 2e jaars HIO praktica, ik praat hier over prof. software development. Als je daar 'a' en 'b' gebruikt als variabelen, tja, dan zijn we uitgeluld.

Als je Visual Assist gebruikt i.c.m. VC++ dan maakt zet ie ook automatisch je hoofdletters goed (tenzij je natuurlijk x en X constructies gebruikt.. maar dat lijkt me niet zo handig). Kijk, als alles incase sensitive zou zijn, dan is x en X hetzelfde, maar door de compiler wel case-sensitive te maken verplaats je de verantwoordelijkheid naar de programmeur...

Welke verantwoordelijkheid? m_iPolygonID en m_iPolygoniD zijn voor C/C++ compilers 2 verschillende dingen. Semantisch echter niet, ik bedoelde hetzelfde, maakte een tikfoutje. Tikfouten komen voor, bij bakken, zelfs de meest doorgewinterde secretaresses tikken geen 20 brieven achter elkaar zonder 1 tikfout. Als een compiler erachter komt dat een identifyer niet klopt, maar een close match in de symtable is er wel, in het bovenstaande voorbeeld m_iPolygonID, kan hij een warning genereren en de identifyer aanpassen in de build. Compile loopt dan verder door, je kunt het meteen testen en je programmatekst is aangepast.

Nog erger: met ';'. Iedereen die in meerdere talen programmeert weet dat je ze af en toe vergeet. (Dat ze er uberhaupt staan is al debiel, want ze zijn totaal overbodig, compiler technisch) De compiler weet T.A.T. wanneer op welke plek een ';' is vergeten. VC++ geeft het zelf ook aan, maar fixt je code niet. Er _IS_ geen ambiguïteit mogelijk in dit geval, dus waarom moet ik zelf die editor weer in, ';' aanpassen, opnieuw de meuk compileren. De compiler had ook een warning kunnen geven, de ';' kunnen plaatsen en door kunnen gaan met de compile. Elke tokenparser weet namelijk waar een ';' hoort, waar een '}' hoort, waar 'end if' hoort etc.

'tis een beetje soort van java vs. C+ verhaal ... als je in java een nieuw object maakt (dus met "new") hoef je je niet meer druk te maken over opruimen van de pointer... met C++ is dit dus niet en dat vindt ikzelf persoonlijk prettiger, zo heb je meer verantwoordelijkheid/controle over je eigen code.. 'tis wel foutgevoeliger

Is ook oude discussie. Mensen die C++ tot de ubertaal hebben gekwalificeerd en alle andere talen en hun programmeurs tot lagere regionen hebben gedegradeerd, roepen dat memory management niet uit handen moet worden gegeven.

Men vergeet echter het allerbelangrijkste: waarom schrijf je DIE betreffende software? Wat is de core logic van wat je wilt bouwen? Alle _OVERHEAD_ die daarvoor nodig is is dus ballast, tijdverspillende rommel wat je het liefst niet doet, kost nl. tijd, en wellicht fouten, kost extra tests etc. Daarom is GC een essentiele hoeksteen voor moderne software development. En met GC alle mogelijke tools die het traject analyze-ontwerp-bouw-test-oplevering zo kort en zo solide mogelijk maken.

Ik zal menigeen hier weer voor het hoofd stoten met de volgende opmerking, maar de ECHTE softwaredeveloper interesseert het geen moer HOE memory management is geregeld, het liefst gebruikt hij/zij daarvoor een library of een taal/tool waar het al in zit (bv Java of de .NET talen). Dat zijn namelijk details die gaan over de 'overhead'. En die beperk je zoveel mogelijk.

Wannabee's echter focussen op details zoals memory management en andere overhead, en verbinden daar hun waarde-oordeel aan, terwijl juist de ANDERE zaken belangrijk zijn, de overhead is er juist om zoveel mogelijk te worden beperkt, zowel in het kader van "zelf doen" (want dat levert fouten op) als in het kader van "invloed op het project", want voor bestaande technieken kun je bewijzen hoe de invloed van die technieken op je project is, voor eigengeschreven brouwsels weet je dat achteraf pas. En dat is veelal zeer kostbaar.

[mbravenboer]

Waar ik nog wel eens problemen mee heb is tikfouten in C++, voornamelijk casesensitiviteit gerelateerd. Dit _kost__ tijd_. En het is ONNODIG, want VB en T-SQL laten zien dat het niet hoeft.

Denk je niet dat jouw tik-foutjes in C++ komen doordat je ook veel VB en T-SQL gebruikt? Als je tegelijk in veel verschillende talen werkt is het logisch dat je af en toe dingen verward. Dat wil echter niet direct zeggen dat de feature ongelukkig is.

Nu kan men beweren dat die tijd die het kost onzin is, of nihil, maar dat is niet zo. Elke error die ik krijg in C++ die de editor of compiler voor mij had kunnen fixen is er 1 teveel.

Dat vind jij. Dat ik iets anders vind is geen onzin, maar een andere mening. Dat jij die mening onzin vind is uiteraard verder prima.

Waarom dit nog altijd niet is doorgevoerd in sommige talen ergert me tot op de dag van vandaag.

Java ondersteunt unicode identifiers zodat je in je eigen taal kunt proggen als je gek bent. De hoofdletter versus kleineletter situatie in ons deel van Unicode is slechts een van de vele voorbeelden waar tekens als 'identiek' kunnen worden beschouw, terwijl ze het in feit niet zijn. Het is zelfs mogelijk dat uppercase meer tekens oplevert. Als je consequent wilt zijn moet je dus voor heel de wereld deze relaties gaan vastleggen. Ik kan je garanderen: dat wordt een zooi.

Ik praat over bakken code van 100.000 regels of meer. Leuk dat men loopt te ontkennen wat ik aan den lijve ondervind

Je moet je niet zo persoonlijk aangevallen voelen. Dat ik (wij) bepaalde zaken die jij noemt in situatie niet zo relevant vinden als jij is helemaal geen kritiek op jouw persoon. Dat jij ontzettend veel code schrijft weten we verder ook wel, dus ook hier hoef je jezelf helemaal niet te bewijzen.

Code intikken is opzich al een raar iets, want het is relatief traag, foutgevoelig, geestdodend en schadelijk voor lijf en leden. Dat je dan zelf je fouten moet corrigeren, terwijl de compiler dondersgoed weet wat er fout is en het zelf kan herstellen (bv ';' vergeten, 'iD' ipv 'ID') of dmv het presenteren van een lijstje suggesties meteen de error kan fixen en de compile kan voortzetten, schijnt iets te zijn wat je niet mag verwachten van software.

Men WIL het niet eens, zonder na te denken waarom je uberhaupt achter een computer zit.

Nee, dat wil ik inderdaad niet. Ik wil niet dat een compiler gaat trachten te begrijpen wat ik bedoel omdat ik de kans niet wil lopen dat hij mij verkeerd begrijpt. Code bevat al meer dan genoeg bugs. Ik heb liever dat ik exact moet aangeven wat ik bedoel dan dat allerlei vage constructies toegestaan zijn. Het aanbieden van mogelijke correcte oplossingen moet een feature zijn van een IDE, niet van een taal. Als een IDE dus auto-correcte aanbiedt voor vergeten ; of case-insensitive variabele noemen vind ik prima. Als de taal het maar niet als feature heeft.

Wat is dit nu voor onzinnige triestheid!

Is er ergens een cursus normaal communiceren in de zaal?

Wat is de grondslag van de filosofie dat je bij het inbeitelen van spartaanse programmateksten GEEN hulp mag hebben van het apparaat waar je die programmateksten intikt?

Op dit punt ben ik het ook helemaal met je eens, met laat het dan een feature van de IDE zijn. De discussie ging er eerst over of een taal case-sensitive moest zijn. Daarop zei ik ja! Als een IDE het progwerk wil vergemakkelijken en jouw 'case-insensitive' foutjes of ; foutjes gaat corrigeren. fantastisch! (zolang je het ook maar uit kan zetten ). Om nu echter ook een taal met deze features uit te gaan rusten, gaat mij veel te ver.

Maar nee, laten we ons toch vooral zoveel mogelijk beknotten in het werk wat we allemaal zo geweldig schijnen te vinden: het inbutsen van teksten.

Het is een feit dat visuele tools veelal de uitdrukkingskracht ernstig beperken. Het is niet voor niets dat er nog steeds zoveel van handmatig coden gebruik wordt gemaakt. Tegen de kracht van code, kan geen enkele visuele omgeving op.

maar als ik sommige reacties lees van bv ook braveboer dan denk ik... besef je wel dat je met je ideeen nauwelijks IETS bent opgeschoten vergeleken bij die terminal met 80x24 chars, no color coding, no intellisense, no in-editor-errorreporting, no makefile generation, no real time syntax checking etc etc? Ik hoop het.

Je hebt mij duidelijk verkeerd begrepen (en de discussie was wellicht ook niet helemaal duidelijk). Het ging aanvankelijk dus over de features in een taal. IDE's mogen zich wat mij betreft uitleven.

Ik ga verder maar niet op je persoonlijk gerichte geflame in, want dat wordt toch weer een zinloze rel. Wel valt het mij weer op dat je er kennelijk nooit in slaagt om normaal meningen uit te wisselen zonder dat je je aangevallen moet voelen en je gaat verdedigen door je discussie-partners persoonlijk af te zeiken.

[The - DDD]

En bovendien moet je wel degelijk nadenken over het opruimen van je objecten in Java. Cirkulaire referenties zijn erg grondig in het ervoor zorgen dat het object niet vrijgegeven wordt.

En waarom denk je dat in grote C++ projecten vaak wel met GC gewerkt wordt?

[Verwijderd]

Op zondag 30 december 2001 16:43 schreef OiSyN het volgende:
[..]
je kan ook overdrijven natuurlijk. En als je er echt zo'n last van hebt kun je ook gewoon naar een andere IDE gaan zoeken (VC++ + Visual Assist verbetert bijvoorbeeld ook de case, en zelfs . naar -> en andersom)

Ik overdrijf niet, want het valt me meteen op als ik een week C++ klop na een week VB te hebben gekrast. Visual Assist ken ik niet, dus vandaar dat ik die tool niet gebruik. Als die tool je leven makkelijker maakt, dan is dat een grote stap voorwaards. Blijft wel over dat het in de IDE fixen van case sensitive fouten omdat de taal het anders niet vreet, een symptoombestrijdingsactie is en niet oplossend werkt voor het fundamentele probleem: de taal is case sensitive. Als men het legacy-gezeik en andere moedergevoelens eens vergeet, kan men dan nog 1 goede reden opnoemen waarom C++ case sensitive MOET zijn? Neem dan meteen mee dat andere talen dit niet kennen en ook goed functioneren.

Je neurale interface is overigens dichterbij dan je denkt. Men doet onderzoek naar en is al heel ver met het gebruik van visueel programmeren. Dus visueel logica in elkaar zetten op basis van regels. Eigenlijk hetzelfde wat je doet in C++ alleen dan meer met voor de mens makkelijker te doorgronden blokken. Ik weet niet of je wel eens naar Biztalk server hebt gekeken, maar die gebruikt dus grafische tools om business logic te genereren. Je programmeert visueel de logica bij elkaar. Visual Studio.net architect bevat soortgelijke tools, die databases en aanverwante logica genereren op basis van ORM regels. (dus die niam zinnen).

Kromme-tenen trekkend voor iedereen die denkt dat het echte werk zit in het cycle optimizen van polypushers, maar op een gegeven moment bereik je ook daar een status quo, waarbij je zo'n logica blokje middels sleur/pleur in je 3D engine wilt plakken zonder omkijken.

[mbravenboer]

Otis: de ECHTE softwaredeveloper interesseert het geen moer HOE memory management is geregeld

Wannabee's echter focussen op details zoals memory management en andere overhead, en verbinden daar hun waarde-oordeel aan, terwijl juist de ANDERE zaken belangrijk zijn

Ik heb verder geen behoefte om op je eerdere verhaal in te gaan, maar ik wil je toch maar weer eens oproepen om mensen gewoon eens in hun waarde te laten! Iedereen heeft andere interesses en toepassingen.

[^Mo^]

Op zondag 30 december 2001 16:43 schreef Otis het volgende:

Welke verantwoordelijkheid? m_iPolygonID en m_iPolygoniD zijn voor C/C++ compilers 2 verschillende dingen. Semantisch echter niet, ik bedoelde hetzelfde, maakte een tikfoutje. Tikfouten komen voor, bij bakken, zelfs de meest doorgewinterde secretaresses tikken geen 20 brieven achter elkaar zonder 1 tikfout.

en hoe moet de compiler nu weten wat een tikfout is en wat niet? Je moet ergens een grens trekken, en case-sensitiviteit (woord bestaat vast niet) dwingt de programmeur tot netter coden... anders zouden m_iPolygonID en m_ipolygonid precies het zelfde zijn, maar het is absoluut niet prettig debuggen (vooral niet voor een ander) als dit door elkaar wordt gebruikt.

Nog erger: met ';'. Iedereen die in meerdere talen programmeert weet dat je ze af en toe vergeet. (Dat ze er uberhaupt staan is al debiel, want ze zijn totaal overbodig, compiler technisch) De compiler weet T.A.T. wanneer op welke plek een ';' is vergeten. VC++ geeft het zelf ook aan, maar fixt je code niet. Er _IS_ geen ambiguïteit mogelijk in dit geval, dus waarom moet ik zelf die editor weer in, ';' aanpassen, opnieuw de meuk compileren. De compiler had ook een warning kunnen geven, de ';' kunnen plaatsen en door kunnen gaan met de compile. Elke tokenparser weet namelijk waar een ';' hoort, waar een '}' hoort, waar 'end if' hoort etc.

Hoe moet de compiler nu weten waar een } moet? moet na de eerste regel, of na de tweede, of na de derde? ga zo maar door... en op een gegeven moment komt ie aan het einde van de code en zegt ie dat er ergens een } is vergeten, wel zo logisch... zelfde geldt in wezen voor de ;

[Predator]

Er schiet bij mij maar 1 taal echt bovenuit kwa ergernis en dat is VB

Persoonlijk vind ik het de naam "programmeertaal" niet waardig.

Ik vind het 1 grote soep moet zeer inconsistente dingen, vaak is logica daar heel ver te zoeken.
De meeste dingen zijn er al over gezegd en ik sluit mij daar bij aan.

Geen lazy evaluation is ook wel

[Verwijderd]

Op zondag 30 december 2001 16:47 schreef mbravenboer het volgende:
[Otis: Waar ik nog wel eens problemen mee heb is tikfouten in C++, voornamelijk casesensitiviteit gerelateerd. Dit _kost__ tijd_. En het is ONNODIG, want VB en T-SQL laten zien dat het niet hoeft.]

Denk je niet dat jouw tik-foutjes in C++ komen doordat je ook veel VB en T-SQL gebruikt? Als je tegelijk in veel verschillende talen werkt is het logisch dat je af en toe dingen verward. Dat wil echter niet direct zeggen dat de feature ongelukkig is.

Nee, dat komt niet door het gebruik van andere talen, want ik wil wel degelijk bv m_iPolygonID intikken, maar mis even de shiftkey. VB corrigeert me meteen, VC++ pas tijdens compiletijd. Nu weet ik het niet, maar het laatste is bijzonder irritant, als je weet dat het ook anders kan. Kijk eens naar visual studio.net, die komt meteen met syntax fouten aanzetten. Direct fixen en door. Maar jij mag natuurlijk wachten op je compile en het daarna fixen.

[Otis: Waarom dit nog altijd niet is doorgevoerd in sommige talen ergert me tot op de dag van vandaag]
Java ondersteunt unicode identifiers zodat je in je eigen taal kunt proggen als je gek bent. De hoofdletter versus kleineletter situatie in ons deel van Unicode is slechts een van de vele voorbeelden waar tekens als 'identiek' kunnen worden beschouw, terwijl ze het in feit niet zijn. Het is zelfs mogelijk dat uppercase meer tekens oplevert. Als je consequent wilt zijn moet je dus voor heel de wereld deze relaties gaan vastleggen. Ik kan je garanderen: dat wordt een zooi.

Voor je API kies je een bepaalde namingscheme. Op zich vind ik dan dat je voor je eigen code een andere scheme moet kiezen zodat je API calls en eigen code uit elkaar kan houden, maar dat is persoonlijk. Als Java unicode ondersteunt en daar komen ambigue interpretaties uit, wellicht is dan de keuze voor unicode niet correct. Om het dan maar 'case sensitive' te maken lijkt me eerder het bestrijden van het gevolg van de foutieve keuze voor unicode dan het oplossen van het werkelijke probleem.

[Otis: Ik praat over bakken code van 100.000 regels of meer. Leuk dat men loopt te ontkennen wat ik aan den lijve ondervind]
Je moet je niet zo persoonlijk aangevallen voelen. Dat ik (wij) bepaalde zaken die jij noemt in situatie niet zo relevant vinden als jij is helemaal geen kritiek op jouw persoon. Dat jij ontzettend veel code schrijft weten we verder ook wel, dus ook hier hoef je jezelf helemaal niet te bewijzen.

Men gebruikt argumenten die wellicht opgaan voor zaterdag-middag frutsels, maar niet opgaan voor reallife software development, terwijl men ze wel zo presenteert.

[Otis: (code fixing door compiler) Men WIL het niet eens, zonder na te denken waarom je uberhaupt achter een computer zit.]
Nee, dat wil ik inderdaad niet. Ik wil niet dat een compiler gaat trachten te begrijpen wat ik bedoel omdat ik de kans niet wil lopen dat hij mij verkeerd begrijpt. Code bevat al meer dan genoeg bugs. Ik heb liever dat ik exact moet aangeven wat ik bedoel dan dat allerlei vage constructies toegestaan zijn. Het aanbieden van mogelijke correcte oplossingen moet een feature zijn van een IDE, niet van een taal. Als een IDE dus auto-correcte aanbiedt voor vergeten ; of case-insensitive variabele noemen vind ik prima. Als de taal het maar niet als feature heeft.

Een compiler is niet onderdeel van de taal. Een taal is niet meer dan een syntaxbeschrijving. De compiler maakt net als de editor deel uit van de tools om IN die taal software te bouwen. Een taal HEEFT dus deze features niet, de compiler/editor heeft ze. Dat jij niet wilt dat een compiler een ';' fixt voor je, geeft aan dat je te weinig vertrouwen hebt in wat een tokenparser kan en weet, terwijl je dondersgoed weet dat een tokenparser t.a.t. dit soort info EXACT op kan lepelen ZONDER fouten. Maar goed, misschien WIL jij niet geholpen worden. Waarom tik je dan wel je javacode in in programmatekst en niet in bytecodes/asm?

[Otis: Wat is dit nu voor onzinnige triestheid! ]
Is er ergens een cursus normaal communiceren in de zaal?

No offence, maar de triestheid die erboven stond associeer ik niet bij de persoon die het intikte. Ik verwacht en verwachtte meer visie.

[Otis: Wat is de grondslag van de filosofie dat je bij het inbeitelen van spartaanse programmateksten GEEN hulp mag hebben van het apparaat waar je die programmateksten intikt? ]
Op dit punt ben ik het ook helemaal met je eens, met laat het dan een feature van de IDE zijn. De discussie ging er eerst over of een taal case-sensitive moest zijn. Daarop zei ik ja! Als een IDE het progwerk wil vergemakkelijken en jouw 'case-insensitive' foutjes of ; foutjes gaat corrigeren. fantastisch! (zolang je het ook maar uit kan zetten ). Om nu echter ook een taal met deze features uit te gaan rusten, gaat mij veel te ver.

Een taal HEEFT geen features, anders dan in dit kader het zijn van case insensitive. Een taal corrigeert dus niet, de compiler corrigeert. De taal case sensitive maken is een goed ding, waarom? Ik zie nog steeds geen argument. Je vindt het veel te ver gaan. Leuk, maar dat lijkt me geen argument WAAROM een taal case sensitive MOET zijn. Er zijn zat talen die het NIET zijn en volkomen goed functioneren.

[Otis: Maar nee, laten we ons toch vooral zoveel mogelijk beknotten in het werk wat we allemaal zo geweldig schijnen te vinden: het inbutsen van teksten]
Het is een feit dat visuele tools veelal de uitdrukkingskracht ernstig beperken. Het is niet voor niets dat er nog steeds zoveel van handmatig coden gebruik wordt gemaakt. Tegen de kracht van code, kan geen enkele visuele omgeving op.

Nee, het is een mythe. 'De uitdrukkingskracht beperken' is hetzelfde argument dat werd gebruikt door de assemblerprogrammeurs toen COBOL kwam. De reden waarom er nog steeds zoveel handmatig code wordt geklopt is omdat de meeste programmeurs zo kortzichtig zijn als het maar kan. Iets nieuws uitproberen is er niet bij en vooruitgang is alleen mogelijk op platgetreden paden. Kijk voor de aardigheid eens naar de tools die databasedesigners gebruiken. Code schrijven? Waarom zou je. Het is veel te complex om via een editor dat allemaal te gaan programmeren. Daar heb je generatoren voor. Wat overblijft is lijmcode, code die de gegenereerde elementen aan elkaar praat.

Leuk voorbeeld hiervan is de simulaties die men vroeger maakte in APL van logische schakelingen. Nu laat men een grafisch programma de schakelingen narekenen en checken. Vroeger bouwde men in NCR assembler de transactiecode voor betalingen, tegenwoordig genereert men die vanuit casetools. Wat denk je, zou men dat doen omdat de uitdrukkingskracht is beperkt? Nee natuurlijk niet. Want wat WIL je doen? Logica zo creeeren dat de computer het begrijpt en uitvoert. Dan gaan zitten kloppen in een editor is leuk, maar een fenomeen dat is overgebleven uit de tijd dat het de enige manier was om computerprogramma's te bouwen. (na de tijd dat men stekkers prikte, ponskaarten prikte etc). Wat je aanvoert hoor ik vaker, maar het is onzin, echt.

[Otis: maar als ik sommige reacties lees van bv ook braveboer dan denk ik... besef je wel dat je met je ideeen nauwelijks IETS bent opgeschoten vergeleken bij die terminal met 80x24 chars, no color coding, no intellisense, no in-editor-errorreporting, no makefile generation, no real time syntax checking etc etc? Ik hoop het.]
Je hebt mij duidelijk verkeerd begrepen (en de discussie was wellicht ook niet helemaal duidelijk). Het ging aanvankelijk dus over de features in een taal. IDE's mogen zich wat mij betreft uitleven.

Een feature van de taal is case sensitiviteit. OF beter: non-feature. Dat werd aangevoerd als ergernis. Het is een oude discussie, de argumenten voor pure 'C' ken ik, maar voor de rest lijken ze me niet opgaan voor andere talen. Dus waarom zijn die dan nog steeds case sensitive? Ik heb nog geen geldige reden gezien.

Ik ga verder maar niet op je persoonlijk gerichte geflame in, want dat wordt toch weer een zinloze rel. Wel valt het mij weer op dat je er kennelijk nooit in slaagt om normaal meningen uit te wisselen zonder dat je je aangevallen moet voelen en je gaat verdedigen door je discussie-partners persoonlijk af te zeiken.

Ik wil best meningen uitwisselen, maar meningen uitwisselen zijn zo zinloos als ieder zo is overtuigd van zn gelijk. Ik vind het prima als men denkt zoveel ervaring te hebben dat men erover kan oordelen wat werkelijk belangrijk is en wat niet, maar ik word soms wat moe van de kortzichtigheid waarmee men hier zaken benadert en zich blindstaart op compleet irrelevante zaken, de hoofdzaken vergetend.

[Tom-my]

Op zaterdag 29 december 2001 15:12 schreef Crazy_D het volgende:

[..]


Ik werk ook vaak met een andere db-provider, en daar is de .next meteen een functie zodat je een hele fijne loop als
Do While r.next
kan doen. Erg fijn
(en idd erg k*t als je die MoveNext vergeet. Volgens mij vergeet 95% van de mensen die met adodb recordsets werken dat weleens/regelmatig ...).

euhm... welnee..

[Verwijderd]

Op zondag 30 december 2001 16:52 schreef mbravenboer het volgende:

[..]

Ik heb verder geen behoefte om op je eerdere verhaal in te gaan, maar ik wil je toch maar weer eens oproepen om mensen gewoon eens in hun waarde te laten! Iedereen heeft andere interesses en toepassingen.

Er stond een warning boven, je hoeft je dus niet te gaan verdedigen. Iedereen heeft andere interesses. Wellicht had deze discussie moeten worden opgesplitst in hobbyisten en professionals, zodat de ergernissen verdeeld worden over de juiste groep mensen. Ik vind het op zich wel grappig hoe men de problemen afdoet als 'het is zo, je lost het zelf maar op, anders gebruik je toch [insert gevolgbestrijdertool here]?', zonder ook maar in staat te zijn waarom men uberhaupt programmeert in de vorm van programmateksten ipv het verbinden van logische components in een visuele editor (ik noem maar een zijstraat).

[marcusk]

Otis:
Dat jij niet wilt dat een compiler een ';' fixt voor je, geeft aan dat je te weinig vertrouwen hebt in wat een tokenparser kan en weet, terwijl je dondersgoed weet dat een tokenparser t.a.t. dit soort info EXACT op kan lepelen ZONDER fouten.

Het voorbeeld van curry684 lijkt mij toch perfect aan te geven dat dat niet het geval is.

voor de duidelijkheid:

Waarom denk je dat dat ding er is? Omdat ie overbodig is? Vergelijk de volgende 3 stukken code:

code:

while(array[i++]);
result += i;
result *= 2;

code:

while(array[i++])
result += i;
result *= 2;

code:

while(array[i++]) {
result += i;
result *= 2; 
}

Alle 3 zijn ze mogelijkerwijs nuttig en/of correct. Als je hier niet tegen kunt had je niet aan C++ of Java moeten beginnen maar bij VB moeten blijven.

[Verwijderd]

Op zondag 30 december 2001 17:06 schreef _Mo_ het volgende:
[..]
en hoe moet de compiler nu weten wat een tikfout is en wat niet? Je moet ergens een grens trekken, en case-sensitiviteit (woord bestaat vast niet) dwingt de programmeur tot netter coden... anders zouden m_iPolygonID en m_ipolygonid precies het zelfde zijn, maar het is absoluut niet prettig debuggen (vooral niet voor een ander) als dit door elkaar wordt gebruikt.

Ok, dat laatste over leesbaarheid klinkt plausibel. De compiler kan het weten want in de scope waar hij zich op dat moment bevindt, zal een symbol moeten zijn gedefinieerd die matcht met de gevonden identifyer.

[..]
Hoe moet de compiler nu weten waar een } moet? moet na de eerste regel, of na de tweede, of na de derde? ga zo maar door... en op een gegeven moment komt ie aan het einde van de code en zegt ie dat er ergens een } is vergeten, wel zo logisch... zelfde geldt in wezen voor de ;

De ';' is heel gemakkelijk:

Voor de lexical analyzer heb je in feite dit:
statement;statement;statement; ...

als je in je simpele taal bv statement als dit definieert:
statement:
identifyer=value
if (expression) statement

en je schrijft dan in deze simpele taal:
i=0
if (i=1) i=4;
foo=3;

dan zal de lexical analyzer zien:
i=0if(i=1)i=4;foo=3;

omdat statement niet iets kan zijn als identifyer=0identifyer, zal achter de 0 een ';' moeten. Dit zal de tokenparser voor het statement identifyer=value concluderen.

De '}' plaatsen is lastiger. Je kunt concluderen aan de hand van structuuranalyses van de code (die je toch doet voor optimizing) dat een blok eindigt op een bepaalde plaats. Maar echt zeker weten doe je dat idd niet, omdat bv C++ in een blok alle statements toelaat. Op zich is dit IMHO een flaw in C++, waardoor je bij het vergeten van een statement de programmastructuur verandert. Je zou dan dus, wil je minder bugs in je code terugvinden, een betere taal moeten gebruiken.

Hier zie je goed dat de programmeur eigenlijk helemaal niet geholpen wordt. Functionele talen zoals miranda en lisp hebben dit fenomeen niet, wat voor sommigen een reden is om juist die talen te gebruiken.

[.oisyn]

ik kap ermee... mijn stelling dat (oud)democoders zich vrijwel altijd uit de hoogte gedragen is wederom bevestigd (als het een andere mening betreft iig)

[mbravenboer]

VB corrigeert me meteen, VC++ pas tijdens compiletijd.

Ik heb al behoorlijk benadrukt dat ik hulp fantastisch vind. Echter niet door een compiler. Een compiler moet een taal verwerken die exact beschreven is in een grammatica. Hij kan je adviezen geven over wat er fout is aan je code, maar hij moet niet zonder input zelf aan gaan rommelen. Als een IDE jouw helpt vind ik dat fantastisch.

Als Java unicode ondersteunt en daar komen ambigue interpretaties uit, wellicht is dan de keuze voor unicode niet correct. Om het dan maar 'case sensitive' te maken lijkt me eerder het bestrijden van het gevolg van de foutieve keuze voor unicode dan het oplossen van het werkelijke probleem.

Eerlijk gezegd vind ik dit stuk vooral een bewijs dat jij volledig uitgaat van jouw gelijk en van jouw situatie. Java ondersteunt unicode identifiers omdat wij hier in het westen niet de enige op de aardbol zijn. Nu lijkt het mij zeker op dit moment zeer onverstandig om ook echt chinese variabele namen te gaan gebruiken, maar er is zeker wel iets voor te zeggen. Jouw case-sensitivity probleem boeit die chinees echt helemaal niets. Als het hem al wel mocht boeien dan verwacht hij ook dat de tekens die in zijn karakter-set equivalent zijn ook door elkaar mogen worden gebruikt. Je krijgt dan echter dan echter een onmogelijk complexe situatie omdat de wereld der karaketers ongelofelijk ingewikkeld in elkaar zit. Case-insensitivity is dus in feite een weg terug: je richt een taal volledig op ons denkbeeld en onze gebruiken.

Een compiler is niet onderdeel van de taal. Een taal is niet meer dan een syntaxbeschrijving. De compiler maakt net als de editor deel uit van de tools om IN die taal software te bouwen. Een taal HEEFT dus deze features niet, de compiler/editor heeft ze. Dat jij niet wilt dat een compiler een ';' fixt voor je, geeft aan dat je te weinig vertrouwen hebt in wat een tokenparser kan en weet, terwijl je dondersgoed weet dat een tokenparser t.a.t. dit soort info EXACT op kan lepelen ZONDER fouten.

Een taal bestaat uit twee delen (dat hoef ik jou niet te vertellen, maar er zijn vast meer mensen die dit lezen...): een syntax, beschreven met behulp van een grammatica en een semantiek. Een compiler hoort naar mijn mening een taal als input te hebben en een andere taal als output. Er moet sowieso een formele specificatie zijn van de input vom het gedrag niet ambigu te maken.

Jij verwart naar mijn mening componenten met elkaar: je zou het corrigeren van taal-fouten kunnen zien als een aparte fase. Deze fase komt voor de fase waarin de 'echte' taal gecompileerd wordt naar een andere vorm. Door dit component vast in de compiler op te nemen kan je er niet meer voor kiezen om de fout-correcties uit te schakelen. Dat vind ik verkeerd. Het is naar mijn mening het beste als de fout-correctie stap volledig voor de fase komt waarin een concrete taal wordt gecompileerd. Dit kan je doen door een component voor de compiler, maar het is nog veel functioneler als een IDE dit biedt. Het hoort in ieder geval niet in de grammatica van een taal thuis.

Men gebruikt argumenten die wellicht opgaan voor zaterdag-middag frutsels, maar niet opgaan voor reallife software development, terwijl men ze wel zo presenteert.

OiSyN en ik zijn allebei geen zaterdag-amateurs. We volgen allebei een degelijk opleiding en ik ben bijna afgestudeerd. Naast mijn studie heb ik bepaald niet stil gezeten. Dat jij ontzettend veel pratijk-ervaring hebt weet ik, maar daarom hoef je ons nog niet als onwetend of newbies te behandelen. Ik heb een sterke voorkeur voor de theoretische/formele kant van de informatica. Jij bent waarschijnlijk een stuk praktischer bezig. Daaruit kunnen een hoop menings-verschillen ontstaan.

maar meningen uitwisselen zijn zo zinloos als ieder zo is overtuigd van zn gelijk.

Mensen op dit forum zijn allemaal met andere dingen bezig: de een is zonder echt formele achtergrond te hebben bezig met het bouwen van dynamische websites, de andere vindt 3D engines prachtig en houdt van het lagere-werk in C/C++. De volgende bekijkt de zaak van een iets theoretischere kant en dan ander is uitermate op de praktijk van de software-ontwikkeling gericht. Hierdoor ontstaan andere meningen, maar die meningen hebben betrekking op het onderdeel van ons boeiende vakgebied, waar zij mee bezig zijn. Bovendien zijn er altijd meer mensen die overtuigd zijn van hun gelijk. Een goede discussie hoeft helemaal niet bedoeld te zijn om anderen van mening te veranderen: het uitwisselen van standpunten en inzichten is al boeiend genoeg.

Ik vind het prima als men denkt zoveel ervaring te hebben dat men erover kan oordelen wat werkelijk belangrijk is en wat niet, maar ik word soms wat moe van de kortzichtigheid waarmee men hier zaken benadert en zich blindstaart op compleet irrelevante zaken, de hoofdzaken vergetend.

Hoofdzaken voor jou. Jij hebt veel ervaring op jouw gebied en weet wat daar relevant of minder relevant is. Ik zou niet zo snel oordelen over de ervaring van anderen als ze alleen maar een andere visie hebben.

Er stond een warning boven

Dat is geen excuus om mensen niet in hun waarde te laten (ik spreek niet over mezelf, want ik voel me tegenwoordig niet meer snel aangevallen ).

[Verwijderd]

Op zondag 30 december 2001 17:36 schreef marcusk het volgende:
[Otis: Compiler weet precies waar ';' moet]
Het voorbeeld van curry684 lijkt mij toch perfect aan te geven dat dat niet het geval is.

Het 2e voorbeeld levert geen error op, dus zal de compiler geen ';' inserten. Die ';' zou alleen moeten worden toegevoegd waar een echte ERROR plaatsvind, dus bv:

code:

while(array[i++])
result +=i
result *=2;

Dit levert een error op, want 'result *=2;' is een unexpected statement in de tokenparser-handler voor assignmentexpressies. Whitespace skippend komt de ';' dan achter de i te staan.

Wilde curry voorbeeld 1, maar tikte voorbeeld 2, dan krijgt hij geen syntax error, de boel compileert gewoon. Hij krijgt echter een bug, want de code is SEMANTISCH niet correct.

Daar is echter de ';' niet voor. Die is voor het afscheiden van statements, iets wat de compiler, mits de syntax solide is, heel goed zelf kan.

[mbravenboer]

Je moet de ; denk ik ook niet zien als een vergissing van de taal-ontwerper, die dacht dat het een noodzakelijke constructie was. Ik denk dat de ; in een imperatieve taal een stuk duidelijk biedt. Bovendien geeft het de compiler mee gelegenheid om te analyseren wat jij bedoelt als hij een fout vindt. Zonder een duidelijke scheiding tussen statements zou dat een stukje lastiger zijn.

Als jij bijvoorbeeld een component wilt gebruiken die voor de toepassing van de compiler overal ; inserts, vind ik dat prima. Ik zou het echter liever geen feature maken van de compiler als geheel.

Dat functionele talen geen ; hebben is logisch: ze hebben over het algemeen geen side-effects en dus ook geen statements. Een statement zonder side-effect is immers zinloos.

Overigens kennen andere niet imperatieve talen soms ook ; . In Stratego is het de sequentiele compositie van strategien. Ik vind dat wel een aardige notie en zou dan ook liever de ; gebruiken als sequentiele compositie van statements. Het is in dat geval dus geen afsluiting van statements, maar een scheiding van statements.

[Verwijderd]

Even resumerend, want anders blijf ik tikken:
Een compiler is een verzamelnaam van een serie taken die uitgevoerd moeten worden. Het is voor veel talen een checker die achteraf bepaalt wat ingevoerd is correct is en waar dat dan wel/niet zo is, de correcte invoer omzet in een uitvoer, de uitvoer eventueel optimaliseert en tenslotte in de final output omzet.

Vanaf het punt dat de invoer correct is, is het een one-way street naar de final output. Omdat de invoer correct is, dwz syntactisch correct, DUS is er een uitvoer mogelijk, gaat dit altijd goed. De fases ervoor echter, zijn lastig: de initiele invoer kan niet correct zijn. Omdat men achteraf checkt (veelal) of dit het geval is of niet, is het pragmatischer om deze fases zo te laten verlopen dat het proces van compileren zoveel mogelijk te laten slagen. Omdat de fase 'correcte-invoer -> output' altijd slaagt, is alleen dat gedeelte ervoor van belang. Waarom zou je daar niet wensen dat DAT gedeelte van de compiler je zoveel mogelijk helpt? Dat heeft imho niets met pure input -> output compilatie te maken, omdat dat daarna pas komt.

Over de ';': je kunt als taalontwerper er voor kiezen statementdelimiters te gebruiken, immers je compiler wordt een stuk simpeler (elke keer dat je een statement delimiter vindt is het zaak de handler te verlaten). Echter, het is onnodig, omdat je dmv lookaheads kunt besluiten of er een nieuw statement begint of niet. Het geheel wordt wel wat complexer, maar je vermijdt onnodige errors gemaakt door de programmeur.

Over uit de hoogte doen: zie het niet zo. Denk niet dat je uniek bent of dat sukkels zoals ik de fase waarin jij/jullie nu in zitten niet hebben doorgemaakt. Mijn kijk op softwarebouw is een totaal andere dan de meerderheid hier. Echter ik draai ook al wat langer mee. Wat me dan opvalt is dat gemiddelde mening hier is echter al zo oud is en, en dit vind ik echt heel jammer, niet vernieuwend: er zitten nauwelijks echt vernieuwende visies tussen. Men predikt de aloude leuzen, en houdt conservatief vast aan alom bekende zaken, generaliserend gedacht. Zet die dingen eens aan de kant, ga eens een stap van de materie afstaan en kijk eens met andere ogen naar wat je aan het doen bent en waarom, en wat de kernpunten zijn van WAT je eigenlijk wilt doen en of je daar ook idd alle tijd mee bezig bent of dat je veelvuldig met andere zaken bezig bent omdat je niet genoeg geholpen wordt door je tools.

Ik schuif overigens het 'maar ik vind het juist leuk' even terzijde, iedereen die het leuk vindt om in de regen van Amsterdam naar Den Haag te lopen zal ontkennen dat auto's of treinen enig nut hebben.

[mbravenboer]

Otis: Vanaf het punt dat de invoer correct is, is het een one-way street naar de final output. Omdat de invoer correct is, dwz syntactisch correct, DUS is er een uitvoer mogelijk, gaat dit altijd goed.

Syntaxtische correctheid is slechts 1 van de eerste stappen in de compiler. Met syntactische correctheid doel ik nu op het juist zijn van de code met de grammatica van een taal. De semantische analyse (na de abstract parse tree fase) is de hoofdtaak van de compiler en daar kan nog een heleboel misgaan.

Omdat de fase 'correcte-invoer -> output' altijd slaagt, is alleen dat gedeelte ervoor van belang. Waarom zou je daar niet wensen dat DAT gedeelte van de compiler je zoveel mogelijk helpt? Dat heeft imho niets met pure input -> output compilatie te maken, omdat dat daarna pas komt.

Als je uitgaat van een correct stukje code is de rest van het compileer traject inderdaad niet zo erg interessant. Een belangrijke taak van de compiler is echter juist om de correctheid te controleren. De syntax is hierbij maar stap 1 van het verhaal. Het traject na de syntax (dus vanaf de abstract parse tree) is dus wel degelijk zeer relevant.

Mijn hele punt is nu juist dat je het corrigeren van incorrecte syntax en de semantische analyse + transformatie fase moet scheiden.Je krijgt dus twee gescheiden onderdelen: transformatie naar een correcte syntax en een compilatie fase van een correcte syntax naar een output. Tijdens deze tweede fase vind semantische analyse plaats, waar dus wel degelijk nog iets mis kan gaan. De eerste fase kan je een apart component van de compiler maken, maar wat mij betreft past het beter in een IDE.

De syntax van een taal is je macht: met behulp van deze syntax bepaal je wat er moet gebeuren. Daarom wil ik er ook zeker van zijn dat de compiler het eens is met deze syntax en niet zelf aan het fantaseren slaat.

Over de ';'

Je gaat totaal niet op mijn argumenten in (trouwens ook niet op mijn duidelijke unicode verhaal). Ik ben het volledig met je eens dat de ; niet nodig is. Het is echter niet de vraag of hij nodig is, maar of hij wenselijk is. Ik zeg: ja, want het schept duidelijkheid en een compiler kan beter begrijpen wat ik bedoelde en zo betere meldingen geven over incorrecte code.

Dat het parse-technische (veel) complexer is ben ik eigenlijk niet helemaal met je eens. Je hebt volgens mij niet meer look-ahead nodig omdat je in voortdurend op je huidige positie weet of hier een statement afgesloten zou moeten worden als je white-space tegenkomt.

Denk niet dat je uniek bent of dat sukkels zoals ik de fase waarin jij/jullie nu in zitten niet hebben doorgemaakt. Mijn kijk op softwarebouw is een totaal andere dan de meerderheid hier. Echter ik draai ook al wat langer mee.

Ik vind het zo grappig dat jij voortdurend kritiek hebt op anderen omdat ze 'atijd' gelijk denken te hebben. Verder doe je volgens jou ook niet uit de hoogte. Terwijl je dit meldt moet je echter nog even melden dat jij veel langer meeloopt, waarmee je impliceert dat onze mening verkeerd is en die van jouw goed.

Wat me dan opvalt is dat gemiddelde mening hier is echter al zo oud is en, en dit vind ik echt heel jammer, niet vernieuwend: er zitten nauwelijks echt vernieuwende visies tussen.

Mwah, dat vind ik wel meevallen. Misschien dat ik op sommige punten een conservatieve mening heb, maar dat is niet per definitie verkeerd. Dit zegt niet zoveel over 'vernieuwend' bezig zijn. Daarmee impliceer je namelijk dat die vernieuwingen ook beter zijn. Dat zijn ze in mijn ogen dus niet. Verder vinden anderen (nee, niet speciaal hier op GoT) wel dat ik vernieuwend bezig ben, maar nog belangrijker: ik vond zelf dat ik leuk bezig ben. Dat jij dat niet vindt, word ik echt niet heet of koud van . Zolang mijn artikelen maar gepubliceerd worden en ideeen verder uitgedacht worden door anderen vind ik het prima.

[Verwijderd]

Waar ik me toch eens verschrikkelijk aan erger, zijn die kl*te headers in PHP. Ik zou eens willen dat je ze overal kon neerzetten ongeacht de output .

[mbravenboer]

Markuz: Waar ik me toch eens verschrikkelijk aan erger, zijn die kl*te headers in PHP. Ik zou eens willen dat je ze overal kon neerzetten ongeacht de output .

Toch leuk tussendoor .

Lijkt dit je niet een beetje onhandig ivm de combinatie van de aard van het HTTP protocol en performance?

[Verwijderd]

Moeten ze daar dus ook maar eens een oplossing voor vinden .

[Verwijderd]

Op zondag 30 december 2001 17:52 schreef Otis het volgende:
Het 2e voorbeeld levert geen error op, dus zal de compiler geen ';' inserten.

Het zogenaamde dummy statement..

[Verwijderd]

Op zondag 30 december 2001 20:15 schreef GDOG het volgende:

[..]

Het zogenaamde dummy statement..

[Joror]

Op zondag 30 december 2001 20:03 schreef Markuz het volgende:
Moeten ze daar dus ook maar eens een oplossing voor vinden .

[offtopic-post reply]
Als je echt wil is er een eenvoudige oplossing, met gebruik van de php output buffers:

Zet
"ob_start();"
als eerste regel in je code, eenvoudig te doen in een include file

En als laatste in je code
"
echo ob_get_contents();
ob_end_clean();
"
Ook te doen in een include file.

Maar dit is een non-oplossing, omdat in het HTML protocol *juist* direct "on the spot" geflusht wordt, waardoor paginas voorbereid kunnen worden terwijl de HTMLcode binnenkomt, halve paginas kunnen worden getoond enz.
[/offtopic-post reply]

[Netman768]

Als ik in VB een icoon in de taakbalk zet en het programma draai vanuit de compiler zit ik me vaak dood te ergeren (voornamelijk aan mezelf). Als je dan namelijk op de stopknop drukt wordt het programma met een End beeindigd wat betekend dat het icoon niet uit de balk gehaald wordt en het proggie vastloopt, daarmee de compiler meeslepend.

weg aangepaste source......

[mbravenboer]

Pr3d4t0r: [VB zuigt] Geen lazy evaluation is ook wel

Dat VB geen lazy-evaluation kent is vrij logisch, want dat is absoluut niet mogelijk in een taal met side-effects. C++, C, Java, Pascal, Delphi, VB, C# en ga zo maar door zijn allemaal talen met side-effects. Op zich vind ik die (in ieder geval om deze reden) dus nog wel meevallen .

Stricte functionele talen, waar geen side-effects zijn, bieden wel lazy-evaluation. Hier kom je echter een stuk exotischer uit: Haskell, Miranda, Clean etc.

[Verwijderd]

Op zondag 30 december 2001 19:52 schreef mbravenboer het volgende:
[Otis: Vanaf het punt dat de invoer correct is, is het een one-way street naar de final output. Omdat de invoer correct is, dwz syntactisch correct, DUS is er een uitvoer mogelijk, gaat dit altijd goed.]
Syntaxtische correctheid is slechts 1 van de eerste stappen in de compiler. Met syntactische correctheid doel ik nu op het juist zijn van de code met de grammatica van een taal. De semantische analyse (na de abstract parse tree fase) is de hoofdtaak van de compiler en daar kan nog een heleboel misgaan.

Humor. de semantische analyze is iets wat komt kijken bij optimalisatie, immers, daar kun je door diepere interpretatie van wat er gebeurt, kijken of er wat te optimaliseren valt. Echter 3GL talen bevatten in de compile-stap geen semantische analyzes, er is immers een 1:1 afbeelding te realiseren tussen syntactisch correcte programmatext en een output. Let wel: een 3GL concludeert pas of iets SYNTACTISCH correct is in de tokenparser (dus of bv een for header is afgesloten met een haakje)! Dezelfde plek waar initiele emitting plaatsvindt.

Ik begrijp derhalve niet waar je op doelt met je 'er kan nog van alles mis gaan'. Wellicht interpreteer ik je teksten foutief. (no pun intended)

[Otis: Omdat de fase 'correcte-invoer -> output' altijd slaagt, is alleen dat gedeelte ervoor van belang. Waarom zou je daar niet wensen dat DAT gedeelte van de compiler je zoveel mogelijk helpt? Dat heeft imho niets met pure input -> output compilatie te maken, omdat dat daarna pas komt.]
Als je uitgaat van een correct stukje code is de rest van het compileer traject inderdaad niet zo erg interessant. Een belangrijke taak van de compiler is echter juist om de correctheid te controleren. De syntax is hierbij maar stap 1 van het verhaal. Het traject na de syntax (dus vanaf de abstract parse tree) is dus wel degelijk zeer relevant.

Dat klopt, maar wanneer weet je of de syntax van de geboden tekst correct is? Als je die compleet hebt doorlopen en hebt getest, bv of een 'end' is vermeldt na een 'begin' en men niet een end of file of bv een nieuwe functie header tegenkomt. Als je geen emitting laat plaatsvinden tijdens je tokenparser, maar daarin hooguit de syntaxis fixt waar nodig en waar MOGELIJK, krijg je daarna een syntactisch correcte input die door de tokenparser _ALTIJD_ tot code kan worden omgezet. Je moet wel eenduidig code KUNNEN fixen natuurlijk.

Mijn hele punt is nu juist dat je het corrigeren van incorrecte syntax en de semantische analyse + transformatie fase moet scheiden.Je krijgt dus twee gescheiden onderdelen: transformatie naar een correcte syntax en een compilatie fase van een correcte syntax naar een output. Tijdens deze tweede fase vind semantische analyse plaats, waar dus wel degelijk nog iets mis kan gaan. De eerste fase kan je een apart component van de compiler maken, maar wat mij betreft past het beter in een IDE.

Dit is niet juist. Een correcte syntaxis zal altijd zonder fouten compileren naar EEN output. Immers, hoe kun je anders ooit een goed kloppende syntax compileren? Wat jij, naar ik aanneem, bedoelt is de analyze van volgorde van tokens in bv een if handler, of een for() handler. Maar dat is nog steeds syntax checking! Pas als dat naar behoren gedaan is, kun je overgaan tot het compileren van de opgebouwde datastructuren naar een output, de transformatie van wat is aangeboden in tokens naar statements in de doeltaal. Eventueel door meerdere passes gevolgd.

De syntax van een taal is je macht: met behulp van deze syntax bepaal je wat er moet gebeuren. Daarom wil ik er ook zeker van zijn dat de compiler het eens is met deze syntax en niet zelf aan het fantaseren slaat.

Dat kun je sowieso niet. Weet jij hoe een compiler jouw 3GL programmatext compileert naar machinecode? En of dat allemaal precies klopt met wat je verwachtte? Dat kun je niet. Je neemt het maar aan, wat terecht is, anders schreef je het zelf wel in assembler. Ik ben het met je eens dat een compiler alleen DIE code moet fixen die eenduidig gefixt KAN worden. Gelukkig is dat veelal het geval. Op goed geluk statements toevoegen zonder enige vorm van feedback lijkt me ook niet te prefereren, maar jij weet net zo goed als ik dat ik daar niet op doelde.

[Otis: Over de ';']
Je gaat totaal niet op mijn argumenten in (trouwens ook niet op mijn duidelijke unicode verhaal). Ik ben het volledig met je eens dat de ; niet nodig is. Het is echter niet de vraag of hij nodig is, maar of hij wenselijk is. Ik zeg: ja, want het schept duidelijkheid en een compiler kan beter begrijpen wat ik bedoelde en zo betere meldingen geven over incorrecte code.

Over je argumenten mbt het unicode verhaal: dat Kanji characters het case-sensitive/insensitive aspect niet kennen zou al genoeg moeten zijn voor het afschaffen van case-sensitiviteit. Immers: een 6 jarige die kan lezen zal "KoekJe" en "Koekje" beide als "koekje" zien, wat correct is, want beide keren staat dat er. Exact wat iemand met Kanji characters bereikt en wil bereiken. Overigens snap ik het gebruik van Kanji characters in variabelen niet, wanneer de rest van de taalstatements incl API volledig van het Engels zijn afgeleid. Dit geeft IMHO aan dat case sensitiviteit (wat inhoudt: semantisch hetzelfde, syntactisch verschillend) WEL wenselijk is in beschavingen met een latijns alfabet, maar niet in een beschaving met een anderssoortig alfabet. Raar. Geeft je dit niet te denken dat het wellicht gevolg-bestrijding is?

Over of het wenselijk is: daar kun je over discussieren, ikzelf vind het lastig, echter als ik zou moeten kiezen tussen EOL delimiters zoals in VB en ';' dan kies ik voor de ';'. Echter, als ik kijk naar T-SQL waar ik geen van beide heb, dan vind ik dat wel een verademing en mis ze totaal niet. Maar gewenning kan je ingeven dat je ze wel wilt. Echter, imho is het ballast wat 1) errors oplevert en 2) niet echt iets toevoegt aan de leesbaarheid van de code

Dat het parse-technische (veel) complexer is ben ik eigenlijk niet helemaal met je eens. Je hebt volgens mij niet meer look-ahead nodig omdat je in voortdurend op je huidige positie weet of hier een statement afgesloten zou moeten worden als je white-space tegenkomt.

Lijkt me niet: ik kan een tab, EOL of spaties toevoegen zonder dat dat duidt op een statement wat afgesloten is. Wat ik bedoelde met complexer is dat een handler van een statement t.a.t. kan stoppen wanneer hij een ';' token ziet. Een syntax die dat niet gebruikt zal moeten testen welk token wel en niet kan, waardoor de handlers complexer worden. Verder gebruiken veel C compilers geen lookahead, omdat de ';' dat overbodig maakt: zodra je die ziet ben je klaar, en je hoeft die ';' niet te bewaren. Dus je kunt met het huidige token al bepalen wat je moet doen, zonder vooruit te kijken. (vandaar geen lookahead, en waarom ik het aanhaalde, dat je dat bij het ontbreken van een statement delimiter wel nodig hebt).

[Otis: Denk niet dat je uniek bent of dat sukkels zoals ik de fase waarin jij/jullie nu in zitten niet hebben doorgemaakt. Mijn kijk op softwarebouw is een totaal andere dan de meerderheid hier. Echter ik draai ook al wat langer mee.]
Ik vind het zo grappig dat jij voortdurend kritiek hebt op anderen omdat ze 'atijd' gelijk denken te hebben. Verder doe je volgens jou ook niet uit de hoogte. Terwijl je dit meldt moet je echter nog even melden dat jij veel langer meeloopt, waarmee je impliceert dat onze mening verkeerd is en die van jouw goed.

1) Wellicht niet tot je doorgedrongen, maar ik vermeldde dat 'ik veel langer meedraai' erbij als reden waarom mijn mening anders is.
2) Omdat ik langer meedraai zegt niets over de validatie van mijn mening, alleen dat hij anders is OMDAT ik langer meedraai.
3) Ik impliceer helemaal niks omtrent de kwaliteit van jouw mening tov de mijne. Jouw mening blijft prima binnen platgetreden paden, dus hoe kan ik twijfelen aan jouw mening?

[Wat me dan opvalt is dat gemiddelde mening hier is echter al zo oud is en, en dit vind ik echt heel jammer, niet vernieuwend: er zitten nauwelijks echt vernieuwende visies tussen.]
Mwah, dat vind ik wel meevallen. Misschien dat ik op sommige punten een conservatieve mening heb, maar dat is niet per definitie verkeerd. Dit zegt niet zoveel over 'vernieuwend' bezig zijn. Daarmee impliceer je namelijk dat die vernieuwingen ook beter zijn. Dat zijn ze in mijn ogen dus niet.

Vernieuwing bereik je sowieso niet door op betreden paden te blijven. Vernieuwing bereik je WEL door anders tegen de materie aan te kijken. Dat resulteert iig in verandering, of dat beter is zal moeten uitwijzen. Een groot scala aan veranderingen zal net als de geschiedenis uit heeft gewezen, een verbetering opleveren.

Dat ze in jouw ogen niet 'beter' zijn, ligt voor de hand: jouw mening houdt in dat je op bestaande paden vernieuwing zoekt, of althans ruimte tot verandering. Die zal er ongetwijfeld zijn, maar op lange duur zal het je niet brengen wat je zoekt. Ik vind dat jammer, maar wel naar verwachting: [generaliserend]de gemiddelde inf. student denkt meer in details dan in grote lijnen, waardoor de focus niet op waar werkelijk de vernieuwing gehaald kan worden wordt gericht, maar op de enigzinds bekende gebieden[/generaliserend]. Enkelen, en laat ik mezelf daar even buitenplaatsen ter bevordering van de discussie, denken anders dan anderen en komen met op het oog bizarre veranderingen op bestaande thema's veel verder. Wat tot gevolg heeft dat na een lange tijd de mensen die eerst kritisch waren hen volgen met "hij had gelijk!". Ik vind het jammer dat er zo weinig meningen zijn hier die ECHT veranderend zouden kunnen zijn.

Verder vinden anderen (nee, niet speciaal hier op GoT) wel dat ik vernieuwend bezig ben, maar nog belangrijker: ik vond zelf dat ik leuk bezig ben. Dat jij dat niet vindt, word ik echt niet heet of koud van . Zolang mijn artikelen maar gepubliceerd worden en ideeen verder uitgedacht worden door anderen vind ik het prima.

Ik heb al vermeld dat wat je LEUK vindt om te doen (bv het programmeren van een OS puur omdat je dat interesseert en leuk vindt) niet relevant is voor argumentatie waarom iets beter zou KUNNEN en eigenlijk zou MOETEN. Die laatste zin van je is overigens wel iets van pot-ketel, denk je ook niet? Of had jij het niet over wie er uit de hoogte deed .

Welke artikelen bedoel je overigens? Wetenschappelijke publicaties of artikelen op sites?

[Verwijderd]

Op zondag 30 december 2001 20:26 schreef mbravenboer het volgende:

[..]

Dat VB geen lazy-evaluation kent is vrij logisch, want dat is absoluut niet mogelijk in een taal met side-effects. C++, C, Java, Pascal, Delphi, VB, C# en ga zo maar door zijn allemaal talen met side-effects. Op zich vind ik die (in ieder geval om deze reden) dus nog wel meevallen .

Overigens zou je:
Dim oFoo as object
Dim i as integer

set oFoo = CreateObject("mypackage.myclass")
i=oFoo.mymethod()

als lazy evaluation kunnen beschouwen, VB evalueert oFoo pas at runtime, wat je als een vorm van lazy evaluation kunt beschouwen

[mbravenboer]

Otis: Ik begrijp derhalve niet waar je op doelt met je 'er kan nog van alles mis gaan'. Wellicht interpreteer ik je teksten foutief. (no pun intended)

Tja, het ligt er maar aan wat je onder semantische-analyse verstaat . Ik heb nog even nagekeken in mijn boek en die vermeldt dit:

The semantic analysis fase of a compiler connects variable definitions to their uses, checks that each expression has a correct type and translates the abstract syntax into a simpler representation suitable for generating machine code.

Volgens deze analyse valt type-checking dus ook onder semantische analyse en uiteraard kan daar van alles misgaan. Syntaxtische correctheid wordt (in de stukken die ik heb gelezen) alleen correctheid tov een grammatica bedoeld. De semantiek vakt hier dus meestal niet onder. Je kunt bij semanische analyse ook denken aan het opzoeken van lexical-scopes etc.

Semantische analyse kan je natuurlijk ook als optimalisering zijn, maar meestal wordt dat apart aangeduid met control-flow analyse, dataflow-analyse, loop-optimalisatie, pipeling en scheduling etc.

Maar goed, het hangt dus vooral af van je definitie. Spraakverwarring is nu vast opgeheven .

Dat klopt, maar wanneer weet je of de syntax van de geboden tekst correct is? Als je die compleet hebt doorlopen en hebt getest, bv of een 'end' is vermeldt na een 'begin' en men niet een end of file of bv een nieuwe functie header tegenkomt. Als je geen emitting laat plaatsvinden tijdens je tokenparser, maar daarin hooguit de syntaxis fixt waar nodig en waar MOGELIJK, krijg je daarna een syntactisch correcte input die door de tokenparser _ALTIJD_ tot code kan worden omgezet.

Nou ja, dat hangt er dus vanaf wat je onder syntaxtische correctheid verstaat. Mij is geleerd dat dat correctheid ten opzichte van een grammatica is. Dat wil echter niet zeggen dat het programma ook uitgevoerd kan worden: er kunnen type-fouten in zitten. Dat hoort volgens mij bij semantische analyse en zeker niet in een parser. De parser levert een parse-tree. Deze zet je over het algemeen eerst om naar een abstracte-syntax-tree en deze ga je type-checken en verder analyseren.

Dit is niet juist. Een correcte syntaxis zal altijd zonder fouten compileren naar EEN output.

Hangt er dus vanaf wat je onder 'een correcte syntaxis' verstaat .[quote]
fantaseren Dat kun je sowieso niet. Weet jij hoe een compiler jouw 3GL programmatext compileert naar machinecode? [/b]
Ja, sterker nog: ik ben er op dit moment zelf een aan het schrijven .

maar jij weet net zo goed als ik dat ik daar niet op doelde.

Uiteraard . Dat begrijp ik heel goed. Het is ook zeker niet mijn bedoeling om over je goede idee heen te praten. Wat wel mijn bedoeling is: het component wat de syntax corrigeert een duidelijk los component te maken en nog steeds een strakke definitie van je taal te maken die dan als tussen-stap wordt gebruikt.

Overigens snap ik het gebruik van Kanji characters in variabelen niet, wanneer de rest van de taalstatements incl API volledig van het Engels zijn afgeleid. Dit geeft IMHO aan dat case sensitiviteit (wat inhoudt: semantisch hetzelfde, syntactisch verschillend) WEL wenselijk is in beschavingen met een latijns alfabet, maar niet in een beschaving met een anderssoortig alfabet. Raar. Geeft je dit niet te denken dat het wellicht gevolg-bestrijding is?

Ik begrijp niet helemaal waar je op doelt. Ik probeerde duidelijk te maken dat onze min of meer equivalent notie van kleine en hoofdletters slechts 1 specifiek geval is. Uiteraard ben ik het volledig met je eens dat het op dit moment merkwaardig is om niet in het Engels, of in ieder geval in het latijnse alfabet te programmeren, maar voor een verre toekomst is het nog geeneens zo'n gek idee. Misschien moeten API functies zelfs in meerdere talen worden aangeboden terwijl ze hetzelfde zijn .

Maar goed, ik snap je punt en mijn unicode tegenvoorbeeld is op dit moment niet zo sterk, maar ik blijf toch bij mijn mening dat het onduidelijk werkt in een formele definitie van een taal. Dat een IDE of een component voor de compiler je helpt om vergissingen recht te breien (want het blijven toch vaak vergissingen) vind ik prachtig.

Lijkt me niet: ik kan een tab, EOL of spaties toevoegen zonder dat dat duidt op een statement wat afgesloten is.

Hum, dat vraag ik me af. White-space kan altijd geelimineerd worden tot 1 character als het dient als scheiding tussen statements. Je kunt white-space dus gewoon opeten tot het volgende token. Bij dit token zal je moeten beslissen of dit token een nieuwe statement aangeeft of niet. Dat zorgt verder niet voor grote problemen.

Wat ik bedoelde met complexer is dat een handler van een statement t.a.t. kan stoppen wanneer hij een ';' token ziet. Een syntax die dat niet gebruikt zal moeten testen welk token wel en niet kan, waardoor de handlers complexer worden.

Daar zit wel wat in, complexer is het wel.

[over langer meerdraaien]

Dat heb ik dan inderdaad verkeerd opgevat. Ik las wellicht teveel tussen de regels door .

Ik impliceer helemaal niks omtrent de kwaliteit van jouw mening tov de mijne. Jouw mening blijft prima binnen platgetreden paden, dus hoe kan ik twijfelen aan jouw mening?

.

Ik vind het jammer dat er zo weinig meningen zijn hier die ECHT veranderend zouden kunnen zijn.

Ach, ik hoop dat ik je nog eens kan verbazen .

Die laatste zin van je is overigens wel iets van pot-ketel, denk je ook niet? Of had jij het niet over wie er uit de hoogte deed .

hehe . Hij was een beetje bijdehand, dat geef ik toe .

Welke artikelen bedoel je overigens? Wetenschappelijke publicaties of artikelen op sites?

In eerste instantie wetenschappelijk. 1 artikel is al gesubmit maar moet nog aangepast worden, 2 andere zijn in voorbereiding. Ze gaan alle drie over nieuwe ideeen op programma-transformatie gebeid. Eentje behandelt een implementatie voor dynamische instructie-selectie met herschrijf-regels, waardoor je altijd de beste tile verdeling krijgt (itt tot het greedy Maximal Munch algoritme, wat je vast wel kent). Ik ga in de toekomst echter ook wat stukken schrijven voor de Nederlandstalige Java site, maar die worden vrij informeel en toepassings-gericht. 1 XML gerelateerd idee is aardig interessant en dat wil ik daarom ook op internationale sites insturen .

[mbravenboer]

Otis:
set oFoo = CreateObject("mypackage.myclass")
i=oFoo.mymethod()

Ik ken de semantiek van dit stukje niet, maar ik neem aan dat de instantie van oFoo altijd wordt aangemaakt voordat naar de statement i=mymethod() wordt gegaan?

als lazy evaluation kunnen beschouwen, VB evalueert oFoo pas at runtime, wat je als een vorm van lazy evaluation kunt beschouwen

Hum.... mwah... . Het hangt uiteraard van je definitie van lazy-evaluation af, maar dit vind ik toch wel een zeer matige vorm . Normaal gesproken wordt onder lazy-evaluation natuurlijk het uitstellen van een berekening verstaan totdat het resultaat van deze berekening ook daadwerkelijk nodig is. In dit geval is daar natuurlijk geen sprake van: er wordt gewoon altijd een instantie van die klasse aangemaakt. De methode zal ook altijd aangeroepen worden. Dan is gelijk duidelijk waarom dit in een taal met side-effects niet mogelijk is.

[Verwijderd]

Big time ergernis
Microsoft heeft bij het maken van VB componenten gewoon niet nagedacht dat property's wel leuk standaard zouden kunnen zijn. Zo kan je bij de tekstbox etc allemaal wel de tekstkleur aanpassen, maar probeer dat maar eens met de date/time picker ( MS Component ), kan dus gewoon niet, en dat is voor mijn huidige app erg k_t, kan ik weer een usercontrol gaan maken.

[Verwijderd]

Op zondag 30 december 2001 21:39 schreef mbravenboer het volgende:
[runtime evaluation van created object]

Ik ken de semantiek van dit stukje niet, maar ik neem aan dat de instantie van oFoo altijd wordt aangemaakt voordat naar de statement i=mymethod() wordt gegaan?

Ja dat klopt, maar je weet at compile time verder niets over het object, er is dus ook geen code gegenereert die altijd klopt bij de assignment. Als de method niet bestaat of geeft geen integer terug, dan krijg je een runtime error. Vziw valt dit imho wel onder lazy evaluation omdat de compiler de expressies niet evalueert, maar dat dit at runtime gebeurt. Talen met lazy evaluation hebben dit altijd, daar evalueert een compiler nooit een expressie. Procedurele talen leven zich overigens niet echt voor lazy evaluation, naast het feit of het nut van lazy evaluation nu zo wereldschokkend is.

[..]
Hum.... mwah... . Het hangt uiteraard van je definitie van lazy-evaluation af, maar dit vind ik toch wel een zeer matige vorm . Normaal gesproken wordt onder lazy-evaluation natuurlijk het uitstellen van een berekening verstaan totdat het resultaat van deze berekening ook daadwerkelijk nodig is. In dit geval is daar natuurlijk geen sprake van: er wordt gewoon altijd een instantie van die klasse aangemaakt. De methode zal ook altijd aangeroepen worden. Dan is gelijk duidelijk waarom dit in een taal met side-effects niet mogelijk is.

Dat klopt, het is niet een schoolvoorbeeld , maar het leek me wel eentje waarbij je aangeeft dat de compiler met dit stukje code wel degelijk lazy evaluation achtige technieken toepast: de code die wordt gegenereert bevat extra code maar niet de code die je zou verwachten, wanneer je oFoo niet als Object definieert, maar als mypackage.myclass type. Maar verder kon ik niet echt op een goed voorbeeld komen. VB6 heeft nog wel een val() statement (dus niet een libcall) die getallen uit strings leest, maar geen eval() statement zoals vbscript, waar je commando's at runtime mee kunt executeren, die in stringvorm als argument worden meegegeven.

[Verwijderd]

Op zondag 30 december 2001 21:12 schreef Otis het volgende:
Overigens zou je:

Dim oFoo as object
Dim i as integer
set oFoo = CreateObject("mypackage.myclass")
i=oFoo.mymethod()

als lazy evaluation kunnen beschouwen, VB evalueert oFoo pas at runtime, wat je als een vorm van lazy evaluation kunt beschouwen

Dit is geen lazy evaluation maar gewoon runtime binden van objecten.
Lazy evaluation noem ik:

code:

manyNumbers :: [Int]
manyNumbers = [1..938383]

doubleNumbers :: [Int] -> [Int]
doubleNumbers = map (2 *)

main :: [Int]
main = take 3 (doubleNumbers infiniteNumbers)

De functie main levert [2,4,6] op.

take is een functie die een int en een lijst neemt en de eerste drie elementen oplevert.
map is een functie die een lijst neemt en een functie en dat op elk element los laat. In dit geval maal twee.

In Haskell word echt niet elk element van de oneindige lijst integers vermedigvuldigd met twee. Dit gedrag valt wel te emuleren in een imperatieve taal, maar het word een redelijke brei code.

Lazy evalutaion is dat waardes of functies die waardes opleveren pas berekend worden als ze nodig zijn, niet het instantieren van objecten als ze nodig zijn.

De volgende code zou ik nog wel een verkapte vorm van lazy evaluation willen noemen, maar die moet je dan wel met de hand uitprogrammeren.

code:

public class EMail
{
  private string rawString;
  private string sender;

  public EMail(string rawString)
  {
    this.rawString = rawString;
  }
  public string Sender
  {
    get
    {
    if(sender == null)
      sender = ParseSenderFromRawString();
    return sender;
    }
  }
}

Nog meteen een ergenis(je) van C#.
Het niet kunnen onderscheiden van access protector voor de get en set van een property. In een sommige gevallen zou ik best de get public willen hebben terwijl de set protected is. Nu moet je dat met lossen functies oplossen of twee properties. Terwijl het volgens mij in MSIL best zou kunnen, daar is een property gewoon een verwijzing naar twee losse functies:

code:

.property instance string Text()
{
  .set instance void System.Windows.Forms.Control::set_Text(string)
  .get instance string System.Windows.Forms.Control::get_Text()
} // end of property Control::Text

[Verwijderd]

• veranderende APIs (moet je bijvoorbeeld weer overal #ifdef's toevoegen om het op beide versies te laten werken of een overlappende functie toevoegen)

• domme gebruikers (met het prototype voorbeeld "het werkt niet, help")

• domme mede-developers (bijvoorbeeld eentje die over de hele code 100000000 #ifdef's toevoegt omdat een functie in de API is verandert en niet op het slimme idee komt er 1 overlappende funtie overheen te gooien in plaats van al die #ifdefs) - ben je dubbel zo lang bezig om dat weer recht te trekken

• het feit dat je compiler volledig gek gaat doen als je een ; of " vergeten bent. Moet ie uiteraard van mijn code afblijven maar vertel dan tenminste dat er een ; of " mist in plaats van gek te gaan doen

[curry684]

Op maandag 31 december 2001 13:59 schreef beelzebubu het volgende:
• het feit dat je compiler volledig gek gaat doen als je een ; of " vergeten bent. Moet ie uiteraard van mijn code afblijven maar vertel dan tenminste dat er een ; of " mist in plaats van gek te gaan doen

Ik snap echt geen hol van dit hele geemmer... de originele kwestie gaat over stupiditeiten van programmeertalen, dit gaat over stupiditeiten van programmeurs.

In C++ is er toevallig voor gekozen dat je een instructie moet afsluiten met een puntkomma. Dit is niet bij ALLE instructies nodig, maar bij conditionals en loop-statements WEL (zie mijn eerdere voorbeeld). In plaats van een onduidelijke wirwar ervan te maken heeft men vervolgens ervoor gekozen om de puntkomma overal vereist te maken, wat toevallig voor heel leesbare code zorgt. In VB moet je 1 statement per regel gebruiken, en kun je dus niet aan de volgende methodiek:

code:

switch(l_Value)
  {
  case 0:   printf("Nul");       break;
  case 1:   printf("Een");       break;
  case 2:   printf("Twee");     break;
  case 3:   printf("Drie");     break;
  default:  printf("Illegal value"); break;
  }

Ik gebruik zelf altijd maar 1 statement per regel, maar de mogelijkheid is er wel indien handig/nodig/overzichtelijk.

Sowieso, als ik het volgende stukje code in VC++ inklop:

code:

t_UInt4  l_Piet
t_UInt4  l_Baas;

meldt het ding vriendelijk:

error C2146: syntax error : missing ';' before identifier 't_UInt4'

What's the problem?!?

Onduidelijke errors komen alleen als er een ambigue situatie ontstaat. Sowieso zal het ding hier proberen verder te compileren en nog een stapel errors gooien op 'undefined identifier l_Piet', maar dat is logisch: daarom begin je ook altijd bovenaan de lijst met compiler errors te fixen.

En nogmaals: die compiler heeft maar met z'n klauwen van mijn code af te blijven. Als ik een autocorrect optie wil hebben installeer ik die zelf wel.

[mbravenboer]

solar: Dit is geen lazy evaluation maar gewoon runtime binden van objecten.
Lazy evaluation noem ik:

Prachtig voorbeeld .

In Haskell word echt niet elk element van de oneindige lijst integers vermedigvuldigd met twee. Dit gedrag valt wel te emuleren in een imperatieve taal, maar het word een redelijke brei code.

Precies, kijk maar eens hier :
[topic=197726/1/25]

Lazy evalutaion is dat waardes of functies die waardes opleveren pas berekend worden als ze nodig zijn, niet het instantieren van objecten als ze nodig zijn.

Exact.

Nog meteen een ergenis(je) van C#. Het niet kunnen onderscheiden van access protector voor de get en set van een property. In een sommige gevallen zou ik best de get public willen hebben terwijl de set protected is.

Hum, das best een goed punt.... daar was ik nog geeneens tegenaan gelopen .

Nu moet je dat met lossen functies oplossen of twee properties. Terwijl het volgens mij in MSIL best zou kunnen, daar is een property gewoon een verwijzing naar twee losse functies.

Precies, het is complete suiker. Kijk maar eens wat voor SOAP message er wordt verstuurd in .NET Remoting als je een property remote gebruikt .

[johnwoo]

Op maandag 31 december 2001 14:53 schreef curry684 het volgende:

[..]

In VB moet je 1 statement per regel gebruiken, en kun je dus niet aan de volgende methodiek:

code:

switch(l_Value)
  {
  case 0:   printf("Nul");       break;
  case 1:   printf("Een");       break;
  case 2:   printf("Twee");     break;
  case 3:   printf("Drie");     break;
  default:  printf("Illegal value"); break;
  }

In VB mag je ook gewoon meerdere statements per regel gebruiken hoor:

code:

For Index = 0 To 10: Debug.Print Str$(Index): Next Index

(ok niet echt netjes om een loopje op 1 regel te zetten maar het gaat om het idee )

[Orphix]

[beetje offtopic]
Waarom is de ';' in C++ na een class { } nodig?!
Ik heb dit altijd als overbodig gezien
[/beetje offtopic]

[whoami]

Op maandag 31 december 2001 15:29 schreef Orphix het volgende:
[beetje offtopic]
Waarom is de ';' in C++ na een class { } nodig?!
Ik heb dit altijd als overbodig gezien
[/beetje offtopic]

...is in C# weggelaten.

[Verwijderd]

Op maandag 31 december 2001 15:49 schreef whoami het volgende:
[..]
...is in C# weggelaten.

Gelukkig wel ja. Grappige is dat in java syntax wel een ; na een inner class mag, alleen in de base library hebben ze dit soms wel, maar niet overal gedaan, tijdens compileren van de base libs van java 1.3.1 met J# kwam ik bergen warnings tegen dat deze vergeten waren

[.oisyn]

Op maandag 31 december 2001 15:29 schreef Orphix het volgende:
[beetje offtopic]
Waarom is de ';' in C++ na een class { } nodig?!
Ik heb dit altijd als overbodig gezien
[/beetje offtopic]

Omdat je nog variabelen kunt declareren na de class

code:

class Blaat
{
} blaat1, blaat2;

[raptorix]

Op zaterdag 29 december 2001 15:22 schreef MarcKonings het volgende:

[..]

Talen die NIET casesensitive zijn, nodigen uit tot slordige code. Zeker talen waarbij variabelen niet gedeclareerd hoeven te worden, zijn een bron van ellende en het opsporen van bugs kan heel vervelend zijn.

Wat een onzin, je kan niet eens in Camelstyle werken in sommige talen omdat anders de functies niet meer kloppen, geef me overigens 1 GOEDE reden aan wat het voordeel van case sensitivity zou zijn.

[Verwijderd]

Op maandag 31 december 2001 17:20 schreef raptorix het volgende:

[..]

Wat een onzin, je kan niet eens in Camelstyle werken in sommige talen omdat anders de functies niet meer kloppen, geef me overigens 1 GOEDE reden aan wat het voordeel van case sensitivity zou zijn.

Case-sensitivity dwingt je consequent te blijven.
Ik ken genoeg mensen die zonder case-sensitivity een var de ene keer 'ditIsEenVar' noemen, en de volgende keer 'ditiseenvar' en weer een andere keer 'DITISEENVAR'.
Wordt er dus niet overzichterlijker op...

[Gumbo!]

Grootste programmeer ergenis vindt ik dat ik niet kan programmeren

Lees er erg veel over alleen blijft niet in mijn kop vast zitten
Goed voornemen voor 2002... beter geheugen aanschaffen!!

[curry684]

Op maandag 31 december 2001 15:29 schreef Orphix het volgende:
[beetje offtopic]
Waarom is de ';' in C++ na een class { } nodig?!
Ik heb dit altijd als overbodig gezien
[/beetje offtopic]

OiSyN bedoelde het goed maar zei het fout

Je kunt de class behalve alleen declareren ook meteen instantieren. Vooral handig bij static private subclasses:

code:

class SomeComponent
{
public:
  // Troep

private:
  // Manager subclass for all instances
  static class MyManager
    {
    public:
                 MyManager();
    virtual    ~MyManager();

    // Meer troep
    } m_Manager;
};

[.oisyn]

Op maandag 31 december 2001 17:20 schreef raptorix het volgende:

[..]

Wat een onzin, je kan niet eens in Camelstyle werken in sommige talen omdat anders de functies niet meer kloppen, geef me overigens 1 GOEDE reden aan wat het voordeel van case sensitivity zou zijn.

jonge, als jij nou even fijn die discussie hierboven gaat lezen tussen mbravenboer, otis en mij

[.oisyn]

Op maandag 31 december 2001 17:45 schreef curry684 het volgende:

[..]

OiSyN bedoelde het goed maar zei het fout

neeheeeeej, ik zei het goed, maar jij begreep me verkeerd

[Verwijderd]

Op maandag 31 december 2001 17:45 schreef curry684 het volgende:

[..]

OiSyN bedoelde het goed maar zei het fout

Je kunt de class behalve alleen declareren ook meteen instantieren. Vooral handig bij static private subclasses:

Precies. Daarbij komt dat een class definitie afstamt van de struct declaratie uit C, wat de ';' nodig heeft voor de zaken waar OiSyN over sprak.

[Verwijderd]

totaal off-topic:

'de cap' die lachend 4 ton vraagt voor (delphi) code waar dit soort zaken in zitten:

code:

try
 [..]
except
 on e:exception do raise;
end;

of, nog een leuke:

code:

for i:=0 to 10 do
  begin
    i:=1;
    [..]
  end;

[vinnux]

Ergenissen over Java :

Java beweert platforafhankelijk te zijn.
Maar dit is absoluut niet het geval. Dezelfde code kan op een andere machine soms hele andere dingen doen.
Een van deze eigenaardigheden heb ik gevonden bij het afhandelen van Socket Exceptions.
Op een Win32 krijg je netjes een Connection Refused Exception terwijl je op een SUN/Solaris machine die Exception niet terugkrijgt, maar een algemenere Exception.

Het zal vast zo zijn dat dit bij meer Exceptions zo is.
Dit kan heeeeel erg irritant zijn.

En staat het ergens genoteerd ? Ik heb het nog niet gezien.
Iemand wel.

Ook bij het gebruik van AWT zijn er een hele boel problemen waar je tegenaanloopt als je voor meerdere platformen een GUI maakt. Eventhandling bijvoorbeeld is som erg verschillend.

Zo dit zijn mijn ergenissen

[raptorix]

Op maandag 31 december 2001 17:55 schreef OiSyN het volgende:

[..]

jonge, als jij nou even fijn die discussie hierboven gaat lezen tussen mbravenboer, otis en mij

Had geen tijd om 8 * 25 berichten te lezen

[curry684]

Op maandag 31 december 2001 18:08 schreef hezik het volgende:
totaal off-topic:

'de cap' die lachend 4 ton vraagt voor (delphi) code waar dit soort zaken in zitten:

Ik heb ooit wat maintenance moeten verrichten op een commercieel VB-project. Bleek dat *IEDERE* van de enkele duizenden functies begon met de volgende regel:

code:

on error resume next

Echt vet gelachen, daarna hard gejankt natuurlijk

Alle variabelen hadden ook duidelijke namen: a, aa, b, c, dd, i

* curry684 heeft tot op de dag van vandaag een beetje frustraties over die opdracht.

[Speedpete]

Ik vraag me weleens af waarom sommige aanroepen zo verrekte lang moeten zijn...

'addActionListener' is mij teveel letters. Zo hebben veel talen van die lange aanroepen.

Al ben ik over VB wel heel tevreden dat ie automatisch een " zet achter een stringetje of hoofdletters aanpast.

[edit]
* Speedpete gebruikt ook altijd duidelijke variabelen.
i, j, k, l, m, var1, var2, myStr1, etc. etc.

Maakt het des te moeilijker voor anderen om je code te jatten

Heb ooit ergens gelezen hoe je er voor kan zorgen dat je code amper gejat wordt, de tip: gebruik rare vars.

bijv:

code:

Dim hond as Boolean
Dim kat as Integer
Dim mevrouw_de_vries as string

private sub printerklep()
    if hond then
      kat = 5
    else
      mevrouw_de_vries = "Blaat"
    end if
end sub

Als buitenstaander zal dat ZWAAR irritant zijn.
[edit]

[Crazy D]

Op woensdag 02 januari 2002 13:14 schreef Speedpete het volgende:
Ik vraag me weleens af waarom sommige aanroepen zo verrekte lang moeten zijn...

'addActionListener' is mij teveel letters. Zo hebben veel talen van die lange aanroepen.

Tjah wat wil je dan, aAL? Niet echt duidelijk... of addActList dat maakt het er imho ook niet echt duidelijker op...

[drm]

Op vrijdag 28 december 2001 20:52 schreef wasigh het volgende:
PHP + Strings: een ' en een " hebben een andere functie?

Waarom zouden ze hetzelfde "moeten" zijn, dan