Czy stosowanie pętli for to obciach?

Ciekawostki składniowe nie mające żadnego wpływu na wynik ani sposób działania programu.
Jak ktoś świadcząc swoje usługi programistyczne nie rozwiązuje poważnych problemów to poważnym problemem stają się właśnie takie bzdety jak:

• wybór rodzaju pętli,
• ilości linii w funkcji,
• głębokość wcięć w kodzie.

Wszystko to pierdoły nie mające żadnego znaczenia a jednak rozgrzewające serca i dusze amatorów "składniowych masturbatorów"...

... a najszybsze auta to są czerwone ...

A to też jest być może nie piękna ale poprawna pętla do while:

<?php
  $inputArr = [ 'ala', 'ola', 'iza', 'iga', 'ula' ];

  $idx = 0 ;		
  myLoop:
  	
  	echo $inputArr[$idx]."\r\n";
  	$idx++ ;
  	
  if ( $idx < count( $inputArr ) - 1 ) goto myLoop ; 

katakrowa napisał(a):

Ciekawostki składniowe nie mające żadnego wpływu na wynik ani sposób działania programu.
Jak ktoś świadcząc swoje usługi programistyczne nie rozwiązuje poważnych problemów to poważnym problemem stają się właśnie takie bzdety jak:

• wybór rodzaju pętli,
• ilości linii w funkcji,
• głębokość wcięć w kodzie.

Jak się pisze, a potem oddaje kod komuś innemu, to faktycznie nie trzeba się przejmować czytelnością. Gorzej, jak to, co napiszemy, będziemy sami utrzymywali, wtedy lepiej się trochę bardziej postarać.

LukeJL napisał(a):

pętle for też bywają różne. W wielu językach do iteracji po kolekcji można zrobić coś w stylu for a in b i to jest bardziej czytelne niż for (init; cond; after).

To, o czym piszesz to jest foreach, tylko czasami jest to zapisywane jako for . Zwykle będzie to czytelniejsze, chyba że potrzebujesz bieżącego indeksu. Map też będzie czytelniejsze niż for, pod warunkiem że będzie używane zgodnie z przeznaczeniem, a nie na siłę żeby tylko nie było pętli.

Kwestie głębokości wcięć według mnie najlepiej rozwiązano w języku Dart. Jest jeden niekonfigurowalny formatter dostarczany razem z językiem, który formatuje kod zawsze tak samo - ma tak być i koniec. Konfiguracja ogranicza się tylko do długości linii, dodatkowo język pozwala na trailing commas, jak wstawisz przecinek to formatter daje nową linię i to tyle. Kod zawsze jest sformatowany tak samo.

Tak jak jest w Pythonie, yaml (formatowanie jest elementem składni) to już według mnie przegięcie. Bo czasem się chce coś wpisać byle jak w edytorze i po tl jest formatter żeby to ułożył.

gajusz800 napisał(a):

LukeJL napisał(a):

pętle for też bywają różne. W wielu językach do iteracji po kolekcji można zrobić coś w stylu for a in b i to jest bardziej czytelne niż for (init; cond; after).

To, o czym piszesz to jest foreach, tylko czasami jest to zapisywane jako for .

Nawiasem mówiąc taka "tradycyjna" pętla for (init; cond; after) to jest dość sztuczny twór. Można powiedzieć, że to takie while, tylko zapisywane jako for, z wygodnymi skrótami.

LukeJL napisał(a):

gajusz800 napisał(a):

LukeJL napisał(a):

pętle for też bywają różne. W wielu językach do iteracji po kolekcji można zrobić coś w stylu for a in b i to jest bardziej czytelne niż for (init; cond; after).

To, o czym piszesz to jest foreach, tylko czasami jest to zapisywane jako for .

Nawiasem mówiąc taka "tradycyjna" pętla for (init; cond; after) to jest dość sztuczny twór. Można powiedzieć, że to takie while, tylko zapisywane jako for, z wygodnymi skrótami.

Ano.

Drobne różnice w sumie są, np w for scope iterowanej zmiennej jest mniejszy, ale zgadzam się że koncepcyjnie to jest to samo. Tak samo w sumie jak if i switch.

ogólnie to tam pod spodem i tak jest pewnie jakiś skok warunkowy w assemblerze, więc tak naprawdę "wszystko jest jednym", jakby to napisał Coelho.

To zależy. Sam osobiście wolę podejście funkcyjne, więc używam „map” gdzie to ma sens (jest czytelne i wydajne). Z drugiej strony, w takiej javie czasami można się zakląć na śmierć próbując coś zrobić na streamach. Co innego jeśli zależy na wydajności i chcemy robić czary mary ze zrównoleglaniem, wtedy używanie mapów raczej jest na to sposobem i nawet w javie można się pomęczyć (skoro już zrobiłeś tę niemądrą rzecz i dotknąłeś się tego jezyka to przecież wiedziałeś że będzie boleć xD). Natomiast jeśli robię zwykły iteracyjny, proceduralny algorytm to nie ma co wydziwiać, a już w ogóle raczej na pewno nie robiłbym czegoś w stylu range(1,10).foreach(i->…) bo to jakiś przerost formy nad treścią. xD

Pętla jest bardziej niskopoziomowym i zarazem bardziej abstrakcyjnym mechanizmem niż przekształcenia funkcyjne. Taki uniwersalny młotek do wszystkiego.
Przez to tak naprawdę trudniej się ją czyta.

