Java Productivity vs Inne Frameworki/Języki

0

Tyle razy słyszę jak to Java jest mało produktywna itp. itd.
A ma ktoś solidne porównanie? Że posadziłbym np. Doświadczonego Javowca vs Doświadczony Pythonowiec i kto szybciej coś naklepie np. Spring Boot vs Flask? albo vs Rails?

Czy opłaca się do domowego projektu, żeby coś po prostu naklepać... opanować jakieś inne technologie, żeby robić to.... szybciej?
Czy może po prostu historie o szybszym developmencie w Rails, Pythonie itp. to nie jest tak naprawdę duży zysk mając do dyspozycji Spring Boot, albo nie wiem Spark Java, Ratpack czy cokolwiek bardziej 'micro' ?

Lubię się uczyć innych rzeczy, chodzi mi głównie o development speed.

0

To narzekanie się bierze się głównie z dawnej JEE i pewno EJB 2.

2

To raczej jest tak, że doświadczony Javowiec nie będzie się mógł powstrzymać przed wrzuceniem do kodu wszelkich możliwych frameworków, adnotacji i wzorców projektowych. Inaczej będzie mu można zarzucić brak kwalifikacji. To niestety daje pewien narzut:

@Service
public class FizzStringPrinter implements StringPrinter {

	private final SystemOutFizzBuzzOutputStrategyFactory _systemOutFizzBuzzOutputStrategyFactory;

	private final FizzStringReturnerFactory _fizzStringReturnerFactory;

	@Autowired
	public FizzStringPrinter(final FizzStringReturnerFactory _fizzStringReturnerFactory,
			final SystemOutFizzBuzzOutputStrategyFactory _systemOutFizzBuzzOutputStrategyFactory) {
		super();
		this._fizzStringReturnerFactory = _fizzStringReturnerFactory;
		this._systemOutFizzBuzzOutputStrategyFactory = _systemOutFizzBuzzOutputStrategyFactory;
	}

	public void print() {
		final StringStringReturner myFizzStringReturner = this._fizzStringReturnerFactory
			.createStringStringReturner();
		final FizzBuzzOutputStrategyToFizzBuzzExceptionSafeOutputStrategyAdapter myOutputAdapter =
				new FizzBuzzOutputStrategyToFizzBuzzExceptionSafeOutputStrategyAdapter(
						this._systemOutFizzBuzzOutputStrategyFactory.createOutputStrategy());

		myOutputAdapter.output(myFizzStringReturner.getReturnString());
	}

	@Override
	public void printValue(final Object value) {
		this.print();
	}

}
0

Ok. Ale wybierzcie dostepne rozwiazania z JVM vs inne technologie. Czy faktycznie mozna zyskac boost productivity? Np. Kotlin czy Scala z jakims frameworkiem.

Jak sie bawilem roznymi technologiami to chyba stawialbym na Go. Ale tez nie do wszystkiego.

Frameworki w innych technologiach tez maja swoje narzuty.

To samo co o Javie slyszalem o C#.
Oklepane teksty w internetach.

0

W sensie czy poza JVM mozna zyskac wiekszy speed development.

0

Co rozumiesz przez produktywność? Czas dowiezienia pierwszego prototypu? Weź railsy. Cały czas życia projektu? To już zupełnie inna historia.
Z genialnej prezentacji Richa Hickeya "Simple Made Easy":
title

Morał: weź Clojure

0

Jeden i drugi przypadek ;)

0

No to nie wiem @jarekr000000, bo ja nigdzie nie znalazłem nadmiernie wykorzystywanych wzorców...

0

Osobiscie wole pisac po prostu z TDD, czasem wyjdzie to cos okolo wzorcow czasem nie. Ale jak cos zaczyna przypominac wzorzec lub zauwazam mozliwe wykorzystanie to refaktoryzuje do nich.

0
scibi92 napisał(a):

No to nie wiem @jarekr000000, bo ja nigdzie nie znalazłem nadmiernie wykorzystywanych wzorców...

