Wątek przeniesiony 2021-12-02 08:23 z Off-Topic przez cerrato.

Technologie wymarłe, legacy i żywe trupy

8
pieczarek napisał(a):

Wy serio piszecie programy na kolanie?

TAK :D

Jak wam analityk tłumaczy algorytm pocieniania wrzeciona twardego bulbulatora wstecznie skrętnego?

A weź mnie nie wkur'iaj. Ostatnio dostałem story które można streścić "zrób tak żeby było dobrze" :D

4

Kod napisany w jak to nazywasz legacy, który działa od 20 lat i przynosi pieniądze jest dużo przydatniejszy niż świeżo napisany kod napisany w fensi szmensi frameworku w najnowszym JS.

8

Kod legacy to nie kod 20 letni. System dwuletni może być o wiele bardziej legacy niż 15 letni.

1

Generalnie nie wiem ocb z tym legacy. Odnoszę wrażenie, że kod legacy to kod kiepskiej jakości i przez lata poznaczony bliznami haków. Często to jest prawda, ale przede wszystkim kod legacy to kod odziedziczony po innych senior devach (lub seniorach rodu - np. jak ktoś odziedziczył system w Cobolu po dziadku). Owszem - może być napisany w przestarzałym języku, który nie ma części konstrukcji (np. var, min, max, wyjątków, interfejsów). Niemniej taki kod może być dobrze napisany, dobrze podzielony na warstwy, na komponenty, może być SOLID, może stosować wzorce i standardy. Problem z legacy jest taki, że często dokumentacja jest nieaktualna, kod jest gigantycznych rozmiarów często a nikt nie pamięta jak on działa, gdzie zaglądnąć. Trzeba potrafić takie systemy rozgryzać, odgadywać intencje autorów, wiedzieć jak zacząć debuggować. Czasem nie można użyć nowszego frameworka czy języka. W greenfieldzie jest architekt (żywy), pewnie zespół wie co i gdzie trzeba młotkiem puknąć, kodu jest znacząco mniej, można eksperymentować z nowymi frameworkami, a każda regresja to tylko failowanie testów a nie realne straty kasy, bo system wysadzi prace w x fabrykach. To są problemy kodu dziedziczonego.

To, że legacy może być kiepsko napisane to już jest problem kiepskiego napisania i tyczy się to też greenfieldów jak i legacy i to problem rozdzielny, od bolączek kodu legacy. Dlaczego w projekcie legacy jest więcej kiepskiego kodu? Bo po prostu projektów legacy jest więcej niż greenfieldów i działa efekt skali. Większość kodu na świecie jest już napisana i działa, czasem od 40-50lat. Przecież kod Unixa ma jakieś 50lat i przedostał się do wszystkich obecnych systemów. Raz dobrze zaprojektowany kawałek kodu ma prawo działać dziesięciolecia i to jest ok. Refaktoryzacja jest ważna - ale musi ona mieć cel i uzasadnienie.

2

Dokładnie - znaczna część projektów na starcie jest legacy - kiepska architektura, brak testów, copy paste development etc.
A może być system 10 letni z dobra architekturą, testami, programistami którzy wiedzą co robią, z regularnym sprzątaniem długu technicznego etc.

3

Zgadzam się z tym że Delphi nie jest ani nieumarła, ani nie jest trupem. Jest to język poprzedniej dekady (lub dekad) - podobnie jak Java, C++, JavaScript, PHP, PowerBuilder, PL/SQL, COBOL, ale ma swoją niszę czy kogoś to boli czy nie. Na ile ta nisza jest duża to każdy musi sobie sam ocenić - jeśli go to interesuje.

Obecnie technologie pojawiają się jak grzyby po deszczu, i w którymś momencie może się okazać że nie nadążamy za wszystkim. Wtedy być może będzie warto zwrócić się w kierunku technologii które nie znikają od 20 lat.

Oczywiście fajnie jest mieć wszystkie te nowe świecące zabawki pod ręką (Cloud-native reactive Snowflak blockchain ML), ale do takich zabawek lgnie najwięcej juniorów. Pytanie jak długo będzie Nas stać na konkurowanie z młodymi, nieskażonymi wiedzą i doświadczeniem umysłami?

BTW język C++ już prawie pogrzebałem, chwilę później dowiedziałem się że kumpel dostał w tym języku robotę przy asystencie głosowym w pewnej firmie dystrybuującej kiedyś głównie książki.

3

