Programmeertalen, welke, wat, hoe duur?

[Roman]

Ik ben jongst weer een beetje begonnen met programmeren. Wat simpele Windows programma's in elkaar knutselen. Of moet ik dat tegenwoordig ook app noemen? Nee beter niet.

Ben dus een beetje op zoek gegaan naar wat er nu allemaal zo op de markt is en uiteraard ook niet te duur, of beter nog gratis. Ben er gauw achter gekomen dat ook Microsoft tegenwoordig in de "Intermediate language" sector onder weg is. Vroeger had je Visual Basic waarmee je een progje kon knutselen. En nu is er Visual Studio met Visual Basic, Visual C(++) en Visual C#. En dan nog de gratis versie Visual Studio Express. Lijkt leuk.. is Intermediate. Wat wil dit zeggen, nou het is net Java, traag. Omdat het half gecompileerd word en pas bij het uitvoeren geheel compileert word. Daarom heb je ook altijd het .Net Framework nodig.

Ze zeggen dat je het niet zou merken met de snelheden van de computers van tegenwoordig. Maar ik moet zeggen je merkt het wel. Ik zie een hoop bedrijven die hun producten met Visual Studio bouwen (is eraan te merken dat ze altijd zeggen dat .Net nodig is). En hun producten voelen altijd traag aan, ook met een quad core en een berg geheugen. Ik zie het momenteel op mijn werk, we zij aan het zoeken naar een nieuw kassasysteem. Diverse systemen gezien, bijna allemaal gebaseerd op .Net en in vergelijking met ons oude systeem (geprogrammeerd in Delphi) zijn ze traag, terwijl ze nog niet eens dat kunnen wat ons oud systeem kan. Maar dat terzijde.

Ook zeggen ze dat Intermediate languages platform en OS onafhankelijk zijn. Bij Java klopt dat ook, maar .Net is Microsoft en eigenlijk alleen maar voor Windows producten te verkrijgen, tenminste de officiële. Er zijn wel wat projecten om .Net op Mac en Linux te gebruiken.

Delphi is ook een leuk trefwoord. Ja het bestaat nog steeds, alleen niet meer van Borland. En is vrij prijzig. Alternatief is er Lazarus, wat gebaseerd is op Delphi (voelt aan als Delphi 5), maar dan ook prima werkt op Windows 7/8 en waarschijnlijk ook op 10, en verder is er ook een Mac en Linux compiler. En het is geheel gratis.

Maar... wat is er nog? Zijn er nog andere goedkope programmeer talen? Is er nog een echte betaalbare C++ (alhoewel ik nooit echt goed was in C++, ik ben meer het Pascal Type). Waar programmeren jullie mee?

De vraag is natuurlijk wat ik ermee wil doen. Geen idee. Ten eerste denk ik weer wat grondkennis opdoen. En later misschien wat kleinere programmaatjes maken, wat kan ik nog niet zeggen.

[Rupie]

Dit lijk mij eerlijk gezegd eerder een topic voor PRG. Ik verplaats je topic die kant op!

[RobIII]

Roman schreef op woensdag 04 november 2015 @ 07:11:
Lijkt leuk.. is Intermediate. Wat wil dit zeggen, nou het is net Java, traag. O
[...]

Ze zeggen dat je het niet zou merken met de snelheden van de computers van tegenwoordig. Maar ik moet zeggen je merkt het wel. Ik zie een hoop bedrijven die hun producten met Visual Studio bouwen (is eraan te merken dat ze altijd zeggen dat .Net nodig is). En hun producten voelen altijd traag aan, ook met een quad core en een berg geheugen. Ik zie het momenteel op mijn werk, we zij aan het zoeken naar een nieuw kassasysteem. Diverse systemen gezien, bijna allemaal gebaseerd op .Net en in vergelijking met ons oude systeem (geprogrammeerd in Delphi) zijn ze traag, terwijl ze nog niet eens dat kunnen wat ons oud systeem kan.

