Dyskusja pod postem o tym jakich języków wg. mnie się warto uczyć uświadomiła mi, że w ciągu ostatnich 3 lat przysiadłem na laurach jeśli chodzi o naukę programowania. Trzeba to nadrobić :-)
Java mi wystarcza i zbytnio nie przyglądam się niczemu innemu, a to błąd. Bo jedynym sposobem by w miarę dobrze pisać [lub robić cokolwiek innego ;-)] to ćwiczyć, ćwiczyć i jeszcze raz ćwiczyć!
Dlatemu na pierwszy front pójdzie C# do którego niechęć będę zwalczał pisząc w nim :-) Może nie stanie się moim ulubionym językiem, ale powinien zyskać.
W ramach zachęty proszę o podesłanie ciasteczek ;-) [wasze przeglądarki to już robią :-)]
Podobne postybeta
O tym dlaczego programista powinien mieć oczy dookoła głowy
Uczymy się... a przynajmniej próbujemy się uczyć ;-)
Windows++ ;-)
Urodzeni koderzy
Moja możliwa zemsta za zamknięcie Google+ ;-)
piątek, stycznia 15, 2010
Subskrybuj:
Komentarze do posta (Atom)
I znalazłeś w sobie wewnętrzne fuj.
OdpowiedzUsuńW ramach ćwiczeń, proszę o port Paint.NET na Mono.
Zdaje się, że stworzono Paint.Mono, ale toto nigdy nie działało.
Przeczytałem jeszcze raz twój poprzedni wpis i tknęła mnie jedna rzecz – że jakoby Ruby nie jest wart poznania, bo ma już 15 lat. Przecież większość przedstawionych tam języków jest starsza. Niedawno, w jakimś dziwnym ataku nostalgii, próbowałem zainstalować na VirtualBox RedHat 4.2 z 1997 roku i były tam zarówno Python jak i Java (ciekawostka paczka z Pythonem była wielokrotnie większa niż Java).
OdpowiedzUsuńWracając do C#
To chyba jakaś małą obsesja, ale zauważyłem że średnio co pół roku poznaję nowy język programowania – po prostu to lubię. Czasami pobieżnie, czasami całkiem dokładnie. C# też nie przepuściłem, ale już na dzień dobry, pomysł nazywania właściwości z dużej litery był dla mnie argumentem by powiedzieć "Dot Niet!".
To trochę zabawne jak takie drobiazgi, potrafią zrazić, szczególnie w porównaniu z JavaScript, którego lubię, używam na co dzień, a który ciemnych stron ma bez liku…
(O czym nie omieszkałem ostatnio wspomnieć u siebie)
Moim zarzutem dla Ruby nie jest to, że jest stara, ale to, że przez pierwsze 10 lat praktycznie "nie istniała", dopiero Railsy ją rozsławiły. To tak samo jak z Windowsem, który istniał sobie chyba 7 czy 8 lat bez rozgłosu i niewiele znaczył, aż nagle pojawił się Windows 3.0 i zamieszał rynkiem.
OdpowiedzUsuńPrzyglądam się temu C# i tak, ma fajnie ficzery których nie ma Java, ale jak na razie nie zwiększają one mojej satysfakcji z kodowania tak że nie mógłbym bez nich żyć, a nadal przeszkadzają mi te rzeczy, które uznaje za bałaganiarskie. I nie chodzi nawet o konwencję nazw bo do tego można się przyzwyczaić, ale już np. to, że jak się będzie chciało napisze się cały kod składający się z milionów klas w jednym pliku, system Java'owy, gdzie jedna publiczna klasa przypada na 1 plik, jest wg. mnie o wiele bardziej czytelny, nadal przeszkadzają mi właściwości, bo mogą prowadzić do głupich błędów bo patrząc na kod nie wiem tak naprawdę czy piszę do zmiennej czy tak naprawdę wołam metodę, przeszkadza mi podział na metody wirtualne i niewirtualne, o wiele bardziej wolę Java'owe założenie, że wszystko co nie jest metodą prywatną bądź statyczną jest wirtualne, skompilowane też jest używanie virtual w klasie wprowadzającej metodę i później używanie override, szczerze to chyba nigdy się nie spotkałem z sytuacją w której potrzebowałbym w Java'ie publicznej i nie statycznej metody, która nie byłaby wirtualna. Podobają mi się za to z ficzerów C# 3.0 anonimowe typy i z 4.0 typ dynamic, to są rzeczy których mi czasem brakuje w Java'ie. Parametry ref i out mogą prowadzić do poważnych błędów, ale mogą być przydatne, choć do nich w Java'ie nie tęsknię. LINQ i lambda... miłe, choć w LINQ fajnie by było gdyby np. Where zwracało nie IEnumerable ale typ tego co filtrujemy, chociaż takie zachowanie ma sens, bo opiera się na normalnych zasadach dziedziczenia, a nie na jakichś domysłach kompilatora więc jest zaletą :-)
Z miłych rzeczy jest jeszcze operator ??, bo w Java'ie muszę zwykle używać tenarnego, ale daje on mniejsze możliwości i jest mniej czytelny od ??.
Nie podobają mi się klasy częściowe i metody częściowe, chociaż wskazują one na to, że C# ma inną filozofię niż Java, bo stosować je można do umieszczania automagicznie generowane kodu, w końcu co developera ten kod obchodzi, a nie powinien tego kodu modyfikować [w Java'ie taki NetBeans dodaje "urocze" komentarze by nie edytować ręcznie kodu co do końca rozsądne nie jest ;-)], a ta inna filozofia jest w tym, że jednak w Java'ie mało kodu się generuje [inaczej mówiąc, można napisać dużo kodu w Java'ie i generowanie kodu ograniczyć do seterów i geterów, a w C# od początku jest parcie na korzystanie z generowanego kodu]. Więc partial ma sens, jednak mnie osobiście trochę burzy strukturę kodu.
Przyznam, że zaczynam rozumieć konserwatyzm Twórców Java'y, bo dzięki temu jest bardziej spójna, chyba jednym złamaniem zasady najmniejszego zdziwienia w Java'ie jest problem z inicjalizowaniem enumów http://przemelek.blogspot.com/2009/09/javozagadka.html
Inna sprawa, że ten konserwatyzm prowadzi do stagnacji, żeby do teraz na 100% nie było wiadomo czy w Java 7 będą domknięcia?
C# nie znam aż tak dokładnie… ale wiele opisywanych przez Ciebie mechanizmów pojawia się również w innych językach, takich jak na przykład Vala czy Haxe. Niekiedy twórcy wręcz przyznają że źródłem inspiracji jest dla nich C#.
OdpowiedzUsuńC# jest bardzo ograniczony co do wyboru platformy.
Drugi problem to ograniczona kompatybilność w przypadku kolejnych wydań języka. Jakoś trudno mi sobie wyobrazić aplikację która miała by działać ponad 10 lat bez większych problemów i modyfikacji.
Co do Java, to minimalizm w samym języku ma swoje koszty. Ceną jest mniejsza czytelność kodu i większe (co ja piszę… olbrzymie) biblioteki.
Znalezienie złotego środka jest bardzo trudne. Wydaje się że możliwość przeciążania operatorów w Scala znacznie poprawia czytelność kodu – do momentu gdy nie trafi się w kodzie na jakiś dziwny zbitek znaczków.
Osobiście w Java najbardziej brakuje właśnie getterów i setterów z prawdziwego zdarzenia. Pozwoliło by to wyeliminować tak wiele zbędnego kodu…
@blog - mnie właśnie taki rodzaj getterów i setterów jaki jest w Java'ie o wiele bardziej pasuje, bo kod mogę wygenerować w dowolnym środowisku, ale widzę, że wołam metodę. W przypadku właściwości nie wiem czytając kod czy obj.Value = 7 to tylko przypisanie wartości do pola czy może jednak wywołanie jakiegoś kodu związanego z właściwością. Już w Delphi mi to przeszkadzało i w C# też przeszkadza.
OdpowiedzUsuńBo gdy mowa o getterach/setterach, to są dwie szkoły…
OdpowiedzUsuńZ tego co widzę większość natywnych programistów Java woli wywołanie obj.setValue(7), podczas gdy osoby, które zaczynały od innych języków wolą pisać wprost obj.value = 7.
Problem z Java jest taki że gdybyś chciał zmienić semantykę o.value na o.setValue(), to musisz przepisywać cały kod korzystający z tej właściwości – trochę się to kłóci z ideą enkaspulacji…
Inny problem jest taki, że w rezultacie braku setterów z prawdziwego zdażenia, właściwości nie zachowują się jak metody wirtualne. Przynajmniej raz zaoszczędziło mi to kilku tygodni pracy.
Cała reszta to sprawa takiej a nie innej konwencji.
oczywiście @blog == @Red
OdpowiedzUsuńprzypadkowo autoryzowałem się kontem Google zamiast OpenID
(może to i lepiej)
Chodzi głównie o to, że z obj.setValue(7) w najgorszym przypadku mogę się spodziewać wyrzucenia wyjątku, z przypisania wartości bym się tego nie spodziewał ;-) a wylecieć może
OdpowiedzUsuń