[linux] Welke programmeertaal

[IJnte]

Ik heb een relatief simpele vraag, die eigenlijk meer gebaseerd zal zijn op meningen.
Welke programmeertaal is het gemakkelijkste om met linux een poort aan te sturen, of andere hardware aan te sturen.
Zelf heb ik ervaringen met pascal en een beetje assembly, maar ik vraag me toch een beetje af wat jullie aanraden. Ik zie heel veel C en C++ programmeurs hier op tweakers rondneuzen, maar is dit een goede taal om in combinatie te werken met linux(i.v.m. compilers e.d.)?

[Mayco]

ivm compilers zou ik net voor C++ gaan

[Verwijderd]

is die 'net' als niet bedoeld?

Hoe dan ook, ik denk dat C(++) je beste keus is

[Exirion]

Mocht je het echt nog niet weten, kijk eens in welke taal de Linux kernel gecode is en trek je conclusies over de bruikbaarheid voor technische toepassingen....

[Verwijderd]

linux is toch grotendeels in c(++) geschreven....?
kijk je SRPMS maar es door

[psyBSD]

Linux heeft ondersteuning voor veel programmeertalen, ik weet niet welke distro je hebt. maar veel distros ondersteunen by default python, perl, ruby, c(++), java, assembly (AT&T / NASM).

De linux kernel is geschreven in c(++), maar de andere talen worden ook veel gebruikt. Mijn advies is, leer er een aantal en besluit op basis van je kennis / ervaring welke taal voor welk doel het meest geschikt is.

Om poorten aan te sturen zijn c(++), java en assembly goed te doen. Maar dat hangt natuurlijk af van jouw vertaling van het begrip 'goed'. Het feit dat in unix-based systemen ALLES een file is maakt alles wel makkelijker.

[ Voor 22% gewijzigd door psyBSD op 09-05-2004 18:20 ]

[Bergen]

Verwijderd schreef op 09 mei 2004 @ 17:33:
is die 'net' als niet bedoeld?

Als 'juist' denk ik.

Linux is inderdaad grotendeels in C(++) geschreven en ik vermoed dat een aantal low-level dingen in assembly zijn geschreven.

[Verwijderd]

met C heb je het makkelijkst meest direkt toegang tot de hardware, alleen C is best lastig om bugloos te krijgen.
kijk eens naar Perl of Python, je kan vast een module in een van die talen vinden die de juiste hardware poort voor je aanstuurt zoals jij dat wilt
www.python.org voor python
www.cpan.org voor perl modules

Python is het makkelijkst om te leren (deze taal is zo ontworpen dat ie makkelijk te leren is)

en alle 3 de talen C,perl,python zijn hoogstwaarschijnlijk al geinstalleerd op je linux bak

[ Voor 7% gewijzigd door Verwijderd op 09-05-2004 18:58 ]

[Creepy]

Mag ik er even op wijzen dat C en C++ twee verschillende dingen zijn? (en de Kernel is gescheven in C en een heel klein beetje ASM).

Rechtstreeks poorten aansturen is naar mijn idee ook het beste te doen in C en C++, aangezien je direct de beschikking hebt over een aantal api calls (ioperm, inportb, outportb etc.). Maar de meeste talen zullen hier wel wrappers voor hebben.

Java kan ik je in dit geval niet aanraden aangezien je een dll achtig iets moet hebben, buiten de JVM om, om alsnog rechtstreeks de poorten aan te kunnen spreken.

[Wilke]

Bergen schreef op 09 mei 2004 @ 18:41:
[...]
Als 'juist' denk ik.

Linux is inderdaad grotendeels in C(++) geschreven

C, zonder twijfel.

Aan Linux (de kernel) komt AFAIK geen regel C++ te pas (en C en C++ zijn twee heel verschillende dingen).

C is waarschijnlijk de makkelijkste manier om lowlevel aansturingen te doen zoals direct poorten (wat voor poorten trouwens? USB? parallel? serieel?).

[Bergen]

Waarom niet in C++ dan? (Zo ver reikt mijn C-kennis (nog) niet.) Mja, zoveel snelheidswinst zullen asm-routines bij nader inzien nou ook weer niet opleveren. Moderne compilers doen hun werk erg goed natuurlijk.