Chyba trochę mylisz pojęcia. Nisza tzn taka dziedzina, gdzie np stosuje się tylko C++, bo tylko C++ się tam nadaje albo nadaje się najlepiej, jak np embedded czy jakieś sterowniki sprzętu.

Delphi miałby konkurować z .net np na desktopie czy z Flutterem/React Native na mobilne jako framework multi platformowy. W obu przypadkach Delphi to żałość w porównaniu z nowszymi technologiami. Delphi nie ma tak jak C++ czy C swojej niszy, gdzie nowocześniejsze technologie nie sprawdzą się lepiej, niż Delphi.

Nie wiem po co ktoś miałby kiedykolwiek wybierać Delphi do całkiem nowego projektu, chyba jedyny powód to posiadanie teamu Delphi, który albo by musiał przestawić się na inną technologię (nierealne i bezsensowne) albo trzeba zorganizować nowy team, a stary rozpędzić.

1

Już wspominałem - Delphi jest językiem, który tworzy natywne binarki i masz absolutną kontrolę nad pamięcią. Dlatego używa się go w nowych projektach do rzeczy krytycznych. Jeśli z kolei chodzi o aplikacje, które, muszą być wydajne a jednocześnie mieć GUI to Delphi ma dużą przewagę nad C++ w postaci FireMonkey i DevExpressów.

Jeśli chodzi o embended i gamedev to jeśli od początku były by darmowe kompilatory i środowiska, a Delphi powstało by wcześniej niż C++ to właśnie Delphi mogło by królować. Nie widzę żadnej rzeczy, którą zrobisz w C++ a nie zrobisz w Delphi.

Dodatkowo jeden kod ruszy na Windowsie, Linuxie, MacOs, Androidzie, iOS, cały czas natywnie i z kontrolą nad pamięcią.

0
pieczarek napisał(a):

Nie widzę żadnej rzeczy, którą zrobisz w C++ a nie zrobisz w Delphi.

Zlinkowanie z ambitniejszą biblioteką w C++, a powiedzmy sobie ważnych bibliotek jest od groma.

1
J.Muzykant napisał(a):
pieczarek napisał(a):

Nie widzę żadnej rzeczy, którą zrobisz w C++ a nie zrobisz w Delphi.

Zlinkowanie z ambitniejszą biblioteką w C++, a powiedzmy sobie ważnych bibliotek jest od groma.

Co ty opowiadasz? Normalnie można korzystać z bibliotek C++ w Delphi. Zarówno w postaci bibliotek BPL, DLL, OCX czy po prostu mając w jednym projekcie kod C++ i Delphi i RAD Studio to zbuduje do jednej binarki.

Wydaje mi się, że te wszystkie opinie o Delphi wynikają z ignorancji i niewiedzy.

1
pieczarek napisał(a):
Wyjątek napisał(a):

A UML można dopisać? Czy ciągle ktoś tworzy grafy w M$ Visio?

Wy serio piszecie programy na kolanie?

W sumie to przypominam sobie, że parę lat temu widziałem diagramy stanu, ale to był standard IEEE, oni się starają.
Kilkanaście lat temu chyba ktoś mi narysował jak okno dialogowe ma wyglądać.

Jak projektuje się flow między mikroserwisami to jak inaczej niż przez diagramy sekwencji czy komunikacji?

Nie mam pojęcia, co to jest mikroserwis. Muszę ci uwierzyć, że gdybym się zajmował takimi pierdołami, to musiałbym mieć diagramy jakieś tam :)

1

Ja w jednej z firm rzeźbiłem w Eclipse RAP, myślałem że nikt tego nie używa bo na SO nie mogłem nic znaleźć w tej technologii, ale wypuszczają nową wersję co 3 miesiące, więc chyba komuś to służy xD

0
pieczarek napisał(a):

Oczywiście, że Delphi ma swoje problemy. Mógłbym wymieniać godzinami. Począwszy od beznadziejnego modelu biznesowego, przez łatanie ewidentnych błędów RTL i VCL tylko w nowych wersjach, przez niełatanie części błędów gdyż na nich bazuje już część softu, przez utrudnianie migracji kodu do nowszych wersji, niestabilne IDE, czy to że ciągle gonią technologię (patrz kiedy wprowadzili PPL). Zgodzę, się, że w wielu przypadkach można znaleźć lepszą technologię. Niemniej Delphi ma pewną cechę, a w zasadzie zestawienie dwóch - nie bazuje na VM i nie jest C++. Delphi to nisza, ale naiwnością twierdzić, że jest żywym trupem, jeśli wychodzą nowe wersje tej technologii, duzi gracze go używają i od ręki można dostać robotę w nim. Mam portfel kilku ofert, z niedawna.