Przecież piszesz w Springu. Wszędzie masz singletony.
Po prostu się przyzwyczaiłeś i nie widzisz.
"This is water"

0

Myślę, żeby sobie zrobić mały side project z Spring Web Reactive (z RouterFunction, nie adnotacje) + Kotlin i może MongoDb.
I w takim zestawie wydaje mi się, że 'speed' powinien być niezły.

0

No, tylko jak ci Spring Boot podbije wersję Reactora do 3.1 to spędzisz kilka godzin zastanawiając się czemu kod się nie kompiluje, ale ogólnie spoko rzecz, polecam. Tylko MongoDB zastąp czymś co nie pochodzi ze śmietnika.

1
jarekr000000 napisał(a):
scibi92 napisał(a):

No to nie wiem @jarekr000000, bo ja nigdzie nie znalazłem nadmiernie wykorzystywanych wzorców...

Przecież piszesz w Springu. Wszędzie masz singletony.
Po prostu się przyzwyczaiłeś i nie widzisz.
"This is water"

Ale to nie sa te singletony z wzorców projektowych. To jest jedno wywołanie new, i nie widzę nic w tym dziwnego.

2
scibi92 napisał(a):
jarekr000000 napisał(a):
scibi92 napisał(a):

No to nie wiem @jarekr000000, bo ja nigdzie nie znalazłem nadmiernie wykorzystywanych wzorców...

Przecież piszesz w Springu. Wszędzie masz singletony.
Po prostu się przyzwyczaiłeś i nie widzisz.
"This is water"

Ale to nie sa te singletony z wzorców projektowych. To jest jedno wywołanie new, i nie widzę nic w tym dziwnego.

To w ogóle nie są singletony, tylko się tak nazywają. W 99% przypadków możesz dodać @Prototype i efekt będzie ten sam. Jak już porównywać do GoF, to bliżej do flyweight, czyli użycie jednego obiektu skoro nie ma potrzeby tworzyć 100.

0

Nie wiem jak nowsze frameworki, ale dla mnie Java z EJB 2 jest mocno enterprise.
Czyli przygotowana na utworzenie w powiedzmy rok softu który będzie działał (i był rozwijany) przez kolejne 20 lat.
Ale nie w tydzień stronki z obsługą eventu (typu koncert, spektakl, kabaret), bloga czy "apki" dla magazynu wujka.

Póki siedzisz z daleka od EJB (i mu podobnych) to jeszcze mogę sobie to jakoś wyobrazić - framework web, baza, unit testy.
Od Ciebie zależy ile warstw zrobisz - jeśli w ogóle.
Gdy zaczynasz się bawić z EJB, serwisami, repozytoriami, DAO, DTO, fabrykami helperów do handlerów(!), DI itd to nawet dodanie checkboxa może trwać kilka dni.

Zakładam że w Androidzie i przy programowaniu usług RESTowych jest o wiele wygodniej.

0
caer napisał(a):

No, tylko jak ci Spring Boot podbije wersję Reactora do 3.1 to spędzisz kilka godzin zastanawiając się czemu kod się nie kompiluje, ale ogólnie spoko rzecz, polecam. Tylko MongoDB zastąp czymś co nie pochodzi ze śmietnika.

No to sie zgodze ;)
Jakies propozycje zamiast mongodb ?

0

W sumie to startupy tez czesto nie wybieraja Javy bo niby slaba produktywnosc...

A moze raczej moda?

0

Nie wykorzystują, ale później na nią przepisują :D

1
scibi92 napisał(a):

Nie wykorzystują, ale później na nią przepisują :D

Mysle, ze to dobre podejscie, zeby zrobic syfne MVP a jak sie skaluje to przepisac.

0
Krzywy Krawiec napisał(a):

W sumie to startupy tez czesto nie wybieraja Javy bo niby slaba produktywnosc...

A moze raczej moda?

Albo średnia wysokość stawek w danej technologii.

0
vpiotr napisał(a):
Krzywy Krawiec napisał(a):