[Verwijderd]

Bergen schreef op 09 mei 2004 @ 22:56:
Waarom niet in C++ dan? (Zo ver reikt mijn C-kennis (nog) niet.) Mja, zoveel snelheidswinst zullen asm-routines bij nader inzien nou ook weer niet opleveren. Moderne compilers doen hun werk erg goed natuurlijk.

Als je geen kernel-spul of libraries schrijft is C++ een op zijn minst net zo goede keuze als C. Je kunt alle C libraries moeiteloos vanuit C++ gebruiken (zonder wrappers) en C++ heeft een manier van programmeren die de bekende C problemen (memory leaks en buffer overflows) voorkomt.

Nu de nadelen: 1) De code die een C++ compiler genereert is niet portable tussen compilers van verschillende fabrikanten (dit veroorzaakt problemen als je binaire C++ libraries distribueert). 2) C++ is een ingewikkelde taal die je niet zomaar ff leert (trek er maar 2 jaar voor uit), terwijl je voldoende kennis van de taal hebben moet om geen "veredelde C" te schrijven en zo het zelfde risico op fouten te lopen als een C programmeur. 3) Bepaalde features van de taal zijn "duur" in executietijd, als je kernel gerelateerde software wilt schrijven moet je daarom heel exact weten hoe C++ achter de schermen functioneert (en dat is niet gemakkelijk).

[Wilke]

Verwijderd schreef op 09 mei 2004 @ 23:22:
Als je geen kernel-spul of libraries schrijft is C++ een op zijn minst net zo goede keuze als C. Je kunt alle C libraries moeiteloos vanuit C++ gebruiken (zonder wrappers)

Behalve dan deze:

code:

extern "C" {
#include <een-c-header.h>
}

en dat je voor alle aanroepen van C-functies vanuit C++ eigenlijk '::' moet zetten om naamgevingsconflicten met andere namespaces te vermijden.

en C++ heeft een manier van programmeren die de bekende C problemen (memory leaks en buffer overflows) voorkomt.

Waarmee je neem ik aan doelt op constructors/destructors; want verder is er weinig verschil toch? Je moet ook in C++ zelf puinruimen, geen garbage collection helaas (net zo min als in C) - memory leaks veroorzaken is net zo makkelijk en soms zelfs nog makkelijker dan in C++.

C heeft ook manieren van programmeren die memory leaks en buffer overflows voorkomt, dus dit argument snap ik niet echt.

Nu de nadelen: 1) De code die een C++ compiler genereert is niet portable tussen compilers van verschillende fabrikanten (dit veroorzaakt problemen als je binaire C++ libraries distribueert).

Vanaf GCC 3.2 (geloof ik, iig een 3.x versie) hanteert GCC als ik het goed heb begrepen/onthouden dezelfde ABI (binary interface voor modules/libraries) als Intel compilers, dus dat is in ieder geval iets. maar in het algemeen heb je gelijk (geldt dat trouwens niet ook voor C-compilers of vergis ik me dan?).

2) C++ is een ingewikkelde taal die je niet zomaar ff leert (trek er maar 2 jaar voor uit)

Daar ben ik het helemaal mee eens, mensen maken ook nogal eens de vergissing om te denken van "oh da's gewoon C en dan een paar extra taalconstructies". Mja, als je zo aan het programmeren slaat zou ik je code liever niet zien/hoeven debuggen

[IJnte]

Bedankt vast voor de reacties! Wat ik wil gaan doen is iets simpels eigenlijk. Ik wil een lcd display gaan aansturen, maar wil alle software daarvoor zelf gaan maken samen met nog 3 anderen. Niet al te moeilijk, maar je moet wel een goede programmeertaal hebben uitterraard. Ik hoef dus niks voor de kernel te proggen.

Verwijderd schreef op 09 mei 2004 @ 23:22:
[...]

[knip]