Niemniej rozumiem, że musisz przekonywać innych, że Delphi jest trupem. Tak samo jak inni podobni Tobie przez 20lat. Widziałem wiele śmierci. Można umierać gwałtownie, można godzinami, a nawet dniami. Niektórzy umierają miesiącami a nawet latami. Natomiast nie widziałem kogoś, kto umiera dekadami. Przez 20 lat można zbudować dom, spłodzić dziecko, odchować, wyprowadzić na ludzi a nawet zostać dziadkiem... Nie wiedziałem by umierający tyle dokonał. Co więcej nie widziałem, by do umierającego inżyniera zgłaszali się klienci, żeby im coś zaprojektował. Sam mówisz o pragmatyzmie. Nie chcę się powtarzać, ale właśnie przez ten pragmatyzm nadal powstają projekty w Delphi.

Ja przez żywy trup uważam np. stan, gdzie soft jest utrzymywany, ale nie z chęci, ale z konieczności bo baza kodu jest nieprzepisywalna, gdzie trzymamy ostatnich programistów pod respiratorem bo kto to będzie robił, gdzie nie ma już wsparcia producenta, a my starami się sami poprawiać technologię i pisać obejścia. Tak to można nazwać żywym trupem, a nie technologię gdzie powstają nowe projekty, pisze się książki o niej, ludzie kupują licencje i sie jej uczą. Pewne wersje Delphi to jest trup, ale nie technologia. Tak jak można powiedzieć, że .NET 2.0 jest takim żywym trupem - zacofane, z błędami, bez wsparcia a ludzie nadal utrzymują na tym soft.

EOT z mojej strony, bo nie zamierzam dyskutować dlaczego białe nie jest białe, a czarne nie jest czarne. Jeśli będzie Ci lepiej, z tym, że Delphi to trup - ok, niech tak będzie, ale rzeczywistości nie zmienisz.

@pieczarek: Moim zdaniem sprawa z Delphi wygląda bardzo prosto:
brakuje programistów, mamy na rynku dużo seniorów z Delphi którzy nie chcą się uczyć nowych rzeczy i tkwią w tej technologii
Będąc przedsiębiorstwem też wolałbym mieć takich niż uczyć ich nowoczesnych narzędzi, gdyż to podniosłoby koszty

Nowych programistów raczej nie przybywa, na uczelniach nie uczy się tej technologii. Nie słyszałem o bootcampach w tej technologii. Mógłbyś przytoczyć jakieś źródła jeżeli się mylę bo zaskoczyłeś mnie swoim postem.

pieczarek napisał(a):
Wyjątek napisał(a):

A UML można dopisać? Czy ciągle ktoś tworzy grafy w M$ Visio?

Wy serio piszecie programy na kolanie? Raczej nie w Visio, a w Rationalu od IBM się trzaskało srogie UML'e 4+1, etc. etc. Obecnie często projektuje strukturę klas przez diagramy klas UML'a. Jak projektuje się flow między mikroserwisami to jak inaczej niż przez diagramy sekwencji czy komunikacji? Projektujecie diagramy maszyny stanów waszych obiektów czy walicie ifologię tak długo aż QA nie puści? Jak wam analityk tłumaczy algorytm pocieniania wrzeciona twardego bulbulatora wstecznie skrętnego? Pisze bajkę na Jira, czy daje diagram aktywności? Skąd ten analityk ma wiedzieć jaki algorytm zaprojektować? Rozmawia z biznesem i pisze opowiadanie, czy raczej rysuje diagram przypadków użycia?

Fakt - pełen RUP w dobie podejścia iteracyjnego nie ma dużego sensu, ale poszczególne elementy są ciągle używane. Jak u was nie to zmieńcie firmę. Narobiłem się w Rationalu troszkę i obecnie jak rysuje dla siebie to kartka/tablica, a jeśli piszę pdf'a z dokumentacją czy projektem to kiedyś używałem DIA (nadal używam czasem), a częściej UMLet. Proste, a robią robotę - umożliwiają szybkie zrobienie schematu.

Teoretycznie można by powiedzieć, że Waterfall to zombie bo teraz wszystko jest raczej iteracyjne, ale to też nieprawda bo jest pełno projektów fixedprice gdzie waterfall jest konieczny. Żeby się nie rozsypało to niby są wymagania, często w rządowych projektach żeby robić waterfallem, ale firma musi mieć np. certyfikaty PRINCa2.

