Programmeertalen, welke, wat, hoe duur?

[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.

[RayNbow]

BoringDay schreef op maandag 09 november 2015 @ 20:00:
[...]


Het doet denk ik er helemaal niet toe of een boek 1300 pagina's heeft.
Bij andere talen is dat niet anders

The C Programming Language telt anders geen eens 300 pagina's.

[.oisyn]

Lees je nou gewoon slecht? Ik zeg toch juist dat je polymorphisme en exceptions ook niet gebruikt? En het hele gemis van de standaard library laat je voor het gemak maar even buiten beschouwing, terwijl dat ook een niet gering onderdeel is van de taal .

Je zegt dat C++ geschikt is voor beginners, en dan kom je met als voorbeeld een DSL gebouwd in C++. Ja dan houdt de discussie snel op inderdaad...

[Sissors]

.oisyn schreef op maandag 09 november 2015 @ 20:42:
Lees je nou gewoon slecht? Ik zeg toch juist dat je polymorphisme en exceptions ook niet gebruikt?

Dat zeg je ja. Maar waar is het op gebaseerd? (Exceptions gebruik ik overigens idd niet, polymorphism, zowel in de vorm van inheritance als in de vorm van templates gebruik ik wel, en heb je echt geen new voor nodig. Geen idee of exceptions ze nodig hebben.

En het hele gemis van de standaard library laat je voor het gemak maar even buiten beschouwing, terwijl dat ook een niet gering onderdeel is van de taal .

En waar is deze op gebaseerd? Uiteraard maakt het niks uit als een functie onder de motorkap het gebruikt (zoals een vector class zal doen). Daar heb je als gebruiker niks mee te maken, en dan hoef je dus ook niet na te denken over memory leaks en soortgelijken.

Je zegt dat C++ geschikt is voor beginners, en dan kom je met als voorbeeld een DSL gebouwd in C++. Ja dan houdt de discussie snel op inderdaad...

Jouw argumentatie komt niet verder dan wanneer je niet/beperkt new gebruikt, en je dus niet druk hoeft te maken over memory management, het geen C++ is.

[BoringDay]

Op het moment iemand gaat beweren je niet op memory management hoeft te letten bij een taal krijg ik een beetje het kriebel gevoel (soms is het noodzakelijk de regie in handen te nemen, dus weet wat er gebeurd).

[.oisyn]

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

Dat zeg je ja. Maar waar is het op gebaseerd? (Exceptions gebruik ik overigens idd niet, polymorphism, zowel in de vorm van inheritance als in de vorm van templates gebruik ik wel, en heb je echt geen new voor nodig. Geen idee of exceptions ze nodig hebben.


[...]

En waar is deze op gebaseerd? Uiteraard maakt het niks uit als een functie onder de motorkap het gebruikt (zoals een vector class zal doen). Daar heb je als gebruiker niks mee te maken, en dan hoef je dus ook niet na te denken over memory leaks en soortgelijken.


[...]

Jouw argumentatie komt niet verder dan wanneer je niet/beperkt new gebruikt, en je dus niet druk hoeft te maken over memory management, het geen C++ is.

Nee, *jouw* argument was dat je louter geen memory management functies gebruikt. Ik beweer dat het veel verder gaat en je het *daarom* geen C++ kunt noemen. Bovendien werd er gezegd dat je in een embedded context helemaal geen geheugenallocaties gedaan werden, en daarom valt de stdlib dus af.

Polymorphisme, leuk voor die paar cases waar je direct je object by value aanmaakt, maar iets als een factory kun je al niet meer implementeren. Templates, een van de complexere features van de taal en absoluut niet voor beginners. De relevantie van dat jij ze wel gebruikt ontgaat me even.

[Sissors]

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

Nee, *jouw* argument was dat je louter geen memory management functies gebruikt.

Link? Mijn argument was dat als je bang bent voor geheugen beheer in C++ je een heel eind bij veel zaken kan komen door gewoon niet/heel beperkt new/malloc te gebruiken.

Ik beweer dat het veel verder gaat en je het *daarom* geen C++ kunt noemen.

Wat gaat veel verder?

Bovendien werd er gezegd dat je in een embedded context helemaal geen geheugenallocaties gedaan werden, en daarom valt de stdlib dus af.

Link? In sommige omgevingen wordt geen geheugenallocatie gebruikt. Dat is wat anders.

Polymorphisme, leuk voor die paar cases waar je direct je object by value aanmaakt, maar iets als een factory kun je al niet meer implementeren. Templates, een van de complexere features van de taal en absoluut niet voor beginners. De relevantie van dat jij ze wel gebruikt ontgaat me even.

De relevantie dat ik ze gebruik is omdat jij specifiek zei dat ik ze niet gebruikte. Om je te quoten:

zeg toch juist dat je polymorphisme en exceptions ook niet gebruikt?

[.oisyn]

Laat maar, we lullen langs elkaar heen denk ik. Als het je louter om memory management te doen is: als je alleen dat wegdenkt blijft de taal complex. Als je al die andere complexe zaken ook wegdenkt kun je het geen C++ meer noemen.

[ Voor 66% gewijzigd door .oisyn op 09-11-2015 21:09 ]

[BoringDay]

Templates zijn in principe ook niet complex alleen je moet er even in de materie duiken.
Iedereen kan bakstenen op elkaar stapelen maar niet iedereen kan een muur bouwen met een goed fundament.

[.oisyn]

Volgens die redenatie is niets complex, je moet alleen de materie snappen. Geldt bijvoorbeeld ook voor kwantummechanica. Maar jij vindt templates dus blijkbaar wel voer voor beginners?

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

[BoringDay]

.oisyn schreef op maandag 09 november 2015 @ 21:10:
Volgens die redenatie is niets complex, je moet alleen de materie snappen. Geldt bijvoorbeeld ook voor kwantummechanica.

Je kan natuurlijk de basis overslaan, kost alleen maar moeite en tijd.
Met een beetje knip en plakwerk komen we er ook wel

Begin bij het begin, mijn inziens hoort templates daar ook als onderdeel bij maar wel op het juiste moment (niet dat je er meester werk van maakt maar wel van op de hoogte bent en wat snapt

.oisyn schreef op maandag 09 november 2015 @ 21:33:
Het lijkt me nou niet bepaald de materie waarmee je middelbare scholieren bij hun introductie met programeertalem mee wilt lastigvallen, tenzij je ze af wilt schrikken om job security redenen

).

[ Voor 67% gewijzigd door BoringDay op 09-11-2015 21:42 ]

[.oisyn]

Het lijkt me nou niet bepaald de materie waarmee je middelbare scholieren bij hun introductie met programeertalen mee wilt lastigvallen, tenzij je ze af wilt schrikken om job security redenen

[Bartjuh]

Geef een leek de opdracht om één dag Python te leren, en één dag C++. Wedden dat de gemiddelde beginner C veel lastiger vind.

Ducktyping, simpele syntax, alles objects met magic methods (niks casten), handige scope rules. Python is 100x vergevingsgezinder, weinig verbose, goed human readable, etc. Veel, maar dan ook veel betere beginnerstaal. Dus niet een veel betere taal, dat is een andere discussie (C is sowieso veel sneller).

[ Voor 11% gewijzigd door Bartjuh op 09-11-2015 21:38 ]

[BoringDay]

.oisyn schreef op maandag 09 november 2015 @ 21:33:
Het lijkt me nou niet bepaald de materie waarmee je middelbare scholieren bij hun introductie met programeertalen mee wilt lastigvallen, tenzij je ze af wilt schrikken om job security redenen

Ik bedoel dan ook niet je er een meesterwerk van moet maken, maar op zijn minst van het bestaan af weet.
Wellicht iemand er nooit verder mee wat doet (net zoiets als staartdeling, we hebben het allemaal geleerd maar vraag me af hoeveel het in de praktijk toepassen).

[BoringDay]

Bartjuh schreef op maandag 09 november 2015 @ 21:37:
Geef een leek de opdracht om één dag Python te leren, en één dag C++. Wedden dat de gemiddelde beginner C veel lastiger vind.

Ducktyping, simpele syntax, alles objects met magic methods (niks casten), handige scope rules. Python is 100x vergevingsgezinder, weinig verbose, goed human readable, etc. Veel, maar dan ook veel betere beginnerstaal. Dus niet een veel betere taal, dat is een andere discussie (C is sowieso veel sneller).

Je moet ook niet een taal kiezen omdat het makkelijker is maar omdat je er een hoop van leert en uiteindelijk meer aan hebt.

[Bartjuh]

BoringDay schreef op maandag 09 november 2015 @ 21:48:
[...]
Je moet ook niet een taal kiezen omdat het makkelijker is maar omdat je er een hoop van leert en uiteindelijk meer aan hebt.

De eerste taal moet vooral toegankelijk zijn. Snel resultaat geven, en niet ontmoedigen. In praktisch elke programmeertaal zitten if's, while's, functies, arrays, etc (muv functionele/declaratieve talen, maar dat is andere koek). De basiselementen van programmeren, waar je moet beginnen.

Iemand de verder gaat komt vanzelf andere talen tegen, en komt daar dan ook makkelijker in.

[pedorus]

BoringDay schreef op maandag 09 november 2015 @ 21:08:
Templates zijn in principe ook niet complex alleen je moet er even in de materie duiken.
Iedereen kan bakstenen op elkaar stapelen maar niet iedereen kan een muur bouwen met een goed fundament.

C++ Templates zijn alleen maar een turing-compleet onderdeel van de compilatiefase, totaal niet complex ofzo. De complexiteit ervan is een reden dat dit bijvoorbeeld niet in java of c# is overgenomen, omdat de bedenkers daarvan zagen dat het een slecht fundament was... (Generics zijn geen Templates) Zo stikt het in c++ van de concepten die niet worden overgenomen in andere talen omdat ze slecht blijken uit te pakken (losse header files + defines bijv ...).

BoringDay schreef op maandag 09 november 2015 @ 21:42:
(net zoiets als staartdeling, we hebben het allemaal geleerd maar vraag me af hoeveel het in de praktijk toepassen).

Schitterende vergelijking, want staartdelingen worden veelal ook niet meer geleerd..

[BoringDay]

C is toegankelijk, alleen moet je eerst beginnen met de theorie (datatypes, operators, declaraties ect. ect.) en op basis van de theorie stapsgewijs gaan oefenen. Het gaat om het begrijpen van waarom iets zo werkt en C mijn inziens het meest geschikt voor.

De theorie is namelijk de basis niet meteen code kloppen.

[begintmeta]

Er zijn ook mensen die zeggen dat het theoretisch voor de theorie beter is functionele/logische programmeertalen te gebruiken om te beginnen meen ik.

[krosis]

pedorus schreef op donderdag 05 november 2015 @ 00:04: Maar wat je ook kiest, gebruik in jouw geval vooral geen scala of javascript. Gebruik c++, ruby of visual basic ofzo.

JavaScript werkt prima serverside. Node is snel.

[.oisyn]

pedorus schreef op maandag 09 november 2015 @ 23:42:
Zo stikt het in c++ van de concepten die niet worden overgenomen in andere talen omdat ze slecht blijken uit te pakken (losse header files + defines bijv ...).

Dat komt voornamelijk omdat C++ gebouwd is op het C ecosysteem, die op zijn beurt weer enorm oud is. Er zijn al wat proposals voor een module-achtige structuur. Het wordt momenteel gemaintained door de modules subgroup (SG2). CLang heeft al een implementatie.

[ Voor 8% gewijzigd door .oisyn op 10-11-2015 01:20 ]

[HuHu]

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

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).

Sorry, maar als ik op de language reference kijk, zie ik toch echt geen C++. Pas als je zelf libraries gaat schrijven kom je met C++ in aanraking.

[...]

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

Ik had het over achterliggende concepten. En die zijn bij C++ veel ingewikkelder dan bij Python.

[...]

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).

Oké... het enige dat je hier laat zien is dat voor een zeer specifiek probleem (Arduino programmeren) er nog geen mooie Python library of interface bestaat. Dat heeft helemaal niets met de taal te maken.

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.

Het valt wel mee hoe verschillend Python is van andere talen. Ik merk in ieder geval dat het veel eenvoudiger aan studenten te onderwijzen is dan C++.

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


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.

Ja geschikter. Ik begrijp niet wat je bedoelt met 'cout << "Hello world"', want dat compileert niet? Ik heb in zowel C++ als Python het minimale voorbeeld van "Hello world" gegeven. Hoe had ik de vergelijking anders moeten doen?

Het maakt mij niet uit dat Python in C is geschreven, het gaat om de taal zelf. Niet om de taal waarin de taal is geschreven. Uiteindelijk komen alle talen weer bij machinecode of assembly terecht, maar dat is geen argument.

Main (of generieker: het startpunt van je applicatie) is inderdaad een belangrijk stukje kennis. Maar je kunt ook niet ontkennen dat het in C++ ingewikkelder is dan in Python.

[RayNbow]

HuHu schreef op dinsdag 10 november 2015 @ 08:23:
Het maakt mij niet uit dat Python in C is geschreven

...plus dat niet alle implementaties in C geschreven zijn. PyPy is een Python JITter geschreven in Python.

[incaz]

BoringDay schreef op maandag 09 november 2015 @ 23:42:
C is toegankelijk, alleen moet je eerst beginnen met de theorie (datatypes, operators, declaraties ect. ect.) en op basis van de theorie stapsgewijs gaan oefenen. Het gaat om het begrijpen van waarom iets zo werkt en C mijn inziens het meest geschikt voor.

De theorie is namelijk de basis niet meteen code kloppen.

Dat is vooral zo'n ideaalbeld... maar zo zitten mensen niet in elkaar. Mensen kunnen en willen niet eerst droge materie als basis. Mensen leren juist het beste van concreet naar abstract, niet andersom.

Dat betekent dus juist een taal waar de basis als vanzelf naar voren komt, waar je snel mee aan de gang kunt, en waar je daarna pas toewerkt naar het theoretische kader, beter werkt. De theorie kun je daarna makkelijk ophangen aan de ervaringen, dat werkt veel beter dan andersom.

[Onbekend]

Een korte theoriecursus a.d.h.v. kleine voorbeelden is erg raadzaam.
Bijvoorbeeld de verschillen tussen if ( x = 1 ) en if ( x == 1 ), de do-, while- en for loops, if/else en switch/case.

Als je daarna de functies met verschillende soorten argumenten en classes met public en private variabelen (protected hoeft van mij nog niet) leert, dan kan iemand snel aan de gang met C#.

Daarna moet de programmeerervaring worden opgebouwd en komen de rest van de vragen vanzelf.

[Brent]

.oisyn schreef op maandag 09 november 2015 @ 21:33:
Het lijkt me nou niet bepaald de materie waarmee je middelbare scholieren bij hun introductie met programeertalen mee wilt lastigvallen, tenzij je ze af wilt schrikken om job security redenen

Ik had het genoegen een uitstekend C++ intro vak te volgen, en dat ging supervloeiend. De docent hield ons netjes bij harige zaken vandaan, en leerde ons modern C++. Door dat vak snapte ik classes pas (wat ik met Python totdantoe nooit aan toe kwam). C++ kan dus zeker geschikt zijn voor beginners, maar dan moet je wel een docent hebben die ver blijft van C-ismes, handmatig geheugenbeheer, liefst wat libs meeleverd etc etc. Modern C++ is heus modern! Het valt me alleen op dat mensen die langer meelopen niet meegaan met de ontwikkelingen

Bartjuh schreef op maandag 09 november 2015 @ 21:37:
Python is 100x vergevingsgezinder,

Deze mis ik het meest als ik C++ code. Maar ik zou eraan toevoegen dat dat ook grotendeels cultuur is. De meeste C++ in het wild (en de meeste (oude) C++ coders) omarmen STL te weinig, terwijl die juist een hoop ellende voor je wegneemt als je er goed mee om leert gaan.

Waar geen kruid tegen gewassen is, ik noemde hem al, is iets als pip. Tenzij je onderzoeker bent, is elk probleem al 3 keer opgelost. Python heeft de tooling en de cultuur tenminste 1 zo'n oplossing op Pypi te zetten zodat niemand dat nog eens hoeft op te lossen. In de C++ wereld is door de moeilijkheid van libraries vinden en compilen het wiel al miljoenen malen opnieuw uitgevonden. Mijn eerstgeborene voor een C++ package index + tooling + cultuur

[HuHu]

Je kon dus al programmeren (in Python) voordat je aan C++ begon, Brent?

[InZane]

krosis schreef op dinsdag 10 november 2015 @ 00:16:
[...]


JavaScript werkt prima serverside. Node is snel.

Ligt er maar net aan wat je wil gaan doen. Voor CPU intensieve taken wil je sowieso niet bij Node zijn.

[Brent]

HuHu schreef op dinsdag 10 november 2015 @ 12:49:
Je kon dus al programmeren (in Python) voordat je aan C++ begon, Brent?

Beetje, in beide overigens.

[valvy]

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

C++ wordt gecompileerd naar een generiek platform (het moet immers overal werken). Java heeft echter het voordeel dat een jvm optimaal op specifieke hardware beter gebruikt.

Zoals beter een cache gebruiken, meer cores. En nog veel meer wat per pc verschilt. En waar c++ geen rekening mee kan houden(wat een jvm wel kan)

Echter is c++ sneller in graphics, daar worden hardware optimilisaties gedaan in de video driver(dus eigenlijk geen c++ maar een shading language) en kunnen met name pointers wonderen verrichten.

[begintmeta]

valvy schreef op dinsdag 10 november 2015 @ 18:15:
...
C++ wordt gecompileerd naar een generiek platform (het moet immers overal werken). ...

Een hoop software wordt ook in C++ voor specifieke systemen gecompileerd, en er is ook heel wat software die afhankelijk van de omgeving waar het gedraaid wordt een bepaald pad kiest of zaken aan of uit zet (Intels MKL is daar een voorbeeld van (wel gedeeltelijk fortran, maar het principe is hetzelfde, libav (ook geen c++) heeft meen ik ook dergelijke voorzieningen)).

[ Voor 8% gewijzigd door begintmeta op 10-11-2015 18:31 ]

[Brent]

valvy schreef op dinsdag 10 november 2015 @ 18:15:
[...]


C++ wordt gecompileerd naar een generiek platform (het moet immers overal werken). Java heeft echter het voordeel dat een jvm optimaal op specifieke hardware beter gebruikt.

Je begrijpt het verkeerd. C++ kan alleen compiletime optimaliseren, Java ook tijdens runtime (meestal wat later, vandaar dat je vaak een JVM warm moet draaien). Echter, C++ kan heel wat codepaths meecompilen, en bij runtime gebruik maken van datgene wat past bij wat beschikbaar is. Java kan hoeft dit pas op runtime te beslissen, wat wat ruimte scheelt (in theorie).

De praktijk is echter dat het Java behalve op wat kleine punten niet is gelukt C++ te verslaan, vandaar dat bijna niemand Java gebruikt voor grote numerieke taken. Ik moet zeggen dat Java (of eigenlijk, de JVM) indrukwekkend is, maar de payoff is er wmb niet. Die is toch meer de betere deploybaarheid van .jars vs executables uit GCC/LLVM/etc. Je kunt Java ook een betere taal vinden (of niet). Maar als het op ruwe performance en optimalisaties aankomt (om niet te spreken van geheugenbeheer), dan kan de JVM slechts in de schaduw van GCC staan.

Zie evt ook https://gcc.gnu.org/wiki/FunctionSpecificOpt

[BoringDay]

incaz schreef op dinsdag 10 november 2015 @ 10:04:
[...]


Dat is vooral zo'n ideaalbeld... maar zo zitten mensen niet in elkaar. Mensen kunnen en willen niet eerst droge materie als basis. Mensen leren juist het beste van concreet naar abstract, niet andersom.

Dat betekent dus juist een taal waar de basis als vanzelf naar voren komt, waar je snel mee aan de gang kunt, en waar je daarna pas toewerkt naar het theoretische kader, beter werkt. De theorie kun je daarna makkelijk ophangen aan de ervaringen, dat werkt veel beter dan andersom.

Maar dat mensen niet zo in elkaar zitten is geen excuus? Waarom zou je eerst dingen leren waarbij de kans groot is dat je het fout aanleert en ook nog eens allerlei aannames doet er vervolgens kan je jezelf weer op allerlei punten corrigeren omdat je van een hoop dingen niks afwist.

[incaz]

BoringDay schreef op dinsdag 10 november 2015 @ 19:04:
Maar dat mensen niet zo in elkaar zitten is geen excuus? Waarom zou je eerst dingen leren waarbij de kans groot is dat je het fout aanleert en ook nog eens allerlei aannames doet er vervolgens kan je jezelf weer op allerlei punten corrigeren omdat je van een hoop dingen niks afwist.

Dat mensen zo in elkaar zitten lijkt me een uitstekend excuus. Het is ontzettend dom om te verwachten dat mensen leren op een manier die ze niet goed kunnen. Je kunt wel proberen om kinderen eerst de grammatica van een taal te leren en een lijst met woordjes en dan verwachten dat ze ineens vloeiend de taal kennen, maar zo werkt dat gewoon niet. Bij kinderen gaat dat via gebrabbel en kernzinnen naar langzamerhand steeds complexer, bij leren programmeren is dat in zekere zin niet anders.
Mensen werken meer iteratief, steeds een beetje gedetailleerder en complexer en abstracter. (De stapsgrootte verschilt wel tussen mensen, en hoeveel ze willen weten aan theorie, details en abstractie is ook per persoon anders, maar toch.)

Daar niet bij aansluiten is vooral heel ineffectief (je probeert theorie te stampen die helemaal nog geen aangrijpingspunten heeft) en levert alsnog heel veel fouten op in de basis. Wil je mensen goed leren programmeren dan moet je zoeken naar iets dat aansluit bij hoe mensen denken, en van daaruit de details en theorie uitwerken. Het is dan geen enkel probleem om in eerste instantie een highlevel taal te nemen die simpele dingen simpel maakt, en dat vervolgens uit te bouwen naar dingen die complexer worden. Belangrijk is dat ze op het juiste moment het juiste zetje krijgen, net voordat ze creatief maar gevaarlijk worden zeg maar.
(Maar, ik heb nog geen taal gezien die niet heel makkelijk glorieus misbruikt kan worden, dus verwacht uberhaupt niet dat een programmeertaal dat gaat voorkomen.)

[BoringDay]

Bij mijn weten begint praktisch elk boek met een stuk theorie voordat ze met voorbeelden komen (niet zonder reden overigens). Maar jij wil de inhoud overslaan en meteen maar een voorbeeld pakken.

Lijkt mij de omgekeerde volgorde (structuurloos).

[ Voor 3% gewijzigd door BoringDay op 10-11-2015 19:46 ]

[gekkie]

BoringDay schreef op dinsdag 10 november 2015 @ 19:45:
Bij mijn weten begint praktisch elk boek met een stuk theorie voordat ze met voorbeelden komen (niet zonder reden overigens). Maar jij wil de inhoud overslaan en meteen maar een voorbeeld pakken.

Lijkt mij de omgekeerde volgorde (structuurloos).

Meeste programmeerboeken die ik heb gelezen combineren theorie met voorbeelden en hanteren in de begin hoofdstukken met enige regelmaat versimpelingen van de werkelijkheid / mogelijkheden (welke in latere hoofdstukken worden aangevuld, vaak met hetzelfde voorbeeld dat aangevuld wordt met de nieuwe kennis uit het desbetreffende hoofdstuk waaruit dan ook gelijk blijkt wat de meerwaarde kan zijn van die nieuwe kennis (al komt ook dat soms niet uit de ver omdat de voorbeelden relatief simpel zijn))

Niet alles is linear uit te leggen, tevens is ook niet alles simultaan uit te leggen.

[BoringDay]

Stap voor stap inderdaad maar het begint met theorie per onderdeel en de voorbeelden zijn gebaseerd op dat stukje theorie.

[incaz]

Dat klinkt al heel wat genuanceerder, maar past niet bij C als beginnerstaal.

[pedorus]

Brent schreef op dinsdag 10 november 2015 @ 18:42:
De praktijk is echter dat het Java behalve op wat kleine punten niet is gelukt C++ te verslaan, vandaar dat bijna niemand Java gebruikt voor grote numerieke taken. Ik moet zeggen dat Java (of eigenlijk, de JVM) indrukwekkend is, maar de payoff is er wmb niet. Die is toch meer de betere deploybaarheid van .jars vs executables uit GCC/LLVM/etc. Je kunt Java ook een betere taal vinden (of niet). Maar als het op ruwe performance en optimalisaties aankomt (om niet te spreken van geheugenbeheer), dan kan de JVM slechts in de schaduw van GCC staan.

Hierboven poste ik nog een benchmark waar java net boven c++ uitkwam. Gezien de verminderde security van c++ op dingen als bounds checking enzo is het eigenlijk verbazingwekkend slecht van gcc..

Ander voorbeeld. Even de contestwinnaars van dit forum op een rijtje:
[Programming Contest 5] Tuintopia .net
Programming Contest Nieuwe Stijl: Contest 4 *Score-update* jvm
Programming Contest Nieuwe Stijl: Contest 3 *uitslagen!* jvm
Programming Contest Nieuwe Stijl: Contest 2 *WINNAARS LEZEN* c++ (30% verschil tussen binaries)
Programming Contest Nieuwe Stijl: Contest 1 *uitslagen!* jvm

Dit ging om vooral numerieke taken, waar als "niemand" daar java voor gebruikt java toch opvallend vaak (3/5) wint. Het lijkt mij dat de overhead van dingen als bounds checking enzo die je bij jvm/.net hebt ondergeschikt zijn aan de kwaliteit van de programmeur. Voor veel projecten is c++ voor de productiviteit dan ook een slecht idee wat mij betreft.

Onbekend schreef op dinsdag 10 november 2015 @ 10:12:
Bijvoorbeeld de verschillen tussen if ( x = 1 ) en if ( x == 1 ),

Ook weer iets waardoor c++ lastiger is uit te leggen, en een bron van (security) bugs.

InZane schreef op dinsdag 10 november 2015 @ 12:54:
Ligt er maar net aan wat je wil gaan doen. Voor CPU intensieve taken wil je sowieso niet bij Node zijn.

Valt nog wel mee, afhankelijk van het type. Mutli-core gebruik is wel een issue, en node eindigt niet bovenaan in een contest. Maar het meest vervelende vind ik dat je je bijna altijd in Future-land begeeft, zonder dat de taal daarvoor support biedt zoals c# of scala dat heeft. In de plaats daarvan zijn er tal van libraries om dat deels op te lossen, op steeds andere manieren. En het gebrek aan block scope in combinatie met closures wordt ik trouwens ook niet blij van.

[Bartjuh]

Verreweg de meeste programmeerboeken zijn geschreven voor mensen die al een (redelijke) basiskennis en ervaring hebben met programmeren. Voor if, comparison, bools, functies, etc moet je vooral eerst praktisch bezig. Laten zien wat er kan, printen naar scherm, wat berekeningen, invoer, plots, etc, en zo snel mogelijk resultaat geven zonder daarbij zorgen te hoeven maken over static typing, scope, oop abstractie, etc.

pedorus schreef op dinsdag 10 november 2015 @ 20:28:
[...]
Ook weer iets waardoor c++ lastiger is uit te leggen, en een bron van (security) bugs.

In python kan je zelfs sommige dingen super human-readable maken, zoals "if variable is not 3: print 5", of "if 'knikker' in bakje", waarin bakje een iterable is (list, dict, etc)

[ Voor 31% gewijzigd door Bartjuh op 10-11-2015 20:42 ]

[gekkie]

BoringDay schreef op maandag 09 november 2015 @ 23:42:
C is toegankelijk, alleen moet je eerst beginnen met de theorie (datatypes, operators, declaraties ect. ect.) en op basis van de theorie stapsgewijs gaan oefenen. Het gaat om het begrijpen van waarom iets zo werkt en C mijn inziens het meest geschikt voor.

De theorie is namelijk de basis niet meteen code kloppen.

Ik vind dan om de redenen die je hier aandraagt C weer volstrekt ongeschikt voor een beginner.
Net zoals hogere programmeertalen veel te veel abstraheren over C .. abstraheert C natuurlijk veel te veel van machinecode. Gewoon lekker zelf met de registers aan de slag en de instructies uit de developer manual van de chipbakker(s) halen. Je druk maken of iets in een cacheline past enzo .. je kunt er echt niet vroeg genoeg mee beginnen .

Achja in de jaren 80 was het toch makkelijker ... nagenoeg allemaal basic denk ik voor den beginner.
(okee misschien "logo" in de schoolbus .. wat een tijden )

[ Voor 8% gewijzigd door gekkie op 10-11-2015 20:46 ]

[Brent]

pedorus schreef op dinsdag 10 november 2015 @ 20:28:
[...]

Hierboven poste ik nog een benchmark waar java net boven c++ uitkwam. Gezien de verminderde security van c++ op dingen als bounds checking enzo is het eigenlijk verbazingwekkend slecht van gcc..

De fameuze microbenches Ik weet dat ze te vinden zijn, maar doet niet ter zake, en dat weet je als het je brood is

En modern C++ doet netzoveel bounds checken als Java, nu klink je als iemand die de taal het laast in het vorige milenium gebruikte

[pedorus]

Het andere voorbeeld met contestresultaten of de andere benchmarks negeer je maar voor het gemak, of dat de meeste HFT code in java is..

Gisteren nog een pakketje gestuurd naar een moderne c++ service (c++11): een string zonder \0 op het einde. Vervolgens werd er op willekeurige momenten keurig aangevuld met willekeurig geheugen. Een gebruikte library deed kennelijk toch echt niet aan bounds checking..

Overigens zijn er ook genoeg gevallen van beroerde java code (java.net.ssl is bijvoorbeeld vrij traag). Mijn punt is dat voor de meeste problemen java evenveel of meer performance kan geven als c++, omdat vooral developmentproductiviteit uitmaakt. Er is maar een beperkte set problemen waar dit niet zo is (vooral grafische dingen), en waar je soms zelfs assembly wil gebruiken.

[valvy]

begintmeta schreef op maandag 09 november 2015 @ 23:59:
Er zijn ook mensen die zeggen dat het theoretisch voor de theorie beter is functionele/logische programmeertalen te gebruiken om te beginnen meen ik.

Het mooie aan een functionele programmeer taal is dat het vrij makkelijk concurrent programmeren is. En zeker nu computers steeds meer cores krijgen, grid computing zal het een steeds grotere opmars maken.

Echter wordt dit al sinds eind jaren negentig geroepen en is imperatieve talen vaak nog steeds een stuk sneller dan functionele talen. (Maar functionele talen zoals haskell zijn echt elegant en leuk)

[Brent]

pedorus schreef op dinsdag 10 november 2015 @ 22:08:
Het andere voorbeeld met contestresultaten of de andere benchmarks negeer je maar voor het gemak, of dat de meeste HFT code in java is..

HFT is CRUD, maar dan heel snel. Ik moet toevoegen dat echte numerieke algos nog gewoon in FORTRAN gecode worden (paketten als BLAS enzo).

Gisteren nog een pakketje gestuurd naar een moderne c++ service (c++11): een string zonder \0 op het einde. Vervolgens werd er op willekeurige momenten keurig aangevuld met willekeurig geheugen. Een gebruikte library deed kennelijk toch echt niet aan bounds checking..

Geloof ik niets van

Overigens zijn er ook genoeg gevallen van beroerde java code (java.net.ssl is bijvoorbeeld vrij traag). Mijn punt is dat voor de meeste problemen java evenveel of meer performance kan geven als c++, omdat vooral developmentproductiviteit uitmaakt. Er is maar een beperkte set problemen waar dit niet zo is (vooral grafische dingen), en waar je soms zelfs assembly wil gebruiken.

Weleens in supercomputerland rondgelopen? Niet alles speelt zich op desktops af

[farlane]

valvy schreef op dinsdag 10 november 2015 @ 18:15:
[...]
C++ wordt gecompileerd naar een generiek platform (het moet immers overal werken). Java heeft echter het voordeel dat een jvm optimaal op specifieke hardware beter gebruikt.

Zoals beter een cache gebruiken, meer cores. En nog veel meer wat per pc verschilt. En waar c++ geen rekening mee kan houden(wat een jvm wel kan)

Echter is c++ sneller in graphics, daar worden hardware optimilisaties gedaan in de video driver(dus eigenlijk geen c++ maar een shading language) en kunnen met name pointers wonderen verrichten.

Tot zo ver de theorie. Pakken die theoretische voordelen die Java (het platform, want de taal heeft daar niets mee te maken) ook zo ongelooflijk goed uit?

Overigens kan ik met C++ ook heel nauwkeurig bepaalde hardware targetten (en dan ben ik volgens mij weer sneller dan Java kan zijn) alleen kan ik het niet @runtime doen.

[.oisyn]

En laten we wel wezen, automatic vectorization is nog altijd dramatisch in compilers/jitters. De meeste C++ implementaties ondersteunen SIMD intrinsics.

[Merethil]

.oisyn schreef op woensdag 11 november 2015 @ 10:54:
En laten we wel wezen, automatic vectorization is nog altijd dramatisch in compilers/jitters. De meeste C++ implementaties ondersteunen SIMD intrinsics.

Ik ben gaan Googlen waar je het in hemelsnaam over had en toen vond ik dat Java-gebruikers dan vastzitten aan het aanroepen van C(++) code dmv JNI.
Mijn kennis van dit soort zaken is nogal matig (iets met Enterprise developer enzo ), maar zou die issue nu "verholpen" zijn door gebruik van JNI?

Linkje voor wat ik vond: http://stackoverflow.com/...orized-floating-point-ins

[ Voor 11% gewijzigd door Merethil op 11-11-2015 11:12 ]

[.oisyn]

Merethil schreef op woensdag 11 november 2015 @ 11:12:
[...]


Ik ben gaan Googlen waar je het in hemelsnaam over had

Het gebruiken van SIMD (ook wel: vector) operaties voor herhalende wiskundige operaties. Stel je hebt twee even lange arrays van floats, en je wilt die componentsgewijs bij elkaar optellen. Je zou dan zoiets kunnen doen:

Java:

void addTo(float[] a, float[] b)
{
    for (int i = 0; i < a.length; i++)
        a[i] += b[i];
}

Moderne processoren (nou ja, modern, al vanaf de PIII wat betreft x86 ) hebben speciale registers en instructies aan boord om dit soort operaties te versnellen. In plaats van een enkel float register, heb je een register waar bijvoorbeeld 4 floats tegelijk in passen. En een bijbehorende instructie om die bij elkaar op te kunnen tellen. Grof gezegd heb je dus een 4x performance winst, want met een enkele instructie vermenigvuldig je 4 floats tegelijk ipv 1. Tegenwoordig heb je AVX-256 waar er 8 floats in een enkel register passen, en AVX-512 staat ook voor de deur (16 floats per register).

In C++ kun je bovenstaande code omschrijven door gebruik te maken van zogenaamde "instrinsics". Een intrinsic function is een functie waarvan de compiler van tevoren al weet hoe de implementatie eruit ziet. Dit gaat wat verder dan inline functions, en ze compilen vaak direct naar een bepaald pattern van assembly instructies. VC++ heeft intrinsics voor zo'n beetje alle assembly instructies die niet direct corresponderen met standaard operators, en dus ook voor SIMD.

Bovenstaande code kun je dus in C++ ook zo schrijven:

C++:

void addTo(__m128 * a, __m128 * b, size_t n)
{
    for (size_t i = 0; i < n; i++)
        a[i] = _mm_add_ps(a[i], b[i])
}

Waarbij de intrinsic _mm_add_ps() direct wordt vertaald naar de addps instructie

Automatic vectorization is het proces waarbij de compiler/JITer bovenstaande Java code herkent als vector operaties en dat compileert naar bijbehorende instructies, in plaats van gewoonweg enkele floats op te gaan zitten tellen. Voor hele simpele loopjes zoals bovenstaand lukt dat wellicht nog wel, maar bij complexere code snapt ie er niets meer van.

Al zie ik dat .Net 4.6 blijkbaar wel wat SIMD primitieven heeft in System.Numerics, mooi . Bijkomend voordeel is dat je met een Vector<float> dan ook meteen gebruik maakt van de lengte van onderliggende hardware. Run je je .Net app op een AVX-512 CPU dan heb je dus ook automatisch 16-component vector operaties. Dat is natuurlijk een groot voordeel van JIT tov static compilation. Al wil ik hierbij ook even gezegd hebben dat C++ geen static compilation impliceert, dat kan net zo goed geJIT worden.

maar zou die issue nu "verholpen" zijn door gebruik van JNI?

Leuk voor basale number crunching operaties, maar als dergelijke bewerkingen in je hele app te vinden zijn wordt dat natuurlijk lastig

[Merethil]

.oisyn schreef op woensdag 11 november 2015 @ 11:40:
[...]

[Uitleg]

[...]

Leuk voor basale number crunching operaties, maar als dergelijke bewerkingen in je hele app te vinden zijn wordt dat natuurlijk lastig

Thanks! Ik zat al wat rond te browsen en vond al wat uitleg hierover, maar de jouwe is nog wat duidelijker. Natuurlijk kan niet constant op die manier C(++) included worden door JNI als je het op veel plekken nodig hebt, dus daarvoor zou zoiets bouwen in Java duidelijk minder performen, maar zo te zien is er in ieder geval een mogelijkheid om, mocht het écht nodig zijn, dit zelf te forceren.

Ik zag wel, onder dezelfde link die ik hiervoor postte, dat er een aantal verbeteringen in zijn gemaakt met Java 7u40 en verder, waarbij er wel ondersteuning is gekomen voor auto vectorization van simpele for-loops, maar wat ik opmaak uit andere posts op 't internet omtrent het onderwerp is dat lang niet alles wat je zou willen

[gekkie]

Je moet wel vrij helderziende zijn als beginner om te bedenken dat je later wellicht een performance probleem gaat krijgen waar het wel of niet gebruiken door je compiler / runtime env. van onderliggende extended instructies cruciaal is. (en dan nog is het de vraag of het starten met een taal die er wel van gebruik kan maken, ipv later overstappen op zo'n taal, werkelijk het beste plan is.)

[begintmeta]

UIteindelijk zal het grootste deel van de software toch zichzelf gaan schrijven verwacht ik, je heb dat vooral talen nodig waarin je goed kan uitdrukken wat de bedoeling is.

[.oisyn]

gekkie schreef op woensdag 11 november 2015 @ 13:26:
Je moet wel vrij helderziende zijn als beginner om te bedenken dat je later wellicht een performance probleem gaat krijgen waar het wel of niet gebruiken door je compiler / runtime env. van onderliggende extended instructies cruciaal is. (en dan nog is het de vraag of het starten met een taal die er wel van gebruik kan maken, ipv later overstappen op zo'n taal, werkelijk het beste plan is.)

Dat klopt, maar ik vraag me af wie hier in de topic een dergelijke bewering heeft gedaan. Het is een beetje flauw om de zijdiscussie die is ontstaan te wijten aan de vraagstelling van de TS die opperde dat de ene taal wellicht sneller was dan de andere.

[ Voor 11% gewijzigd door .oisyn op 11-11-2015 13:36 ]

[gekkie]

.oisyn schreef op woensdag 11 november 2015 @ 13:34:
[...]
Dat klopt, maar ik vraag me af wie hier in de topic een dergelijke bewering heeft gedaan. Het is een beetje flauw om de zijdiscussie die is ontstaan te wijten aan de vraagstelling van de TS die opperde dat de ene taal wellicht sneller was dan de andere.

Mwah verwijten verwijten .. maar het lijkt me dan wel handig om enigzins de context van de TS erbij te houden. Vooralsnog lijkt de TS voor iets kleins en niks speciaals iets te zoeken (okee okee Linus begon misschien ook met "het is maar klein en niks speciaals", maar vooralsnog zie ik nergens dat de TS een niche op zou willen zoeken van een OS programmeren, een realtime 3D graphics spel, realtime beeldverwerking etc.

Kortom de kans dat hij in de nabije toekomst binnen die context dit soort optimalisaties nodig heeft acht ik kleiner dan de kans dat hij geholpen is met een taal om de basics van programmeren zich weer eigen te maken.

Nou maakt dat het gelijk weer lastig omdat er eigenlijk voor iedere taal ondertussen wel:

• een gratis IDE / editor met fatsoenlijke ondersteuning bestaat.
• er een of meerdere gratis beschikbare compilers / dev en runtime envirionment is.
• er voldoende stdlibs, code snippets, externe libs beschikbaar zijn, om nog iets sneller te kunnen komen waar je wil zijn.
• er voldoende boeken en webdocumentatie is.
• voor alle verschillende OS' en
• en elke taal en omgeving heeft z'n eigen nukken, maar voor de basics is dat beperkt

En dat het meest lastige soms nog wel eens is om uit te zoeken wat je bij een bepaalde taal juist beter niet kunt gebruiken aan legacy frameworks en libs.

[.oisyn]

Ik was in de veronderstelling dat de vraag van de TS inmiddels al lang en breed was beantwoord. En ik heb nota bene zelf al eerder gezegd dat ik C++ niet bepaald de meest ideale instaptaal vind

[farlane]

gekkie schreef op woensdag 11 november 2015 @ 14:02:
Mwah verwijten verwijten .. maar het lijkt me dan wel handig om enigzins de context van de TS erbij te houden

Het was meer een door de TS aangezwengelde secundaire (uitzichtsloze ) discussie over performance van taal X versus taal Y. Altijd leuk!

[Merethil]

gekkie schreef op woensdag 11 november 2015 @ 13:26:
Je moet wel vrij helderziende zijn als beginner om te bedenken dat je later wellicht een performance probleem gaat krijgen waar het wel of niet gebruiken door je compiler / runtime env. van onderliggende extended instructies cruciaal is. (en dan nog is het de vraag of het starten met een taal die er wel van gebruik kan maken, ipv later overstappen op zo'n taal, werkelijk het beste plan is.)

In dit geval ging het me natuurlijk ook niet om een beginner maar om een developer die, zoals al vaker geopperd is, gewoon de taal pakt die past bij wat je aan het maken bent/gaat. Er zijn gewoon talloze voordelen voor het gebruiken van een C(++) in tegenstelling tot een Java / C# / Python etc wanneer je aan de slag gaat met optimalisaties, snelheid en efficiëntie van je uiteindelijke programma.

Dit neemt niet weg dat in veel gevallen het overkill is om dit te gaan proberen te bereiken in alle software die je maakt: Soms is het net zo makkelijk en niet veel minder snel (maar waarschijnlijk wel sneller geproduceerd) als je met C# en WPF een programmaatje bouwt wat als kassa-interface gaat werken. Hetzelfde programma willen ombouwen om een kerncentrale volledig te automatiseren daarentegen... Tja

[gekkie]

farlane schreef op woensdag 11 november 2015 @ 14:37:
[...]
Het was meer een door de TS aangezwengelde secundaire (uitzichtsloze ) discussie over performance van taal X versus taal Y. Altijd leuk!

Hmm dan wordt het tijd voor een moddereter om de gehele "PHP is een poes" en alle whitespace discussies er dan ook alvast maar in te kopieren , hebben we die ook gelijk weer eens gehad .

[gekkie]

Merethil schreef op woensdag 11 november 2015 @ 14:47:
[...]
In dit geval ging het me natuurlijk ook niet om een beginner maar om een developer die, zoals al vaker geopperd is, gewoon de taal pakt die past bij wat je aan het maken bent/gaat. Er zijn gewoon talloze voordelen voor het gebruiken van een C(++) in tegenstelling tot een Java / C# / Python etc wanneer je aan de slag gaat met optimalisaties, snelheid en efficiëntie van je uiteindelijke programma.

Klopt alleen komen ze vaak verre van gratis, met de talloze voordelen krijg je er ook weer talloze nadelen bij. Vaak zijn alleen maar bepaalde delen van een programma werkelijk performance critical. Ga je vervolgens voor het volledige project low-level taal gebruiken dan, dan heb je daar voor last van de nadelen en weinig baat bij de voordelen. Uiteraard heeft mixen ook weer nadelen, zo blijft het altijd afwegen :-), achja als het allemaal eenvoudig was, was ook de lol er vanaf.

Dit neemt niet weg dat in veel gevallen het overkill is om dit te gaan proberen te bereiken in alle software die je maakt: Soms is het net zo makkelijk en niet veel minder snel (maar waarschijnlijk wel sneller geproduceerd) als je met C# en WPF een programmaatje bouwt wat als kassa-interface gaat werken. Hetzelfde programma willen ombouwen om een kerncentrale volledig te automatiseren daarentegen... Tja

Bij een kerncentrale heb je wel meer problemen, formele bewijzen hebben dat iets werkt, alles van compiler (te optimisitsche optimalisaties) tot runtimes. Lijkt me geen sinicure, ook niet met C.

[farlane]

[b]gekkie schreef op woensdag 11 november 2015 @ 15:25:
Bij een kerncentrale heb je wel meer problemen, formele bewijzen hebben dat iets werkt, alles van compiler (te optimisitsche optimalisaties) tot runtimes. Lijkt me geen sinicure, ook niet met C.

Runtime allocaties zijn in dat soort software niet toegestaan, laat staan een GC.

[begintmeta]

gekkie schreef op woensdag 11 november 2015 @ 15:25:
...

Bij een kerncentrale heb je wel meer problemen, formele bewijzen hebben dat iets werkt, alles van compiler (te optimisitsche optimalisaties) tot runtimes. Lijkt me geen sinicure, ook niet met C.

Worden dergelijke zaken niet ook regelmatig (onder andere) in bijvoorbeeld Ada of bijvoorbeeld ML-varianten of Haskell gemaakt? seL4 is zo te zien ook eigenlijk een 'legering' van diverse talen (zo te zien m.n. haskell, asm en c).

[ Voor 4% gewijzigd door begintmeta op 11-11-2015 15:58 ]

[gekkie]

begintmeta schreef op woensdag 11 november 2015 @ 15:57:
[...]

Worden dergelijke zaken niet ook regelmatig (onder andere) in bijvoorbeeld Ada of bijvoorbeeld ML-varianten of Haskell gemaakt? seL4 is zo te zien ook eigenlijk een 'legering' van diverse talen (zo te zien m.n. haskell, asm en c).

Ada lijkt idd in iedergeval voor te komen: http://archive.adaic.com/projects/atwork/nuclear.html
Lisp is wellicht ook nog wel een kandidaat. Voorspelbaarheid en correctheid lijken me een stuk belangrijker dan ruwe snelheid en de mogelijkheden werkelijk overal aan kunnen pielen voor micro-optimalisaties.
Dus voor het geval de TS nog aspiraties heeft in z'n achtertuin .

[ Voor 17% gewijzigd door gekkie op 11-11-2015 16:08 ]

[Brent]

farlane schreef op woensdag 11 november 2015 @ 15:31:
[...]

Runtime allocaties zijn in dat soort software niet toegestaan, laat staan een GC.

Het zal je verbazen

[begintmeta]

gekkie schreef op woensdag 11 november 2015 @ 16:05:
[...]

Ada lijkt idd in iedergeval voor te komen: http://archive.adaic.com/projects/atwork/nuclear.html
Lisp is wellicht ook nog wel een kandidaat. Voorspelbaarheid en correctheid lijken me een stuk belangrijker dan ruwe snelheid en de mogelijkheden werkelijk overal aan kunnen pielen voor micro-optimalisaties.
Dus voor het geval de TS nog aspiraties heeft in z'n achtertuin .

Ada is ook nog eens behoorlijk snel als ik wat makkelijk te vinden benchmarkjes mag geloven.

Dus misschien is Ada ook wel een kandidaat voor de TS.

[Area]

Kon geen relevante topic vinden en voor één simpele vraag wil ik geen topic openen.

Aan JavaScript-kenners, wat is het verschil tussen classList en className?
Kan iemand dat in Jan en Jippeke-taal aan mij even verduidelijken?

Alvast bedankt!

[.oisyn]

En dan kick je maar even een 5 jaar oud topic .

Je vraag lijkt me redelijk googlebaar. Je mag een topic openen, maar dan wel met een beetje moeite (leg uit welk antwoord je gevonden hebt en waarom je moeite hebt met het begrijpen ervan)