Nu de nadelen: 1) De code die een C++ compiler genereert is niet portable tussen compilers van verschillende fabrikanten (dit veroorzaakt problemen als je binaire C++ libraries distribueert). 2) C++ is een ingewikkelde taal die je niet zomaar ff leert (trek er maar 2 jaar voor uit), terwijl je voldoende kennis van de taal hebben moet om geen "veredelde C" te schrijven en zo het zelfde risico op fouten te lopen als een C programmeur. 3) Bepaalde features van de taal zijn "duur" in executietijd, als je kernel gerelateerde software wilt schrijven moet je daarom heel exact weten hoe C++ achter de schermen functioneert (en dat is niet gemakkelijk).

Het is wel lastig dat de code niet zomaar uitwisselbaar is tussen verschillende compilers. Het zou namelijk vaak voorkomen dat we in windows gaan proggen en et b.v. met KDE development gaan compileren..
Ik kan wel opmaken dat het voornamelijk C en C++ is. Je zegt ook dat het lang duurt om te leren. Ik hoop dat mijn basiskennis programmeren mij hierbij help
Mm nu is dus nog de afweging, C of C++.. Iemand tips nog?

[Verwijderd]

IJnte schreef op 09 mei 2004 @ 23:43:
Het is wel lastig dat de code niet zomaar uitwisselbaar is tussen verschillende compilers. Het zou namelijk vaak voorkomen dat we in windows gaan proggen en et b.v. met KDE development gaan compileren..

Dat is geen probleem. Je krijgt een probleem als je een library met met compiler A compileert en vervolgens met compiler B die library probeert te gebruiken; zo lang als je sourcecode overdraagt naar een andere compiler is er niets aan de hand.

[_Squatt_]

Wilke schreef op 09 mei 2004 @ 23:38:
[...]
Vanaf GCC 3.2 (geloof ik, iig een 3.x versie) hanteert GCC als ik het goed heb begrepen/onthouden dezelfde ABI (binary interface voor modules/libraries) als Intel compilers, dus dat is in ieder geval iets. maar in het algemeen heb je gelijk (geldt dat trouwens niet ook voor C-compilers of vergis ik me dan?).

GCC 3.2 inderdaad, en in 3.4 is een bug gefixt in de implementatie van de C++ ABI, dus die is weer incompatible met 3.3.

Voor C compilers geldt dat ook, maar de C ABI is een stuk simpeler (bijv. geen name mangling om overloading mogelijk te maken) en is al een langere tijd bekend/gestandardiseerd.

_{Voor zover ik het begrepen en onthouden heb, corrigeer me gerust als ik het verkeerd heb}

[Verwijderd]

Hmm, post gemist...

Wilke schreef op 09 mei 2004 @ 23:38:
en dat je voor alle aanroepen van C-functies vanuit C++ eigenlijk '::' moet zetten om naamgevingsconflicten met andere namespaces te vermijden.

Nee hoor, alleen als je "using namespace" declaraties gebruikt heb je kans op clashes, voor de rest is het probleem vrijwel identiek aan dat van C.

Waarmee je neem ik aan doelt op constructors/destructors; want verder is er weinig verschil toch? Je moet ook in C++ zelf puinruimen, geen garbage collection helaas (net zo min als in C) - memory leaks veroorzaken is net zo makkelijk en soms zelfs nog makkelijker dan in C++.

Ik doel op de STL met zijn automatische allocatie en deallocatie van heapspace en zijn automatisch resizende inputbuffers. Als je de STL juist gebruikt is het extreem moeilijk leaks of overflows te produceren.

C heeft ook manieren van programmeren die memory leaks en buffer overflows voorkomt, dus dit argument snap ik niet echt.

Het verschil is dat je bij C elke keer opnieuw "het wiel uit moet vinden" (hoe vaak heb je b.v. opnieuw een linked list geimplementeerd), terwijl C++ in de STL al gegarandeerd bugvrije en safe oplossingen aanlevert.

[nhimf]

Ik denk dat je het beste c++ kan gaan doen. En dan icm met QT of GTK (voor je X spul).
C is stabieler dan C++ (al zal je er niets van merken met 99,9% van de applicaties).
Maar het verschil is dat je met c++ OO kan gaan coden en met C niet.

En zoals hierboven al gezegd is:

Het verschil is dat je bij C elke keer opnieuw "het wiel uit moet vinden" (hoe vaak heb je b.v. opnieuw een linked list geimplementeerd), terwijl C++ in de STL al gegarandeerd bugvrije en safe oplossingen aanlevert.

Voor de meeste apps is C meer een bezigheids therapie dan dat het echt iets bijdraagt.

Andere talen kan je proberen, maar ik denk dat c++ het meest toegankelijk is, en java is zowiezo geen optie (vanwege de VM gedoe).
Ik ben zelf ook van pascal naar c++ gegaan (alleen dan op een windows/dos omgeving) en de syntax van pascal zit tussen basic en c(++) in, dus is het goed overstappen.

Als je al goed bent in c0den met pascal, dan is c++ redelijk makkelijk onder de knie te krijgen, en dan zeker _geen_ 2 jaar. Tenzij je mee wil gaan doen aan opensource projecten die redelijk groot en hardcore zijn (om het zo maar te noemen). (dus dat je de taal helemaal onder de knie wil krijgen)

[odysseus]

nhimf schreef op 10 mei 2004 @ 12:21:
Ik denk dat je het beste c++ kan gaan doen. En dan icm met QT of GTK (voor je X spul).
C is stabieler dan C++ (al zal je er niets van merken met 99,9% van de applicaties).

Waarom zou C stabieler zijn? Het is net zo stabiel als jij het programmeert...en ik betwijfel sterk of je eenvoudiger 'stabiel' programmeert in C dan in C++ .

Overigens kan ik met iedereen instemmen dat Java geen goede keuze is - ik ben nu bezig met het schrijven van een full-duplex file transfer protocol over LPT in Java en behalve dat je een low-level library nodig zult hebben, loop je ook tegen irritante problemen aan als het ontbreken van unsigned bytes .

[Sir Isaac]

Of je neemt C voor de low-level onderdelen (hardware access) van je programma, en schrijft de rest in python.

[Verwijderd]

Wel leuk allemaal, die programmeertalen, maar laat het OS eigenlijk wel toe dat je direct poorten aanspreekt?

Ik zou eerst de hardware gaan ontwikkelen en dan gaan kijken hoe je het aanstuurt. Uiteindelijk is de keuze van de programmeertaal triviaal. Alles wordt toch uiteindelijk naar machinecode gecompileerd dan wel geinterpreteerd.

Mijns inziens vindt het OS het prettiger dat je de randapparatuur via bestaande device-drivers aanspreekt. Dus als je randapparatuur aan de seriele poort "gehangen" kan worden, dan scheelt het een heel stuk ontwikkelen van de device-driver. Ook zo voor de parallelle poort.

Maar wat programmeertaal betreft is het eenvoudig: hoe hoger de programmeertaal, hoe verder weg van de hardware. Waardoor de door Sir Isaac hierboven beschreven oplossing best zinnig is.

[voodooless]

Prima dat iedereen direct over C begint... maar de grote vraag aan de TS is natuurlijk: Wat the hell wil je eigenlijk gaan maken. C mag dan wel zo'n beetje standaard zijn in linux, maar dat houdt nog lang niet in dat je ieder app in C gaat maken. Vele dingen worden gedaan door script talen, zelfs grafische toepassingen zijn mogelijk.

Je kiest je taal bij je toepassing, en niet bij je OS, dat is mijn mening...

[Verwijderd]

nhimf schreef op 10 mei 2004 @ 12:21:
Voor de meeste apps is C meer een bezigheids therapie dan dat het echt iets bijdraagt.

Daarom is een van de twee grote Linux desktops natuurlijk ook in C geprogrammeerd (okee, met glib; maar zelfs dan). .

Maargoed, brakke C is - net als brakke C++ - geen goede programmeerstijl. Een goede C-programmeur kan hetzelfde bereiken als een goede C++-programmeur, in dezelfde tijd, in hetzelfde aantal regels code etcetera. Slechte (...) programmeurs kunnen beter iets high-levels nemen: python, java, c#. Bovenstaande opmerking geeft slechts aan dat de poster geen goede C coder is.