@pieczarek Pisząc o metodyka RUP i stosowaniu tego przez IBM - zobacz w jaką stronę poszła branża IT, nikt nie pamięta już o closed source i systemach tworzonych przez tą firmę. Moim zdaniem powinieneś wykonać research odnośnie ich technologii i metodyki dlaczego RUP sprawdzał się w ich przypadku. Niestety ale minęło bardzo dużo czasu i teraz rynek wygląda inaczej. Mainframe, OS/400, iSeries, pSeries i zSeries to historia. Nawet nazwy mainframe są nazwane od dinozaurów. Świat poszedł do przodu. Nie wiem w jakiej organizacji pracujesz ale pisanie UML i projektowanie za jego pomocą klas brzmi dziwnie. Pierwszy raz się z tym spotykam. Moim zdaniem powinieneś przeczytać Czy korzystacie z jakichś generatorów kodu (poza frameworkowymi)? tutaj na prawdę nie zauważam wartości w pisaniu UML i klas przez to. Może @somekind mógłby się na ten temat wypowiedzieć. Ja nie mam dostatecznej wiedzy w temacie. Nigdy nie myślałem aby zastosować UML do pisania klas.

@KamilAdam
Moim zdaniem do technologii tego typu można zaliczyć też BPMN - Business Process Model and Notation
nie słyszałem o użyciu tego aby się sprawdziło, uczyłem się na studiach lecz na żadnej konferencji ani od kolegów nie słyszałem o zastosowaniu tego.

Biznes nie wie czego chce i te wszystkie notacje i modele zazwyczaj od strony biznesu są niewiele warte poza tym "macie zrobić"

@.andy @J.Muzykant Źle napisałem. Chodziło mi o wymieranie XML jako plików z konfiguracją np. w Javie. Dziękuję za poprawkę.

Spearhead napisał(a):

@jarekr000000: napisał kiedyś na mikroblogu ciekawy wpis o zombiakach Javy

Szkoda że nie przeczytałem o tym. Brakuje takich materiałów a są one na prawdę wartościowe. Przydałby się dobry artykuł odnośnie technologii wymarłych na frontendzie przez osobę kompetentną w temacie.

2
Marcin Marcin napisał(a):

Nowych programistów raczej nie przybywa, na uczelniach nie uczy się tej technologii. Nie słyszałem o bootcampach w tej technologii.

Ja na uczelni miałem Wstęp do Programowania, który był realizowany z wykorzystaniem Turbo Delphi 2006 :]

Ale ja, podobnie jak wielu innych programistów, nigdy nie liczyłem na to, żeby uczelnia nauczyła mnie programować. Większość przedmiotów językowych i tak trwała jeden semestr i nie wszystkie języki były potem wykorzystywane na konkretnych przedmiotach, np. C++.

BTW. jak odszedł nasz wykładowca ze Wstępu do Programowania, to następny rocznik realizował ten przedmiot w języku C.

0

@Marcin Marcin:

Moim zdaniem do technologii tego typu można zaliczyć też BPMN - Business Process Model and Notation
nie słyszałem o użyciu tego aby się sprawdziło, uczyłem się na studiach lecz na żadnej konferencji ani od kolegów nie słyszałem o zastosowaniu tego.

No ja nie dość, że słyszałem to i pracowałem.
Ba niektóre silniki workflow bazują na takiej notacji.

Biznes nie wie czego chce i te wszystkie notacje i modele zazwyczaj od strony biznesu są niewiele warte poza tym "macie zrobić"

Nie wiem w jakich firmach pracowałeś ale znowu mam odmienne zdanie. Jeżeli już rzucać takim hasłem, to w stronę klientów się też nie koniecznie, bo klienci wiedzą bardzo dobrze czego chcą - nie wiedzą tylko jak to osiągnąć.

BPMN potrafi fajnie opisać jak wygląda proces klienta w formie zrozumiałej dla klienta i programistów.

@Marcin Marcin

@.andy @J.Muzykant Źle napisałem. Chodziło mi o wymieranie XML jako plików z konfiguracją np. w Javie. Dziękuję za poprawkę

No ale xml zawsze był traktowany jako worek na dane i tutaj się sprawdza świetnie.
Zobacz na XMPP. Jego podstawą jest XML, dane są wysyłane opisane w xmlu. Nie widzę możliwości zastosowania czegoś innego. (Formaty binarne odrzucam)

2
Marcin Marcin napisał(a):