W sumie to startupy tez czesto nie wybieraja Javy bo niby slaba produktywnosc...

A moze raczej moda?

Albo średnia wysokość stawek w danej technologii.

Z tego powodu u nas często jest to PHP/MySQL ? ;)

0

Na pewno na produktywność negatywnie wpływa czytelność stacktrejsów przy wyrzuceniu wyjątku
toosmall

2

Dla mnie na produktywność duży i niedoceniony wpływ ma czas feedbacku (zmieniam kod - widzę zmiany w działaniu).

Jak to jest więcej niż 2 sekundy - to jest kiepsko.
Jak więcej niż 30 sekund to bardzo źle.
Jak więcej niż 2 minuty to w zasadzie nie można o produktywności mówić.

Tu z jednej strony trzeba używać platform, które na szybkie restarty itp pozwalają - np. Java :-)
Z drugiej maximum rzeczy w testach robić - szybkich.
I po trzecie potrzeba toolingu specyficznego (jak szybko podmieniać JS i CSS w działającej stronce).

1

Jesli chodzi o backend to uwazam, ze uruchamianie appki, zeby sprawdzic czy cos dziala za anty pattern.

Idealnie powinno byc Feedback loop:

  • testy 80% czasu
  • testy + drbugger 15% czasu
  • uruchamianie 5%

Niestety czesto antypattern jest najbardziej powszechny.

0

@LukeJL: niby na JVM sa inne jezyki ale, zeby to czasem nie byla slepa uliczka... Java to Java, bedzie dzialac i wszyscy znaja.

Obecnie Kotlin to chyba najbezpieczniejszy wybor. Ale nie widze problemu przepisywac na jave. Nie ma co jej demonizowac.

1

Jesli chodzi o backend to uwazam, ze uruchamianie appki, zeby sprawdzic czy cos dziala za anty pattern.

Idealnie powinno byc Feedback loop:

testy 80% czasu
testy + drbugger 15% czasu
uruchamianie 5%
Niestety czesto antypattern jest najbardziej powszechny.

Jakby dało się polubić 2 razy to bym polubił. Nic tak nie napawa mnie zwątpieniem*, jak wejście do dużego projektu, w którym każda drobna zmiana to pieprzenie się z buildem, uruchamianiem, rekonfiguracją, restartowaniem dockera, kasowaniem baz danych, kasowaniem konfigów, reinstalacją paczek itp.

*zwątpieniem, tzn. zaczynam wtedy wątpić w zdrowy rozsądek programistów, którzy taki projekt rozwijają razem ze mną od długiego czasu, a którzy stosują tak bardzo partyzanckie metody pracy. I o dziwo - im to nie przeszkadza. Dla nich to normalne, że trzeba coś zrestartować, poczekać, bawić się w dev opsy przy każdej okazji, pochodzić po konsoli itp. A mnie to strasznie rozprasza bo zamiast myśleć o rozwiązaniu problemu programistycznego, zaczynam tylko co chwila uruchamiać i czekać na builda (ile czasu się traci!)

A można byłoby tego uniknąć stosując TDD, a jeśli nie TDD (bo nie zawsze się da), to pomyśleć o stworzeniu jakiegoś przyjaznego workflow, możliwości sprawdzenia części funkcjonalności bez restartowania całej kobyły (nawet GUI można by testować np. na jednym komponencie, zamiast na całej aplikacji). Tylko, że programiści muszą o tym myśleć wcześniej, bo często jest tak, że nie da się przetestować jednego komponentu, bo jest on silnie zależny od całego środowiska.

Tylko, że to nie ma nic wspólnego z Javą, ja się z tym zetknąłem w JS i w Rubym.

0

@LukeJL: ale oddzielmy technologie od tego co robia ludzie ;)

Nie rozumiem tylko krytyki 'bawienia sie w devopsy przy kazdej okazji'. Brzmi to troche raczej jak za malo devopsu w devopsie. Bo dobry devops akurat skraca sporo czasu.