[edit]
Ohja, nog even voor de topicstarter: hardware aansturen in het algemeen is strict C/asm, kernel support namelijk alleen deze twee. Als je userspace wilt doen (bv. via parport, via userspace USB, dat soort dingen) kun je voor alles gaan wat (in)direct C API kan aanspreken. De API calls zullen uiteindelijk C zijn, maar het geneuzel eromheen zou evt. in C++ of zelfs C# kunnen. Ikzelf zou alsnog voor C gaan, maar da's persoonlijke smaak.

[ Voor 25% gewijzigd door Verwijderd op 11-05-2004 04:49 ]

[Verwijderd]

IJnte schreef op 09 mei 2004 @ 17:06:
Welke programmeertaal is het gemakkelijkste om met linux een poort aan te sturen, of andere hardware aan te sturen.[..]

Zelf heb ik ervaringen met pascal en een beetje assembly

Ik wil een lcd display gaan aansturen, maar wil alle software daarvoor zelf gaan maken samen met nog 3 anderen. Niet al te moeilijk, maar je moet wel een goede programmeertaal hebben uitterraard. Ik hoef dus niks voor de kernel te proggen.

Volgens mij schieten een heleboel mensen hier het doel voorbij. Je hebt ervaring met pascal, probeer dan kylix (=delphi voor linux) eens. Is een goede IDE, een bekende taal, en wat jij wil kan er mee.

C/C++ zijn ongetwijfeld de meest efficiente keuzes, als je dat goed beheerst zullen je applicaties hoogstwaarsch. soepeler lopen en een kleinere footprint hebben etc. Dat is allemaal waar. Het noopt je echter wel tot het leren van een andere taal, terwijl je pascal al beheerst..

[Exirion]

Ik heb nog even voor je gekeken. Zoek eens naar de PDFs (of het boek zelf uiteraard) van Linux Device Drivers. Het is een boek van Oreilly uit 2001 en het dekt kernel 2.0, 2.2 en 2.4. Hoofdstuk 8 en met name pagina 237 en 238 zijn interessant voor je denk ik Je kunt vrij simpel een kernel module in elkaar draaien die wat poorten aanstuurt en op de betreffende pagina's wordt een voorbeeld besproken.

[MSalters]

_Squatt_ schreef op 10 mei 2004 @ 00:46:
[...]
GCC 3.2 inderdaad, en in 3.4 is een bug gefixt in de implementatie van de C++ ABI, dus die is weer incompatible met 3.3.

Niet helemaal; de default ABI is inderdaad veranderd maar er is een "ABI version" command line argument.

Voor C compilers geldt dat ook, maar de C ABI is een stuk simpeler (bijv. geen name mangling om overloading mogelijk te maken) en is al een langere tijd bekend/gestandardiseerd.

Name mangling voor overloading is niet de ellende, templates maken het moeilijk.
Overigens is de C++ ABI van GCC een gegeneraliseerde vorm van de C++ ABI voor Itanium, en die is dus net zo oud/gestandariseerd als de C ABI voor Itanium.

[psyBSD]

Verwijderd schreef op 09 mei 2004 @ 23:22:
[...]


Als je geen kernel-spul of libraries schrijft is C++ een op zijn minst net zo goede keuze als C. Je kunt alle C libraries moeiteloos vanuit C++ gebruiken (zonder wrappers) en C++ heeft een manier van programmeren die de bekende C problemen (memory leaks en buffer overflows) voorkomt.

Nu de nadelen: 1) De code die een C++ compiler genereert is niet portable tussen compilers van verschillende fabrikanten (dit veroorzaakt problemen als je binaire C++ libraries distribueert). 2) C++ is een ingewikkelde taal die je niet zomaar ff leert (trek er maar 2 jaar voor uit), terwijl je voldoende kennis van de taal hebben moet om geen "veredelde C" te schrijven en zo het zelfde risico op fouten te lopen als een C programmeur. 3) Bepaalde features van de taal zijn "duur" in executietijd, als je kernel gerelateerde software wilt schrijven moet je daarom heel exact weten hoe C++ achter de schermen functioneert (en dat is niet gemakkelijk).