@pieczarek: Moim zdaniem sprawa z Delphi wygląda bardzo prosto:
brakuje programistów, mamy na rynku dużo seniorów z Delphi którzy nie chcą się uczyć nowych rzeczy i tkwią w tej technologii
Będąc przedsiębiorstwem też wolałbym mieć takich niż uczyć ich nowoczesnych narzędzi, gdyż to podniosłoby koszty

Nowych programistów raczej nie przybywa, na uczelniach nie uczy się tej technologii. Nie słyszałem o bootcampach w tej technologii. Mógłbyś przytoczyć jakieś źródła jeżeli się mylę bo zaskoczyłeś mnie swoim postem.

Ile firm, które mają seniorów Delphi znasz? Ilu seniorów Delphi znasz, że wiesz, że nie chcą się uczyć nowych rzeczy? Moim zdaniem wymyśliłeś sobie to wszystko, żeby podeprzeć swoją tezę. Delphi sobie przycupło pod krzaczkiem i tak sobie od kilkudziesięciu lat siedzi i nie wydaje się, żeby miało się wywrócić. Pomału firma się obetonowuje, ale bardzo powoli. Po przejęciu przez Iderę, z jednej strony wydali wersje CE, ale z drugiej strony próbowali telemetrią wykrywać łamanie licencji CE, i wysyłali wezwania do zapłaty. Czasem słusznie, czasem nie, natomiast to troszkę mnie zdystansowało od nich.

No ale spójrzmy na fakty i co mówi rynek, przynajmniej w Polsce. Dystrybutor od lat generuje dość marny jak na branże obrót lekko ponad 1kk zł. Za to firmy używające Delphi generują od kilku do kilkunastu kk zł rocznie. Można oszacować, że w Polsce rynek Delphi generuje obrót kilkudziesięciu do kilkuset kk zł. Ja odczytuje to, tak, że nie powstają nowe firmy, które wchodzą w tą technologię(inaczej BSC generował by coraz większe przychody), ale istnieje pewna grupa firm, która radzi sobie dobrze i istnieje na rynku już długo. Warto zauważyć, że np.że w Polsce istnieją firmy, które same generują obrót rzędu kilkuset kk zł. Pokazuje to, że Delphi jest raczej marginesem rozwiązań, ale nadal jest i nie umiera, a rynek jest rentowny.

Na podstawie powyższego zgodzę się, że firmom nie opłaca się wychodzić z Delphi, ale raczej nie dlatego, że to by były duże koszty, a były by to koszty bezsensowne, bo po co to robić, skoro firma nadal generuje dziesiątki kk przychodu? Nie zgodzę się co do charakterystyki programisty Delphi - każdy programista Delphi, którego znam i jest to prawdziwy programista a nie foliarz totolotkarz, zazwyczaj zna dobrze kilka języków i pracuje/pracowało w innych technologiach. Zresztą każdy senior moim zdaniem jest poliglotą programistycznym a specjalizacja w jednej wąskiej dziedzinie jest nieaktualnym mitem.

@pieczarek Pisząc o metodyka RUP i stosowaniu tego przez IBM - zobacz w jaką stronę poszła branża IT, nikt nie pamięta już o closed source

Wybacz, ale odnoszę wrażenie, że Ty nigdzie nie pracowałeś jeszcze ;) Albo byłeś w tylko jednej firmie. Closed source ma się bardzo dobrze. Open source istnieje jedynie tam gdzie ten model się opłaca. Np. Docker daje OpenSource rozwiązanie, ale zarabia na wsparciu, realizacji funkcji jakie potrzebują sponsorzy, oraz ma swoje usługi. Podobnie jest z RedHatem i wielu innymi. MS też poszedł w OpenSOurce, ale bardziej moim zdaniem, żeby usprawnić proces tworzenia samego .net'a bo przecież VisualStudio nadal jest closed i zarabiają na nim, tak samo jak Windows jest closed source i zarabia się na nim. Google, kluczowe usługi mają closed source. Wszystkie chmury w zasadzie infratrukturę na jakiej zarabiają jest closed source. W bankowości masz tylko closed source. Facebook jest closed source. Usługi gdzie ważne jest know-how a ich osiagnięcia są unikatowe też są closed source, czasem do tego stopnia, że działają jako SaaS czy endpointy, byle by nie dawać binarki, żeby nikt RE nie zrobił. Chyba przesadzasz z tym open source.

Niemniej to nie ma znaczenia, bo UML sprawdza sie zarówno w closed jak i open source.