Osobiscie lubie devopsowac ale wydaje sie bardziej wydajne miec do tego dedykowana osobe.

0
LukeJL napisał(a):

.... Nic tak nie napawa mnie zwątpieniem*, jak wejście do dużego projektu, w którym każda drobna zmiana to pieprzenie się z buildem, uruchamianiem, rekonfiguracją, restartowaniem dockera, kasowaniem baz danych, kasowaniem konfigów, reinstalacją paczek itp.

*zwątpieniem, tzn. zaczynam wtedy wątpić w zdrowy rozsądek programistów, którzy taki projekt rozwijają razem ze mną od długiego czasu, a którzy stosują tak bardzo partyzanckie metody pracy. I o dziwo - im to nie przeszkadza. Dla nich to normalne, że trzeba coś zrestartować, poczekać, bawić się w dev opsy przy każdej okazji, pochodzić po konsoli itp. A mnie to strasznie rozprasza bo zamiast myśleć o rozwiązaniu problemu programistycznego, zaczynam tylko co chwila uruchamiać i czekać na builda (ile czasu się traci!)

Tylko, że to nie ma nic wspólnego z Javą, ja się z tym zetknąłem w JS i w Rubym.

True. To nie ma nic wspólnego z Javą. Ma to dużo wspólnego z przerośniętymi platformami.

Jak już się postawi serwer, powalczy z jego konfiguracją w XMLach i konsoli, zestawi połączenie z bazą danych, skonfiguruje security....
Jak już się beany zaczną wstrzykiwać, transakcje commitować, a stronka startowa rpzestanie opluwać błędem 401 ...
to mamy już 4 tydzień projektu, spore opóźnienie, za dwa dni kolejne demo, a do tego 50 cudem działających klas.
I w tym momencie ktoś zaczyna się zastanawiać, a jak by tu robić testy...

Ale ponieważ serwer działa tylko dzięki cudowi to nie da się tego testować, bo cuda z natury nie są powtarzalne, a testy niestety muszą być powtarzalne .
Gorzej, czasem nie da się nawet zbudować drugiego serwera i cały zespół deplojuje na jakiś biedny serwer integracyjny.

Nawet nie wiem ile razy to widziałem. Da się naprawić, ale boli.
To dotyczy nie tylko JavaEE i serwerów typu Websphere, ale również wypasionych projektów na OSGi, Springu, a nawet platform CMS typu Adobe albo Coremedia.

Zawsze to samo.

Jak wybieram technologię to testowalność (albo lepiej weryfikowalność) wszystkiego co robimy w zespole (łącznie z konfiguracjami) to w zasadzie rzecz numer 1.
Niestety, wielu architektów - managerów nadal nabiera się na sztuczki typu - klikamy w Netbeans New projekt, trzy razy klikamy i proszę jakie piękne Hello World - prawie bez kodowania.
A do tego w super hiper technologii, stabilnej i wybieranej przez "fszystkie" firmy z top 500.

W jednym banku, gdzie "konsultowałem" - deployment na produkcje (WAS) szedł z Eclipsa - tylko tak umieli wrzucić - zbudowanie EARa czymkolwiek innym niż Eclipsem (RAD) było mission impossible.

0

Mimo wszystko zarowno Spring jak i JEE można ucznic spoko projektami, z dzialajacymi, szybkimi testami, z sensownym czasem deployu, z klasami co nie wygladaja jak rzygi, tylko calkiem SOLID, z sensownym api RESTowym.

Tylko trzeba to robic z glowa a nie z ulanską fantazją.
No i nie podchodzic do tematu, ze to proste... Tylko z szacunkiem. Zaczynac zawsze latwo. Ale nie mozna doprowadzic nowy projekt w kilka miesiecy do... Legacy.

0

No to @jarekr000000 skoro uważasz że testowalnośc jest tak ważne czemu hejtujesz jeden z najlepszych frameworków do tworzenie testowalnego kodu jakim jest Spring?

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