wat versta je onder leren? Het kunnen maken van heap-exploits of het exploiteren van vulnerabilities in een slecht geprogrammeerd onderdeel van een kernel (linux, BSD of w32). Ja dan heb je mss 2 jaar nodig. Maar voor het 'normale' programmeerwerk met kennis van stack-overflows (en hoe je ze prevent) kun je c leren in enkele maanden, c++ is niet veel moeilijker.

Uiteindelijk moet je natuurlijk wel 'safe' programs maken

[ Voor 4% gewijzigd door psyBSD op 11-05-2004 12:22 ]

[Creepy]

Exirion schreef op 11 mei 2004 @ 09:56:
Ik heb nog even voor je gekeken. Zoek eens naar de PDFs (of het boek zelf uiteraard) van Linux Device Drivers. Het is een boek van Oreilly uit 2001 en het dekt kernel 2.0, 2.2 en 2.4. Hoofdstuk 8 en met name pagina 237 en 238 zijn interessant voor je denk ik Je kunt vrij simpel een kernel module in elkaar draaien die wat poorten aanstuurt en op de betreffende pagina's wordt een voorbeeld besproken.

Vanuit userspace kan je ook prima "poorten" aanspreken. Hij heeft het over LCD's die over het algemeen aan de seriele of parallele poort hangen. De meeste USB LCD's die er zijn maken een virtuele seriele poort aan zodat je ze als een serieel apparaat kan aanspreken. Geen kernel driver voor nodig.

Welke taal je er verder voor gebruikt maakt opzich niet zo heel veel uit. Let er wel op dat voor het direct aanspreken van de LPT poort (nodig voor een HD44780 comp. LCD) je root rechten nodig hebt! Voor de USB en seriele varianten is dit niet nodig.

[Verwijderd]

Exirion, er is ook een 2.6 variant: http://tech9.net/rml/kernel_book/. .

[Verwijderd]

Verwijderd schreef op 11 mei 2004 @ 04:47:
Maargoed, brakke C is - net als brakke C++ - geen goede programmeerstijl.

En oorzaak nummer een van brakke programmeerstijl is natuurlijk gebrek aan kennis.

Een goede C-programmeur kan hetzelfde bereiken als een goede C++-programmeur, in dezelfde tijd, in hetzelfde aantal regels code etcetera.

Kun je dit ook onderbouwen? Uit eigen ervaring weet ik dat ik ongeveer 2x zo snel ontwikkel in C++ als in C en een stuk minder debug. Daarnaast moet je natuurlijk meer inspanningen doen om in C het zelfde te bereiken als in C++; je zult b.v. delen van de taal die ontbreken in C zelf moeten implementeren, zoals b.v. inheritance en vtables, of exception handling (bring out the longjump, ook wel "super goto" genoemd).

psyBSD schreef op 11 mei 2004 @ 12:21:
wat versta je onder leren? Het kunnen maken van heap-exploits of het exploiteren van vulnerabilities in een slecht geprogrammeerd onderdeel van een kernel (linux, BSD of w32). Ja dan heb je mss 2 jaar nodig. Maar voor het 'normale' programmeerwerk met kennis van stack-overflows (en hoe je ze prevent) kun je c leren in enkele maanden, c++ is niet veel moeilijker.

C++ beheersen is geen sinecure; de taal zelf is een stuk complexer dan C en dan heb je ook nog eens een complete STL om te leren. Dit binnen "enkele maanden" beheersen is compleet utopisch (wat is b.v. het verschil tussen een input iterator en een forward iterator?).

[Verwijderd]

Verwijderd schreef op 11 mei 2004 @ 18:06:
En oorzaak nummer een van brakke programmeerstijl is natuurlijk gebrek aan kennis.

/me *.

Kun je dit ook onderbouwen? Uit eigen ervaring weet ik dat ik ongeveer 2x zo snel ontwikkel in C++ als in C en een stuk minder debug. Daarnaast moet je natuurlijk meer inspanningen doen om in C het zelfde te bereiken als in C++; je zult b.v. delen van de taal die ontbreken in C zelf moeten implementeren, zoals b.v. inheritance en vtables, of exception handling (bring out the longjump, ook wel "super goto" genoemd).