Nie wiem w jakiej organizacji pracujesz ale pisanie UML i projektowanie za jego pomocą klas brzmi dziwnie. Pierwszy raz się z tym spotykam. Moim zdaniem powinieneś przeczytać Czy korzystacie z jakichś generatorów kodu (poza frameworkowymi)? tutaj na prawdę nie zauważam wartości w pisaniu UML i klas przez to. Może @somekind mógłby się na ten temat wypowiedzieć. Ja nie mam dostatecznej wiedzy w temacie. Nigdy nie myślałem aby zastosować UML do pisania klas.

W takim razie jak przedstawisz strukturę klas programiście z Indii, który nie zna angielskiego? Jak planujesz architekturę systemu jaki projektujesz? Właśnie kod legacy powstaje od nieprzemyślanego naparzania w klawiaturę. Jak inaczej zwizualizować i opisać zależności systemu? Można wymyślać swoje sposoby, ale po co jak są dobrze zdefiniowane notacje? Znów odnoszę wrażenie, że po prostu nie masz doświadczenia w komercyjnej pracy w dużych firmach.

@KamilAdam
Moim zdaniem do technologii tego typu można zaliczyć też BPMN - Business Process Model and Notation
nie słyszałem o użyciu tego aby się sprawdziło, uczyłem się na studiach lecz na żadnej konferencji ani od kolegów nie słyszałem o zastosowaniu tego.

Dla mnie normalnym jest to, że analityk, który jest u klienta i słucha kierownika magazynu, pracowników szeregowych, wypytuje jak działa firma, a na sam koniec produktem takiej analizy jest dokument, który ma w sobie opis procesów, ale także różne schematy, w tym także schematy BPMN czy maszyny stanów opisujące stany np. zamówienia, reklamacji etc,

Teraz to idzie w dwie strony - jeśli firma ma gotowy soft z jakimś silnikiem workflowowym, to przenosi te BPMN do schematów opisujących procesy, a system zaczyna się sam konfigurować, żeby realizować te procesy.

Jeśli z kolei nie ma takiego systemu i trzeba coś tworzyć z pewnego zestawu code base, lub jest to po prostu softwarehouse, to wtedy architekt odpowiedzialny za projekt przetwarza dokument analityczny na projekt techniczny właśnie okraszony częściowo w UML'e. Dalej to można dzielić na taski i planować sprinty. Bo teraz mamy rozbity projekt i możemy w końcu go wycenić. Wiadomo, że idea SP jest jednym, ale trzeba wiedzieć jak technicznie to wykonać by to wycenić.

Biznes nie wie czego chce i te wszystkie notacje i modele zazwyczaj od strony biznesu są niewiele warte poza tym "macie zrobić"

Biznes wie co chce, dlatego czasem jest niezadowolony jak widzi produkt.

@.andy @J.Muzykant Źle napisałem. Chodziło mi o wymieranie XML jako plików z konfiguracją np. w Javie. Dziękuję za poprawkę.

Plik konfiguracyjny jest takim typem pliku, że sprawdzi się dobrze XML, JSON czy INI. Moim zdaniem nie ma to większego znaczenia, przy czym INI przez brak hierarchiczności czasem trzeba hakować.

Przyznam, że tutaj zalety XML nie są użyteczne (już je opisywałem) i JSON jest nawet wygodniejszy do konfguracji, bo robisz to szybciej i nie jest to przeładowane. Niemniej do reprezentacji dokumentów raportów, zbiorów danych, uważam, że nadal nie ma konkurencji do XML.

1
KamilAdam napisał(a):

W większości to są bazodanowcy. Oni przywykli do braku statycznego typowania, braku dobrego IDE, braku systemu kontroli wersji i review kodu

No chyba raczej nie: SSMS bardzo dobrze radzi sobie z debugowaniem, teraz nawet przenieśli do wsparcie baz do VS. PL/sql developer był całkiem w porządku do Oracle, jeśli chodzi o debugowanie. Jeśli mówimy o standardowych narzędziach dla MySQL (workbanch) i Postgresa (pgadmin) to jest padaka ale są rozwiązania firm trzecich, które radzą sobie z tym.

3

