Dodatkowe języki programowania

0
Wibowit napisał(a):

Mój szefo chciał uwspólnić kod między JavąME, a Androidem i w zasadzie JavąSE. To tak jakby np wziąć trochę libek z Qt 1, trochę z Qt 2, Qt 3, trochę z GTK, no i jeszcze coś innego i chcieć to pogodzić między sobą.

Pewnie można - cały backend. Ale morda musi być różna, bo inaczej to wyjdzie jakaś kobyła - więcej ifów / XMLi niż właściwej logiki aplikacji. Dlatego nie korzystam z struktur danych / stringów Qt / wxWidgets - jeśli nie muszę.
MVC - można stosować wszędzie.

0

Dowolnosc implementacji jest problemem. Ogolnie moim zdaniem przenosnosc aplikacji JavaEE jest poki co mrzonka.

0

Hmm, no to na jakiej platformie jest lepsza przenośność między serwerami aplikacyjnymi?

Poza tym, czy różnice są na tyle duże, żeby przesiadka z Glassfisha na JBossa była bardzo bolesna? Albo inaczej mówiąc: czy dzięki temu, że API jest w miarę jednorodne da się szybko wdrożyć programistę Glassfisha do projektu na JBossie?

Pewnie można - cały backend.

Backend czyli? W JavaME nie ma dostępu do plików w standardzie, jest tylko RecordStore, którego znowu nie ma w JavieSE, ani Androidzie. GUI jest robione totalnie różnie na każdej z tych trzech platform, itp itd

To, że jest taki sam język nie oznacza przenośności, no bez przesady. Obojętne czy Java, Python, C++ czy cokolwiek innego. Jak piszesz pod określone API to tylko pod tym określonym API zadziała. A ani JavaME, ani Android nie implementują API JavySE.

Scala dla przykładu daje się skompilować zarówno do MSILa (czy tam CILa czy choj wie jak) jak i do Javowego bajtkodu, ale co z tego, skoro kod Scalowy często gęsto odwołuje się do API JavySE?

Sorry za offtop.

PS:
Ze swojej strony polecam naukę paradygmatu funkcyjnego. Tutorial http://learnyouahaskell.com/ jest dość łatwy i przyjemny, a nawet dość dobrze wprowadza w świat języków funkcyjnych. Tutoriale do Scali skupiają się głównie na programowaniu obiektowym; to że np for-comprehensions w Scali działają na monadach (jak i to czym w ogóle są monady) dowiedziałem się przypadkiem, długo po tym, jak zacząłem czytać o Scali. Jak zdobędę robotę w Scali to pouczę się jeszcze Clojure, aby mieć jeszcze lepsze rozeznanie wśród paradygmatów.
F# z .NOTa jest podobno zbyt uproszczony, żeby miał jakieś wielkie zalety nad najnowszą wersją C# (a kolejne wersje C# wychodzą szybko i dystans do F# się zmniejsza pewnie).

Czy znajomość wielu języków jest asem w rękawie dla przeciętnego pracodawcy? Hmm, raczej rzadko, no ale czasem tak.

Najlepiej po prostu rozejrzeć się po ofertach pracy i zobaczyć jakie języki występują obok siebie w ofertach pracy. W przypadku Javy atutem byłby pewnie Groovy, który jest ZTCW najpopularniejszym językiem skryptowym na JVM.

2

W tej chili najbardziej opłacalne języki to : Objective-C, Java (+jako platforma), C, JavaScript. Piszę z własnego doświadczenia. Mnie najbardziej przydaje się Java + JavaScript (biblioteka Rhino) na Androidzie, gdzie często zmieniające się kawałki kodu wypycham do JS, by nie trzeba było po kilka razy kompilować dla indywidualnych klientów (pomoc zdalna także łatwiejsza dzięki temu). Poznaję też Clojure, który nie powstał na uczelni w celu matematycznej masturbacji, a wymyślił go człowiek, który potrzebował narzędzia do rozwiązywania realnych problemów.