Vergeet niet dat jij een ervaren C++-programmeur bent, en daarmee (automatisch) beter in C++ dan een onervaren ander persoon. Zoals jij in je comment daaronder al zegt, is C++ leren niet makkelijk. Ik durf zelfs te zeggen dat C++ op bepaalde onderdelen complexer is dan C om te begrijpen & leren. Object inheritance en virtual functions zijn inderdaad nogal pijnlijk in "plain" C, daarom gebruik ik glib + C (ik speel dus vals. ).

[Verwijderd]

Verwijderd schreef op 11 mei 2004 @ 18:13:
Zoals jij in je comment daaronder al zegt, is C++ leren niet makkelijk. Ik durf zelfs te zeggen dat C++ op bepaalde onderdelen complexer is dan C om te begrijpen & leren.

/me *

Dat heeft te maken met abstractieniveau van de taal. C zit op een vrij laag abstractieniveau; je hebt de indruk dat je "op de hardware" programmeert in C doordat er geen taalconstructies zijn die ver boven het abstractieniveau van een macroassembler staan (eigenlijk alleen wat type safety); maar dat betekent ook dat je alles wat boven dat abstactieniveau van array's structs en atomaire types staat zelf moet implementeren (of dat je als programmeur nooit dat abstractieniveau overstijgt en blijft houthakken).

Talen als scheme en ruby zitten daartegen (op verschillende manieren) op een vrij hoog abstractieniveau, ze zijn moeilijk te leren door de complexiteit die dat abstractieniveau oplevert maar als je ze eenmaal beheerst zijn het wel enorm krachtige talen waarin je zeer snel prototypes e.d. kunt ontwikkelen. Het nadeel is dat het met dit soort talen haast onmogelijk is om "op de hardware" te programmeren.

C++ is een combinatie van zowel hoog als laag abstractieniveau en zelfs van verschillende abstractiemethodieken, je kunt er op een ruby-achtige manier mee programmeren maar ook net als in C. Het echte probleem van C++ is meteen die diversiteit, wanneer welke abstractiemethodiek te gebruiken blijft bij elk project opnieuw moeilijke vragen opleveren (doen we dit object georienteerd, functioneel of gestructureerd?).

[ Voor 3% gewijzigd door Verwijderd op 11-05-2004 19:08 ]

[Verwijderd]

Perl: there's more than one way to do it

[Loesje]

Heel leuk deze discussie over wat nu beter is, C of C++, maar in dit geval zou ik nooit C(++) aanraden, simpelweg omdat het om een ogenschijnlijk simpel projectje gaat, uitgevoerd door een pascal-programmeur. Tenzij het doel is om een andere taal te leren (C), zou ik het gewoon in pascal gaan schrijven.

Je kan Kylix gebruiken, maar daar heb ik alleen slechte ervaringen mee. Probeer anders Freepascal, en als je een GUI achtig iets nodig hebt, installeer je er Lazarus over heen.

Dat lijkt me een prima start, mocht je er dan niet uitkomen kan de je altijd nog naar C grijpen.

Daarnaast is FPC (Freepascal) geen scripttaal, heeft geen VM o.i.d. nodig. Je kan er eigenlijk alles mee net als met C. Je kan compilen voor OS/X, Windows, Dos, Linux, Os/2 op verschillende processoren. (Mooie gadget is dat je op een linux bak bv. ook de windows-executable kan bouwen)

Nadeel is dat FPC nog lang niet uitontwikkeld is. Niet te vergelijken met GCC in ieder geval. Maar ik zou het hiermee proberen.

[IJnte]

Uitteraard gaat het er ook om dat we iets leren he! Dat is ook vaak een doel waarom je zoiets doet. Ik zie dat de meningen nog wel wat verdeelt zijn. Is C echt zoveel lastiger te leren, of is het misschien minder begrijpelijk. In C++ zet je output naar je scherm met cout, en bij C is het printF (om maar iets heel simpels te noemen). Van welke 2 programmeertalen is de "structuur" om zo maar te zeggen gemakkelijk te begrijpen? Ik hoor ook sommige mensen positief en negatief zijn over Kylix. Kunnen jullie mij wat voorbeelden noemen wat er zo lastig is aan Kylix?