Oczywiście to moje gdybania i jedynie powrócenie do niniejszego wątku za 10 lat będzie sensowną weryfikacją ale moje typy są następujące:

  1. Nadejdzie taki moment w ciągu najbliższych 10 lat, że będzie większe zapotrzebowanie na programistów Delphi niż TypeScript. Nie oznacza to wcale, że Delphi stanie wiele się bardziej popularne niż jest obecnie.
  2. Znikną niemal do zera wszelkie VUE, Reacty, Angulary itp...
  3. Zmarginalizowane ( do poziomu Delphi ) zostaną Kotlin i Scala.
  4. Na TOP wysuną się JavaScript i pewnie powróci JAVA.
  5. W PHP wciąż będzie napisana większość projektów WEB, a jego przeciwnicy wciąż będą bzyczeć, że to trup.
  6. XML wciąż będzie miał stabilną pozycję bo zbyt wiele świata XML'em stoi a JSON wcale nie jest alternatywnym dla XML formatem. Może jest ale jedynie w malutkim obszarze zastosowań i możliwości XML.
3

Zmarginalizowane ( do poziomu Delphi ) zostaną Kotlin i Scala.

Na to jest naprawdę duża szansa. Wystarczy że Java przejmie większość feature'ów z Kotlina i nastąpi powrót programistów do Javy

2

Tyle że Kotlin to default dla Androida a Scala jest daleko od Javy, więc wątpię.

1
Marcin Marcin napisał(a):

@pieczarek Pisząc o metodyka RUP i stosowaniu tego przez IBM - zobacz w jaką stronę poszła branża IT, nikt nie pamięta już o closed source i systemach tworzonych przez tą firmę. Moim zdaniem powinieneś wykonać research odnośnie ich technologii i metodyki dlaczego RUP sprawdzał się w ich przypadku. Niestety ale minęło bardzo dużo czasu i teraz rynek wygląda inaczej. Mainframe, OS/400, iSeries, pSeries i zSeries to historia. Nawet nazwy mainframe są nazwane od dinozaurów. Świat poszedł do przodu. Nie wiem w jakiej organizacji pracujesz ale pisanie UML i projektowanie za jego pomocą klas brzmi dziwnie. Pierwszy raz się z tym spotykam. Moim zdaniem powinieneś przeczytać Czy korzystacie z jakichś generatorów kodu (poza frameworkowymi)? tutaj na prawdę nie zauważam wartości w pisaniu UML i klas przez to. Może @somekind mógłby się na ten temat wypowiedzieć. Ja nie mam dostatecznej wiedzy w temacie. Nigdy nie myślałem aby zastosować UML do pisania klas.

Owszem, mogę się wypowiedzieć. Nie mam zielonego pojęcia o mainframach, OS/400 IBM, RUP, dla mnie te słowa brzmią jak nazwy chorób wenerycznych.
UML używałem na studiach (pewnie nawet generowałem klasy, jak kazali). W pracy spotkałem się z UML raz, cały system był opisywany za jego pomocą przez analityków biznesowych, i była to jedyna forma przekazywania zadań (nie było tam żadnej Jiry, scrumów, user story, itd.). I nawet to jakoś działało, tylko oczywiście było implementowane, a nie generowane.
Poza tym nie wiem o co chodzi w tym wątku, i nie wiem po co zostałem wywołany.

5
pieczarek napisał(a):

W takim razie jak przedstawisz strukturę klas programiście z Indii, który nie zna angielskiego? Jak planujesz architekturę systemu jaki projektujesz? Właśnie kod legacy powstaje od nieprzemyślanego naparzania w klawiaturę. Jak inaczej zwizualizować i opisać zależności systemu? Można wymyślać swoje sposoby, ale po co jak są dobrze zdefiniowane notacje? Znów odnoszę wrażenie, że po prostu nie masz doświadczenia w komercyjnej pracy w dużych firmach.

  1. Jeśli programista z Indii nie zna angielskiego to przedstawianie mu UML też nie pomoże, w żadnym mierzalnym stopniu.

  2. Architekture planauje się w kodzie i zmienia. Jak coś trzeba narysować to UML jest dużo mniej użyteczny niż zwykłe bazgroły na tablicy.

  3. Jak ktoś się nie pierniczy w UML to nie znaczy, że bezmyślnie naparza w klawiaturę - wręcz przeciwnie - najgorszy kod jaki widziałem pochodził z czasów zabaw w UMLe (i MDA)

  4. Mam co prawda tylko 20 kilka lat doświadczenia w komercyjnych projektach więc jeszcze wiele przede mną. Muszę powiedzieć, że UML stosowałem - zaraz po studiach, ale mi przeszło. Potem co jakiś czas spotykałem zdolnych młodych absolwentów i oni też stosowali UML, ale im przechodziło.

  5. UML się po prostu nie nadaje do modelowania. To potwór ze starych czasów, kiedy ludzie robili singletony.

1

