Kopiuj
var persons = Enumerable.Range(0, 10).Select(i => new Person {
FirstName = i.ToString(),
LastName = "Nazwisko"
}).ToList();
persons.ForEach(Console.WriteLine);
Bardzo naciągany przykład. Gdy chcemy coś wykonać wiele razy, to używamy pętli, a nie tworzymy niepotrzebną kolekcję liczb, i wołamy na niej metodę.
Moj algorytm nie wymusza znajomosci sposobu iteracji po kolekcji.
Dzięki czemu może być użyty przez kogoś, kto nie zna pętli. Coś pisałeś chyba o równaniu średniej umiejętnościowej, ale aż tak?...
Wszystkie czesci sa atomowe i moga byc reuzywane w osobnych miejscach, niezaleznie od rodzaju obiektow czy kolekcji agregujac.
Naprawdę trudno mi znaleźć jakieś części w tak krótkim kawałku kodu. :)
Nie korzystam z zadnych wnetrznosci specyficznych dla danej kolekcji, nie wymagam indeksera czy dostepu do losowego elementu. Nie wymaga, zeby argumentem tego indeksera byl int. W gruncie rzeczy nic nie wymagam, tylko korzystam z abstrakcji dostarczonej przez MS.
Właśnie wymieniłeś wszystkie zalety foreach.
Twoj kod natomiast uzywa prymitywnych rozwiazan rodem z C, ale nie przejmuj sie, kiedys zrozumiesz ile wnosi przekazywanie odpowiedzialnosci za iteracje do kolekcji, ktora ma wieksza wiedze o tym jak ja wykonac i jaka modularnosc i elastycznosc to powoduje. Zarowno w programowaniu rownoleglym, jak i 1-watkowym.
No i prymitywne rozwiązanie z Lispa jest argumentem na prymitywne rozwiązanie z C? ;P
Po pierwsze, to foreach nie jest pętlą. To tylko zgrabne opakowanie składniowe na abstrakcję, którą dostarcza IEnumerable. To jest elastyczne i modularne rozwiązanie.
Po drugie, foreach jest w wielu zastosowaniach wydajniejszy, bo jest optymalizowalny przez kompilator, np. w przypadku iterowania po stringu albo tablicy.
Tak pominalem ten blad w sztuce .NET. Ja mam ForEach dla kazdej kolekcji, po ktorej chce iterowac, ale znow... musialem to napisac, przetestowac i w gruncie rzeczy zajelo calosc wiecej niz 5 minut.
To nie jest błąd w sztuce, to jest celowe i spójne działanie. Metoda ForEach nie jest częścią LINQ, i została zaimplementowana tylko tam, gdzie ma ona sens.
Metody z LINQ zawsze zwracają wartość i nie powodują skutków ubocznych - co jest zgodne z funkcyjnymi założeniami tej technologii. Metoda ForEach jest całkowitym przeciwieństwem tego - jej jedynym sensem jest powodowanie skutków ubocznych, a nie zwracanie wyniku. Jako, że LINQ nie powoduje skutków ubocznych, to może działać na IEnumerable<T>, czyli na kolekcjach z definicji niezmiennych. Tworzenie metody zmieniającej stan tam, gdzie chodzi właśnie o niemutowalność, wygląda mi na lekką paranoję.
Oczywiscie, ze jest. Moj kod mowi o tym, co chce zrobic, twoj jak to zrobic.
Ty chyba chcesz z C# zrobić coś, czym on nie jest.
Fakty są takie, że C# jest językiem imperatywnym. Sterowanie w nim odbywa się poprzez pętle i instrukcje warunkowe. Te kilka funkcyjnych dodatków, które posiada, absolutnie nie czynią z niego języka funkcyjnego. Są miłe i przydatne, bo pozwalają pominąć pisanie żmudnych pętli w wielu typowych przypadkach, ale nie zastępuję one typowych, imperatywnych operacji.
Jak ktoś chce pisać funkcyjnie, to niech robi to w języku funkcyjnym, a nie w C#.
Dlatego tez nie widze zadnego sensu w uczeniu ludzi mowienia komputerowi pokolei jakie rozkazy ma wykonywac.
Nikt nie mówi nikomu dokładnego algorytmu, tylko wywołuje funkcję. Jak najbardziej imperatywną, bo ludzie są imperatywni, myślą i działają w ten właśnie sposób.
C# 