Wat een complete, absolute, kul. Misschien dat je een paar slechte voorbeelden hebt gehad en daarmee een slechte indruk hebt gekregen, maar dat geldt niet voor het gehele spectrum. Er zijn meer dan genoeg applicaties (.Net (C#/VB.net/F#/IronPython en ga zo maar door) en Java) die prima werken en performen. De "overhead" die je betaalt door IL/ByteCode te gebruiken (...en een GC en ga zo maar door; wat vaak ook bij dergelijke runtimes hoort) wordt vaak door de JIT compiler goed gemaakt door specifiek voor jouw platform geoptimaliseerde code terplekke (en eenmalig(!)) uit te poepen en, waar nodig, nogmaals nog zwaarder te optimaliseren wanneer (een stuk) code een "hot path" blijkt. En dan laat ik pre-jitting en andere zaken nog achterwege. In sommige gevallen presteert 't zelfs beter dan, zeg, C(++) code. En in die andere gevallen is het prestatieverschil vaak verwaarloosbaar; en is 't dat niet dan heb je of een knudde geprogrammeerde applicatie of gooi je er voor een paar euro extra wat betere hardware tegenaan die je prima kunt betalen van de besparingen die je tijdens development hebt opgedaan
(Voor .Net specifiek: misschien dat je hier en hier eens moet beginnen met lezen en wat linkjes volgen )

En dat ging allemaal nog over "performance"; ik zou niet weten wat je met Delphi zogenaamd wél zou kunnen wat met .Net of Java niet zou kunnen... (als het al niet andersom is ). En dat geldt voor zo'n beetje elke ("generieke") programmeertaal; zolang je geen taal kiest die specifiek gericht is op één doel is zo'n beetje elke ("generieke") taal inwisselbaar voor een andere. Dat je in de één X makkelijker klaar krijgt dan in de ander en dat de ander weer makkelijker is om Y in te implementeren: daarom kies je een taal op basis van je doel ("opdracht") en niet op 'mooi' of 'hip' of 'gratis'.
(En ja, het is wat zwart-wit wat ik hier schrijf en, ja, het ligt allemaal iets genuanceerder, maar het stuk waar ik op inhaak kon ik echt niet zonder repliek laten staan...)

Roman schreef op woensdag 04 november 2015 @ 07:11:

Ook zeggen ze dat Intermediate languages platform en OS onafhankelijk zijn. Bij Java klopt dat ook, maar .Net is Microsoft en eigenlijk alleen maar voor Windows producten te verkrijgen, tenminste de officiële. Er zijn wel wat projecten om .Net op Mac en Linux te gebruiken.

.Net Core is al bijna een jaar open source en prima te gebruiken op Linux / OS X / iOS / Android. En dan heb je nog Mono waar je waarschijnlijk met die laatste zin op doelt. En deze is heet van de naald

Roman schreef op woensdag 04 november 2015 @ 07:11:
Maar... wat is er nog? Zijn er nog andere goedkope programmeer talen?
[...]
De vraag is natuurlijk wat ik ermee wil doen. Geen idee. Ten eerste denk ik weer wat grondkennis opdoen. En later misschien wat kleinere programmaatjes maken, wat kan ik nog niet zeggen.

Dit kan ik alleen maar beantwoorden met Welke programmeertaal moet ik leren?
De tl;dr versie is: boeie. Kies een taal en ga leren. Zéker als je nog aan 't leren bent is een taal als Java / C# / VB.Net / Go / PHP of Javascipt wat 'vriendelijker' dan, zeg, (Objective) C(++) o.i.d. maar dat hangt ook van jezelf af en is nogal subjectief. En het één sluit het ander niet uit. Ben je echt zo "hardcore" als je jezelf nu doet voorkomen dan leer je lekker assembly en pers je de aller-aller-laatste druppel uit elke CPU-cycle. En ben je toch stiekem wat minder serieus in bovenstaand verhaal dan zou ik gewoon een taal kiezen die én praktisch nut heeft voor wat je ermee wil gaan doen (right tool for the job, maar dat zul je dan éérst moeten bedenken...) en die een beetje leervriendelijk is. Ik zou zeggen: pick one. Misschien ben je meer van de populariteitslijstjes? Van de meeste talen is er wel een gratis variant te vinden en anders hou je genoeg alternatieven over zou ik zeggen

[ Voor 14% gewijzigd door RobIII op 04-11-2015 21:24 ]

[farlane]

RobIII schreef op woensdag 04 november 2015 @ 18:38:
[...]
Wat een complete, absolute, kul.

Ik kan me er wel in vinden, applicaties die in .NET of Java zijn geschreven voelen in het algemeen stroperiger aan dan alternatieven (als die er zijn) die in C,C++ of zelfs Delphi geschreven zijn, en dat maakt (mij) echt wel uit.

[Twazerty]

farlane schreef op woensdag 04 november 2015 @ 21:37:
[...]

Ik kan me er wel in vinden, applicaties die in .NET of Java zijn geschreven voelen in het algemeen stroperiger aan dan alternatieven (als die er zijn) die in C,C++ of zelfs Delphi geschreven zijn, en dat maakt (mij) echt wel uit.

Volgens mij heeft het vooral te maken met de ontwikkelaar zelf hoe deze het aflevert. Misschien dat C++ ontwikkelaars over het algemeen wat meer op performance letten dan Java ontwikkelaars die snel iets moois neerzetten.

Een java/.net ontwikkelaar die ook let op de performance zet iets neer wat naar mijn mening niet onderdoet voor c++. Als je lui bent krijg je inderdaad stroperige applicaties.

[Bartjuh]

Hmm, nergens last van met .NET... vind het een geweldig platform. Eigenlijk gebruik ik C# juist als dingen snel moeten gaan die in (Iron)Python lachwekkend traag gaan (er is ook geen numpy of scipy, is cpython). Dan schrijf ik een C# dll voor de rekenintensieve zaken (in mathnet, arrays van miljoenen elementen, etc) en include ik die in Ironpython. Werkt eigenlijk heel goed, wel oppassen voor boxing en unboxing, is traag.

Programmeer eigenlijk praktisch alleen in CPython, IronPython (.NET c# based python) en C#.net.

[Camulos]

OP heeft een betoog alsof ik een theoretisch boek uit eind jaren 90 zit te lezen ongefundeerd en vol aannames.

Waar programmeren jullie mee?

'Whatever is the best tool for the job' in combinatie met 'whatever I am most effective in'.

Currently: .NET fullstack + JavaScript.. verleden ook JAVA en PHP gedaan.

[stevens20]

Ik ga dit even volgen. Heb net les één gehad met C++. Ga in eigen tijd wat leren om er eventueel les in te gaan geven (ben techniekdocent) op het voortgezet onderwijs waar programmeren waarschijnlijk in het vakkenpakket gaat komen.

[pedorus]

c++ is niet echt een taal voor de middelbare school. Schijnt php, visual basic, alice enzo beter voor te zijn.

Roman schreef op woensdag 04 november 2015 @ 07:11:
Lijkt leuk.. is Intermediate. Wat wil dit zeggen, nou het is net Java, traag.

Lol, java de meest gebruikte HFT taal en taal waarin sommige van de snelste webservers geschreven zijn, is traag...

Dan liever c++ programmatuur die willekeurig crashed en security bugs bevat zullen we maar zeggen

In >99% van de gevallen maakt de taal maakt niet uit of zijn er meerdere mogelijkheden, en de concepten zijn toch steeds hetzelfde. Maar wat je ook kiest, gebruik in jouw geval vooral geen scala of javascript. Gebruik c++, ruby of visual basic ofzo.

[valvy]

Java is in de meeste gevallen sneller dan c++. en de enigste nadeel is dat jvm eerst moet opstarten(wat tegenwoordig echt snel is)

Zelf ben ik fan van functionele programmeer talen. Zo programmeer ik graag in Haskell.
Naast dit kan ik ook alle standaard talen zoals c++/java etc.

[Roman]

RobIII schreef op woensdag 04 november 2015 @ 18:38:
[...]

Wat een complete, absolute, kul.

Het kan zijn dat goede programmeurs er wat minder stroefigs kunnen bakken. Weet natuurlijk niet wat die bedrijven voor programmeurs hebben die ons een kassasysteem van 100k verkopen, (we hebben 70 kassa's nodig en dan zit je bij elk bedrijf ergens tussen de 80k en 120k).

Ik kan wel nog meer voorbeelden geven waarin, vooral Java maar ook .Net, traag is. Zelfs producten van Microsoft, zoals de nieuwe Navision Role Tailored Client, welke in Visual C# geschreven zou moeten zijn volgens onze leverancier, voelt traag. Kan zijn dat er ook andere, positieve voorbeelden zijn, maar die moet ik dan eerst nog vinden (sorry). Ik vergelijk ze dan altijd met oude software, misschien moet ik dat niet doen (zo vergelijk ik elk musikprogje met winamp, geen 500k en doet wat het moet doen).

Camulos schreef op woensdag 04 november 2015 @ 23:36:
OP heeft een betoog alsof ik een theoretisch boek uit eind jaren 90 zit te lezen ongefundeerd en vol aannames.

Hmm ja... ik ben ook een beetje retro. Heb dat ook eind jaren 90 mijn opleiding gedaan en tijdens deze Turbo Pascal en C++ gehad. Later, ergens 2000-2002, een beetje met Visual Basic en Delphi geknutseld. Maar daar bleef het ook bij. Heb dus een beetje een achterstand van een kleine 13 jaar. Heb dan dit jaar wat geknutseld met Visual Studio VB.Net en C#. De resultaten werken uiteraard, maar toch voelt te traag, vooral op onze huidige kassa's met Via 2ghz single core CPU.

pedorus schreef op donderdag 05 november 2015 @ 00:04:
Lol, java de meest gebruikte HFT taal en taal waarin sommige van de snelste webservers geschreven zijn, is traag...

Java is voor mij een no go. Het mag zijn dat het veel gebruikt word, misschien is dat ook het probleem dat er zoveel slechte programma's zijn. Ben eventueel door java gebrandmerkt, zo dat ik tegenwoordig, telkens als ik iets zie wat in java geprogrammeerd is, toch eerder op zoek ga naar een iets anders dan dat te installeren.

Ook vind ik aan het Intermediate het probleem, zal wel aan mij liggen, dat ik op de elke machine de runtime moet hebben geïnstalleerd. Ik kan niet zomaar het programma nemen en ergens op een machine draaien. En als ik dan, zoals bij java gevoeld, elke week een update krijg, wordt ik daar ook niet echt vrolijk van.

In ieder geval gaat mijn keuze naar een niet Intermediate Language. Heb met https://www.freebyte.com/programming/ een leuke site gevonden waar redelijk wat aan talen staat.

[Soldaatje]

Ik ben een totale noob maar ik heb aardig wat dingen geleerd van PHP door gewoon de source te lezen van bijvoorbeeld Owncloud op github en kleine dingetjes te proberen aan te passen, dat gaat vrij snel en makkelijk.
Misschien is het volgende ook wel totale kul maar ik heb het idee dat kort door de bocht genomen de meeste talen wel redelijk op elkaar lijken; als je heel goed bent in een taal kan je makkelijk overstappen.

[Ryur]

Roman schreef op donderdag 05 november 2015 @ 07:57:
[...]
Ik kan wel nog meer voorbeelden geven waarin, vooral Java maar ook .Net, traag is. Zelfs producten van Microsoft, zoals de nieuwe Navision Role Tailored Client, welke in Visual C# geschreven zou moeten zijn volgens onze leverancier, voelt traag.

Ik ben zelf een Microsoft Dynamics NAV programmeur (niet de pakket zelf maar de modules).

Allereerst het pakket heet geen Navision meer . En het is ook niet geschreven in Visual C# maar in C#.

RTC kan relatief traag zijn, heel erg afhankelijk hoe de config staat en hoe de NAV Application Server (de NAS) instelt staat.
Momenteel is MS vooral met NAV2016 enorm aan het pushen naar de webclient i.p.v. RTC. En die is heerlijk!

[RayNbow]

pedorus schreef op donderdag 05 november 2015 @ 00:04:
Dan liever c++ programmatuur die willekeurig crashed en security bugs bevat zullen we maar zeggen

High performance crashes...

Roman schreef op donderdag 05 november 2015 @ 07:57:
Ook vind ik aan het Intermediate het probleem, zal wel aan mij liggen, dat ik op de elke machine de runtime moet hebben geïnstalleerd. Ik kan niet zomaar het programma nemen en ergens op een machine draaien. En als ik dan, zoals bij java gevoeld, elke week een update krijg, wordt ik daar ook niet echt vrolijk van.

Je hebt altijd wel een of andere runtime nodig, tenzij je alles statisch gaat linken.

[Twazerty]

Roman schreef op donderdag 05 november 2015 @ 07:57:

[...]

Ook vind ik aan het Intermediate het probleem, zal wel aan mij liggen, dat ik op de elke machine de runtime moet hebben geïnstalleerd. Ik kan niet zomaar het programma nemen en ergens op een machine draaien. En als ik dan, zoals bij java gevoeld, elke week een update krijg, wordt ik daar ook niet echt vrolijk van.

In ieder geval gaat mijn keuze naar een niet Intermediate Language. Heb met https://www.freebyte.com/programming/ een leuke site gevonden waar redelijk wat aan talen staat.

Ook dat is niet waar. Je kunt prima java applicaties draaien zonder de JRE geinstalleerd te hebben. Dus geen last van updated en andere afhankelijkheden. Je packaged de JRE gewoon mee.

Je schopt wel veel mensen tegen hun benen met zulke uitspraken heb ik het idee.

[Anoniem: 172410]

Roman schreef op donderdag 05 november 2015 @ 07:57:
Het kan zijn dat goede programmeurs er wat minder stroefigs kunnen bakken. Weet natuurlijk niet wat die bedrijven voor programmeurs hebben die ons een kassasysteem van 100k verkopen, (we hebben 70 kassa's nodig en dan zit je bij elk bedrijf ergens tussen de 80k en 120k).

Misschien helpt het als je dingen gaat kwantificeren, in plaats van zaken te baseren op 'een gevoel van stroevigheid'. Daar kunnen mensen natuurlijk niet veel mee en valt ook onmogelijk te ontkrachten, dan wel te bevestigen, buiten dat mensen terecht aangeven dat het niet zo hoeft te zijn.

[farlane]

pedorus schreef op donderdag 05 november 2015 @ 00:04:
Dan liever c++ programmatuur die willekeurig crashed en security bugs bevat zullen we maar zeggen

Op welke manier is Java of .NET daar niet vatbaar voor dan? ( Of daar die smiley voor bedoeld? )

valvy schreef op donderdag 05 november 2015 @ 07:07:
Java is in de meeste gevallen sneller dan c++.

Zou je dat kunnen onderbouwen? Mijn (subjectieve) ervaringen zijn echt anders.

[WoutervOorschot]

C# .NET is volledig gratis qua ontwikkeltools, tutorials, documentatie en publishing(windows store als je Universal Windows Apps maakt).

Langzaam kan ik me niet in vinden, ja het is langzamer dan C één maal compilen en dan draaien. C# is ook een concurrent van Java. Dat is de trade-off, makkelijker te leren, veel betere 'toegang' tot ingewikkelde functionaliteit (asynchroon is zeer makkelijk geworden). Sinds een tijdje is .NET open source en kan je het cross-platform als ASP.NET gebruiken, WPF en Windows Forms zijn echter altijd nog windows-only.

C# kan met mono voor Linux(en opzich dus ook mac) kunnen worden gecompiled, via xamarin voor android, iOS, mac en windows developen.

Als je er mee wilt beginnen en de basiskennis nog nodig hebt: channel9.msdn.com en dan zoeken op c# for absolute beginners, en windows 10 development for absolute beginners als je dat leuk vindt.

Anders is ieder antwoord dat je nodig hebt ook wel op stackoverflow te vinden. De documentatie op msdn is zeer goed uitgewerkt, compleet en duidelijk en goed doorzoekbaar gepresenteerd.

Visual Studio is gratis, en wordt over het algemeen toch als één van de, zo niet de beste, IDE gezien. Het is gratis, en je kan er praktisch alles mee(zelfs iOS development, java nog niet echt).

Als je .NET programma langzaam is heb je het verkeerd gemaakt want .NET is niet langzaam.

[H3llrais3r]

Mijn vraag zou zijn:
wat bedoel je met langzaam?

1) Windows Form met alleen knopjes (native controls ex. data grids e.d.)
2) Windows Form met een datagrid => welke meer dan 10.000 records toont(willekeurig x aantal)

[Siebsel]

Roman schreef op donderdag 05 november 2015 @ 07:57:
Ook vind ik aan het Intermediate het probleem, zal wel aan mij liggen, dat ik op de elke machine de runtime moet hebben geïnstalleerd. Ik kan niet zomaar het programma nemen en ergens op een machine draaien. En als ik dan, zoals bij java gevoeld, elke week een update krijg, wordt ik daar ook niet echt vrolijk van.

Waarbij het .NET framework al sinds Windows Vista (dacht ik) standaard geinstalleerd staat, dus feitelijk elke Windows machine die geleverd is vanaf 2007 kan de applicatie draaien.

[elleP]

Ik ben zelf nogal fan van c++ met qt-creator. Werkt cross-platform en lekker snel

edit: wat onderbouwing is wel een goed idee ja

Ik gebruik waar mogelijk linux en dus heb ik me nooit in visual studio verdiept, omdat dat gebonden WAS aan windows. De recente ondersteuning voor linux vind ik leuk, maar ik heb nog geen tijd gehad om er naar te kijken.

De keuze voor QT is wat mij betreft makkelijk, je klikt er vrij makkelijk een gui mee in elkaar die er uit ziet alsof het een onderdeel is van het os. Mijn (hopeloos outdated) ervaring met java is dat je enorm ziet dat het java is.

Wat betreft mijn keuze voor c++, ik ben in het dagelijks leven embedded programmeur en mijn professionele ervaring is in c en c++ dus voor mijn hobbyprojecten heb ik nooit zin gehad om iets anders te leren.

Als laatste nog even over software bloat: Do One Thing and Do It Well. Kleine tooltjes die gewoon werken zijn goed.

[ Voor 84% gewijzigd door elleP op 05-11-2015 10:48 . Reden: onderbouwing ]

[Roman]

Twazerty schreef op donderdag 05 november 2015 @ 08:34:


Je schopt wel veel mensen tegen hun benen met zulke uitspraken heb ik het idee.

Sorry hiervoor.

Ik weet niet of het aan mij ligt maar ik vind dat software de laatste jaren überhaupt trager en groter geworden is. Okee er zit steeds meer in en zier er fancy uit. Ik vind het b.v. ook vreemd dat ik voor een simpel pinterdrivertje een paar honderd mb moet downloaden. Is een vreemde ontwikkeling.

WoutervOorschot schreef op donderdag 05 november 2015 @ 09:41:

Als je .NET programma langzaam is heb je het verkeerd gemaakt want .NET is niet langzaam.

Vind van Visual Studio iig wel dat je makkelijk wat kan bouwen en een hoop documentatie kan vinden. En dat ik het niet goed geprogrammeerd heb zal ook wel logisch zijn aangezien ik maar heel weinig erin gedaan heb. Vraag me dat af als je dat zou proberen op een P-III te draaien en eens te kijken hoe dat presteert.

[ Voor 34% gewijzigd door Roman op 05-11-2015 10:33 ]

[RobIII]

elleP schreef op donderdag 05 november 2015 @ 10:16:
Ik ben zelf nogal fan van c++ met qt-creator. Werkt cross-platform en lekker snel

En dit is nou precies waarom we Welke programmeertaal moet ik leren? hebben geschreven en waarom dit soort topics geen lang leven beschoren zijn. Replies zonder onderbouwing, iedereen gaat zijn haar favo taaltje roepen zonder onderbouwing, welles-nietes spelletjes etc. Als het topic op deze voet door gaat is het alsnog geen lang leven beschoren.

Roman schreef op donderdag 05 november 2015 @ 10:24:
Ik weet niet of het aan mij ligt maar ik vind dat software de laatste jaren überhaupt trager en groter geworden is. Okee er zit steeds meer in en zier er fancy uit. Ik vind het b.v. ook vreemd dat ik voor een simpel pinterdrivertje een paar honderd mb moet downloaden. Is een vreemde ontwikkeling.

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. - Jamie Zawinski

En een ander slim iemand schreef dit

Programma's worden natuurlijk ook groter omdat we steeds meer, en goedkopere, opslag, CPU cores, geheugen etc. hebben.

[ Voor 39% gewijzigd door RobIII op 05-11-2015 10:30 ]

[Anoniem: 172410]

Roman schreef op donderdag 05 november 2015 @ 10:24:
Ik weet niet of het aan mij ligt maar ik vind dat software de laatste jaren überhaupt trager en groter geworden is. Okee er zit steeds meer in en zier er fancy uit. Ik vind het b.v. ook vreemd dat ik voor een simpel pinterdrivertje een paar honderd mb moet downloaden. Is een vreemde ontwikkeling.

Ik krijg toch sterk de indruk dat je een bepaald idee hebt van de stand van zaken en dat je je waarnemingen en conclusies met enige moeite naar dat idee probeert te buigen. Ik laat me graag overtuigen als het anders is.

[Roman]

Mooi stukje dat over de software bloat, en dat uit 2008, is volgens mij maar erger geworden.

@Camacha: dat zou kunnen.

@RobIII: Vind het juist handig als iemand iets roept, zo hoort men soms van andere dingen waarvan man niet op de hoogte is.

[RobIII]

Roman schreef op donderdag 05 november 2015 @ 10:50:
@RobIII: Vind het juist handig als iemand iets roept, zo hoort men soms van andere dingen waarvan man niet op de hoogte is.

Iets roepen: best. Maar dan wel met onderbouwing. Als je bang bent om iets te missen ben je veel meer geholpen met dit; hoeft niemand meer iets te roepen en is 't topic klaar

[.oisyn]

valvy schreef op donderdag 05 november 2015 @ 07:07:
Java is in de meeste gevallen sneller dan c++.

Wat zijn "de meeste gevallen"?

[Roman]

RobIII schreef op donderdag 05 november 2015 @ 10:56:
[...]

Iets roepen: best. Maar dan wel met onderbouwing. Als je bang bent om iets te missen ben je veel meer geholpen met dit; hoeft niemand meer iets te roepen en is 't topic klaar

Ik mis STOS in die lijst... sorry....

[ZaZ]

.oisyn schreef op donderdag 05 november 2015 @ 11:04:
[...]
Wat zijn "de meeste gevallen"?

Lijkt me simpel: De gevallen die geen uitzondering zijn

[Haan]

Roman schreef op donderdag 05 november 2015 @ 11:10:
[...]


Ik mis STOS in die lijst... sorry....

Staat genoemd in See Also -> List of Basic Dialects

[TunderNerd]

Wat ik gebruik? Python (kan gecompileerd worden, erg interessant als snelheid in het geding komt), en C voor de cruciale delen (drivers, inhaken op Linux, etc). Pracht combinatie én platform onafhankelijk!

[Denarius]

Ik wil even reageren op het idee dat .Net (met name C#) traag, log en stroperig is.
Dit is alleen waar als je niet in de gaten hebt waarom het zo aanvoelt.

Even een korte achtergrond.
Ik heb heel veel in C, C++ (met én zonder Qt), en Java gedaan.
Sinds begin dit jaar echt bezig gegaan met C#, omdat het bedrijf waar ik nu voor werk daarin zijn programma's schrijft.

Wat moet ik doen in C#.
Let op dat deze programma's die ik in C# schrijf, programma's zijn die zoveel mogelijk, als niet altijd, real-time en soepel moeten verlopen. Waar ik hiermee wil zeggen is dit. Dat kan ook in C#. Mits je weet waar je mee bezig bent en wat de omgeving onderwater allemaal aan het doen is.

Het probleem waar de niet .Net programmeurs en 'leken' tegenaan lopen.
Het grootste probleem dat ik hoor is, het is traag. Maar de vraag is eigenlijk: Waaróm is het traag?
Nou, omdat C# heel erg sterk leunt op Threading! En de main thread (dat wat alles grafisch regelt in C#) stopt op het moment je grafisch iets wil doen, of een zware berekening wil doen op deze main thread.

De les die je hieruit leert is deze. Als een programmeertaal de main thread de grafische thread laat zijn, dan moet je daar zo min mogelijk in doen en alles in andere threads moet doen. En dit is het lastigste eraan. Want daar kan heel wat verkeerd gaan.
En sommige dingen mag en kun je alleen maar op de main thread doen (alles wat grafisch is namelijk)

De laatste tip die ik geef.
Snel iets in elkaar flansen wat werkt is makkelijker dan iets in elkaar flansen wat goed en vloeiend werkt. Dit is waar voor elke willekeurige taal die je gebruikt. Dus als je voor een taal kiest, verdiep je dan in de eigenaardigheden van die taal. Welke taal dat dan ook mag zijn. En verdiep je vooral in die eigenaardigheden die het langzaam en log laat aanvoelen. Want dan heb je in eerste instantie niet begrepen wat de taal/omgeving onderwater allemaal aan het doen is om dat éne wat jij wilt voor elkaar te krijgen.
Maar de belangrijkste. Verdiep je pas in de eigenaardigheden als en wanneer je er tegenaan loopt.

[mashell]

De discussie over wat goed en niet goed is ga ik niet aan. Maar wil best deze vraag beantwoorden:

Maar... wat is er nog? Zijn er nog andere goedkope programmeer talen? Is er nog een echte betaalbare C++ (alhoewel ik nooit echt goed was in C++, ik ben meer het Pascal Type). Waar programmeren jullie mee?

Ja dat is er. Uit de Open Source wereld is er GCC. Top compiler. Kan C, C++. En met gratis tools als Cygwin ook op Windows.

[Anoniem: 172410]

Roman schreef op donderdag 05 november 2015 @ 10:50:
@Camacha: dat zou kunnen.

Nog maar eens expliciet dan: heb je iets gemeten, of gaat het alleen om een subjectieve waarneming?

[.oisyn]

mashell schreef op donderdag 05 november 2015 @ 11:55:
Ja dat is er. Uit de Open Source wereld is er GCC. Top compiler. Kan C, C++. En met gratis tools als Cygwin ook op Windows.

Nog een andere topcompiler: Visual C++. Community edition is ook gewoon gratis. Met een shitload aan performance tools. Ook gratis. En natuurlijk gewoon te gebruiken voor commerciele projecten (max 5 Visual Studio Community Edition gebruikers binnen een non-enterprise bedrijf)

[ Voor 9% gewijzigd door .oisyn op 05-11-2015 12:16 ]

[hellum]

Roman schreef op woensdag 04 november 2015 @ 07:11:
Maar... wat is er nog? Zijn er nog andere goedkope programmeer talen? Is er nog een echte betaalbare C++ (alhoewel ik nooit echt goed was in C++, ik ben meer het Pascal Type). Waar programmeren jullie mee?

Als je meer het Pascal type bent, http://www.freepascal.org/

[Kwistnix]

Denarius schreef op donderdag 05 november 2015 @ 11:38:
De les die je hieruit leert is deze. Als een programmeertaal de main thread de grafische thread laat zijn, dan moet je daar zo min mogelijk in doen en alles in andere threads moet doen. En dit is het lastigste eraan. Want daar kan heel wat verkeerd gaan.
En sommige dingen mag en kun je alleen maar op de main thread doen (alles wat grafisch is namelijk)

Dat geldt ook voor Swing applicaties in Java. Enigszins kostbare operaties moet je niet op de Event Dispatch Thread uitvoeren, maar asynchroon in een worker thread. Helaas gebeurd dat vaker niet dan wel en dat maakt dat een applicatie ontzettend langzaam/unrepsonsive aanvoelt. Dat wordt dan vertaald naar: "Java is langzaam". Wat absolute onzin is.

[.oisyn]

Maar bij Swing komt ook nog eens kijken dat het een overgeabstraheerde bende is waardoor er gewoonweg heel veel programmacode wordt uitgevoerd voor relatief simpele operaties. Dat ligt uiteraard aan het framework zelf, niet zozeer aan het platform waarop het gebouwd is.

[farlane]

Denarius schreef op donderdag 05 november 2015 @ 11:38:
Let op dat deze programma's die ik in C# schrijf, programma's zijn die zoveel mogelijk, als niet altijd, real-time en soepel moeten verlopen

Wij hebben een andere definitie van realtime.

.oisyn schreef op donderdag 05 november 2015 @ 12:30:
Maar bij Swing komt ook nog eens kijken dat het een overgeabstraheerde bende is waardoor er gewoonweg heel veel programmacode wordt uitgevoerd voor relatief simpele operaties. Dat ligt uiteraard aan het framework zelf, niet zozeer aan het platform waarop het gebouwd is.

Net als .NET zeg maar.

[.oisyn]

Ik vind het nogal kort door de bocht om daar heel .Net van te beschuldigen. Ik noemde ook specifiek Swing, de .Net tegenhanger zou WPF zijn (met het verschil dat WPF wel hardwarematige rendering ondersteunt ). Java AWT is rap, net als Windows Forms.

[R3M1]

Roman schreef op woensdag 04 november 2015 @ 07:11:
Ik ben jongst weer een beetje begonnen met programmeren. Wat simpele Windows programma's in elkaar knutselen. Of moet ik dat tegenwoordig ook app noemen? Nee beter niet.

Ben dus een beetje op zoek gegaan naar wat er nu allemaal zo op de markt is en uiteraard ook niet te duur, of beter nog gratis. Ben er gauw achter gekomen dat ook Microsoft tegenwoordig in de "Intermediate language" sector onder weg is. Vroeger had je Visual Basic waarmee je een progje kon knutselen. En nu is er Visual Studio met Visual Basic, Visual C(++) en Visual C#. En dan nog de gratis versie Visual Studio Express. Lijkt leuk.. is Intermediate. Wat wil dit zeggen, nou het is net Java, traag. Omdat het half gecompileerd word en pas bij het uitvoeren geheel compileert word. Daarom heb je ook altijd het .Net Framework nodig.

Ze zeggen dat je het niet zou merken met de snelheden van de computers van tegenwoordig. Maar ik moet zeggen je merkt het wel. Ik zie een hoop bedrijven die hun producten met Visual Studio bouwen (is eraan te merken dat ze altijd zeggen dat .Net nodig is). En hun producten voelen altijd traag aan, ook met een quad core en een berg geheugen. Ik zie het momenteel op mijn werk, we zij aan het zoeken naar een nieuw kassasysteem. Diverse systemen gezien, bijna allemaal gebaseerd op .Net en in vergelijking met ons oude systeem (geprogrammeerd in Delphi) zijn ze traag, terwijl ze nog niet eens dat kunnen wat ons oud systeem kan. Maar dat terzijde.

Ook zeggen ze dat Intermediate languages platform en OS onafhankelijk zijn. Bij Java klopt dat ook, maar .Net is Microsoft en eigenlijk alleen maar voor Windows producten te verkrijgen, tenminste de officiële. Er zijn wel wat projecten om .Net op Mac en Linux te gebruiken.

Delphi is ook een leuk trefwoord. Ja het bestaat nog steeds, alleen niet meer van Borland. En is vrij prijzig. Alternatief is er Lazarus, wat gebaseerd is op Delphi (voelt aan als Delphi 5), maar dan ook prima werkt op Windows 7/8 en waarschijnlijk ook op 10, en verder is er ook een Mac en Linux compiler. En het is geheel gratis.

Maar... wat is er nog? Zijn er nog andere goedkope programmeer talen? Is er nog een echte betaalbare C++ (alhoewel ik nooit echt goed was in C++, ik ben meer het Pascal Type). Waar programmeren jullie mee?

De vraag is natuurlijk wat ik ermee wil doen. Geen idee. Ten eerste denk ik weer wat grondkennis opdoen. En later misschien wat kleinere programmaatjes maken, wat kan ik nog niet zeggen.

Echte mannen programmeren is ASM - probeer dat eens

Nee, zonder grappen maar elke generieke taal heeft een stap om van generiek naar specifieke machine code te gaan, met zoals door anderen aangeven vele variaties van coderen en deployen.

Het is niet zo eenduidig als in jouw betoog.

[Anoniem: 699645]

Mijn ervaring is dat je zonder ervaring met C# en XAML al heel snel productief kan zijn, en met Visual Studio in combinatie met Xamarin kun je er op alle gangbare platformen mee uit de voeten. C# en XAML zijn niet alleen zeer geschikt voor data driven applicaties, maar ook prima voor wat simpelere spelletjes. Ik ben eerder dit jaar met nul ervaring begonnen en heb ongeveer een maandje geleden mijn eerste game in de Windows Store gepubliceerd gemaakt in met 100% puur XAML en C#. Kijk hier maar eens: http://bit.ly/1KSzgp6

[Quinz]

Informeren wat een goede taal is om in te programmeren is hetzelfde als vragen wat de beste auto is om in te rijden. Vraag honderd programmeurs en allemaal geven ze een ander antwoord. Meestal zal de taal worden aanbevolen waar iemand op dat moment in programmeert of waar ze een goede ervaring mee hebben.

Snelheid is natuurlijk een factor om een voorkeur op te baseren, maar natuurlijk niet de enige. Denk bijvoorbeeld aan de documentatie, learning curve, platformbeschikbaarheid, beschikbare frameworks, kosten, taalconsistentie, toepassing, IDE en SDK.

De snelheid is naast een taaleigenschap sterk afhankelijk hoe je programmeert en op welk platform de applicatie moet draaien. En in sommige gevallen is het niet eens een issue.

Het handigste is om eerst te bepalen wat je wil maken en aan de hand daarvan een taal te selecteren die je het meeste aanspreekt. Als je bijvoorbeeld geen webgerelateerd product wil gaan maken heeft JavaScript niet heel veel zin (hoewel ook dat inmiddels niet meer het geval is).

Ik zou je adviseren om een taal uit te kiezen die niet heel erg mainstream is. Mede doordat de community die er achter zit meestal fanatieker is om je te helpen. En gewoon omdat het leuk is. Denk bijvoorbeeld aan Go of Ruby on Rails. Of verdiep je in AngularJS.

[DXaroth]

Programmeertalen zijn stukken gereedschap, en als je alleen om kan gaan met een hamer, wordt elk probleem een spijker.

Mijn advies zou zijn, begin met simpele talen, en leer de basisprincipes van programmeren.. deze principes zijn (nagenoeg) altijd hetzelfde ongeacht de taal die je gebruikt, dus of je het nou leert terwijl je met python bezig bent, met ANSI C, of met brainfuck, dat maakt weinig uit (al is brainfuck niet het beste voorbeeld....)

Zodra je wat onder de knie hebt, richt je op de dingen waar je je in wilt verdiepen.. je gaat waarschijnlijk geen C nodig hebben als je website backends wilt bouwen, en java is wellicht niet de beste keuze als je hardware drivers gaat bakken, maar als je weet wat ze wel kunnen, dan kan je voor jezelf de keuze maken waar je mee verder gaat.

En serieus, mensen, al die onzin over welke taal de beste performance heeft.. tegen de tijd dat je een use-case hebt waarbij je die extra microseconden nodig hebt om iets snel genoeg uit te voeren heb je hele andere problemen... 90% van de snelheid van een applicatie ligt niet aan de taal die gebruikt wordt.

[WoutervOorschot]

Denarius schreef op donderdag 05 november 2015 @ 11:38:
Het probleem waar de niet .Net programmeurs en 'leken' tegenaan lopen.
Het grootste probleem dat ik hoor is, het is traag. Maar de vraag is eigenlijk: Waaróm is het traag?
Nou, omdat C# heel erg sterk leunt op Threading! En de main thread (dat wat alles grafisch regelt in C#) stopt op het moment je grafisch iets wil doen, of een zware berekening wil doen op deze main thread.

De les die je hieruit leert is deze. Als een programmeertaal de main thread de grafische thread laat zijn, dan moet je daar zo min mogelijk in doen en alles in andere threads moet doen. En dit is het lastigste eraan. Want daar kan heel wat verkeerd gaan.
En sommige dingen mag en kun je alleen maar op de main thread doen (alles wat grafisch is namelijk)

Dit is één van de grote valkuilen in C# .net inderdaad. Daarom moet je in bijvoorbeeld uwp apps(in tegenstelling tot wpf of winforms) alles wat eventueel ietsje langer kan duren(ophalen content/bestanden, inladen locale data) async doen. Sinds .net4(volgens mij) is asynchroon threads maken dan ook doodsimpel gemaakt zodat iedereen dat kan. VS geeft ook aan wanneer iets async moet en hoe het dan moet.

[.oisyn]

Dat is natuurlijk niet een kenmerk van .Net, maar een vrij generiek programmeerprobleem.

[Denarius]

farlane schreef op donderdag 05 november 2015 @ 13:28:
[...]

Wij hebben een andere definitie van realtime.


[...]

Net als .NET zeg maar.

Oew, een aanname met daarin meteen een conclusie verweven. Altijd leuk!

Ik denk toch echt dat wij allebei hetzelfde bedoelen met realtime.
Dus indien dit toch niet het geval is, zal ik de mijne maar opnoemen.

De garantie geven om binnen een voorafbepaalde verstreken tijd gereageerd te hebben.

Bij mijn .Net applicatie is die voorafbepaalde verstreken tijd 200ms.
De langste verstreken tijd is 120ms. Het gemiddelde is tussen de 20ms en 30ms.

De applicaties draaien in een productie omgeving waarin deze reactie tijd gegarandeerd moet zijn.

Mijn vraag aan jouw.
Wat is jouw definitie van realtime?

[farlane]

Denarius schreef op donderdag 05 november 2015 @ 17:53:
De garantie geven om binnen een voorafbepaalde verstreken tijd gereageerd te hebben.

Zitten we iig wel op dezelfde lijn, maar ik ben benieuwd hoe jij dat voor elkaar krijgt : Draai je een realtime versie van het .NET platform op een realtime OS?

[Denarius]

.oisyn schreef op donderdag 05 november 2015 @ 13:32:
Ik vind het nogal kort door de bocht om daar heel .Net van te beschuldigen. Ik noemde ook specifiek Swing, de .Net tegenhanger zou WPF zijn (met het verschil dat WPF wel hardwarematige rendering ondersteunt ). Java AWT is rap, net als Windows Forms.

WPF is de vervanger van Windows Forms.
Maar veel mensen programmeren nog met Forms omdat ze dat vertrouwd vinden.

@TS
De vraag moet niet zijn welke programmeertaal het beste is.

De vraag moet eigenlijk zijn met welke talen je je doel kunt bereiken binnen de gestelde eisen die je stelt.
Het antwoord is hier heel vaak op:
(Bijna) allemaal.
Het ligt er alleen aan of je de taal goed gebruikt en/of beheerst.

[Denarius]

farlane schreef op donderdag 05 november 2015 @ 17:59:
[...]

Zitten we iig wel op dezelfde lijn, maar ik ben benieuwd hoe jij dat voor elkaar krijgt : Draai je een realtime versie van het .NET platform op een realtime OS?

Nee, en nee.
Maar in hoever kun je garantie geven?
Ik moet alles uit een SQL Database halen, verwerken en het juiste antwoord terug sturen.
De verloren tijd zit meestal in hoe efficiënt je de queries schrijft, hoe stabiel en druk het op het netwerk is, etc. etc.

Pas als je overal kan aantonen dat het met bepaalde hardware etc. de garantie kunt geven. Dan is het realtime.

Een niet strikt realtime OS kan alsnog realtime zijn als het maar binnen de gestelde tijd kan reageren.
Veel testen en data verzamelen waar de knelpunten zitten dus. Het is soms wel erg lastig om de externe invloeden te beperken. Het gehele systeem moet niet voor niks aan bepaalde eisen voldoen.

edit:
Maar we dwalen af van de Topic.
Na je antwoord zal ik er waarschijnlijk niet op reageren

[ Voor 5% gewijzigd door Denarius op 05-11-2015 18:07 ]

[Sissors]

pedorus schreef op donderdag 05 november 2015 @ 00:04:
c++ is niet echt een taal voor de middelbare school. Schijnt php, visual basic, alice enzo beter voor te zijn.

Ook een mooie voor de lijst ongefundeerde uitspraken.

[.oisyn]

Denarius schreef op donderdag 05 november 2015 @ 17:59:
[...]


WPF is de vervanger van Windows Forms.
Maar veel mensen programmeren nog met Forms omdat ze dat vertrouwd vinden.

De relevantie met mijn post ontgaat me even...

[Denarius]

.oisyn schreef op donderdag 05 november 2015 @ 19:22:
[...]

De relevantie met mijn post ontgaat me even...

Het leek alsof je Windows Forms en WPF naast elkaar zette en Windows Forms efficiënter achtte.
Maar ik kan het ook verkeerd gelezen hebben. Waarschijnlijk wel.
Indien verkeerd begrepen, mijn excuses

[.oisyn]

Dat deed ik ook. WinForms bouwt namelijk op native win32 UI en is heel straight-forward. Dat WPF de vervanger is verandert daar verder niets aan .

Precies hetzelfde kun je overigens zeggen over Swing en AWT.

[Kwistnix]

.oisyn schreef op donderdag 05 november 2015 @ 12:30:
Maar bij Swing komt ook nog eens kijken dat het een overgeabstraheerde bende is waardoor er gewoonweg heel veel programmacode wordt uitgevoerd voor relatief simpele operaties. Dat ligt uiteraard aan het framework zelf, niet zozeer aan het platform waarop het gebouwd is.

Ik weet niet of ik er in mee kan gaan dat Swing een bende is, maar ik snap je punt
Het zijn inderdaad "lightweight" (niet mijn woordkeuze) pure Java componenten, waar bijv. AWT gewoon direct native calls maakt. Inefficiënter is Swing op dat gebied zeker, maar niet dusdanig dat het merkbaar is een applicatie die degelijk geprogrammeerd is. Maar goed, client-side programmeren in Java is wel redelijk dood en begraven en dat graf is inmiddels ook al geruimd. Ondanks dat Oracle het met JavaFX toch blijft proberen.

[pedorus]

TunderNerd schreef op donderdag 05 november 2015 @ 11:18:
Wat ik gebruik? Python (kan gecompileerd worden, erg interessant als snelheid in het geding komt), en C voor de cruciale delen (drivers, inhaken op Linux, etc). Pracht combinatie én platform onafhankelijk!

Pythonprogrammeurs zeggen vaak dat ze performance-gerelateerde stukken in C gaan doen, maar in de praktijk komt het daar meestal niet van. En de vraag is ook wat je moet doen als het performanceprobleem zo'n beetje overal zit. C dat inhaakt op Linux klinkt overigens niet heel platform-onafhankelijk. Fact of the matter is toch dat je nooit Python hoog aantreft op dit soort lijstjes:
https://www.techempower.c...n=data-r10&hw=ec2&test=db
Steevast staan java en c++ (achtigen) bovenaan. Python is een schitterende taal die ik zelf ook gebruik, maar performance en type safety (gaan vaak hand-in-hand) doen mij vaak toch java/scala de voorkeur geven. Java is enkel een stuk verboser (vb: http://spark.apache.org/examples.html ). Aangezien ik werk met veel data, en anderen die hetzelfde doen die 3 talen lijken te prefereren, valt daarom voor mij vaak de keuze op Scala.

Het punt is dus dat kijken naar wat anderen doen die soortgelijke problemen oplossen wat mij betreft de beste oplossing is om een taal te kiezen. Voor veel anderen zal performance bijvoorbeeld een veel kleiner probleem zijn dan voor de dingen die ik nu doe. De meeste websites worden in scripting talen gemaakt bijvoorbeeld.

Sissors schreef op donderdag 05 november 2015 @ 18:46:
[...]

Ook een mooie voor de lijst ongefundeerde uitspraken.

Dat c++ niet de meest geschikte taal voor middelbare school is, is niet ongefundeerd, de fundering staat er nu alleen niet bij en kun je zo googelen. Zelfs in de c++ community raadt men dat vaak niet aan, zie bijv:
http://www.cplusplus.com/forum/lounge/169024/
http://programmers.stacke...ts-where-to-draw-the-line
En gek genoeg staat hier ook heel weinig c++: Wikipedia: List of educational programming languages
Iets als Alice is daarentegen specifiek hiervoor bedacht.

farlane schreef op donderdag 05 november 2015 @ 09:01:
Op welke manier is Java of .NET daar niet vatbaar voor dan? ( Of daar die smiley voor bedoeld? )

De smiley is inderdaad omdat het inderdaad een grapje is, want problemen kun je in elke taal krijgen. Het verschil lijkt mij oa bounds checking en managed memory (geen pointers) in die andere talen (mits geen native constructies). En tools als MySQL Workbench en Robomongo die ik gebruik lijken mij overtuigend geschreven in c++, want die crashen op vreemde manieren. Hadden ze nu maar java gebruikt

Kwistnix schreef op donderdag 05 november 2015 @ 23:03:
[...]

Ik weet niet of ik er in mee kan gaan dat Swing een bende is, maar ik snap je punt
client-side programmeren in Java is wel redelijk dood en begraven en dat graf is inmiddels ook al geruimd. Ondanks dat Oracle het met JavaFX toch blijft proberen.

Minecraft, misschien wel het meest gespeelde spel in Nederland van dit moment, is dood en begraven, en het graf is inmiddels ook al geruimd? Back to the future?

Roman schreef op donderdag 05 november 2015 @ 07:57:
Ook vind ik aan het Intermediate het probleem, zal wel aan mij liggen, dat ik op de elke machine de runtime moet hebben geïnstalleerd. Ik kan niet zomaar het programma nemen en ergens op een machine draaien. En als ik dan, zoals bij java gevoeld, elke week een update krijg, wordt ik daar ook niet echt vrolijk van.

De grap is dat bij een taal waar de libraries er in gecompileerd worden upgraden en zo bijvoorbeeld security problemen oplossen veelal niet mogelijk is. Die blijven dan dus zitten. Ditzelfde effect kun je bereiken door java niet te upgraden, dat doen wij na de initiële installatie (op servers) dan ook veelal trouwens. Dat je java up to date moet houden is specifiek iets vanwege de java-plugin in browsers, en die plugin zou verboden moeten worden en moet je zeker niet installeren.

[.oisyn]

pedorus schreef op donderdag 05 november 2015 @ 23:55:
Dat c++ niet de meest geschikte taal voor middelbare school is, is niet ongefundeerd, de fundering staat er nu alleen niet bij en kun je zo googelen.

Als C++ evangelist () kan ik het hier alleen maar mee eens zijn. C++ is als taal ontzettend complex en zou ik absoluut niet aanraden als instapper op een middelbare school. Beter leer je eerst de basisprincipes voor het programmeren voor je je stukbijt in allerlei low-level details. En zeker op middelbare schoolniveau wil je iets dat snel leuk resultaat oplevert, en ben je beter af met iets als GameMaker.

[HuHu]

Ik kreeg op de middelbare school Java en GameMaker . Ik hoorde dat sommige scholen tegenwoordig Python doen en dat zou persoonlijk momenteel ook mijn voorkeur zijn voor een middelbare school en/of instaptaal.

[stevens20]

.oisyn schreef op vrijdag 06 november 2015 @ 01:09:
[...]

Als C++ evangelist () kan ik het hier alleen maar mee eens zijn. C++ is als taal ontzettend complex en zou ik absoluut niet aanraden als instapper op een middelbare school. Beter leer je eerst de basisprincipes voor het programmeren voor je je stukbijt in allerlei low-level details. En zeker op middelbare schoolniveau wil je iets dat snel leuk resultaat oplevert, en ben je beter af met iets als GameMaker.

Oké, dank je! Dan ga ik dat ook leren. Ondertussen doe ik ook wat aan C++. Dat gaat redelijk snel al zeg ik het zelf.

[begintmeta]

Rust, Ada en Fortran doen het qua snelheid ook niet slecht, zeker in specifieke gevallen maar ook 'algemeen'*, bijvoorbeeld bij Python valt de enorme spreiding van de snelheid ten opzicht van de snelste implementatie op, soms erg snel, vaak behoorlijk veel langzamer, daarbij kan een alternatieve taalkeuze voor een bepaald deel van het programma dus wel wat opleveren. Vooral Rust ziet er dan eigenlijk best interessant uit.

[ Voor 50% gewijzigd door begintmeta op 06-11-2015 10:58 ]

[DXaroth]

pedorus schreef op donderdag 05 november 2015 @ 23:55:
[...]

Pythonprogrammeurs zeggen vaak dat ze performance-gerelateerde stukken in C gaan doen, maar in de praktijk komt het daar meestal niet van. En de vraag is ook wat je moet doen als het performanceprobleem zo'n beetje overal zit. C dat inhaakt op Linux klinkt overigens niet heel platform-onafhankelijk. Fact of the matter is toch dat je nooit Python hoog aantreft op dit soort lijstjes:
https://www.techempower.c...n=data-r10&hw=ec2&test=db

nogal grote aantijgingen, helemaal aangezien ze niet helemaal gefundeerd zijn.. er zijn complete projecten die zich juist focusen op dit soort dingen, en het wordt vaker gebruikt dan veel mensen denken.
Dit komt voor het meerendeel omdat de tooling om python heen veel van die taken op zich neemt, als je via pip PIL/Pillow installeerd.. denken veel dat ze een python library laden, wat ze niet zien is dat tijdens die installatie wel nog even een complete C module gecompiled wordt.. hetzelfde geld voor heel veel anderen.

Dat staat naast het feit dat veel python programmeurs zich daar ook niet al te druk om maken; in heel veel use-cases zijn het andere componenten die voor de 'traagheid' zorgen.. in een web-app heeft het geen nut om de 50ms die python nodig heeft om een pagina te renderen, terug te brengen tot 45, dat merken mensen niet.. wat je wel wilt aanpakken, zijn de 500ms+ die je staat te wachten op database queries.

[Kwistnix]

pedorus schreef op donderdag 05 november 2015 @ 23:55:
Minecraft, misschien wel het meest gespeelde spel in Nederland van dit moment, is dood en begraven, en het graf is inmiddels ook al geruimd? Back to the future?

Ja ja, iets met uitzonderingen die regels bevestigen en zo

[epic007]

'Right tool for the job' zoals al eerder gezegd..

Ik ben ook vanuit C++ begonnen en nu voornamelijk C#. Mijn ervaring is dat ik met C# veel sneller tot resultaat kom (namelijk de oplossing van een probleem) en dat de code veel leesbaarder en ondehoudbaarder is. Met C++ wordt het en bij grotere projecten toch sneller een rommeltje ( maar dat kan aan mezelf liggen ).

Performance? Tja, ik zou geen video encoder, vision applicatie of andere CPU heavy software in C# schrijven maar verder geen issues daarmee.

Als je toch beslist native wil dan lees ik goede verhalen over Rust. C++ performance maar niet de risico's op memory leaks e.d.

[farlane]

Het valt me elke keer weer op hoe "bang" men is om met C en C++ (of eigenlijk de platformen die standaard niet met een GC geleverd worden) iets te maken. Is het dan zo moeilijk om zelf je shit weer op te ruimen?

[Kwistnix]

Meestal niet bijzonder, maar het is wel vervelend. En feit is dat het in de praktijk toch wel vaak mis gaat. Een GC is gewoon heel erg handig en voor veel doeleinden prima geschikt. Het dringt de complexiteit van de code weer een stukje terug en je hoeft je hersenen niet met geheugenbeheer te vermoeien.

[begintmeta]

Kan iemand nog iets zinnigs zeggen over Julia? Ziet er op het ook ook best interessant uit.

[Bigs]

farlane schreef op vrijdag 06 november 2015 @ 12:50:
Het valt me elke keer weer op hoe "bang" men is om met C en C++ (of eigenlijk de platformen die standaard niet met een GC geleverd worden) iets te maken. Is het dan zo moeilijk om zelf je shit weer op te ruimen?

GC kan zelfs echt problematisch zijn. Ik heb menig ElasticSearch cluster (een in Java geschreven zoekmachine) in zien storten omdat nodes uit het cluster worden gegooid door lange GC runs (en dus te lang onderbroken cluster communicatie). Dan heb je toch echt een verkeerde keuze gemaakt ergens lijkt me.

[farlane]

Kwistnix schreef op vrijdag 06 november 2015 @ 13:27:
Meestal niet bijzonder, maar het is wel vervelend. En feit is dat het in de praktijk toch wel vaak mis gaat. Een GC is gewoon heel erg handig en voor veel doeleinden prima geschikt. Het dringt de complexiteit van de code weer een stukje terug en je hoeft je hersenen niet met geheugenbeheer te vermoeien.

Ja maar dat is dus vaak niet waar : in .NET bijvoorbeeld moet je unmanaged resources alsnog zelf opruimen. Je moet er dus wel over nadenken, ook al is er een GC.

[Brent]

Roman schreef op woensdag 04 november 2015 @ 07:11:
Maar... wat is er nog? Zijn er nog andere goedkope programmeer talen? Is er nog een echte betaalbare C++ (alhoewel ik nooit echt goed was in C++, ik ben meer het Pascal Type). Waar programmeren jullie mee?

De notie dat programmeren geld kost is een vreemde, ik gebruik Qtcreator en GCC naar volle tevredenheid voor C++. Python + $editor_of_the_day ook. Vroeger wat Java in Eclipse, ook prima.

De vraag is natuurlijk wat ik ermee wil doen. Geen idee.

Dit lijkt me het belangrijkste. Best tool for the job en wat dies meer zei. Maar geld betalen voor een beetje hobby coden? Dan pak je het verkeerd aan. Zelfs als je het voor je werk doet, trouwens Alle tools die ik wil zijn FLOSS.

[Kwistnix]

Bigs schreef op vrijdag 06 november 2015 @ 14:16:
[...]
GC kan zelfs echt problematisch zijn. Ik heb menig ElasticSearch cluster (een in Java geschreven zoekmachine) in zien storten omdat nodes uit het cluster worden gegooid door lange GC runs (en dus te lang onderbroken cluster communicatie). Dan heb je toch echt een verkeerde keuze gemaakt ergens lijkt me.

Verkeerde/niet getunede CMS GC die een stop-the-world garbage fase uitvoert op een heule grote heap, waarschijnlijk.

[MSalters]

farlane schreef op vrijdag 06 november 2015 @ 12:50:
Het valt me elke keer weer op hoe "bang" men is om met C en C++ (of eigenlijk de platformen die standaard niet met een GC geleverd worden) iets te maken. Is het dan zo moeilijk om zelf je shit weer op te ruimen?

Ja. Dat is een feitelijke conclusie gebaseerd op 30 jaar Software Engineering onderzoek. Het is niet zo moelijk om het 99% goed te doen, maar die laatste 1% leidt tot programma's die langzaam geheugen lekken.

Nu is GC maar 1 van de oplossingen daarvoor. GP (Prevention) is een bruikbaar alternatief, in C++ geïmplementeerd door RAII (Resource Acquisition Is Initialization). Klinkt ingewikkeld, maar betekent praktisch dat de karakters in een string tegelijk met de string zelf worden opgeruimd.

[pedorus]

DXaroth schreef op vrijdag 06 november 2015 @ 10:18:
in een web-app heeft het geen nut om de 50ms die python nodig heeft om een pagina te renderen, terug te brengen tot 45, dat merken mensen niet..

Ik ben nu bijvoorbeeld bezig met een web service die in sommige gevallen maar ~35 ms de tijd heeft om te antwoorden. En als die service consequent te laat is merken de eindklanten dat wel degelijk. In zo'n geval gebruik ik dan ook geen python of R. Right tool for the job he, daar ging het hele verhaal over.

Bigs schreef op vrijdag 06 november 2015 @ 14:16:
GC kan zelfs echt problematisch zijn. Ik heb menig ElasticSearch cluster (een in Java geschreven zoekmachine) in zien storten omdat nodes uit het cluster worden gegooid door lange GC runs (en dus te lang onderbroken cluster communicatie). Dan heb je toch echt een verkeerde keuze gemaakt ergens lijkt me.

Klinkt toch als slechte configuratie van de GC of de hoeveelheid geheugen per server (niet dat een goede configuratie eenvoudig is). En verder is het wachten totdat Shenandoah klaar is voor productie.

Kwistnix schreef op vrijdag 06 november 2015 @ 14:55:
[...]

Verkeerde/niet getunede CMS GC die een stop-the-world garbage fase uitvoert op een heule grote heap, waarschijnlijk.

Vrees het ook, snap nog steeds niet waarom de terugval naar de single threaded GC is ipv de multi-threaded. (In Google's eigen java versie is dit overigens wel het geval).

farlane schreef op vrijdag 06 november 2015 @ 12:50:
Het valt me elke keer weer op hoe "bang" men is om met C en C++ (of eigenlijk de platformen die standaard niet met een GC geleverd worden) iets te maken. Is het dan zo moeilijk om zelf je shit weer op te ruimen?

In een single threaded programma zonder cycles in de geheugenstructuur kan dit eenvoudig lijken, maar blijken mensen bepaalde situaties toch over het hoofd te zien. Met software om leaks op te sporen is dat dan vaak nog wel op te lossen. In de software die ik soms maak met vele threads, met vele cycles in de geheugenstructuur, meerdere programmeurs die er aan werken, en vaak een lange draaitijd (maanden) is dit een stuk lastiger.

Zonder managed geheugen kan het ook nog gebeuren dat het geheugen zodanig gefragmenteerd is geraakt, dat er genoeg geheugen vrij is, maar omdat je pointers niet kan verplaatsen het onmogelijk is om bepaalde allocaties te doen. Of eerder dat allocaties dusdanig inefficiënt worden omdat je niet kan 'pointer bumpen' dat de throughput dramatisch wordt. Lock-free code maken als memory (de)allocatie een lock geeft schijnt ook niet eenvoudig te zijn.

[DXaroth]

pedorus schreef op zaterdag 07 november 2015 @ 00:52:
[...]

Ik ben nu bijvoorbeeld bezig met een web service die in sommige gevallen maar ~35 ms de tijd heeft om te antwoorden. En als die service consequent te laat is merken de eindklanten dat wel degelijk. In zo'n geval gebruik ik dan ook geen python of R. Right tool for the job he, daar ging het hele verhaal over.

[...]

Dan zijn we het daar over eens want daar ging mijn hele rant over het 'X is traag' gedoe over..
Als je enkel een hamer kent wordt elk probleem al snel een spijker, maar er zijn vaak betere manieren om 2 planken te verbinden

[pedorus]

DXaroth schreef op zaterdag 07 november 2015 @ 22:19:
[...]


Dan zijn we het daar over eens want daar ging mijn hele rant over het 'X is traag' gedoe over..
Als je enkel een hamer kent wordt elk probleem al snel een spijker, maar er zijn vaak betere manieren om 2 planken te verbinden

offtopic:
"instead of trying to invent screwdrivers, we should simply get rid of everything that’s not a nail"

[BoringDay]

C++ is niet complex, de code die ermee ontwikkeld wordt kan complex zijn.

[ Voor 4% gewijzigd door BoringDay op 08-11-2015 19:52 ]

[RayNbow]

BoringDay schreef op zondag 08 november 2015 @ 19:52:
C++ is niet complex

Vandaar dat de C++11 standaard slechts 1300 pagina's of zo bevat?

[.oisyn]

Complexe code kun je overal mee schrijven. Maar C++ is als taal wedegelijk complex. Als je denkt van niet dan ken je de taal gewoon niet goed genoeg

[Anoniem: 172410]

.oisyn schreef op zondag 08 november 2015 @ 20:35:
Complexe code kun je overal mee schrijven. Maar C++ is als taal wedegelijk complex. Als je denkt van niet dan ken je de taal gewoon niet goed genoeg

If you think you understand quantum mechanics C++, you don't understand quantum mechanics C++.

[begintmeta]

LISP is naar ik heb begrepen dan weer een exteem eenvoudige taal.

[Sissors]

.oisyn schreef op vrijdag 06 november 2015 @ 01:09:
[...]

Als C++ evangelist () kan ik het hier alleen maar mee eens zijn. C++ is als taal ontzettend complex en zou ik absoluut niet aanraden als instapper op een middelbare school. Beter leer je eerst de basisprincipes voor het programmeren voor je je stukbijt in allerlei low-level details. En zeker op middelbare schoolniveau wil je iets dat snel leuk resultaat oplevert, en ben je beter af met iets als GameMaker.

Tja persoonlijk kan ik het er alleen maar mee oneens zijn. Met een paar regels C++ code kan je onder Arduino, mbed, etc ook gewoon leuk en snel resultaat hebben. Natuurlijk kan je C++ enorm complex maken, maar dat is een keuze: Random voorbeeld: Memory leaks/gebrek aan GC? Waarom moeilijk doen, gebruik nooit new/malloc en je hebt er geen last van (ja met recursieve functies kan je als je je best doet hem nog steeds laten crashen). En nee, die niet gebruiken is niet altijd een optie, maar er zijn genoeg bedrijven waar bij embedded software die gewoon standaard niet toegestaan zijn: Het kan bij genoeg projecten prima zonder die te gebruiken.

Oftewel vandaar mijn conclusie: C++ hoeft helemaal niet moeilijk te zijn, afhankelijk van wat je ermee doet. Ik zal de eerste zijn die toegeeft dat er zat zaken zijn, dat als je die wil gaan maken dat C++ absoluut niet de makkelijkste optie is. Tegelijk als je gewoon met een programmeertaal wil beginnen, wil ik wel ontkennen dat C++ per definitie een moeilijke taal is om mee te beginnen, en dat zie je dan ook erin terug dat systemen als Arduino, mbed en andere ook op middelbare scholen worden gebruikt.

[HuHu]

Arduino is wel echt iets anders dan C++. Het is er dan wel op gebaseerd, maar daar blijft het dan ook bij. In Arduino "programmeren" komt (volgens mij) vaak neer op het copy-pasten van voorbeeldcode, die je vervolgens een beetje aanpast en eventueel plak je er nog een bestaande library bij. Het daadwerkelijk begrijpen van de code en de achterliggende concepten is afwezig.

Verder is het standaard-voorbeeld van Arduino, blink, ook compleet niet object georiënteerd en gebruikt het ook geen C++ functionaliteit.

C++ is, ook naar mijn mening, veel te complex voor een beginner. Neem de simpele hello-world:

C++:

#include <iostream>
using namespace std;

int main ()
{
    cout << "Hello world.";
    return 0;
}

Bij elke regel kun je wel 10 vragen verzinnen. Wat doet include (preprocessor??), wat is iostream? Wat is een namespace, wat is using. Wat is main en zijn er wel/geen argumenten en waarom int? Wat is cout en << (een overloaded shift operator, wtf)? Waarom return 0?

Dan een simpele taal als Python:

Python:

print "Hello world"

Mijns inziens vele malen geschikter als instaptaal.

[.oisyn]

Sissors schreef op maandag 09 november 2015 @ 09:38:
[...]

Oftewel vandaar mijn conclusie: \[Gebruik C++ zonder de constructies van C++]

Tja, waarom zou je dan nog C++ gebruiken? Eigenlijk bewijs je alleen maar mijn punt.

[ Voor 7% gewijzigd door .oisyn op 09-11-2015 10:07 ]

[Brent]

C++ is complex. Echter, C++ is bij uitstek een taal waarbij je een dialect moet kiezen, en indien je je eraan houdt, de complexiteit drastisch inperkt. C++ probeert je niet tot een bepaalde stijl te duwen zoals bijv. Ruby, Python of Java. Dat is dus mooi of vervelend, hangt van jou af Het grootste nadeel daarvan wmb is het feit dat code van anderen dus vaak een vreemd dialect is, dus als je voor je werk samenwerkt, dan moet je een style afspreken of accepteren dat je stiekum vele dialecten moet gaan leren

Dat Python beter geschikt is als instaptaal, allicht. Ik gebruik beide met plezier (Python meer plezier misschien). Het tweede grote gemis in C++ is wmb het onbreken van iets als pip en de enorme verzameling libs die je snel binnen kunt slurpen. Libs voor C++ vinden en succesvol compilen, dat is een specialisme

[.oisyn]

Brent schreef op maandag 09 november 2015 @ 12:05:
C++ is complex. Echter, C++ is bij uitstek een taal waarbij je een dialect moet kiezen, en indien je je eraan houdt, de complexiteit drastisch inperkt.

Je gebruik van het woord "dialect" hier is wat verwarrend. In de context van programmeertalen betekent een dialect van een taal iets dat grote overeenkomsten heeft met de oorspronkelijke taal, maar er niet direct compatible mee is. Denk hierbij aan platform-specfieke zaken zoals __declspec in MSVC++ en __attribute__ in GCC. Maar dat is denk ik niet wat jij bedoelt. Jij hebt het meer over een subset van de taal, of specifieke paradigma's waarmee je programmeert.

Het tweede grote gemis in C++ is wmb het onbreken van iets als pip en de enorme verzameling libs die je snel binnen kunt slurpen. Libs voor C++ vinden en succesvol compilen, dat is een specialisme

Klopt, C++ specificeert geen ABI. C overigens ook niet, maar is door de opzet vele malen simpeler dat C-code binnen een platform gewoon compatible is. Libraries zijn voor het grootste deel gewoon black boxes. Std containers zijn in een gemiddelde implementatie tussen verschillende build configurations al niet eens ABI-compatible.

[Brent]

.oisyn schreef op maandag 09 november 2015 @ 12:45:
[...]

Jij hebt het meer over een subset van de taal, of specifieke paradigma's waarmee je programmeert.

Klopt. Al merk ik op dat een dialect vaak ook niet formeel gedefinieerd is, en dialecten talen zijn en vice-versa, afhankelijk van aan wie je 't vraagt. In die zin zijn de gebruikte paradigma's wmb dus dialecten, C++ code in functionele stijl zal iets tussen even wennen en totaal onbegrijpelijk zijn voor lui die klassieke OO gewend zijn. Bovendien, elke C++ revisie kun je een aparte taal noemen, in de zin dat projecten die met C++98 compilen geen C++11-ismes of later zullen slikken (helaas werk ik aan zo'n project ). In feite eenzelfde verschil als Python2 en 3: zeer gelijkende maar toch net even andere talen.

[Sissors]

HuHu schreef op maandag 09 november 2015 @ 09:53:
Arduino is wel echt iets anders dan C++. Het is er dan wel op gebaseerd, maar daar blijft het dan ook bij.

Arduino = C++. Het is wel meer dan erop gebaseerd. (Ja er zijn wat dingetjes zoals dat de main functie onderwater is en het in setup en loop gesplitst is).

Het is er dan wel op gebaseerd, maar daar blijft het dan ook bij. In Arduino "programmeren" komt (volgens mij) vaak neer op het copy-pasten van voorbeeldcode, die je vervolgens een beetje aanpast en eventueel plak je er nog een bestaande library bij. Het daadwerkelijk begrijpen van de code en de achterliggende concepten is afwezig

Drogredenatie die ik voor elke taal/platform kan maken. Hoeveel mensen weten hoe de achterliggende code van python libraries werkt?

Verder is het standaard-voorbeeld van Arduino, blink, ook compleet niet object georiënteerd en gebruikt het ook geen C++ functionaliteit.

C++ is, ook naar mijn mening, veel te complex voor een beginner. Neem de simpele hello-world:

Dan pak je mbed blink:

C++:

#include "mbed.h"
 
DigitalOut myled(LED1);
 
int main() {
    while(1) {
        myled = 1;
        wait(0.2);
        myled = 0;
        wait(0.2);
    }
}

Laten we dat dan vergelijken met een 'makkelijke' taal als python, oftewel blink programma op een Raspberry.

Python:

import RPi.GPIO as GPIO  
import time  
# blinking function  
def blink(pin):  
        GPIO.output(pin,GPIO.HIGH)  
        time.sleep(1)  
        GPIO.output(pin,GPIO.LOW)  
        time.sleep(1)  
        return  
# to use Raspberry Pi board pin numbers  
GPIO.setmode(GPIO.BOARD)  
# set up GPIO output channel  
GPIO.setup(11, GPIO.OUT)  
# blink GPIO17 50 times  
for i in range(0,50):  
        blink(11)  
GPIO.cleanup()

(Ja code doet niet exact hetzelfde, copy paste van voorbeeldcode voor beide platformen).

Kan iemand me hier, serieus, zonder sarcasme, zeggen dat het python voorbeeld makkelijker is dan de C++ code? En natuurlijk, python is voor zat zaken perfect, ik gebruik het soms ook. Maar het blanket statement dat C++ moeilijk is en bijvoorbeeld python makkelijk voor een beginner ga ik absoluut niet in mee.

Ook bij die python code kan ik 10 vragen per regel verzinnen, waarvan de meeste identiek aan de 'vragen' die jij over C++ verzint. Overigens als je problemen hebt met cout in c++, waarom niet gewoon printf dan gebruiken?

Overigens als instaptaal vind ik het een flink nadeel van Python dat het een taal is die heel anders werkt dan veel andere talen.

.oisyn schreef op maandag 09 november 2015 @ 10:06:
[...]


Tja, waarom zou je dan nog C++ gebruiken? Eigenlijk bewijs je alleen maar mijn punt.

Omdat je één specifiek iets niet meer gebruikt? Lekkere drogredenatie. Zonder malloc heb je dus geen 'echte' C++?

[Brent]

Sissors schreef op maandag 09 november 2015 @ 18:52:
Dan pak je mbed blink:

C++:

#include "mbed.h"
 
DigitalOut myled(LED1);
 
int main() {
    while(1) {
        myled = 1;
        wait(0.2);
        myled = 0;
        wait(0.2);
    }
}

Laten we dat dan vergelijken met een 'makkelijke' taal als python, oftewel blink programma op een Raspberry.

Python:

import RPi.GPIO as GPIO  
import time  
# blinking function  
def blink(pin):  
        GPIO.output(pin,GPIO.HIGH)  
        time.sleep(1)  
        GPIO.output(pin,GPIO.LOW)  
        time.sleep(1)  
        return  
# to use Raspberry Pi board pin numbers  
GPIO.setmode(GPIO.BOARD)  
# set up GPIO output channel  
GPIO.setup(11, GPIO.OUT)  
# blink GPIO17 50 times  
for i in range(0,50):  
        blink(11)  
GPIO.cleanup()

(Ja code doet niet exact hetzelfde, copy paste van voorbeeldcode voor beide platformen).

Lijkt mij te verschilend om iets mee te kunnen concluderen. mbed.h doet waarschijnlijk precies het soort init en cleanup als je met GPIO nu zelf doet. Verder implementeer je blink() in Python, terwijl als je die 4 regels in een while gooit, je exact hetzelfde programma zou hebben, op die GPIO init/cleanup na.

Als ik hier iets concludeer, is dat beide talen even expressief zijn (en dat zou ik sowieso zeggen). Punt is meer dat dat in het wild voor Python vaker voorkomt dan C++. Ik kan je wel zeggen dat de embedded C die ik ken een afzichtelijke brij ellende was.

Omdat je één specifiek iets niet meer gebruikt? Lekkere drogredenatie. Zonder malloc heb je dus geen 'echte' C++?

Ik denk dat mbed.h gewoon een mooie lib is, waar je ontzettend mee boft

[BoringDay]

RayNbow schreef op zondag 08 november 2015 @ 20:04:
[...]

Vandaar dat de C++11 standaard slechts 1300 pagina's of zo bevat?

Je gaat geen 1300 pagina's leren maar je kan het wel doornemen.
De basis is altijd een beter begin, bovendien zijn de meeste talen op C/C++ gebaseerd.

[BoringDay]

HuHu schreef op maandag 09 november 2015 @ 09:53:
Arduino is wel echt iets anders dan C++. Het is er dan wel op gebaseerd, maar daar blijft het dan ook bij. In Arduino "programmeren" komt (volgens mij) vaak neer op het copy-pasten van voorbeeldcode, die je vervolgens een beetje aanpast en eventueel plak je er nog een bestaande library bij. Het daadwerkelijk begrijpen van de code en de achterliggende concepten is afwezig.

Verder is het standaard-voorbeeld van Arduino, blink, ook compleet niet object georiënteerd en gebruikt het ook geen C++ functionaliteit.

C++ is, ook naar mijn mening, veel te complex voor een beginner. Neem de simpele hello-world:

C++:

#include <iostream>
using namespace std;

int main ()
{
    cout << "Hello world.";
    return 0;
}

Bij elke regel kun je wel 10 vragen verzinnen. Wat doet include (preprocessor??), wat is iostream? Wat is een namespace, wat is using. Wat is main en zijn er wel/geen argumenten en waarom int? Wat is cout en << (een overloaded shift operator, wtf)? Waarom return 0?

Dan een simpele taal als Python:

Python:

print "Hello world"

Mijns inziens vele malen geschikter als instaptaal.

Geschikter?
Ten eerste zou je dan de vergelijking cout << "Hello world" moeten maken.
Ten twee is Python op C gebaseerd.
Ten derde die main is een stukje essentiële kennis wat ieder programmeur dient te snappen, laat staan lastiger vinden.

[Sissors]

Brent schreef op maandag 09 november 2015 @ 19:06:
[...]
Lijkt mij te verschilend om iets mee te kunnen concluderen. mbed.h doet waarschijnlijk precies het soort init en cleanup als je met GPIO nu zelf doet. Verder implementeer je blink() in Python, terwijl als je die 4 regels in een while gooit, je exact hetzelfde programma zou hebben, op die GPIO init/cleanup na.

Punt dus: Nagenoeg exact hetzelfde, waarbij python wat 'vreemde' includes heeft. (Uiteraard zitten er in mbed.h ook weer wat verborgen voor de gebruiker).

Overigens behalve container zijn, doet mbed.h enkel het juist zetten van de klok instellingen, iets wat op een raspberry al gedaan is. De init/cleanup van de GPIO zit in de DigitalOut constructor/destructor. Wat toch maar een handig iets van C++ (en natuurlijk genoeg andere talen is).


Mijn persoonlijke TL;DR gaat uitkomen op: Het ligt eraan wat je ermee wil doen. Voor zat zaken is python een prima taal om mee te beginnen. Maar als random voorbeeld, wanneer je ook interesse hebt in elektronica, en die twee wil combineren, dan hoef je als eerste niet bang te zijn voor C++ omdat er zoveel verhalen de ronden gaan over hoe moeilijk het zou zijn. En als tweede, ga alsjeblieft niet beginnen met javascript/python op microcontrollers.
En dus punt drie: Ik wil ook niet beweren dat C++ de geschiktste taal voor beginners is, wel dat het niet ongeschikt is voor beginners.

[ Voor 4% gewijzigd door Sissors op 09-11-2015 19:47 ]

[RayNbow]

BoringDay schreef op maandag 09 november 2015 @ 19:26:
[...]


Je gaat geen 1300 pagina's leren maar je kan het wel doornemen.
De basis is altijd een beter begin,

Het gaat niet om het leren, het gaat om de complexiteit van een taal. Waarom heb je 1300 pagina's nodig om C++ te beschrijven? De enige reden is dat C++ zo veel features heeft dat er ook rekening moet worden gehouden wat er gebeurt als je meerdere features tegelijkertijd gebruikt. Dit is gewoon een gevalletje van een combinatorische explosie.

bovendien zijn de meeste talen op C/C++ gebaseerd.

Er zijn veel talen die inspiratie uit bijv. C en C++ halen, maar dat wil niet zeggen dat die talen meteen de gehele complexiteit erven.

BoringDay schreef op maandag 09 november 2015 @ 19:31:
Ten twee is Python op C gebaseerd.

Python put inspiratie uit meerdere talen, niet alleen C.

[Brent]

Python heeft toch ook gewoon een constructor? Het verschil is dus dat GPIO wat generieker oogt dan mbed.h. Destructor mis ik in elke niet-C++ taal. Het is zeker zo dat op gebied van memorymanagement C++ een steun in de rug geeft. Maar Python is niet minder geschikt omdat GPIO minder voor je doet/generieker is. Ik kan zo 8 tegenvoorbeelden geven waar de Python stdlib veel kalere code mogelijk maakt dan C++

[BoringDay]

RayNbow schreef op maandag 09 november 2015 @ 19:52:
[...]

Het gaat niet om het leren, het gaat om de complexiteit van een taal. Waarom heb je 1300 pagina's nodig om C++ te beschrijven? De enige reden is dat C++ zo veel features heeft dat er ook rekening moet worden gehouden wat er gebeurt als je meerdere features tegelijkertijd gebruikt. Dit is gewoon een gevalletje van een combinatorische explosie.


[...]

Er zijn veel talen die inspiratie uit bijv. C en C++ halen, maar dat wil niet zeggen dat die talen meteen de gehele complexiteit erven.


[...]

Python put inspiratie uit meerdere talen, niet alleen C.

Het doet denk ik er helemaal niet toe of een boek 1300 pagina's heeft.
Bij andere talen is dat niet anders, dit jaar heb ik ook voor een taal/omgeving ruim 1300 pagina's doorgenomen en dat puur om het goed aan te leren i.p.v. add-hoc hobby study.

[Sissors]

Brent schreef op maandag 09 november 2015 @ 19:59:
Python heeft toch ook gewoon een constructor? Het verschil is dus dat GPIO wat generieker oogt dan mbed.h. Destructor mis ik in elke niet-C++ taal. Het is zeker zo dat op gebied van memorymanagement C++ een steun in de rug geeft. Maar Python is niet minder geschikt omdat GPIO minder voor je doet/generieker is. Ik kan zo 8 tegenvoorbeelden geven waar de Python stdlib veel kalere code mogelijk maakt dan C++

Ik weet niet hoe je bedoelt dat GPIO generieker oogt. Edit: Python GPIO is ook gewoon lib specifiek voor raspberry he? Het is (zover ik weet) geen onderdeel van de 'echte' python. Mbed ondersteund hele zooi platforms, maar uiteindelijk werkt het dus ook enkel met ondersteunde platforms.

Maar nogmaals, ik wil niet bediscussieren in hoeveel procent van de situaties python makkelijkere code oplevert en in hoeveel C++, enkel dat je met C++ als beginner ook prima uit de voeten kan, een beetje afhankelijk van wat je ermee wil doen.

[ Voor 12% gewijzigd door Sissors op 09-11-2015 20:05 ]

[.oisyn]

Sissors schreef op maandag 09 november 2015 @ 18:52:
Omdat je één specifiek iets niet meer gebruikt?

Als jij voorstelt om geen geheugenallocatie te doen valt sowieso al 90% de standaard library af. Polymorphisme in classes wordt al snel lastig, exceptions kun je niet gooien, en template code zie je ook niet snel terug in embedded projects. Eigenlijk ben je gewoon C aan het typen.

Lekkere drogredenatie. Zonder malloc heb je dus geen 'echte' C++?

Wat een drogredenatie is, is zeggen dat C++ een prima instaptaal is terwijl je voorstelt dat je alle dingen die C++ C++ maakt niet gebruikt.

Bovendien, malloc is C, C++ gebruikt new/delete en dingen als std::string, std::vector en std::shared_ptr. Échte C++ doet vrij weinig met ruwe pointers en delete zul je relatief weinig tegenkomen.

[ Voor 6% gewijzigd door .oisyn op 09-11-2015 20:18 ]

[BoringDay]

Brent schreef op maandag 09 november 2015 @ 19:59:
Python heeft toch ook gewoon een constructor? Het verschil is dus dat GPIO wat generieker oogt dan mbed.h. Destructor mis ik in elke niet-C++ taal. Het is zeker zo dat op gebied van memorymanagement C++ een steun in de rug geeft. Maar Python is niet minder geschikt omdat GPIO minder voor je doet/generieker is. Ik kan zo 8 tegenvoorbeelden geven waar de Python stdlib veel kalere code mogelijk maakt dan C++

Object Pascal, heeft elk standaard object een destructor
Swift/Objective-C hebben standaard een destructor (wordt alleen anders benoemd).
Elke OOP taal heeft wel ergens een destructor onder de motorkap (immers moet een aangemaakt object altijd weer worden vrij gegeven).

[.oisyn]

Het sleutelwoord is deterministic finalization. Het RAII-principe van C++ is nogal groot een een van de pijlers van de taal. Die heb je in vrijwel geen enkele andere taal.

[BoringDay]

.oisyn schreef op maandag 09 november 2015 @ 20:21:
Het sleutelwoord is deterministic finalization. Het RAII-principe van C++ is nogal groot een een van de pijlers van de taal. Die heb je in vrijwel geen enkele andere taal.

Object Pascal kent initialization/finalization en zo zijn er nog wel meer.
Lijkt me gewoon een standaard OOP principe
.

[ Voor 5% gewijzigd door BoringDay op 09-11-2015 20:26 ]

[.oisyn]

Ga anders eerst even op wikipedia die term opzoeken

[Sissors]

.oisyn schreef op maandag 09 november 2015 @ 20:17:
[...]

Als jij voorstelt om geen geheugenallocatie te doen valt sowieso al 90% de standaard library af. Polymorphisme in classes wordt al snel lastig, exceptions kun je niet gooien, en template code zie je ook niet snel terug in embedded projects. Eigenlijk ben je gewoon C aan het typen.

Weet je, dan noemen we het C met classes, polymorphism, templates, etc ipv het C++ te noemen omdat we geen malloc/new gebruiken. (Geen idee waarom je die overigens nodig zou hebben voor polymorphism). Als we nu de definitie nu blijkbaar zo is geworden dat zolang je new beperkt/niet gebruikt het geen C++ meer is, tja dan zijn we snel klaar hier.

Conclusie: C++ is geschikt voor beginners, behalve wanneer je .oisyn's definitie gebruikt waarbij alleen als je alle opties van een taal direct gebruikt je het die taal mag noemen. Dan ga ik er ook één ingooien: Python is geen Python meer als je geen regular expressions gebruikt. Zo, nu begrijpt ook geen beginner meer iets van Python.