@jarekr000000: przyznaj, po prostu w UML nie ma monad ;]

4

Ogólnie UML (przynajmniej ten który znałem) totalnie odpada przy językach funkcyjnych

Architekci go nie nawidzą. Znalazł jeden prosty sposób żeby nie robić diagramu klas...

uzył języka funkcyjnego który nie ma klas :/

2

Ja tam uważam ze czasem jakiś UMLowy diagram ma sens, szczególnie:

  • deployment diagram, jak masz jakaś pokręconą architekturę i milion serwisów
  • data flow diagram, jak chcemy pokazać jak jakis event przechodzi przez system
  • sequence diagram, podobnie jak wyżej, ale chcemy widzieć konkretnie kto z kim ma interakcje i jak sie komunikują

Niemniej to raczej zabawa post-mortem, tzn dla udokumentowania co zmajstrowaliśmy, niż jakieś projektowanie przed implementacją. A malowanie diagramów klas to bzdura zawsze.

0

@Shalom: teraz widzę jak ludziska stosują C4 przy modelowaniu architektury.

2

logikę biznesową jako procedury składowe bazie danych - z tym spotykam się na co dzień i jest to bardzo dobre rozwiązanie ze względów wydajnościowych. Oczywiście takie rozwiązanie wymaga więcej wysiłku przy utrzymaniu kodu bo musimy koordynować utrzymanie kodu aplikacji i bazy danych, ale to jest to tylko kwestia dobrej organizacji pracy.

2

Gdzie kończyłyby tematy o wymarłych technologiach, gdyby autor celowo nie wrzucił do nich baita w postaci technologii, której aktywnie używa pół świata. Dlaczego zawsze musi być w takim wątku Java/PHP/JS poparty argumentem typu "bo istnieje technologia, w której da się to zrobić lepiej".
Jest jakaś strona z szablonami "jak wywołać flame na forum/konferencji X" czy jak?

1

Za każdym pytaniem powinien się kryć sensowny cel.
Te jest typowym trollingiem.
Na co komu informacje, że ActionScript z Flashem jest martwy (czy inny NetWare) a Delphi pomimo swoich zalet przez bezsensowny model biznesowy i marketing wtoczył się w niszę (i to już od czasów Borlanda)? Nie wyjdzie już z niej. Szkoda, bo warto by było mieć alternatywę do robienia okienek. Tutaj można by podyskutować, co taki FreePascal/Lazarus mógłby zmienić by zacząć się szybciej rozwijać (obciąć mało efektywne gałęzie typu wsparcie dla Android/Apple (są do nich bezpłatne IDE) i skupić się na Windowsie i Linuxie)

Znaczenie ciekawsze by było pytanie- "Czego naukę warto zaryzykować biorąc pod uwagę rozwój technologii i wyzwania obecne i przyszłe, a naukę których technologi sobie odpuścić"

Ale i tutaj łatwiej odpowiedzieć na drugą część pytania niż na pierwszą.
Nigdy bym nie wrócił do RoR/Ruby.
Kotlina z czasem zabiją dwie rzeczy - rozwój samej Javy i wymiana przez Google Androida na system nie oparty na Javie. To, że teraz jest promowany przez Googla nie ma większego znaczenia, lepiej uczyć się czystej Javy.
Ktoś tutaj napisał, że wymrą frameworki JS a sam JS będzie się rozwijać. Dziwna i nielogiczna teza. Tzn część dotycząca wymarcia frameworków JS.

Można by dalej rozwijać temat, wynosząc go na poziom futurologiczny czy wręcz filozoficzny, tworzenia standardów, modeli biznesowych w IT czy za co powinno się płacić dostawcom technologii. Technologia wyprzedziła modele społeczne i ekonomiczne i doprowadziła do absurdów, w których Gates dzięki możliwości sklonowania w milionach swoich systemów oraz znakomicie rozwiniętemu marketingowi/systemowi korupcyjnemu pobiera absurdalne opłaty. Za które płacimy wszyscy.
Pierwszy znaki zmian modelu widać już od wielu lat - największe korporacje dostarczające usługi dla klienta końcowego opierają swoje rozwiązania na bezpłatnym i opensourcowym oprogramowaniu, sami twórcy softu zakładają fundacje i znajdują sponsorów zainteresowanych w rozwoju tego oprogramowania.

2

SVN, CVS itd. chyba można uznać za żywe trupy? Już dawno nie widziałem żeby gdziekolwiek były używane, ktoś je jeszcze spotyka? Git zmonopolizował rynek :)

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