The State of Developer Ecosystem 2021

larsp (6) skrev:

#4 Hvad mener du med concurrency problemer? Python threading giver mulighed for lightweight threads som faktisk har nogle unikke fordele, og python multiprocessing giver mulighed for ægte multithreading. Igen. Det er noget der kan være smart i en hurtig vænding i scripts og mindre projekter. Det er ikke rigtig industrial strength IMO.

arne_v (14) skrev:

1) generel top test (while loop)
...
4) index (Pascal for loop, Fortran do loop, Basic for loop)
...
Bemærk at C familie for loop funktionsmæssigt er en #1 løkke ikke en #4 løkke. Det er bare sådan at idiomatisk brug af den er en #4 løkke.

De herrer K&R skulle aldrig have kommet op med sådan en kontrol struktur, men det gjorde de og en masse sprog har arvet den.

#include <stdio.h>

int main()
{
int i;
for(i = 0; i < 10; i++)
{
printf("%d\n", i);
}
return 0;
}

#include <stdio.h>

int main()
{
FILE *fp1, *fp2;
for(fp1 = fopen("z.1", "r"), fp2 = fopen("z.2", "w"); !feof(fp1); fputc(fgetc(fp1), fp2));
return 0;
}

arne_v (10) skrev:

For server side kode så er node.js hot lige nu, men moden kunne ændre sig om nogle år. Men jeg kunne nu godt forestille mig at node.js vil vise sig langtidsholdbar.

Årsag:
* client side udbredelse sikrer udviklere, libraries og tools
* fundamental sund arkitektur
og så lever man igen med sproget.

larsp (16) skrev:

@concurrency Jep, tråde startet med Thread() i CPython slås om GIL og vil ikke speede CPU begrænset python kode op. Men f.eks. numpy operationer kan køre parallelt med disse tråde fordi GIL ikke holdes hele tiden.

larsp (16) skrev:

Og ja, med multiprocessing forkes hele programmet i flere processer og man må bruge tricks for at dele variable, f.eks. multiprocessing.Manager().dict().

larsp (16) skrev:

Men der er mig bekendt ikke et concurrency *issue* i den forstand at man kan komme galt af sted og lave ulykker, mere end ved andre sprog. Man får bare ikke optimal performance. Python er iørvigt ekstremt langsomg og bør ikke bruges til CPU tung processering i første omgang.

arne_v (9) skrev:

Python eller mere præcist mange Python implementationer heriblandt standard CPython har et concurrency problem eller mere præcist et threading problem.

larsp (17) skrev:

#15 Ja, for konstruktionen i C kan misbruges horribelt, og er et af mange eksempler på nødvendigheden af disciplin hvis man vil skrive god C kode.

arne_v (15) skrev:

#include <stdio.h>

int main()
{
FILE *fp1, *fp2;
for(fp1 = fopen("z.1", "r"), fp2 = fopen("z.2", "w"); !feof(fp1); fputc(fgetc(fp1), fp2));
return 0;
}

FILE *p_file_read;
FILE *p_file_write;
int buffer;

p_file_read = fopen("z.1", "r");
p_file_write = fopen("z.2", "w");

while (!feof(p_file_read)) {
buffer = fgetc(p_file_read);
fputc(buffer, p_file_write);
}

return 0;

arne_v (24) skrev:

(mange ældre C programmører ville vælge kortere fil navne end dig, men det er en detalje)

Claus Jørgensen (20) skrev:

#18

Ah, du er forvirret fordi at JavaScript kan itererer over både arrays og dictionaries.

for...of er array value iteration
for...in er dictionary key iteration

arne_v (22) skrev:

Mine pointer var:
- at C for ikke er en Pascal for men en sær while
- at jeg synes at K&R skulle have lavet en mere normal for løkke

Mange af C's features er farlige men nødvendige for visse typer kode. Og dermed kan den farlige feature begrundes.

Men her er der tale om en sær feature som kan bruges til det samme som en mere traditionel for løkke eller til grim kode (som vel at mærke ikke er mere effektiv end pænere kode).

larsp (29) skrev:

Sjovt som du altid skal kommentere mine programmeringsevner.

larsp (29) skrev:

Javascript bryder helt klart med principle of least surprise her fordi "in" og "of" ikke kommunikerer ret godt hvad der foregår, ligesom "var" og "let" heller ikke gør. Andre sprog har tilsvarende features uden den slags gotcha'er.

Claus Jørgensen (31) skrev:

Du viser ikke ligefrem stor erfaring med forskellige sprog, mens at du samtidigt kritisere dem :p

Claus Jørgensen (31) skrev:

Der er ingen perfekte sprog (dog kommer Swift meget tæt på imo.), men jeg sætter altså Python/Ruby/Javascript side om side i "wtf" moments.

larsp (30) skrev:

arne_v (22) skrev:

Mine pointer var:
- at C for ikke er en Pascal for men en sær while
- at jeg synes at K&R skulle have lavet en mere normal for løkke

Mange af C's features er farlige men nødvendige for visse typer kode. Og dermed kan den farlige feature begrundes.

Men her er der tale om en sær feature som kan bruges til det samme som en mere traditionel for løkke eller til grim kode (som vel at mærke ikke er mere effektiv end pænere kode).

Jeg er enig og man sidder tilbage og undres over at denne for (;;) konstruktion er blevet båret videre til så mange af de nyere sprog med C style syntax.

Claus Jørgensen (33) skrev:

#32

Parallel.ForEach i C# har eksisteret i snart et årti.

larsp (32) skrev:

Apropos løkker. Har nyere sprog ikke efterhånden fået metoder til at skrive løkker der bliver automatisk og smertefrit paralleliseret? Synes jeg læste om det en del år siden. C#? Java? Andre?

larsp (16) skrev:

Python er iørvigt ekstremt langsomg og bør ikke bruges til CPU tung processering i første omgang.

larsp (30) skrev:

arne_v (22) skrev:

Mine pointer var:
- at C for ikke er en Pascal for men en sær while
- at jeg synes at K&R skulle have lavet en mere normal for løkke

Mange af C's features er farlige men nødvendige for visse typer kode. Og dermed kan den farlige feature begrundes.

Men her er der tale om en sær feature som kan bruges til det samme som en mere traditionel for løkke eller til grim kode (som vel at mærke ikke er mere effektiv end pænere kode).

Jeg er enig og man sidder tilbage og undres over at denne for (;;) konstruktion er blevet båret videre til så mange af de nyere sprog med C style syntax.