I tak dalej. Za każdym razem jak widzę pętlę, to się zastanawiam, z którym z ww przypadków mam do czynienia (a często z kilkoma równocześnie).
Z pętlą jest trochę jak z goto - goto też jest bardziej uniwersalne i prostsze do nauki niż if/switch/while/for/funkcje, ale jednak nikt tak już nie pisze - wszyscy się nauczyli używać konstrukcji strukturalnych i raczej nie spotkałem się z wątkiem czy używać goto.

Natomiast co do wydajności to oczywiście mocno zależy od języka - w Javie np. dość łatwo strumieniami naprodukować bardzo dużo tymczasowych obiektów, które potem GC musi sprzątać, co potrafi wpłynąć nie tylko na wydajność samego kodu ze strumieniem, ale również na zupełnie niewinny kod gdzie indziej. Dlatego na ścieżce krytycznej nadal staramy się używać pętli a nie strumieni.

LukeJL napisał(a):

Nawiasem mówiąc taka "tradycyjna" pętla for (init; cond; after) to jest dość sztuczny twór. Można powiedzieć, że to takie while, tylko zapisywane jako for, z wygodnymi skrótami.

Jeden z WIELU problemów C. Ktoś coś w 1970roku chciał przez to uzyskać - zachęcam do odświeżenia historii programowania, były wtedy o wiele lepsze języki, wygrał najbardziej prymitywny https://pl.wikipedia.org/wiki/Prawo_Kopernika-Greshama
Dlaczego pomioty C muszą być w 2022 dla nas biblią ? Nie wiem ... pętla tak, ale czy koniecznie pętla for z C ???

ZrobieDobrze napisał(a):

Jeden z WIELU problemów C. Ktoś coś w 1970roku chciał przez to uzyskać - zachęcam do odświeżenia historii programowania, były wtedy o wiele lepsze języki, wygrał najbardziej prymitywny https://pl.wikipedia.org/wiki/Prawo_Kopernika-Greshama

Myślę, że po prostu ktoś zauważył powtarzający się wzorzec: inicjalizacja licznika -> warunek stopu -> zwiększenie licznika; i stwierdził, że znacznie czytelniej będzie umieścić to w nagłówku pętli.
Jaki lepszy język programowania istniał na początku lat 70ch, byłby lepszy niż C i jednocześnie nadawał się do napisania systemu operacyjnego? W C napisano Unixa, Unix był ważny i popularny, więc sprawiło to, że C stał się popularny. Generalnie, po wkładzie Unixa w rozwój programowania, raczej bym się 2 razy zastanowił nad tym czy inne języki rzeczywiście były lepsze na tamten czas.
Przy maszynach o dzisiejszej mocy, C nie ma wiele sensu, w większości wypadków, ale jeszcze 25 lat temu, typowy PC miał ok 512kB RAMu i 133MHz procka; Tu mówimy o czasach 2 razy dawniejszych. xD

Dlaczego pomioty C muszą być w 2022 dla nas biblią ? Nie wiem ... pętla tak, ale czy koniecznie pętla for z C ???

Dokładnie z tego samego powodu procesory x86_64 mają tryb chroniony i całą resztę spadkowych cech starego x86. Intel myślał, że od tego ucieknie, tworząc Itanium, ale to nie zadziałało. ;D Technologia istnieje w swoim kontekście historycznym. Nowe języki zawierają starsze konstrukcje ze względu na starszych programistów, dla których to może być wygodniejsze.

elwis napisał(a):

Nowe języki zawierają starsze konstrukcje ze względu na starszych programistów, dla których to może być wygodniejsze.

Które nowsze?
Ani Kotlin (https://bulldogjob.pl/readme/jak-dziala-petla-for-w-kotlinie) ani Scala (http://grzegorzbalcerek.org/jps2/for_forloop.html) nie mają klasycznej pętli z C :P

KamilAdam napisał(a):

elwis napisał(a):

Nowe języki zawierają starsze konstrukcje ze względu na starszych programistów, dla których to może być wygodniejsze.

Które nowsze?
Ani Kotlin (https://bulldogjob.pl/readme/jak-dziala-petla-for-w-kotlinie) ani Scala (http://grzegorzbalcerek.org/jps2/for_forloop.html) nie mają klasycznej pętli z C :P

Może dlatego, że Scala i Kotlin są następcami Javy, która jest następcą C++, który jest następną C. Jeszcze Java ma tą konstrukcję.

elwis napisał(a):

Nowe języki zawierają starsze konstrukcje ze względu na starszych programistów, dla których to może być wygodniejsze.

No nie wiem. Nie wydaje się to jakimś sensownym argumentem. Przyzwyczajenia to chyba słaby argument do projektowania elementów języka.

Gdzieś mi mignął post na twiterzu z benchmarkiem z którego wynikało że w NET7 foreach jest już szybszy od klasycznego for'a . Nie weryfikowałem.

kzkzg napisał(a):

Gdzieś mi mignął post na twiterzu z benchmarkiem z którego wynikało że w NET7 foreach jest już szybszy od klasycznego for'a . Nie weryfikowałem.

No nic dziwnego, foreach może zmienić szczegóły implementacyjne kolekcji; a "klasyczny for" jest jakby zmuszony przejść tymi krokami a;b;c; z indexami, a to z kolei wymusza random-access, i ciężej użyć np linked-list.

kzkzg napisał(a):

Gdzieś mi mignął post na twiterzu z benchmarkiem z którego wynikało że w NET7 foreach jest już szybszy od klasycznego for'a . Nie weryfikowałem.

Na pustej kolekcji? ;) Nie takie cuda się w benchmarkach widziało. :P