Jeżeli chcesz się nauczyć czegoś, co ci się przyda to polecam Smalltalk i Lisp (Clojure). Poznanie Smalltalka uchroni cię od takich tekstów jak : " W Scali , C#, Pythonie (wstaw inny "OO" język) wszystko jest obiektem", bo zobaczysz co to znaczy język w pełni obiektowy, gdzie całe środowisko programowania jest jednym wielkim obiektem (programuje się poprzez modyfikację tego środowiska) oraz Clojure, gdzie kod jest reprezentowany jako struktura danych czy poznać makra. Clojure to bezbolesne wejście do programowania współbieżnego. Nie trzeba się martwić o blokowanie dostępu do obiektów i synchronizację. Clojure robi to za nas, a nawet krzyczy przy kompilacji, gdy spróbujemy zmodyfikować strukturę bez użycia transakcji.

Chodzi tu o poznanie pewnych pierwotnych technik (starych jak świat IT) i pomysłów, które wpychane są dziś np. do C#, czy Scali i przedstawiane jako kolejne cuda świata, a które starsze pokolenia miały na porządku dziennym. Coś na wzór Apple, która pokazała ludziom tablety. ;)
Mimo, że być może nie nauczysz się zbyt przydatnych języków (bezpośrednio), ale zmieni się twoje podejście do pisania kodu. Będzie ci łatwiej wejść w Objective-C, który jest krzyżówką C i Smalltalka oraz ułatwi pisanie kodu zorientowanego na współbieżność choćby w C#, którego już znasz.

Na czym polega przewaga Smalltalka można wywnioskować z : http://vimeo.com/17503969
Gdyby ktoś się nie orientował do końca, to napiszę, że środowisko Smalltalka (ST) można porównać do środowiska Javy. Z tą różnicą, że każda aplikacja ST to osobna maszyna wirtualna - nie jak w Javie wspólna podstawa dla wielu aplikacji. Aplikacja ST żyje w jego środowisku, dosłownie. Np. można na potrzeby aplikacji zmodyfikować zachowanie tablic dla całej aplikacji modyfikując tylko środowisko (np. załatać buga bez czekania na update od Oracle).

3

@RaveStar, Common Lisp oferuje porównywalne, możne większe możliwości niż Smalltalk, dlatego był wykorzystywaniy w NASA do programowania sond i satelit. Deep Space 1 okazał się mieć race condition, który nie wyszedł w testach naziemnych, po prostu przedebugowano go w kosmosie i z poziomu REPLa uaktualniono odpowiednie fragmenty kodu. REPL w sprzęcie za dziesiątki milionów dolarów oddalonym o miliony kilometrów, czy programiści Smalltalka mogą pochwalić się czymś podobnym? :]

Podniecanie się Clojure jest nieuzasadnione, to jeden z najmniej udanych dialektów LISPu, fakt, wnosi ciekawą współbieżność, ale poza tym jest żałośnie prymitywny. Z drugiej strony nie ma co się dziwić, JVM i języki funkcyjne, do tego dynamicznie typowane, to czysta sprzeczność.

Stawianie Pythona obok C# i Scali oraz wyraźne odgraniczenie od Smalltalka to lekka przesada. Python jest językiem dynamicznym (i nie mam tu na myśli dynamicznego typowania) na podobnych zasadach do Smalltalka, absolutnie każda deklaracja jest wykonującym się kodem itd. Jest możliwość zmodyfikowania większej części środowiska, wszystko poza składowymi pochodzącymi bezpośrednio z C. Np. biblioteki od puszczania ruchu po socks po prostu importują i modyfikują w pamięci wskazane moduły (przecież to tylko zwykłe obiekty). Podobnie zresztą funkcjonuje Ruby, którego OOP jest w dużej mierze kalką Smalltalka. Co prawda Python i Ruby nie mają możliwości zrzucenia core na dysk, ale to może się zmienić, gdzieś czytałem o pomyśle zaimplementowania takiej mechaniki w zmodyfikowanym PyPy.

0
PS napisał(a):

Podniecanie się Clojure jest nieuzasadnione, to jeden z najmniej udanych dialektów LISPu, fakt, wnosi ciekawą współbieżność, ale poza tym jest żałośnie prymitywny. Z drugiej strony nie ma co się dziwić, JVM i języki funkcyjne, do tego dynamicznie typowane, to czysta sprzeczność.

Mógłbyś to rozwinąć? Szczególnie mnie interesuje żałosna prymitywność clojure (względem innych lispów, czy innych języków funkcyjnych/obiektowych?), czym się objawia? Może być link.

1 użytkowników online, w tym zalogowanych: 0, gości: 1