Wreszcie pojawiły się oficjalne informacje na temat nowego języka Dart. Firma Google proponuje ten język jako następce JavaScript. Specyfikacja Darta i przykłady kodu wydają się bardzo interesujące.
Nieoficjalne informacje na temat nowego języka były bardzo intrygujące i niejeden programista nie mógł się doczekać oficjalnych informacji na temat Darta. Na szczęście firma Google udostępniła oficjalną stronę tego języka www.dartlang.org
Wiadomo już, że język ten będzie wykorzystywał maszynę wirtualną uruchamianą za równo w przeglądarce jak też bez niej. Początkowo Dart ma działać natywnie tylko w przeglądarce Chrome, zaś w pozostałych jego kod ma być przetwarzany do JavaScriptu. W założeniach Dart ma być językiem uniwersalnym do tworzenia aplikacji webowych zarówno po stronie serwera jak i klienta.
Wśród cech jakie ma osiągnąć można wymienić:
- możliwość pisania i korzystania z bibliotek współdzielonych
- duża szybkość działania programów i skryptów (również szybki start)
- pełna obiektowość – podobna do tej z Javy (jednobazowe dziedziczenie z interfejsami)
- opcjonalne statyczne deklaracje zmiennych i zwracanych wartości przez metody
- dodatkowy, specjalny tryb działania – debbug
- dostarczenie odpowiednich narzędzi wszystkim producentom przeglądarek, umożliwiające działanie Darta
- działanie praktycznie na każdym rodzaju urządzenia (smartfon, tablet, laptop, serwer)
- nowy MIME type HTML: application/dart
Po zapoznaniu z przykładami kodu, można stwierdzić, że programista zaznajomiony z językami typu Java lub C++ w zasadzie nie musi uczyć się składni Darta. Wystarczy jednie nauczyć się wykorzystywać jego biblioteki (lub samemu je pisać).
Projekt Google jest jeszcze w bardzo wczesnej fazie rozwoju, więc przyjdzie nam jeszcze długo poczekać, żeby zobaczyć jaki będzie ten nowy język i czy stanie się popularny, albo może czy zupełnie zastąpi JavaScript.
Google jak zwykle na czele.
A reszta pseudoinnowacyjnych firemek grzebie się w bagnie i nie robi nic, żeby z niego wyjść. Póki nie toną, to jest im dobrze.
Jest coś w tym, co piszesz – ostatni raz byłem tak podekscytowany gdy po raz pierwszy usłyszałem o GWT 😉
Lubię eleganckie rozwiązania. Nauczenie się następnego języka programowania to jest kilka dni zabawy jeżeli (jak Dart) podobny do kanonu C/C++/Java.
Ale przeportownie istniejących rozwiązań wcale nie jest już łatwe a pisanie dużych projektów w nowym języku to prośba o kłopoty… Dlatego podejrzewam, że będzie jak z PHP, który jest paskudnym językiem (np. lista ,,wbudowanych'' funkcji zaczynających się literą ,,a'' ledwo mieści się na jednej stronie w trzech kolumnach…) ale powszechnie używanym. Ludzie klną ale dziergają w nim swoje projekty bo jest niezwykle popularny bo dużo ludzi dzierga w nim swoje projekty bo…. 😉
Bo np. nie znają zalet Pythona 😀 sam jeszcze nie umiem w nim programować, ale te zalety już znam 😉
Znają znają. Znają też niestety wady. Brak statycznego systemu typów w Pythonie oraz bardzo słabo zrealizowana wielowątkowość to chyba dwie najpoważniejsze. Brak instrukcji if działającej jak funkcja również jest wkurzający, jak się wcześniej miało do czynienia z językami funkcyjnymi.
Podobno nastawiony na wydajność programisty 🙂 Z drugiej strony nie zawsze bawią się w kompatybilność wstecz, więc może i te większe problemy kiedyś rozwiążą 🙂
Brak statycznego systemu typów akurat znacznie obniża wydajność programisty, bo programista musi sam robić to, co w innych językach robi za niego kompilator.
Częściowo się zgodzę. Kompilator posprawdza czy nie ma tam jakiejś oczywistej bzdury, ale niestety nie zastąpi on regularnego testowania napisanego kodu czy to przez programistę czy testy jednostkowe.
I nie powiedziałbym, że brak kompilatora _mocno_ obniża wydajność. Ja bym to ujął tak: większa moc języka (bo zwykle interpretowane języki potrafią więcej niż kompilowane) w zamian za większą liczbę irytujących błędów w runtime. Myślę, że wydajność programisty – jak już – może troszeczkę spadnie.
Ja osobiście gdy pisałem w Pythonie nie tęskniłem mocno za kompilatorem, ale nadszedł czas kiedy zatęskniłem – refactoring – to jest koszmar bez kompilatora. Kolejna rzecz na minus Pythona to brak dobrego IDE (porównywalnego z np ide Javy), co dodatkowo utrudnia zadanie, ale być może to kwestia przyzwyczajenia.
A czy przypadkiem w Pythonie nie musimy stosować większego stopnia pokrycia kodu testami jednostkowymi niż w Java?
Polecam Scalę, przy odrobinie wprawy pisze się prawie tak szybko jak w Pythonie, a dodatkowo ma kompilator ( i jeszcze nie musisz studiować metody aby wiedzieć co zwraca 🙂 )
"A czy przypadkiem w Pythonie nie musimy stosować większego stopnia pokrycia kodu testami jednostkowymi niż w Java?"
Czy jest _większy_ stopień pokrycia? Jeśli chodzi o sprawdzanie typów, to faktycznie można to robić i faktycznie wtedy testy wyjdą odrobinę dłuższe niż normalnie, ale nie demonizowałbym tego nakładu, że jest wielki. IMO tak czy inaczej testy w porównaniu z Javą będą krótsze, bo python ma większą moc wyrazu (w jednej linii można zawrzeć to co w Javie pisze się w kilku).
Apropo Scali. Dorobiła się ona dobrego IDE? Osobiście nigdy nie pisałem w Scali, ale jakiś czas temu czytałem, że temat IDE wygląda bardzo źle. Druga sprawa odnośnie Scali. Jak wygląda szybkość uczenia się tego języka? Jest to duży problem dla kogoś kto nie miał styczności z językami funkcyjnymi?
IDE do Scali są już na znacznie lepszym poziomie niż te do Pythona.
Owszem, nie wszystko jeszcze działa perfekcyjnie (np. sprawdzanie błędów typów w locie dla złożonego kodu – błędy typu "good code red"), no ale tego przecież IDE do Pythona w ogóle nie mają "by design". Działa nawet refactoring, coś o czym w Pythonie można pomarzyć.
Szybkość uczenia się – jak znasz Javę, to właściwie z marszu można zacząć programować w Scali. Podstawowa Scala jest łatwiejsza niż Java. IDE daje sprawne podpowiadanie metod, widać metody dostępne dla obiektu, widać też co metody przyjmują i co zwracają – dla mnie był to bardzo duży plus w szybkości nauki względem Pythona (gdzie z tym podpowiadaniem to różnie bywało, często IDE podpowiadają wręcz źle albo się gubią). Do tego IMHO kolekcje są w Scali znacznie prostsze w użyciu niż w Pythonie – mniej specjalnej składni, więcej załatwiane bibliotekami.
PS. Jeśli swoją opinię na temat IDE do Scali wyciągnąłeś na podstawie Eclipse rok temu, to musisz odświeżyć swoje zdanie na ten temat. Rok temu nie dało się tego używać.
Jak zatem sprawdza się IDE PyDev?
Swoją drogą, przeniesienie sposobu formatowania kodu na składnię języka ma sporo zalet 🙂
Nie wiem. Mam mieszane uczucia w tej kwestii. Wadą jest konieczność uważania na ustawienia edytora. W innych językach – jeśli rozjadą się wcięcia, to jeden skrót klawiaturowy i kod jest poprawiony. W Pythonie już tak lekko nie jest. Niemożliwość pisania krótkich jednolinijkowych instrukcji if/else też jest trochę niewygodna. Jeśli cały if/else mieści się w 20 znakach, to rozbijanie go na 4 linie tylko zmniejsza czytelność.
[on_true] if [expression] else [on_false]
np.
x, y = 50, 25
small = x if x < y else y
Można wcięcia lubić lub nie (podobnie jak klamry), ale sporo mitów na ich temat powstało. Jeśli ktoś ma z nimi problemy powinien przeczytać PEP 8 lub po prostu skorzystać z edytora ze wsparciem dla Pythona (zdecydowana większość popularnych).
Polecam "Python: Myths about Indentation": http://www.secnetix.de/olli/Python/block_indentat…
Ps Refactoring w Eclipse (PyDev) działa. Niestety nie wiem jak to wypada na tle innych języków programowania i jak wygląda obsługa refactoringu w komercyjnych IDE typu Wingware czy PyCharm.
No właśnie, tak jak kolega wyżej podał 🙂 Po za tym dynamiczne typy i myślenie w kontekście operacji jakie można wykonać na danym obiekcie właściwie zwiększa i wydajność programisty, i użyteczność kodu. Zamiast myśleć jakiego typu danych o jakim rozmiarze nadać danej zmiennej, programista skupia się na problemie. Ma to swoje wady i zalety, ale nie widzę, aby miało to zmniejszać wspomnianą wydajność.
Co do drugiego, jak już wiadomo, w Pythonie nie myśli się typami danych, a operacjami, np. są grupy obiektów będące sekwencjami i taka grupa posiada wspólny zestaw operacji (wycinki itp.). Dzięki czemu ten sam kod może być wykorzystany w kontekście przykładowych list i ciągów znaków (oba są sekwencjami).
Innym ciekawym mechanizmem są listy składane. Zamiast pisać kilkuwierszową pętlę for, w Pythonie robi się to w jednym wierszu, np wybranie nieparzystych liczb z listy wyglądałoby tak: nieparzyste = [i % 2 for i in lista]. Ciekawe są również operacje logiczne na obiektach. Zamiast zwracać prawdę/fałsz, Python zwraca obiekt niepusty, np. niepusty = ob1 || ob2.
Po za tym to co już kolega wspomniał, zamiast pisać tmp = a; a = b; b = tmp, pisze się po prostu a, b = b, a, a nawet można a, b, c = b, c, a. Takich niuansów jest znacznie więcej. Nie każdy język pozwala na konstrukcję x < y < z. Wszystko to (i wiele więcej) zmniejsza ilość kodu do napisania, a im mniej kodu do napisania, tym mniej błędów, co ostatecznie wpływa na większą wydajność programisty i jakość kodu.
Co do refactoringu, nie mam zdania, bo na razie uczę się tego języka z teorii (tzn. czytałem jakiś czas temu fragment książki, ale nie programuję w nim jeszcze).
Co do stosowania klamer w innych językach, trzeba je stosować zawsze, bo może dojść do podobnej sytuacji:
if (warunek1)
if (warunek2)
operacja1;
else
operacja2;
Po za tym to właśnie w tym wypadku czytelność kodu zależy od tego ilu programistów z jak bardzo zróżnicowaną konfiguracją edytora (chodzi o wcięcia) ingerowało w kod. Niby rozwiązuje to jedna kombinacja klawiszy, ale gdy taki kod podlega kontroli wersji, niepotrzebnie wprowadza to dodatkowych "zmian" w kodzie (prym wiodą tu projekty o otwartym źródle).
Edytory, które wspierają pisanie kodu dla Pythona muszą dynamicznie określać, czego użyć dla uzyskania wcięcia w bloku, dzięki czemu edytor tak jakby dynamicznie konfiguruje się do danej sytuacji i "powiela" styl wcinania kodu.
To takie przemyślenia laika w kwestii programowania w Pythonie 🙂 Głównie chodziło o przedstawienie skromnej liczby zalet. Osoby, które pojęły idee tego języka za pewne znajdą znacznie więcej wyższości Pythona nad innymi językami 🙂 Sądzę jednak, że ten język warto znać, ponieważ jest wykorzystywany do rozszerzania możliwości wielu różnych programów, np. w Blenderze, GIMPie itd. Można też dzięki niemu pisać własne rozszerzalne aplikacje.
Hmmm, co do warunków bez klamer, jeszcze raz to przedstawię…
if (warunek1)
….if (warunek2)
……..operacja1;
else
….operacja2;
Kod wyżej nie zachowa się tak jak to widać. W Pythonie natomiast jest to jednoznaczne, tzn.:
if warunek1:
….if warunek2:
……..operacja1
else:
….operacja2
WYSIWYG 🙂 W sumie trochę przykład na wyrost, bo wystarczy wymusić używanie klamer w takich wypadkach.
Niestety wszystkie te udogodnienia, które wymieniłeś, z wyjątkiem kwestii klamer, są od dawna dostępne w językach ze statycznymi systemami typów, i to istniejącymi znacznie dłużej niż Python. Tylko że ludzie mają spaczone wyobrażenie o statycznych systemach typów, bo patrzą przez pryzmat Javy i C++. Jak ktoś przechodzi z Javy do Pythona, to faktycznie brak konieczności klepania typów może jakoś go tam przyspieszać przez pierwsze 100 linii kodu (później niestety przychodzi spłata kredytu czyli… refactoring). Ale jak ktoś przychodzi z np. Scali / F#, to Pythona raczej lubić nie będzie… właśnie dlatego, że mają praktycznie wszystko to samo co Python a do tego jeszcze statyczny system typów.
Dzięki, warto wiedzieć 🙂 Na pewno przyjrzę się obu ostatnio wymienionym językom programowania.
IDE dla Scali działa całkiem nieźle choć daleko mu jeszcze do Javy, ale składnia Scali jest bardziej rozbudowana. Osobiście używam Netbeansa, bo najłatwiej mi zintegrować z mavenem, ale ci co używają IDEA mówią, że jest najlepsze.
Jeżeli ktoś nie jest geniuszem (jak władca_kodu a po nawie zgaduję, że jest 😉 ) to nauka Scali jest trudniejsza niż nowego języka z rodziny C. Dokumentacja niestety nie jest super opisana. Na szczęście są dobre książki w tym IMHO najlepsza "Programing in Scala" Oderskieg, której pierwsza edycja jest dostępna za darmo online. A w sieci jest też sporo przykładów na forach. Poza tym można pisać początkowo bardziej w stylu imperatywnym i dopiero z czasem przechodzić (albo i nie) na styl funkcyjny – większość piszących w Scali stara się pisać funkcyjnie choć sam język tego nie wymaga.
Tak tak….
… kupili od kogoś niszowy i niekompatybilny z niczym pomysł, zrobili trochę szumu jak wokół GO i tyle.
Prawie jak Microsoft i ich VBScript… 😀 Też "na czele".
Masz jakieś bliższe informacje o zakupie Dart, bo wydawało mi się, że zatrudnili ludzi do napisania języka od podstaw?
Oczywiście. Tak samo jak z Wave, Buzz i Plusem czy +1.
fajne, ale znając życie wejdzie w użycie za 10 lat
Masz na myśli wsparcie ze strony producentów przeglądarek? Nie, nie będzie tak źle, bo tam, gdzie nie ma natywnego wsparcia, "degraduje się" do JS. Jeśli chodzi o taką ogólną popularyzację, to na pewno potrwa, choćby dlatego, że na chwilę obecną toto nawet nie jest gotowe – ale potencjał ma spory.
https://gist.github.com/1277224 No niekoniecznie
😉 hehe No coz trzeba sie poswiecic, jak chce sie miec wszystko pod wszystkie wersje przegladarek. Ale to juz jest bardziej wina samego JS – toporny jesli chodzi o skalowalnosc, jak i to ze kazda przegladarka ma swoje wyjatki. .
Skalowalność skalowalnością, ale to jest FAIL. Jaki kod wygeneruje, gdy napiszę coś większego w tym języku. Trzy tryliardy linijek? Może nie, ale nigdy nie mam pewności, prawda?
Kolejna ciekawostka od Google, którą ktoś tworzy w czasie wolnym.
Zapewne niewiele więcej kodu. Dużo deklaracji i tworzenia struktur. Do małych skryptów się nie nadaje, jednak jest to rozwiązanie przejściowe bo docelowo ma chodzić natywnie.
Przecież już mają coś podobnego i nikt tego nie wspiera – Native Code, czy jakoś tak. Nikt, ale to absolutnie nikt, nie zdecyduje się wprowadzać rozwiązań Google. Dlaczego? Bo to rozwiązania kontrolowane przez Google. Gdy coś takiego staje się standardem w sieci, tworzony jest dyktat jednej firmy (już mamy próbkę z Flashem). Twórcy przeglądarek musieliby implementować wszytko, co G sobie wymyśli. Internet nie powinien działać w ten sposób.
Co do ilości kodu, to przekoloryzowałem. Fakt w dużej mierze to framework, ale implementacja struktur obiektowych jakie znamy z innych języków w javascripcie też moim zdaniem będzie dokładać kodu. Już nie w takim stopniu, ale jednak.
Marzeniem Google jest obsługa wszystkiego w przeglądarce, ale w rzeczywistości to jest nonsens. To replikacja funkcji systemu z dodatkowym narzutem.
Porównanie z Flashem w ogole nie trafione. Jak moze byc dyktat skoro to jest open source?
Native Client to jest co innego. Ale na ta technologie jest troche za wczesnie…. Za nim to sie zaadoptuje uplynie troche wody w rzece, i tez jest otwarte.
Raczej chodziło Ci o Closure Compiler. Programisci ktorzy to rozwijaja, rozwineli tez dla GWT i jako framework (nawet pod mobilne przegladarki) dziala swietnie. Teraz to bedzie pracowac dla Darta. Jak na swoj czas istnienia to i tak jest dobrze rozpowszechniane. A do póki jest OS nie ma sie czego obawiac z wdrazaniem.
A co do narzutu kodu. W gwt tez jest w wyniku pelno linijek JS, ale poszczególne przegladarki pobieraja i cache'uja tylko to co im jest potrzebne. Dla Gecko (firefox), Explorer, safari i mobilne , kazde maja swoja wersje. A to sie liczy, a nie ile kodu jest na serwerze. Tak samo bedzie pewnie w przypadku Darta (albo juz jest).
Flash to jest inna technologia i inne rozwiązanie, ale dyktat firmy jest taki sam.
To, że coś jest open source, nie znaczy, że zrobisz ctrl+c i ctrl+v i jest zaimplementowane w przeglądarce. Nie rozumiesz pojęcia kontrolowania projektu. Jeśli Google doda nową funkcję, to wszyscy będą musieli ją dodać w taki sposób jaki Google sobie upatrzyło. A co jeśli to niemożliwe, bo nasza przeglądarka jest zbudowana na innych zasadach? Twórca przeglądarki nie ma nic wtedy do gadania. Google kontroluje projekt.
I chodziło mi o Native Client, bo to dokładnie te samo założenie. My będziemy tworzyć rozwiązanie, a wy grzecznie będziecie to implementować u siebie tak jak my tego chcemy. GWT ma inne założenia. My tworzymy narzędzie, kontrolujemy projekt, ale was to nic nie musi obchodzić, bo my zapewniamy, że będzie u was działać (niczego nie musicie zmieniać). Co do zastosowania, GWT to frontend, tak samo jak jQuery to frontend. A Darta postrzegam jako coś innego, jako język w którym sobie napiszesz grę lub jakąś potężną aplikację, która nie wyrobiłaby z działaniem po stronie serwera. Innymi słowy są to marzenia i mrzonki Google.
Kiedyś może doczekam się, gdy ktoś napisze, że Google rozmawia z innymi dystrybutorami przeglądarek o nowej technologii, ale pewnie nie prędko. G musi się jeszcze parę razy potknąć i wydać paręnaście milionów dolarów na idiotyczne języki.
Projekt na bsd, w każdej chwili Microsoft może zrobić jak zwykle, czyli zmienić implementacje, żeby nie była w pełni kompatybilna z oficjalną wersją 😉
Native Client jest czym więcej niż Dart, bo ten ostatni ma być zastępstwem dla JavaScript. NaCl jest przewidziany tylko na szczególne przypadki, mało kto bez powodu będzie chciał pisać coś na przeglądarkę z użyciem C++.
Niektóre marzenia i mrzonki stają się rzeczywistością. Dart umożliwi to samo co w tej chwili GWT z Javą, a dodatkowo w Chrome (a może szybko w FIrefox) będzie działać bez udziału JS, więc szybko i wydajnie. Ponad to możliwość pisania dla tabletów i telefonów. To może się przyjąć.
Go od razu mi się nie spodobał, Dart od razu wydaje się świetny 😉
Mnie to wygląda na bibliotekę runtime – czyli te 17k linii to stały narzut. W teorii dałoby się wyciąć tylko z tego potrzebne rzeczy, ale jako że Dart jest językiem dynamicznym, byłoby trudno.
Skalowalność to termin zabytkowy, jeśli ktoś w tej chwili poszukuje aplikacji webowych i tego typu technologi to wie jakich przeglądarek używać.
Każdy sprzedający aplikacje podaje zależności, wiec w czym problem. Pisząc aplikacje podaje się jej wymagania jak przy grach czy jak przy dowolnym programie.
Tak z prywatnego aspektu.
Pisze na co dzień aplikacje webowe i jedynym problemem jest dobranie czcionek dla dokumentów bo Panie w biurze się skarżą.
Przestańcie się przejmować tym 1% czy 30% procentami rynku który używa IE bo oni na 100% nie skorzystają z aplikacji webowej 🙂
Pozdrawiam konkurencje
Jak to jest np. sklep internetowy to będzie 30% mniej klientów.
nie nie bedzie. bo jak sklep ma dobra oferte to wiekszosc osob wejdzie tam inna przegladarka 😀 (np. po powrocie do domu, jezeli w pracy maja dostep tylko do IE).
Dobry towar sam się sprzedaje. Tylko miernota wymaga IE.
Narazie jest tak że troche za wczesnie jest tu cos krytykować, chwalić też nie ma czego.
Z mojego punktu widzenia ma pare zalet jak:
– open source, w tym wtyczki dla eclipse, widac ze google bedzie go wspieralo. To IDE z otwartych i niezaleznych jest najlepsze.
– skladnia c like w tym umozliwienie tego czego nie bylo w javie jak przeciazanie operatorow.
A wiec na dobra sprawe czeka nas kolejna wtyczka do przegladarek. Podejrzewam powody sa 2. Google chce wypromowac jezyk, przy okazji uniezaleznijac sie od Javy (jako jezyka). A wiec Oracl nie bedzie mogl sie przyczepic do kolejnej wirtualnej maszyny.
I podejrzewam ze tym produktem chce zwiekszyc zasieg przegladarek, JS nie dosc ze sie slabo nadaje do robienia rozbudowanych aplikacji, to tez nie zastapi aplikacji desktop tu ma zbyt ograniczone mozliwosci, a google jak widac chce proces odchodzenia od aplikacji desktop tylko przyspiejszyc… NArazie wprowadzajac klienty offline pod gmaila, docs, kalendarz etc. budujac takie cos jak Chrome Remote Desktop.
Jak udostepni pelne API pod wszystkie swoje uslugi, i to bedzie do mobile, chrome, i stron www to fakt moze byc spory sukces. Ale do tego dluga droga….
Google reaguje na problemy z rozwojem JS. Od kilku lat rozwój JS nie idzie do przodu, bo ma błędy u podstaw. Więc Google doszło do wniosku, że trzeba wszystko zacząć od początku.
To ma być uniwersalny język do wszystkiego, spełnienie marzeń programisty. Po stronie serwera i w przeglądarce, dynamiczny lub statyczny jak kto woli 🙂
"To ma być uniwersalny język do wszystkiego, spełnienie marzeń programisty. Po stronie serwera i w przeglądarce, dynamiczny lub statyczny jak kto woli 🙂 "
No no, to prawdziwy przelom i innowacja, tylko czy ja czegos
podobnego nie slyszalem 15 lat temu o javie?
Akurat te zapowiedzi 15 lat temu zostały wcielone w życie i Java jest uniwersalnym językiem niemal do wszystkiego, więc nie wiem czy ta ironia jest zasadna… Dla mnie Dart mógłby wyglądać jednak trochę mniej jak Java, żeby był ciekawy. Inaczej to znowu kolejna "prawie Java by Google", niekompatybilna z oryginalną.
Akurat chodzilo mi o 'to prawdziwy przelom i innowacja' a nie o to co sie javie udalo a co nie.
To był przełom i innowacja, jedynie działanie w przeglądarce nie rozpowszechniło się zbyt mocno.
Dziekuje za wytlumaczenie, nigdy bym na to nie wpadl.
Nie rozpowszechniło się może tak mocno jak Flash (w sensie stosowanie tego do byle bannerów), ale nadal jest mnóstwo popularnych stron i gier używających Javy w przeglądarce. Choćby strony z emulatorami starych gier na Commodore / Atari, Minecraft, Runescape, w Polsce Kurnik, bardzo wiele banków używa też apletów Javy do zabezpieczania stron.
Jak dla mnie, JS dałoby radę, gorzej z HTML…
HTML to jest "tylko" piekło niekompatybilności (w czołówce IE i opera). Np. na WebKicie trzyma poziom.
JS to tragiczne rozwiązanie u samych podstaw projektowych, poczynając od braku realnej obiektowości.
Wiele można zarzucić JS, ale brak obiektowości?
var x = new Object();
var x = {
a: "a",
b: "b",
fun: function(){ …}
};
function ToTezJestObiekt(){
this.a = "a";
this.fun = function(){…}
}
Dziedziczenie przez prototypy ma swoje ograniczenia, ale bez przesady. Język obiektowy nie musi mieć koniecznie klas.
Poza tym obiektowość nie jest fetyszem. Akurat do pracy z HTML-em (lub czymkolwiek hierarchicznym) język obiektowy jest słaby, lepiej się sprawdza język funkcyjny – a JavaScript jest również takim językiem. Gdy się go poprawnie wykorzystuje (patrz jQuery) to pracuje się bardzo fajnie.
Obiektowość to przede wszystkim klasy i ich rozbudowane dziedziczenie.
Taką pseudoobiektowiość to ma i C i np. GTK oparte na strukturach.
W JS są żałosne prototypy i absolutny brak typowania, a przez to brak możliwości tworzenia rozsądnych metod o tej samej nazwie i ilości argumentów, w tym argumentach z domyślną wartością. Jasne, że da się to obchodzić sprawdzając typ przekazanego parametru, a gdy jest undefined, nadawać wartość domyślną. Ale to wszystko hacki na idiotyczny projekt tego języka.
JavaScript nie potrafi też wywołać w prosty sposób metody rodzica.
Idiotyczny schemat przekazywania przez wartość/referencję (zresztą tak glupi jak w Javie).
I długo by jeszcze wymieniać.
LOL. Za takie stwierdzenie na egzaminie magisterskim bym Cię oblał.
Choć pewnie by mi nie pozwolili, bo poziom się ustawicznie obniża i większość dostaje tego inżyniera / magistra mimo ewidentnych braków w podstawach.
Akurat obiektowość w JS jest znacznie lepiej zgodna z oryginalnym paradygmatem OOP zdefiniowanym przez Alana Kay'a niż kompletnie wypaczona obiektowość Cpp .
A konkretnie co jest takiego ewidentnie głupiego w tym zdaniu? Rozumiem, że może być nieścisłe, ale za jedno zdanie oblewa się na rzeczach ewidentnych a nie na 'niedopowiedzianych' (np. że 255.255.255.0 to taki specjalny adres IP).
Osobiście wydaje mi się, że zwyczajnie się czepiasz bo przemawia przez ciebie kryzys wieku przedśredniego 😛 😉
Chodzi o to, że klasy i dziedziczenie nie są ani warunkiem koniecznym uznania języka za obiektowy, ani wystarczającym. Tak samo jak możliwość pisania funkcji nie czyni języka funkcyjnym. To czy język jest obiektowy / funkcyjny / strukturalny / reaktywny, wyznacza przede wszystkim sposób w jaki traktowany jest stan i jakie jest podejście do jego zmian. Dziedziczenie czy klasy nie mają tu nic do rzeczy.
To czy język jest obiektowy / funkcyjny / strukturalny / reaktywny, wyznacza przede wszystkim sposób w jaki traktowany jest stan i jakie jest podejście do jego zmian.
<- mozesz to rozwinac bo kompletnie jest to dla mnie niezrozumiale szczerze powiedziawszy
Paradygmat…
proceduralny / strukturalny – stan mutowalny globalny zorganizowany w struktury przekształcane przez procedury
obiektowy – brak stanu globalnego, stan mutowalny prywatny dla obiektów, modyfikowany za pośrednictwem metod
funkcyjny – brak stanu mutowalnego, nowy stan tworzony na podstawie starego za pomocą funkcji
funkcyjno-obiektowy – brak globalnego stanu mutowalnego; jak obiektowy, ale oparty na obiektach niemutowalnych
reaktywny – stan wyznaczany przez dane wejściowe i zestaw ograniczeń (często jako funkcje) spełnionych w każdej chwili
> przez to brak możliwości tworzenia rozsądnych metod o tej samej nazwie i ilości argumentów,
> w tym argumentach z domyślną wartością.
Brak tekiej możliwości też i w Pythonie. Czy wg Ciebie Python też nie jest obiektowy?
W Pythonie wystarczą argumenty domyślne.
"Język obiektowy nie musi mieć koniecznie klas. "
No ale chyba musi miec koniecznie obiekty, a te na podstawie czegos trzeba utworzyc
Na podstawie czegoś, a niekoniecznie klas. Np. na podstawie prototypu. Albo po prostu można utworzyć obiekt specyfikując jego własności w miejscu jak jest w JS.
Obiekt = prywatny stan i metody operujące na tym stanie. Nigdzie nie ma mowy o klasie.
A szczególnie taki wymysł jaki się pojawił w Cpp, Javie i C#, mianowicie metody statyczne klas, to już w ogóle stoi w sprzeczności z OOP.
No dobrze, ale czegoś tu nie rozumiem. To metody zwracające wartość również stoją w sprzeczności z OOP? Przecież prosta proteza na zasymulowanie metod statycznych to stworzenie klasy bez stanu prywatnego:
przecież taką klasę (pseudo kod java/c# bez definicji metod dla uproszczenia)
class Klasa {
public static int statFun(int zm) { … }
public fun(int zm) { … }
}
można zastąpić
class Klasa{
public int fun(int zm) { … }
}
a metodę statyczną wrzucić do pomocniczej klasy:
KlasaHlp{
public int statFun(int zm) { … }
}
jedynie sposób wywołania trochę się zmienia
z
Klasa.statFun(i)
na
new KlasaHlp().statFun(i)
a wieć drugi sposób jest w duchu OOP a pierwszy nie?
W drugim przypadku przecież nie operuje się na prywatnym stanie, więc wg. definicji nie jest to zgodne z ideą OOP.
A więc Cpp, Java, C# nie realizują w czysty sposób założeń OOP?
Uważasz, że pomocnicza klasa zastąpi metody statyczne?
Najbardziej logiczne jest oddzielenie klasy od metod i pól statycznych do singletonu tak jak zrobiono to w Scali.
"Uważasz, że pomocnicza klasa zastąpi metody statyczne? "
Oczywiście że nie – to jest najgorsze rozwiązanie z możliwych. To jest tylko przykład. Chodzi mi tylko i wyłącznie o paradygmat, w którym to metody statyczne łamią OOP.
"Obiekt = prywatny stan i metody operujące na tym stanie."
Dałem przykład, że też klasyczne metody klasy mogą nie spełniać OOP, bo nie modyfikują prywatnego stanu i mogą być w pewnym sensie wykorzystywane jak metody statyczne.
Takie metody są w zgodzie z OOP, bo nigdzie nie jest w OOP powiedziane, że metody MUSZĄ modyfikować stan obiektu. Istotą OOP jest to, że nie grzebią w cudzych danych, tj. danych innego obiektu. Metoda statyczna sama w sobie nie stoi z tą zasadą w sprzeczności, dopóki nie modyfikuje danych wspólnych dla więcej niż jednego obiektu. A zwykle do tego metody i pola statyczne właśnie służą.
Poza tym metody statyczne nie są składowymi obiektu, są zupełnie z innego świata. Ma to dalsze konsekwencje np. takie, że nie mogą być dziedziczone (w językach, które mają dziedziczenie składowych).
@wladca_kodu:
Miło poczytać komentarze kogoś, kto wie o czym pisze. Dzięki za dobrą powtórkę z OOP 🙂
Jeżeli chodzi o małe skrypty to JS jest OK. Gorzej jak chce się napisać arkusz kalkulacyjny w przeglądarce, wtedy przydaje się uporządkowanie kodu. Usuwanie błędów JS to ciężka robota.
A dokładnie z interfejsem DOM. ECMAScript.next będzie całkiem ok. EcmaScript 4, który miał już dawno rozwiązać większość problemów JavaScriptu, został złośliwie zablokowany przez Microsoft, bo był za bardzo podobny do ActionScriptu 3 Adobe i Microsoft się bał, że to utrwali panowanie Flasha.
Dart, no cóż, pamięta ktoś Go Language z Googla?
Albo bał się pozwu. Google się nie bał pozwu i będzie płacił odszkodowanie Oraclowi.
MS też zapłacił. Z MS Javy wyszedł .NET. To samo będzie u Google. Oracle jest zbyt skostniałym tworem by się zajmował czymś tak nieopłacalnym jak innowacyjne technologie. A mógł wyprostować J2ME tak by był kompatybilny z J2SE. Nikt by nie protestował.
Nie jestem pewien, czy Oracle jest tak skostniałym tworem, skoro od kiedy przejął Suna, to rozwój Javy wreszcie znowu ruszył. Na JavaOne ostatnio zaprezentowali apkę napisaną w Javie działającą na… niezmodyfikowanym iOS, więc może nie będzie tak źle.
Gdzieś czytałem, że główne trudności w rozwoju jS leżą w jego wadliwej konstrukcji a nie blokowaniu przez jakąkolwiek firmę.
Go był językiem napisanym na potrzeby samego Google, a nie z myślą o innych (miał się kompilować szybciej niż C++). Same podejście do obiektów w Go mogło go uczynić atrakcyjnym jedynie dla programistów C 😉
> Ale do tego dluga droga….
Kiedyś trzeba zrobić pierwszy krok…
Gdy czytam o darta nie widzę żadnych konkretów w porównaniu do innych języków i mam odczucia jakby to była reklama.
Następnie patrząc na informacje "Początkowo Dart ma działać natywnie tylko w przeglądarce Chrome, zaś w pozostałych jego kod ma być przetwarzany do JavaScriptu".
Nie wiem jak ma to wyglądać po stronie CHROME, ale nie wydaję mi się żeby jakiś generator kodu JS lepiej pisał kod JS niż znający się na tym programiści. A zresztą już frameworków do JS mamy sporo.
Generator kodu nie ma zrobić tego lepiej od Ciebie, ma Ci umożliwić napisanie kodu raz (w Dart), kodu, który działa szybko, natywnie (VM, a nie skrypt jak w JS). A żeby nie zamknąć listy zastosowań wyłącznie do Chroma – generator konwertuje Twój kod do wersji, która zadziała z każdą przeglądarką. Niezbyt szybko? Możliwe, ale to jest proteza na okres przejściowy, a nie finalne rozwiązanie.
Jeżeli Dart będzie cieszył się popularnością na pewno zostanie zaadaptowany w Firefoksie, te dwie przeglądarki wystarczą, żeby pisanie kodu w Dart było opłacalne, a na pewno nie były by jedynymi.
Równie dobrze można powiedzieć, że najlepiej samemu pisać SQL w kodzie programu. Albo po co jest JPython, skoro można pisać w Javie? Automaty nie są złe i często potrafią więcej, niż programiści. A na pewno mają więcej czasu i kodzenie się im nie nudzi. 🙂
A ja powiem tylko tyle: good joke google, try something else.
Liczyłem, że zrobią jakąś hybrydę, coś jak CoffeeScript z klasami jak w Javie/C#, no ale oni woleli zaserwować nam jakąś uproszczoną Javę… sztywną Javę.
Po co nowy język, skoro jest już haXe???
i Opa: http://opalang.org
i Gosu i jeszcze setki innych. Ale tak już wygląda ewolucja, składa się z wielu odgałęzień z których tylko rzadko pojawia się coś co zdobywa dominację 🙂