iPanda om 22:47, 28-12-2003
Echt programmeren en scripten zijn twee verschillende dingen, dus maak een keuze.

Ik wil niet eigenwijs zijn, maar't verschil tussen beiden zou ik zelf zo 1,2,3 niet kunnen geven. Misschien omdat bij scripts dingen 'extern' (Buiten compiler/interpeter om) gebeuren ??

En is perl dan een scripttaal of programmeertaal?

gr. Paul

Oke dat was eruit...  Deze jongen heeft een vraag over hoe hij het beste kan leren programmeren, niet over de discussie of het nou beter is op een mac of op een pc, dat maakt namelijk niets uit. Programmeren is een manier van denken en als je die onder de knie hebt kun je iedere taal in notime leren. De ervaring leert dat mensen het beste met een scripting taal kunnen beginnen om de basis principes (operators, statements e.d.) te snappen. Zonder nu al meteen met een hoop declaraties en regels vooraf te moeten starten. Daarbij komt dat een scripting taal zich perfect leent voor try and error, wat in het begin er handig is als je maar wat aanklooit.

Begin daarom met php, asp of javascript, formuleer een opdracht en kopieer erop los. Dat wil zeggen, struin het net af naar mensen die voorbeeldjes hebben, en gebruik deze en probeer ze te snappen.
Als je het gevoel hebt dat je computer enigszins snapt, stap dan over naar een volwassen programmeer taal (java,c#,c++).  

Bedenk dus wel, dat ik deze vraag dan ook post, omdat ik de computer al in scriptaal begrjp en nu wil overstappen naar het serieuse werk. Zoals ik mijn toekomst wil, wordt het mijn werk en is het dus handig om vroeg te beginnen, vroeg geleerd is oud gedaan (dass toch ut spreekwoord?).

BTW zijn er ook nederlandstalige MacOS X boeken die programmeren behandelen? Ik heb al een chapter uit een engels boek gelezen (legaal, stond op een website over het boek), maar engels is toch wel pittig, niet onmogelijk, maar toch pittig.

En om nog even op de originele vraag terug te komen, Java lijkt me de beste keuze. Je kan er veel mee, van simpele programmaatjes tot ingewikkeldere dingen, en het is nog cross-platform ook..

(Bewerkt door Fredrik om 23:48, 17-01-2004)

Thomas

iPanda om 7:34, 30-12-2003
ActiveX heeft geen sandbox, maar alleen een mogelijkheid om er achter te komen wie het component heeft gemaakt. Een ActiveX-component is verder geschreven in een standaard Windows-programmeertaal die zo je hele systeem kan benaderen (en verneuken). Een Java-applet draait wel weer in een sandbox.

Is dit dan niet waar Fredrik?

Ze zeggen altijd wel dat als je Acqua apps wil maken dat je dat het best in Cocoa kan doen en je Java alleen moet gebruiken om pure Java apps te maken, maar ik heb het vermoeden dat Cocoa-Java het beste is van 2 werelden. Een robuustere en iets simpelere (en algemenere) programmeertaal, maar wel met alle mogelijkheden van Cocoa.

Wanneer je absolute controle wil over je objecten (ok, dan is Obj-C nog niet zo een geweldig voorbeeld, maar C(++) beter) dan moet je duidelijk geen java hebben. Daarbij vind ik het 'eng' om een environment over mijn objecten te laten beslissen

Ook ben ik van mening dat wanneer programmeurs geen aandacht hoeven besteden aan het geheugen beheer/verbruik van hun programmas, dit toch tot slordigheid leidt wanneer er WEL op geheugen gelet moet worden. (als je bijv. wat meer lowlevel gaat).

je zegt dat java meer functionaliteit heeft, ik neem aan dat je daarmee doelt op de standaard APIs die je hebt om met een regel een TCP verbinding op te zetten et all. Indeed, makkelijker zal het zijn, maar het is toch niet mijn deal.

Wellicht zijn het ook wel gewoon 2 verschillende typen programmeurs hoor ik persoonlijk heb het veel meer op het low-level werk, en zie mezelf nog wel aan dingen als filesystems werken in de wellicht niet al te verre toekomst. en de ander maakt graag user apps, waarvoor Cocoa en Java bij uitstek geschikt zijn.

Ach, software ontwikkelen is net als uien pellen (maar dan met minder tranen). Je komt steeds weer een nieuwe interessante laag tegen, met z'n eigen uitdagingen. Heel lowlevel bezig zijn is erg leuk, maar ook als je gebruik maakt van standaard libraries kom je complexiteiten tegen die je moet leren begrijpen en mee moet leren werken.

Ik geloof ook niet dat er ooit een programmeertaal wordt ontworpen waarmee je door het tekenen van een simpel diagram al een programma kan ontwerpen. Een collega beweerde dat Model Driven Architecture (MDA) zoiets was, omdat je vanuit UML-diagrammen code kan genereren, maar toen hij begon te laten zien dat je de relaties tussen UML-objecten kon beschrijven via een of ander modelleringstaaltje wist ik dat dat onzin was. Want uiteindelijk zit je nog te programmeren, maar dan een deels visueel en deels via een modelleringsscripttaal. En volgens mij kan je beter programmeren in een echte programmeertaal, die er per slot van rekening voor ontworpen is.
En zelfs dan nog weet ik zeker dat je bij het toepassen van MDA bepaalde problemen en complexiteiten tegenkomt waardoor het uiteindelijk toch nog een hele klus is om te krijgen wat je wil.
Plus, je moet zulke specifieke kennis hebben om met zo'n tool te kunnen werken dat het verschil tussen zo iemand en een traditionele software engineer me ontgaat.

In Objective-C vind ik het vaak heel onduidelijk of je een object nou wel of niet moet retainen (en dus releasen), of dat-ie in de autoreleasepool zit en dus na uit scope gaan vanzelf wordt gereleased.
Heb je in C++ ook niet dat probleem? Want je maakt niet altijd zelf een object aan. Als je een object terugkrijgt van een method, moet je em dan ook destroyen, of gaat dat vanzelf als het object out of scope gaat?

Het is al weer lang geleden dat ik C++ heb geprogrammeerd (jaar of 8 denk ik). Gek is dat, ik heb m'n hele afstudeerproject in C++ geprogrammeerd, maar ik zou het niet precies meer weten.

ik programmeer nu zo een 13 jaar, in een enorm aantal talen gedaan, maar C++ blijft mijn grote liefde je kunt er alles mee kneden zoals jij het wilt i like that... POWERRR  

Performance is voor mij een big issue. (sinds ik aan de UT begonnen ben, begrijp ik pas ECHT hoeveel kracht het je computer kost om iets te doen) Veel mensen laten dat nog wel eens liggen, en ik voel niet alsof talen als Cocoa en Java de gebruiker aanmoedigen om snelle functies te schrijven (je schrijft ze dan zo snel, dat je nauwelijks nadenkt over de inhoud) in C(++) doe je alles expliciet, en dan krijg je toch een 'persoontje' die over je schouder meekijkt, en neerbuigend doet als je weer eens een functie maakt die veel te veel cycles gebruikt. door de libs van java ea. kan het mi. nog wel eens zo zijn dat je dat soort aspecten uit het ook verliest

Ok, net als alles heeft ook dit z'n beperkingen. De applicatie moet natuurlijk wel redelijk performen op de initiele hardware en voor sommige dingen (zoals embedded software) is performance alles.

Het belangrijkste verschil tussen C++ en Java is toch vooral de allocatie/deallocatie van objecten en de bijbehorende libraries, want de syntax lijkt wel enorm op elkaar. Dus in die zin zie ik niet waarom je in Java zo snel zou schrijven dat je nauwelijks nadenkt over de inhoud. Hoogstens dat je iets minder wordt opgehouden door zaken die fluf zijn en niet wezenlijk voor de functionaliteit van je code.

Als je een commercieel product hebt is het alleen de moeite waard om geoptimaliseerde, mogelijk onleesbare code te schrijven op de punten waar dat belangrijk is. Je moet altijd de afweging maken of geoptimaliseerde, moeilijk leesbare code niet ten koste gaat van de onderhoudbaarheid en of het de moeite (lees: onderhoudskosten) waard is.

Je moet je ook bedenken dat veel programmeerinspanning niet in softwareproducten gaan (die verkocht worden), maar in maatwerksoftware voor bedrijven. En voor die bedrijven zijn de onderhoudskosten van wezenlijk belang.

Wellicht is het dan ook verstandiger om te investeren in een Objective-C boek. De Cocoa APIs zijn even wennen, maar met een devlist, online docs en samples kan er weinig mis gaan

of je nu wil of niet