Red Hat otworzył niedawno stronę domową projektu Ceylon http://ceylon-lang.org/
Czyżby koniec popularności kawy i czas na herbatę? 🙂 Co takiego oferuje nowy język?
Składnia języka jest zbliżona do Javy, choć pojawia się sporo nowych słów kluczowych. Sam język jest dedykowany tworzeniu dużych aplikacji. Nowe cechy języka mają w tym pomóc deweloperom.
Najciekawsze zmiany w stosunku do Javy to:
- pozbycie się typów prymitywnych
- specjalna składnia do przedstawiania rozgałęzionych struktur (np XML)
- interfejsy mogą zawierać konkretne pola i metody
- specjalna składnia do automatycznego tworzenia getterów i setterów bez „beansów”
- konieczność oznaczania zmiennych które mogą mieć wartość null
- częściowa inferencja typów
- higher order function
- uproszczenie i udoskonalenie generics
- przeładowywanie operatorów poprzez iterfejsy
Nie wiadomo czy język ten zdobędzie większą popularność, ale niektóre rozwiązania warto by przenieść do Javy.
Szczególnie genialny wydaje się pomysł na przeładowywanie operatorów. Klasa implementuje na przykład interfejs Numerable, który ma metodę multiply. Dzięki temu klasy te można mnożyć używając operatora *. Równocześnie nie możliwe jest tworzenie dziwnych operatorów lub dziwnie zachowujących się.
Ciekawe, że takie języki jak Closure czy Scala nie rozpowszechniły się jak na razie wśród programistów JVM. Być może elementy programowania funkcjonalnego które te języki wprowadzają zniechęcają programistów. Język Ceylon nie idzie tą drogą, za to wprowadza kilka cech, które wielu programistów chętnie chciałoby zobaczyć w Javie.
"Ciekawe, że takie języki jak Closure czy Scala nie rozpowszechniły się jak na razie wśród programistów JVM. Być może elementy programowania funkcjonalnego które te języki wprowadzają zniechęcają programistów."
Nie ciekawe, tylko oczywiste. Co zachęca czy zniechęca programistów nie ma żadnego znaczenia. Piszą w tym za co im się płaci a za Javę chce płacić znacznie więcej firm niż za Scalę czy Clojure. As simple as that.
Płacą za Scalę i Clojure, i to nawet w Polsce, tylko trzeba dobrze poszukać.
"Płacą za Scalę i Clojure, i to nawet w Polsce, tylko trzeba dobrze poszukać."
Płacą i za Common Lisp, i to nawet w Polsce, tylko trzeba dobrze poszukać. Co z tego? Pisałem, że za Javę płaci więcej firm (i zapewne zdajesz sobie sprawę, że przewaga jest miażdżąca), a nie że za Scalę nie płaci nikt.
Faktycznie – na Indeed.com stosunek jest ok. 1 do 100.
Ale trochę za wcześnie wyrokować jak na język, który w miarę używalnej wtyczki do Eclipse doczekał się dopiero w tym roku.
"trochę za wcześnie wyrokować jak na język"
Nie wyrokuję, stwierdzam fakt. Za 5 lat sytuacja może być inna. Scala jest póki co jedynym z tych nowych języków na JVM który na dobrą sprawę już nie jest tylko blogaskowym meteorem i może coś z niego rzeczywiście poważniejszego być. Ale to jeszcze dłuuugo.
Wyznacznikiem używalności języka typu javowego jest istnienie wtyczki do Eclipse?
Nice.
Wyznacznikiem używalności każdego z języków które pretendują do miana języka do zastosowań biznesowych jest m. in. wsparcie dla wiodących IDE. W której firmie teraz się programuje chociażby w Geany czy Notepad++? Przecież kolorują składnię, ba chyba nawet łatwo dodaje się swoje szablony kolorów (btw, bardzo dobre programiki do podglądu źródeł czy drobnej edycji)
W mojej ;P. Przede wszystkim VIM, także Geany. I żeby nie było – to nie jakieś to realna firma której zadaniem jest zarabianie pieniędzy, a nie przekonywanie kogokolwiek do jakiejś filozofii czy że "da się".
I piszesz w tym CRM, ERP albo inny podobny system? Bo ja nie mówię, że się nie da, ale ten język pasuje do rozwiązań biznesowych. Tak samo jak np. bash, perl,python nadaje się do pisania skryptów, i tutaj VIM, Geany i inne nadają się często dużo bardziej niż duże IDE.
Jasne. Jak język jest idiotyczny to trzeba mieć takie dodatki bo inaczej nie da się go ogarnąć (albo tacy świetni programiści w nim pracują, którzy nie potrafią i muszą mieć takie narzędzia). W C++ można pisać nawet w vi i jest to wygodne i szybkie.
Implikacje tego faktu pozostawiam ci do przemyślenia.
Pisanie w C++ nie jest wygodne ani szybkie w żadnym środowisku w porównaniu do innych, nowocześniejszych języków. I piszę to z punktu widzenia programisty C/C++. Ten język ma kilka zalet, ale na pewno nie jest to wygoda i szybkość pisania! Jeśli wyjdziesz już z podstawówki, pójdziesz na studia a później do pracy jako programista, to życzę Ci szczęścia pisząc projektu które mają po kilkadziesiąt/kilkaset k linii kodu w Vi/Vim razem ze swoim kilkunastoosobowym zespołem.
Moim zdaniem właśnie duży większy projekt tym bardziej NIE powinien być tworzony korzystając z IDE, lecz w prostych edytorach. Pisanie w prostszym edytorze (bez podpowiadaczki nazw i bez możliwości automatycznego przejścia do miejsca definicji struktury/klasy) daje bardzo wcześnie sprzężenie zwrotne, że np. coś jest źle nazwane, albo bałaganiarsko porozdzielane po plikach. Na początku projektu zwykły edytor zamiast IDE może się wydawać utrudnieniem, ale sprzyja powstaniu bardziej przejrzystego projektu, używającego intuicyjnych nazw.
Pełna zgoda jeżeli Ty za to płacisz.
Wręcz odwrotnie. Chciałbym zobaczyć jak robisz refactoring dużego projektu w notatniku – np. przesunięcie jakiejś klasy z jednej przestrzeni nazw (pakietu) do innej. Zwykle jest tak, że programiści unikają wtedy refactoringu jak ognia i po pewnym czasie z kodu robi się kupa.
Inna sprawa, że programiści C i Cpp nigdy nie mieli dobrego IDE, więc faktycznie mogą czuć, że notatnik z kolorowaniem składni to prawie to samo.
Żaden problem: zmieniam przestrzeń nazw -> kompiluję projekt -> koryguję błędy kompilacji. To na prawdę nie trwa długo. A przy takiej okazji, czasami zaglądam w miejsca, w które inaczej bym nie zajrzał i zauważam że coś tam wymaga np. skomentowania, albo w ogóle zmiany. Zajrzenie do iluś tam plików nie musi być czasem straconym.
Mówimy o dużych projektach a nie o hello world.
A tak na boku przypomniała mi się zagadka o ślimaku: ślimak w dzień wspina się 5m na drzewo, ale w nocy śpi i zesuwa się o 4m. Ile dób zajmie mu wspięcie się na drzewo wysokości 10m? 😀
Nie sądzę, aby np. większość programistów linuksowego kernela intensywnie korzystała z IDE. A niewątpliwie jest to projekt bardzo duży. I jakoś patche przesyłane są w formie diff-a – i ten diff jest dla ludzi czytelny, a nie informacji "zrefaktoryzujcie sobie to i to w swoim IDE".
Tylko co ma kontrola wersji do IDE? Tzn. git, svn czy inne ustrojstwo ma wsparcie w IDE, ale i tak suma sumarum dostajesz/wysyłasz diffy, które powinieneś sobie sprawdzić przed nałożeniem.
IDE ma Ci pomóc szybko i przyjemnie programować, to czy kod będzie dobry czy nie, zależy od Ciebie.
Co do programistów kernela linuksa – szczerze nie wiem w czym piszą, pewnie większość vi/emacs, ale myślę że głównie z przyzwyczajenia, bo co niektórzy robią to już od 20 lat 🙂 No i jak wladca_kodu wspomniał wyżej – trochę jest dziura jeśli chodzi o dobre środowiska dla C i Cpp, w szczególności na linuksie gdzie brak VS i XCode.
VS to dobre środowisko? Śmiesz żartować. Pomijam już wyniki kompilacji na tym czymś.
Wśród środowisk C++ jedno z najlepszych. Ale porównując do możliwości popularnych IDE dla Javy i C# – muszę się z Tobą zgodzić. 😛
Więc wskaż mi te inne, dużo lepsze.
Przy takiej korekcie projektów w C++ musisz tą kompilację uruchamiać n-krotnie, bo nie wszystkie powstałe błędy pojawią Ci się za pierwszym razem. Już samo to zniechęca bo dla projektu który ma już ~20k linii kodu pełny proces kompilacji minimum kilka minut. A to nie jest jakiś duży projekt.
Zresztą to jest spór o nic, bo z praktycznego punktu widzenia większość firm woli zapłacić osobie która napisze coś szybciej, dlatego gdzie tylko można to zrobić używa się języków wysokiego poziomu i rozbudowanych IDE. Napisałem większość, bo są też miejsca w których liczy się długie wsparcie produktu, jak chociażby banki, ale i tam lepiej wbijać gwóźdź młotkiem niż kamieniem.
Ale przecież zasadą dobrego projektowania jest, żeby minimalizować zależności pomiędzy poszczególnymi modułami programu, więc np. przeniesienie jednej funkcji/klasy do innego namespace nie powinno wywołać konieczności nanoszenia poprawek w połowie plików całego projektu.
Tak, masz rację, to jest zasada dobrego projektowania. Tylko co w przypadku gdy kod nie jest dobrze zaprojektowany? Przecież bardzo dużo kodu który się dostaje to molochy rozwijane przez wiele lat i X ludzi. Nieraz jest konieczność refactoringu bo już dochodzimy do jakiegoś wąskiego gardła gdzieś w module bazowym. A moduł bazowy może zawierać np. jakieś 'specjalne' kontenery wymyślone przez jakiegoś geniusza i użyte w reszcie modułów . Takie życie.
I tu dochodzimy do sedna:
> Tylko co w przypadku gdy kod nie jest
> dobrze zaprojektowany?
Wtedy właśnie potrzeba IDE, i tak właśnie działają Javowcy i .netowcy.
IDE umożliwia im ogarnięcie się w stworzonym przez nich chaotycznym badziewiu, a nie kodzie źródłowym.
I w ten sposób wracamy do mojego pierwszego komentarza wieleee wpisów wyżej.
Tak, bo aplikacje pisane w C i C++ jakimś cudem zawsze są dobrze zaprojektowane i mają idealny porządek w kodzie. Buhaha. 😀
Bądź łaskaw wskazać mi jakiś projekt którego jesteś autorem/współautorem. Oczywiście znając Twoje zamiłowanie dla otwartego oprogramowania najlepiej niech to będzie jeden z takich właśnie projektów, abym mógł zacząć czerpać wiedzę z tego jak powinno projektować się aplikacje C/C++ bo ja w życiu nie napisałem jeszcze żadnego programu, nie mówiąc już o projektowaniu takich.
Wiesz, no nie każdy jest tak genialny jak Ty, o_O, i ma tyle wolnego czasu, żeby programować w notatniku.
To zapytam inaczej, dlaczego firmy nie robią więcej projektów w Scali? Po co klepią nowe projekty w Spring i Hibernate, skoro w Scali można by napisać wszystko szybciej, łatwiej utrzymywać (a tym samym taniej), oraz wydajniej (dzięki nie używaniu Hibernate)?
Bo nie zmienia się czegoś co działa. Wiele banków w Polsce nadal używa Javy 1.4, mimo że wyszła już Java 7. A ryzyko upgrade'u jest znacznie mniejsze niż zmiana języka.
Mam nadzieję, że mówisz o wersji języka Java, a nie o JVM czy innym softwarze?
Bo jeśli to drugie, to wynika z tego, że wg ciebie bankom odpowiadają luki bezpieczeństwa w ich oprogramowaniu i błędy w działaniu garbage collectora też nie robią na nich wrażenia, i mogą to bez problemu zaakceptować.
"Bo jeśli to drugie, to wynika z tego"
Wynika z tego, że masz ekskrementalną wiedzę na tematy o których się wypowiadasz. Co jakby nie jest żadną nowością.
Bugfiksy dla Javy 1.4 się wciąż ukazują i będą co najmniej do 2013 roku, tylko że są już wyłącznie dla mających wykupiony odpowiedni support. Jak myślisz, czy banki mają?
Bo pan prezes nie dostał ładnej ulotki z magicznymi słowami. Znudzeni pracownicy też potrafią tylko biadolić, że będą musieli się uczyć 😉
Może część pracowników narzeka, ale spotykam często takich którzy mówią, że chętnie użyliby czegoś nowego, ale szef nie chce o tym słyszeć 🙂 Tutaj zapewne jak najbardziej rację ma władcz_kodu
Widocznie rozsądny szef.
Jeśli doświadczenie pokazuje, że dotychczasowe narzędzie sprawdza się dobrze, to nie ma powodu aby od razu rzucać się na nowe. Eksperymentować z nowymi to powinni sobie ludzie hobbistycznie w przeznaczonym do tego czasie, a nie w pracy której celem jest stworzenie czegoś działającego.
Czyli to oznacza, że jest niewielka konkurencja, bo nikt nie musi szukać lepszych rozwiązań. Dopiero tam gdzie pojawia się konkurencja sięgają po Scalę. (mam na myśli Twitter, Foresquare gdzie w serwisach społecznościowych konkurencja jest olbrzymia)
"jest niewielka konkurencja, bo nikt nie musi szukać lepszych rozwiązań."
A priori zakładasz, że Scala jest lepsza i wyciągasz z dupy wniosek.
"pojawia się konkurencja sięgają po Scalę. (mam na myśli Twitter, Foresquare"
Ale zdajesz sobie sprawę, że ten przykład można łatwo odwrócić i napisać, że po Scalę sięgają tam gdzie są na kroplówce od VC, o break-even w bliskiej perspektywie nie mają nawet co marzyć i w związku z tym mają w dupie koszty czy ROI?
(Powyższe nie jest argumentem za wyższością Javy a tylko pokazaniem dlaczego takie wnioskowanie nie ma sensu)
"A priori zakładasz, że Scala jest lepsza i wyciągasz z dupy wniosek. "
Pisałeś kiedyś aplikację webową nie w Javie, tylko jakimś języku dynamicznym? Scala ma niektóre cechy tych języków choć jest statycznie typowana. Kod w Scali jest o wiele krótszy niż w Javie przez co jest znacznie łatwiejszy w utrzymaniu. Scala jest lepsza inaczej nikt by sobie nią głowy nie zawracał. Każdy nowy język musi być kilka razy lepszy od starego, aby zdobyć uznanie.
Wspomniane serwisy mają co prawda spory budżet, ale mało czasu. Liczy się szybkość wprowadzenia nowych funkcjonalności i ich niezawodność.
"Pisałeś kiedyś aplikację webową nie w Javie, tylko jakimś języku dynamicznym?"
Tak. Nigdy więcej. Poza tym zupełnie nie zrozumiałeś o czym pisałem i jedziesz w teksty godne nastolatka, który zza trądziku zobaczył quicksorta w Haskellu.
"Liczy się szybkość wprowadzenia nowych funkcjonalności i ich niezawodność."
#hahaha tak zwłaszcza Twitter tutaj bije wszelkie rekordy. Pewnie ze strachu przed polskim blipem. Albo googlowym Buzzem.
"Tak. Nigdy więcej. Poza tym zupełnie nie zrozumiałeś o czym pisałem i jedziesz w teksty godne nastolatka, który zza trądziku zobaczył quicksorta w Haskellu. "
To Ty piszesz wypowiadając się na temat czegoś czego nie rozumiesz. Poznaj dobrze Scalę i wtedy się wypowiadaj.
Jeżeli uważasz, że aplikację webową pisze się łatwiej w Javie niż w języku dynamicznym, to chyba pisałeś ją w Perlu 🙂
"aha tak zwłaszcza Twitter tutaj bije wszelkie rekordy. Pewnie ze strachu przed polskim blipem. Albo googlowym Buzzem. "
Twitter ma problem z integracją serwisów napisanych głównie w RoR. Przepisując krytyczne elementy na Scalę mają spory problem ze zgodnością.
"aplikację webową pisze się łatwiej w Javie niż w języku dynamicznym"
Jeśli aplikacja ma więcej niż trzy proste strony i nie uważasz, że refaktoryzacja ode złego jest, to tak, jak najbardziej pisze się łatwiej w Javie. W języku dynamicznym fajnie się zaczyna, potem jest już mniej fajnie. A najniefajniej jest po nienajkrótszej sesji debugowania dojść do wniosku, że w Javie znaleziony błąd wykryłby kompilator. Dziwię się, że tego nie wiesz (a miałem nie kłamać!)
"to chyba pisałeś ją w Perlu"
Też. Poza tym w Rubym (RoR) a nawet w Common Lispie. I co mi pan teraz zrobi?
"Twitter ma problem"
Nie, to ty masz problem. Twitter był od dawna znany z tego, że konkurencja go przerasta funkcjonalnością, czasem dość znacznie. I mimo to wygrywał. Podawanie go jako przykład ostrej konkurencji gdzie trzeba zwyciężać funkcjonalnością świadczy o epsilonowym poziomie twojej wiedzy.
"To Ty piszesz wypowiadając się na temat czegoś czego nie rozumiesz. Poznaj dobrze Scalę i wtedy się wypowiadaj. "
O – nawet nie wiesz o czym ja pisałem. Otóż NIE pisałem o Scali, a o gównianej logice "nie używają Scali ergo jest mała konkurencja". Scala może i jest świetna, ale dokąd nikt nie chce mi za jej poznanie zapłacić i nie jest silnym numerem pięć, nie będę sobie zajmował nią czasu.
"Jeśli aplikacja ma więcej niż trzy proste strony i nie uważasz, że refaktoryzacja ode złego jest, to tak, jak najbardziej pisze się łatwiej w Javie. W języku dynamicznym fajnie się zaczyna, potem jest już mniej fajnie. A najniefajniej jest po nienajkrótszej sesji debugowania dojść do wniosku, że w Javie znaleziony błąd wykryłby kompilator. Dziwię się, że tego nie wiesz (a miałem nie kłamać!) "
Dlatego właśnie powstała Scala, masz statyczne typowanie i równocześnie elementy języków dynamicznych. Jednak większość i tak pisze webowo w językach dynamicznych i to takie duże serwisy jak Facebook. Błędy eliminuje się pisząc testy, dziwne że o tym nie wiesz 🙂 Osobiście też wolę języki statycznie typowane, ale nie oznacza to że dynamiczne nie mają zalet. Tam gdzie drobne błędy nie są priorytetem i można je usuwać w trakcie użytkowania języki dynamiczne się sprawdzają.
"Też. Poza tym w Rubym (RoR) a nawet w Common Lispie. I co mi pan teraz zrobi? "
Gratuluje!
"Twitter był od dawna znany z tego, że konkurencja go przerasta funkcjonalnością, czasem dość znacznie. I mimo to wygrywał. Podawanie go jako przykład ostrej konkurencji gdzie trzeba zwyciężać funkcjonalnością świadczy o epsilonowym poziomie twojej wiedzy. "
Życzę aby Twój serwis miał choć mały procent takiej popularności. Podejście do biznesu typu albo jestem nr 1 albo nikim raczej nie jest zbyt rozsądne.
"Scala może i jest świetna, ale dokąd nikt nie chce mi za jej poznanie zapłacić i nie jest silnym numerem pięć, nie będę sobie zajmował nią czasu. "
Nikt Ci nie każe się nią zajmować. Za poznanie nikt Ci nie zapłaci sam musisz zainwestować. W USA dobry programista Scali znajdzie zatrudnienie natychmiast, u nas jeszcze nie.
"Błędy eliminuje się pisząc testy, dziwne że o tym nie wiesz"
Zapewne javistość Javy wyklucza pisanie testów. Albo, co gorsza, uważasz, że testy są w stanie zastąpić statyczne sprawdzanie przez kompilator. Dorośnij.
"języki dynamiczne się sprawdzają. "
Nie zajmuję się pisaniem onelinerów. Do czegoś większego wolę Javę.
"Życzę aby Twój serwis miał choć mały procent takiej popularności. Podejście do biznesu typu albo jestem nr 1 albo nikim raczej nie jest zbyt rozsądne."
Więc sam widzisz, jak debilnym przykładem był Twitter. Ja tam wolę podejście "albo zarabiam albo nie zarabiam" i tych wszystkich "X lat na kroplówce a potem albo nr jeden albo zero" – a to jest rzeczywistość społecznościówek – nie rozumiem. Wystarczy mi więc, że mój serwis będzie zarabiał jakiś ułamek tego co przepala Twitter.
"W USA dobry programista Scali znajdzie zatrudnienie natychmiast, u nas jeszcze nie. "
No więc poczekam aż będzie już tak. Jeśli to będzie Scala a nie kolejne cudowne dziecko.
" Albo, co gorsza, uważasz, że testy są w stanie zastąpić statyczne sprawdzanie przez kompilator. Dorośnij. "
Są, aczkolwiek jest to sporo kosztowniejsze niż niż użycie kompilatora.
Nie, nie są. To znaczy oczywiście możesz zacząć balrogizować, że dobre testy zawsze będą ale problem tkwi gdzie indziej. Po prostu część tych testów napiszesz jako efekt wykrycia i poprawienia błędu przed którym ochroniłby cię kompilator.
"To zapytam inaczej, dlaczego firmy nie robią więcej projektów w Scali? "
Czas życia udanego projektu to minimum pięć lat, często bliżej piętnastu. Scala istnieje tylko siedem lat, obiektem powszechnego zachwytu jest może od trzech, mało kto jej używa. Meteorem blogaskowym już nie jest na pewno, ale wciąż może się okazać innym typem meteoru, takim jak na przykład Groovy, wciąż od Scali popularniejszy ale już raczej powoli schodzący ze sceny. Chyba nawet dzięki Scali.
Kto mi zagwarantuje, że za rok czy dwa nie pojawi się jakiś kolejny wspaniały język, któremu uda się wyjść poza blogaskowe zachwyty dzieciaków, które nigdy nic większego niż oneliner quicksort w języku dnia nie napisały? I czy nie zepchnie Scali z rynku?
Im głębiej tkwi w projekcie narzędzie, tym bardziej ryzykowne jest uzależnienie się od niego – jakąś poboczną bibliotekę można sobie brać niemal w ciemno, ale język to sama podstawa. Nie chciałbym za 10 lat obudzić się i stwierdzić, że programiści do Naprawdę Dużego Projektu kosztują jakieś niemożliwe pieniądze bo język w którym to napisano był troszeczkę popularny w okolicy roku 2010 ale szybko został wyparty przez cośtam i dziś już prawie nikt go nie pamięta.
heh to musisz pisać w javascript – ten język nie zniknie przez następne 30 lat – i ma standard – tylko IDE porządnego nie ma (z tego co wiem).
"javascript – ten język nie zniknie przez następne 30 lat " –
No nie wiem, a Dart? 😛
W netbeans całkiem nieźle pisze się JS, tyle że skryptowe języki nigdy nie będą miały takiego IDE jak statycznie typowane.
"to musisz pisać w javascript"
Może być też Java, C# i kilka innych. Nie musi być numer jeden (którym akurat jest Java), wystarczy silny numer pięć, może nawet dziesięć. Standard nie ma wielkiego znaczenia. Common Lisp ma standard i co z tego?
@cutugno
W Polsce .Net ma chyba większe wzięcie (patrząc po liczbie ogłoszeń "programista praca")
Z tym javascriptem to nie żart. @codinghorror ( http://www.codinghorror.com/blog/ ) już ładnych parę lat temu sformułował "Prawo Astwooda":
"any application that can be written in JavaScript, will eventually be written in JavaScript."
(http://www.codinghorror.com/blog/2007/07/the-principle-of-least-power.html)
Mamy tu dwa ciekawe trendy z jednej strony: SPA (Single Page Application) zachęcający do pisania tylko webservice po stronie serwera (przy pomocy np. backbonejs i dowolnej technologii serwerowej)
Z drugiej nodejs które stał się już najpopopularniejszym projektem na github: https://github.com/popular/watched
Jak by ie było wszyscy skończymy w javascript – nawet apologeci .NET wierzą ( http://haacked.com/archive/2011/11/25/musings-on-… )
Mimo to Java (Banki) i .NET (korporacje) będą żyły jeszcze 100 lat.
Banki i korporacje będą pisały w Javie i .NET kompilowanych do JavaScriptu. Google już to robi od dłuższego czasu.
"W Polsce .Net ma chyba większe wzięcie"
Może. Naprawdę mi wystarczy silny numer pięć. Nie mam żadnych ideolo niechęci do .NET, ale że ostatnio bawię się głównie klockami Oracle (nie, nie tylko bazą) to wybór jest jakby oczywisty.
"Z drugiej nodejs które stał się już najpopopularniejszym projektem na github"
Ja jak zwykle poczekam, aż się stanie silnym numerem pięć na indeed.com 😉
"Mimo to Java (Banki) i .NET (korporacje) będą żyły jeszcze 100 lat."
Nie powiem żeby mnie to martwiło.
"Ja jak zwykle poczekam, aż się stanie silnym numerem pięć na indeed.com"
… jeśli to podpowiada Ci serce 😉
Serce mi podpowiada czekać z wszystkimi projektami na Wielki Dzień Wydania Perla 6.
Język może i ciekawy w porównaniu z Javą, ale:
1. W porównaniu z dzisiejszą Scalą wypada blado. Wszystkie te punkty w newsie są zaimplementowane w Scali, niektóre znacznie lepiej i prościej np. przeładowywanie operatorów.
2. W porównaniu z planowaną Javą 8 i 9, które biorą dużo ze Scali, wypada również blado.
3. No i przede wszystkim: Nie mają nawet kompilatora a co dopiero zestawu bibliotek czy działającego IDE. Na razie to jest vaporware.
Dlatego nie ma o czym gadać. Takich języków w tej fazie rozwoju jest pełno. Jeśli będą pracować mocno to może za 5 lat dojdą do tego poziomu zaawansowania co ma obecnie Scala lub Clojure. A co do rozpowszechnienia Scali i Clojure, nie liczy się ilość a jakość. Wśród najlepszych programistów te języki są bardzo dobrze znane. I używają ich nie tylko w hobbystycznych projektach, ale też w tych dużych komercyjnych (patrz: Twitter, Guardian, LinkedIn, FourSquare).
"Być może elementy programowania funkcjonalnego które te języki wprowadzają zniechęcają programistów."
Nie, to zupełnie nie to. C# ma elementy programowania funkcyjnego i jest bardziej złożonym językiem niż Scala i jakoś nikt nie marudzi. Aby język był używany w firmach potrzebne są co najmniej:
1. solidny jak skała kompilator
2. kompatybilność wsteczna, ogólna stabilność całego ekosystemu
3. dobra wtyczka do wiodących IDE – Eclipse, Netbeans, IntelliJ IDEA
4. wsparcie komercyjne
5. dobra dokumentacja
6. dostępność programistów znających język
Ceylon, Fantom i inne Scala-killery nie spełniają żadnego z tych warunków, nawet w nikłym stopniu. Scala ma wszystkie dopiero od bardzo niedawna, choć w każdym aspekcie dałoby się jeszcze dużo poprawić na lepsze.
"Wśród najlepszych programistów te języki są bardzo dobrze znane"
Jestem genialnym programistą i nie znam ani Scali, ani Clojure 😉
"Nie, to zupełnie nie to. C# ma elementy programowania funkcyjnego i jest bardziej złożonym językiem niż Scala i jakoś nikt nie marudzi."
Prawie każdy kto zetknął się przed Javą z C# żałuje, że Java nie ma części cech C#. Nawet Gnome dla Vala wybrało składnię zbliżoną do tego języka a nie Javy.
Co do programowania funkcyjnego to zauważ jak długo istnieją języki takie jak Lisp i jakoś żaden nie zdobył zbyt dużej popularności. Czyżby większość programistów po prostu nie mogła przekonać się do pisania funkcyjnego?
"Prawie każdy kto zetknął się przed Javą z C# żałuje, że Java nie ma części cech C#"
To akurat działa w dwie strony, ale w opisanym przez Ciebie przypadku zwykle najbardziej żałują braku lambd i delegatów – czyli elementów funkcyjnych. Które zresztą będą lada moment dodane.
"Czyżby większość programistów po prostu nie mogła przekonać się do pisania funkcyjnego?"
Programiści się nie mogą przekonać do pisania czysto funkcyjnego (LISP, Haskell itp), bo jest to skok na głęboką wodę, natomiast stosowanie funkcyjnych elementów w językach imperatywnych jest obecnie bardzo trendy. Nawet C++ się dorobił w końcu lambd, paskudnych składniowo, ale jednak lambd. 🙂
"To akurat działa w dwie strony, ale w opisanym przez Ciebie przypadku zwykle najbardziej żałują braku lambd i delegatów – czyli elementów funkcyjnych. "
Mnie osobiście męczy istnienie prymitywów i parę rzeczy które z tego wynikają. Przydałoby się też jakieś przeładowanie oparatorów. Całe szczęście że jest Scala 😉
Znowu Oracle będzie wypłakiwać się przed sądem?
Nie będzie mieć podstaw, bo oni nie piszą własnej nie do końca kompatybilnej JVM jak to zrobił Microsoft a teraz Google. A i interesu też nie będzie mieć, bo im więcej dobrych języków na JVM, tym łatwiej przyciągnąć do niej developerów. No i takie języki są niezłym poletkiem doświadczalnym dla testowania nowych koncepcji do wprowadzenia do Javy (patrz lambda expressions w Java 8 żywcem wzięte ze Scali).
Kolejny język na JVM.
Przydałby się jakiś język skryptowy do programowania systemowego ze składnią podobną do C czy Java.
Próbowałem podchodzić do Pythona ale mając duże nawyki ze składnią C wogóle go nie trawie a Perl to już kosmos.
Pamiętam jak pare lat temu znając język C zaczynałem poznawać jave to była to czysta przyjemność.
Scali można używać też jak języka skryptowego – jest to mniej znane, ale chyba będzie najbliżej tego, co potrzebujesz. Składnia dosyć podobna do Javy, a możliwości podobne do Pythona. IMHO operacje na plikach i katalogach jakoś w Scali mi się wygodniej robiło niż w Pythonie, ale to już kwestia gustu.
Zainteresuj sie językiem Pike.
wladca_kodu – to jakiś niezły gość.
> specjalna składnia do automatycznego tworzenia getterów i setterów bez „beansów”
Coś co w C++ tworzyło się 10 lat temu za pomocą prostego makro #define. Nie ma jak postęp 😉
Makra mają bardzo dużo wad. Tak samo jak w C/C++ istnieją wskaźniki na funkcje (ew. metody) a jakoś delegaty są dużo lepszym rozwiązaniem. I wbrew pozorom to jednak jest duży postęp, to tak jak byś powiedział, że teraz budują drogi z asfaltu, a w starożytnym Rzymie można to było zrobić za pomocą kamiennych płyt – zero postępu… 😉
Ale o czym ty piszesz? o_O
Ja o jednym, a ty o zupełnie czymś innym. A na koniec niezwiązana metafora… no gratuluję logicznej wypowiedzi…
Makra makrami, ale gettery i settery, wszystko jedno czy z makr, czy naklepane ręcznie, w C++ nie rozwiązują podstawowego problemu – że pole prywatne jest nadal częścią interfejsu publicznego klasy. Dopiero trzeba stosować "pseudowzorce projektowe" jak PIMPL (kosztowne w runtime), żeby to obejść. Rozumiem, że na PIMPL też masz jakieś ładne makro? Nie chciałbym kiedyś poprawiać Twojego kodu.
Właśnie taki tok myślenia (i wynikający z tego sposób pisania kodu) niektórych programistów zniechęca innych do czytania kodu i w efekcie zachęca do szukania innego języka programowania 😉
tak z nieco innej beczki, ale wciąż w temacie javy i setterów/getterów – http://projectlombok.org/ może kogoś zainteresować.
"gettery i settery, wszystko jedno czy z makr, czy naklepane ręcznie, w C++ nie rozwiązują podstawowego problemu – że pole prywatne jest nadal częścią interfejsu publicznego klasy."
Możesz dokładniej wyjaśnić z czym masz ten problem?
I co mają makra do rozwiązywania go?
Mają ocalić cały świat, a jak nie to są złe, nawet jeśli wiele innych zadań wykonują dobrze?
Tylko Java/.net i pochodne są zawsze dobre, cokolwiek by nie zrobiły…
Jakbyś zauważył, to nie piję do makr (to już zrobili inni) tylko do marnego pożytku z getterów i setterów w C++. Wiesz w ogóle po co się stosuje gettery i settery?
Najlepiej po nic. Nie żebym był jakimś wielkim fanem Holuba, ale tu akurat gość ma sporo racji.
Rozwiń myśl 🙂
http://www.javaworld.com/javaworld/jw-09-2003/jw-…
Czytałem to kiedyś. Gość ma trochę racji, a trochę nie. Czasami z powodów technologicznych a czasami z powodów wydajnościowych trudno jest uniknąć getterów/setterów, np. stosowanie JPA, Entity EJB .
Jak każde radykalne rozwiązanie całkowite niestosowanie getterów i setterów doprowadzić mogłoby do logiki biznesowej, która wykonuje się w bardzo dziwnych miejscach np. część w serwerze aplikacji, część jako procedury wbudowane bazy danych, itd. Nieco burzy to paradygmat programowania w oparciu o Model-View-Controler , Document-View lub podobne…
Racje ma w kwestii pisania kodu działającego lokalnie a nie centralnie na danych, co sprzyja mniejszemu powiązaniu w kodzie klas i obiektów ze sobą niepowiązanych.
Poprowadziłem kiedyś niezbyt ważny projekt wg Świętych Zasad Holuba z czystej ciekawości. Sama "nasza" logika nie miała tu problemów i bardzo mi się efekt podobał, gorzej było na styku z bibliotekami czy systemami zewnętrznymi, tu podejście "bezkompromisowe" rzeczywiście prowadzi do dziwnych efektów więc dość szybko trzeba było je zarzucić. Ale ogólnie, bez fanatyzmu, jestem za.
"trudno jest uniknąć getterów/setterów, np. stosowanie JPA, Entity EJB . "
On nawet o tym pisze, nie wiem czy w tym artykule czy w książce, ale też jest.
To się robi żenujące… ja rozumiem, każdy lubi się bawić, no ale litości !
Odnoszę wrażenie, że wszystkie te języki wymyślają ludzie, którym po prostu nie chce się nauczyć Javy albo w ogóle programować i są przyzwyczajeni do rozwiązywania każdego problemu osobnym frameworkiem. Zamiast napisać coś samemu, to lepiej schować złożoność pod ekwilibrystyką potrzebną do lepszego polecenia….
… ew. pozbędą się średników, niczym tapety w Ubuntu i od razu ha ! język !
Oczywiście, to że leży na wirtualnej maszynie tej przebrzydłej Javy i korzysta z bibliotek przebrzydłej Javy napisanych w przebrzydłej Javie to wtedy nagle staje się zaletą. Jakieś małe DSLe, to rozumiem. Ale to ? http://www.neophilic.com/b2evo/blogs/blog4.php/20…
http://reprog.wordpress.com/2010/03/03/whatever-h…
+1
Drugi artykuł z http://reprog.wordpress.com na ten sam temat: http://reprog.wordpress.com/2010/03/04/whatever-h…
Gratulacje. Właśnie niektórzy zauważyli, że programowanie wysokopoziomowe jest *trudniejsze* niż programowanie niskopoziomowe – bo na wysokim poziomie rozwiązuje się znacznie większe i trudniejsze problemy. I nie ma co marudzić tylko trzeba szukać rozwiązań. Nowe języki są jednym ze sposobów poszukiwania tych rozwiązań. Przy czym jak to zwykle jest przy rozwiązaniu trudnych problemów – większość rozwiązań nie działa lub tworzy więcej problemów niż rozwiązuje, a tylko niektóre okazują się dobre.
Dzięki temu mamy postęp, że ktoś wymyśla coś nowego. Gdyby nie to pewnie pisałbyś ciągle w assemblerze lub C 🙂 Mimo, że w 99% nowych językach nikt nigdy nie napisze większego programu to często służą jako źródło inspiracji dla rozwiązań mainstreamowych. Sam Ceylon jest robiony przez Red Hata, który ma w tym jakiś cel. Fajnie by było gdyby kiedyś w nowych wersjach Javy niektóre z tych pomysłów dodano do Javy.
Uważasz, że wszystkie języki nadają się tak samo do wszystkich zastosowań, czy też że po prostu Java jest doskonała? 🙂
"Sam Ceylon jest robiony przez Red Hata, który ma w tym jakiś cel. "
Cel jest pewnie ściśle biznesowy: uzależnić i przejąć kontrolę nad jak największą grupą developerów, co będzie miało przekładkę na wzrost cen akcji. Co po niektórym może to się wydawać okropne, ale sztuka zarabiania pieniędzy i prowadzenia firmy jest niestety trudna i w gospodarce wolnorynkowej powinna być cnotą. Z drugiej strony osiągnęli też efekt marketingowy i PRowski, może ich to taniej wyszło niż gdyby mieli wydać na reklamę kupę forsy ;).
Moze ma ktoś namiary na tą książke lub ebook ponieważ nigdzie już nie można jej dostać.
"Język C w przykładach Grega Perry" ? Czy opłaca się uczyć C , niektórzy twierdzą że jest minimalistyczny i zawiera mało materiału na początek w porównaniu do C++ i Java.
Co do pierwszego pytania nie pomogę, bo do C używałem jedynie 'ANSI C' K&R, co do drugiego: o to który język jest dobry na początek toczą się od wielu lat nierozstrzygnięte spory i jest sporo argumentów w każdą stronę. Jeśli o mnie chodzi, to faktycznie dobrze jest zacząć od C. W prawdzie w czystej formie, jeśli nie zamierzasz pisać dla ES, mało w nim będziesz pisać, ale ucząc się C++ i tak zaczyna się z jego podzbioru którym jest 'prawie C', więc C++ będzie później rozszerzeniem. A na początek lepiej przyswoisz sobie zasady programowania imperatywnego/strukturalnego. W dodatku późniejsze przesiadki na inne języki będą jak przesiadka z malucha do mercedesa, czyli proste i przyjemne 🙂 Ale jak mówię, zdania są podzielone, a wynik nauki zależy od zaangażowania.
Najlepszą metodą nauki języka C to studiowanie i grzebanie w kodzie jądra Linux.
Jak dobrze poznasz C to inne języki takie jak Java, C#, JavaScript czy inne o podobnej semantyce ogarniesz w kilka dni.
Bzdura, początkujący nic nie wyniesie z obcowania z tak skomplikowanym i rozbudowanym kodem.
Inne języki bywają obiektowe, opanowanie języka obiektowego po C zajmie trochę więcej niż kilka dni. Ale zgadzam się że C może być na początek równie dobry co każdy inny. Omijałbym jednak grzebanie w kodzie jądra Linux do czasu poznania języka już na wyższym poziomie.
Oczywiście. Znajomość proceduralnego C znakomicie przyda się przy poznawaniu obiektowego C++, obiektowej Javy czy obiektowo-funkcyjnego C#.
Powodzenia w refactoryzacji projektu mającego 1,5 mln linii kodu w vimie.
Odezwij się za dwa lata jak skończysz :>