[Loesje]

Kylix is niet zo stabiel. Het is maar de vraag of Borland het blijft ondersteunen en of er nieuwe versies van uit gaan komen. De laatste fix is al een jaar oud. Kernel 2.6.x wordt officieel niet ondersteund, het is slechts met allerlei smerige hacks aan de praat te krijgen. Nieuwere distrubuties gaan ook niet goed samen met Kylix. Maar probeer het gewoon! De meest simpele versie (goed genoeg voor jouw eisen) is gratis! Download het en kijk of je het (stabiel) aan de praat krijgt.

Verder C++ of C. Je komt uit de pascal-hoek. Heb je Delphi gebruikt of kan je ook uitstekend met TP7.0 (zonder objects) overweg? Als je de syntax van Deplhi gewend bent -> C++, ben je een TP fanaat -> C.

[Exirion]

Verwijderd schreef op 11 mei 2004 @ 16:16:
Exirion, er is ook een 2.6 variant: http://tech9.net/rml/kernel_book/. .

Thanks, die kende ik nog niet. Voordeel van het Oreilly boek is voor TS in ieder geval dat het gratis beschikbaar is in de vorm van PDF

Loesje schreef op 11 mei 2004 @ 22:52:
Kylix is niet zo stabiel. Het is maar de vraag of Borland het blijft ondersteunen en of er nieuwe versies van uit gaan komen. De laatste fix is al een jaar oud. Kernel 2.6.x wordt officieel niet ondersteund, het is slechts met allerlei smerige hacks aan de praat te krijgen. Nieuwere distrubuties gaan ook niet goed samen met Kylix.

Euh? Ik draai Kylix anders probleemloos stabiel op Redhat en Debian installaties met de 2.6.5 kernel. Ik vraag me af of je uit eigen ervaring spreekt of meer 'van horen zeggen'. Met smerige hacks heb ik in ieder geval niet te maken gehad.

[PipoDeClown]

Loesje schreef op 11 mei 2004 @ 22:52:
Verder C++ of C. Je komt uit de pascal-hoek. Heb je Delphi gebruikt of kan je ook uitstekend met TP7.0 (zonder objects) overweg? Als je de syntax van Deplhi gewend bent -> C++, ben je een TP fanaat -> C.

btw tp7 heeft gewoon objecten
en tis quatsch om aan de hand van wat iemand "gewend" is te zeggen welke taal ie het beste zou moeten gebruiken.

[Exirion]

PipoDeClown schreef op 11 mei 2004 @ 23:09:
btw tp7 heeft gewoon objecten

Sterker nog, OOP is al bij TP 5.5 geintroduceerd in (ik meen me te herinneren) 1989.

[Loesje]

Sterker nog, OOP is al bij TP 5.5 geintroduceerd in (ik meen me te herinneren) 1989.

Klopt helemaal, vandaar dat ik het er nog even expliciet bij vermelde. Maar de WinApi en de VCL kwamen natuurlijk pas in Delphi. Alhoewel: je had natuurlijk Turbo Vision.

Euh? Ik draai Kylix anders probleemloos stabiel op Redhat en Debian installaties met de 2.6.5 kernel.

Ik krijg het op Fedora core2 rawhide anders niet aan de praat? Ik gebruik wel de Enterprise versie. Ik kan programma's bijvoorbeeld niet vanuit de IDE starten. Maar ik moet zeggen dat ik het maar zo'n twee dagen heb geprobeerd om het aan de praat te krijgen.

en tis quatsch om aan de hand van wat iemand "gewend" is te zeggen welke taal ie het beste zou moeten gebruiken.

Daar heb je ook gelijk in, het ging me er eigenlijk meer om om het verschil tussen C en C++ uit te leggen door de pascal varianten daarnaast te leggen. Maar veel zin heeft dat eigenlijk ook niet, daar heb je gelijk in. Maar ik denk wel dat als je het OOP gedeelte van pascal al kent, je veel makkelijker met C++ aan de slag kunt.