Na jakiej podstawie określić dobór języka programowania do rozwiązywanego problemu

2

Dzień dobry

Natrafiłem przy okazji wykonywania projektu na dyskusję w której musiałem udowodnić dlaczego system ma być wykonany w javie.
W porównaniu oczywiście były języki PHP, C#, Python, Ruby

Uzasadnieniem głównym była dostępność bibliotek do mikroserwisów i możliwość tworzenia większych aplikacji niż w przypadku pozostałych.
(tutaj nie róbcie gównoburzy bo zaraz się fani odezwą że w innych języka też da się mikroserwisy robić)

Oczywiście pod napisaniem uzasadnienie do PHP były rzeczy w stylu "powstał nie wiadomo po co i dlaczego, język dla gimbazy itd), że to język w którym nie robi się już nowych projektów,
pod C# że to sklonowana owca i jak głupio skopiowana java, pod Ruby że to się nie nadaje do niczego innego niż prototypowanie.

Po przeczytaniu takich rzeczy (nie ja je pisałem) złapałem się za głowię i stwierdziłem że programiści często podążają za jakimiś stereotypami nie umiejąc merytorycznie dyskutować o tym dlaczego należy użyć danego języka. Może sam już jestem na tyle stary że traktuję język jako narzędzie a nie skupiam się na podniecaniu technologią i że somsiad ma starszą wersję javy.

Jak wy przechodzicie przez takie dyskusje? Jak określacie czy język się nadaje czy nie?

12

Z popularnych języków to najlepszy jest ten, który zna się najlepiej.

2

Najważniejsze dla mnie jest co umieją ludzie. Co to za aplikacja np bez sensu jest pisać grę w Pythonie albo plikacje mobilna.

5

Wydawać by się mogło, że inżynierowie, umysły ścisłe, powinni kierować się jakimiś mierzalnymi oraz w miarę obiektywnymi czynnikami, np.:

  • wyniki benchmarków, np. https://github.com/the-benchmarker/web-frameworks, gdzie php prowadzi,
  • ilość czasu jaką zespół potrzebuje do zaadoptowania technologii,
  • jak szybko można znaleźć programistę danego języka/frameworka na rynku lub wyszkolić nową osobę,
  • w jaki sposób system będzie skalowany?,
  • w jaki sposób system będzie utrzymywany i robione będą kolejne wdrożenia?,
  • architektura systemu, dostępność load balancerów, sharding,
  • integracja z ekosystemem dostępnym w firmie,
  • popularność języka/frameworka, ilość zgłaszanych bugów oraz support jaki zapewniają twórcy,
  • kompatybilność wsteczna języka/frameworka, stabilność frameworka, stabilność ekosystemu.

Ciężko merytorycznie polemizować z argumentem, że jakiś język jest sklonowaną owcą. Generalnie większość dzisiejszych, popularnych języków to sklonowana owca po jakimś już mniej popularnym języku. Najlepszym rozwiązaniem jakie mogę zaproponować w obecnej sytuacji to złożenie wypowiedzenia :)

0

Python - fajny, ale nie do web, ruby - mały support, ciężko z zatrudnieniem, java/c# - korpo.

Życie jest proste. :)

0

Natrafiłem przy okazji wykonywania projektu na dyskusję w której musiałem udowodnić dlaczego system ma być wykonany w javie.

W sensie jaka twoja rola była? Jako szeregowy programista miałeś dokonać wyboru języka czy jesteś jakimś PMem, CTO czy kimś innym takim, kto jest w stanie powiedzieć "potrzebujemy programistów Javy, trzeba wystawić ogłoszenie, niech przychodzą. Zrobimy zespół Javowców"

Bo od strony jednostkowego programisty to najbardziej produktywnym podejściem jest pisanie w tym języku, który się zna (choć też bez przesady, nie wszystkie języki się nadają do wszystkiego), a nie zastanawianie się "w którym języku napiszę dzisiaj projekt".
Z drugiej strony elastyczność i możliwość pisania w różnych językach w zależności od projektu też może być użyteczna.

możliwość tworzenia większych aplikacji niż w przypadku pozostałych.

"możliwość tworzenia większych aplikacji" to taki slogan. Co to znaczy? A w innych się nie da?

1

Do mikroserwisów to rzeczywiście trzeba uzasadniać Jave, bo zwykle robi się je w czymś innym (Python, Js, PHP) i żeby Java miała tak samo szybki start to trzeba się trochę więcej wysilić:
https://developers.redhat.com/blog/2018/07/30/natively-compile-java-code-for-better-startup-time/

"Dostępność bibliotek" to raczej słaby argument bo każdy z języków ma jakieś tam biblioteki, a raczej ważniejsza jest infrastruktura dookoła (bazy danych, autoryzacja, konfiguracja, load balancer, gateway, itd). Ta infrastruktura jest dostępna zwykle dla wielu języków, a bywa że w pierwszej kolejności dla języków nie enterprajsowych.

Oczywiście Java też ma ileś tam rozwiązań, ale nie jestem przekonany czy do serwisów na kilkaset linijek komuś chce się konfigurować pomy, jenkinsa, artifactory, sonara, jacoco...
Może do mikro-monolitów tak.

3

No ja na pewno nie pisałbym systemu większego niż hello world bez statycznego i silnego typowania więc to już ogranicza zakres wyboru ;)
A jak już to mam to postąpiłbym pewnie jak @danek.
Ps. Osobiście wybrałbym Kotlina ale nie ma go na liście :p

1

ruby - (...) ciężko z zatrudnieniem

Zarówno zatrudnić się jak i zatrudnić kogoś. Znajomy miał w firmie testy E2E pisane w Rubim, ale zrezygnowali z nich bo nie byli wstanie zatrudnić ani jednego programisty Rubiego do utrzymywania frameworka. Wszystko przepisali na popularny korpo język.

Podobnie do niedawna (czyli 3 lata temu) w Katowicach było ze Scalą. Dziewczyna z HRu powiedziała prezesowi W Katowicach jest 9 programistów Scali z czego 5 nie chce pracować w naszej firmie. Nie jestem wstanie zrekrutować więcej.

Wniosek z tego taki że jeśli chce się zbudować duży zespół to trzeba brać popularny w danym regionie język.

UPDATE Małe wyjaśnienie. To o braku Scalowców jest sprzed 3 lat. ROk temu w Katowicach powstał też oddział Softwaremill i oni na brak Scalowców nie narzekają

7

@KamilAdam:

Dziewczyna z HRu powiedziała prezesowi W Katowicach jest 9 programistów Scali z czego 5 nie chce pracować w naszej firmie. Nie jestem wstanie zrekrutować więcej.

Nie znam sytuacji, może nawet tak jest (właśnie (UPDATE) sprawdziłem, że to fantazja HR). Ale normalnie to w bzdury od HR nie wierzę. Jakiś czas temu w jednej firmie przekonywali mnie, że nie mogą znaleźć od lat programisty javy, ale od COBOLa znajdują. Jak w firmie są głównie COBOLOwcy i takie ogłoszenia są wywieszone- to nie dziwne. Co więcej wstawienie w ofertę szukamy programisty java, znajomość COBOL będzie zaletą też raczej javowców nie zachęca.

W przypadku Scali paradoks polega na tym, że znam wielu programistów Scali, którzy piszą w javie, bo nie mogą ofert scalowych znaleźć. A w tym samym czasie słyszę info o braku programistów Scali (również w Szwajcarii). Przy czym zwykle nie dotyczy to firm, które faktycznie Scalowców szukają (znam takie, ale nie narzekają na brak zainteresowania z tego co wiem). To jest raczej ostateczny argument architektów w firmach javowych - dlaczego nie można zrobić systemu w Scali.

UPDATE:
Najlepsza weryfikacja tekstów HR
https://www.meetup.com/pl-PL/Silesia-Scala-User-Group/ - 100 członków Grupa publiczna

Czyli jak sie bardzo, ale to bardzo nie chcę szukać to sie nie znajdzie.

Można sprawdzić, że dużo z tych członków dołączyło w 2016 i wcześniej.

3

Każdy problem można rozwiązać JSem!

5

"Na jakiej podstawie określić dobór języka programowania do rozwiązywanego problemu?"
Wybrać taki, który spełni założenia projektu, bo sam język nie jest tu największym problemem. Nie wiesz jaki język wybrać? Doprecyzuj założenia. Nie wiesz mimo precyzyjnych założeń? Wybierz jakikolwiek a potem najwyżej zmienisz.
@twoj_stary_pijany wymienił kilka punktów bardzo pomocnych w tej decyzji. Uzupełnię to o coś, co wynika z biznesowego pragmatyzmu: jeśli coś działa i zarabia na siebie, to jest ok. Kod strony może być brzydki, może być w PHP, asemblerze, Javie... czymkolwiek.
Przykład: komunikator w stylu Discord. Funkcje:

  • możliwość odpalenia w przeglądarce,
  • możliwość odpalenia w telefonie,
  • możliwość odpalenia w aplikacji na Windows,
  • możliwość odpalenia w aplikacji na Linux,
  • czat tekstowy,
  • czat głosowy,
  • możliwość zakładania serwerów,
  • możliwość zakładania kanałów,
  • możliwość rozmowy z konkretnym użytkownikiem,
  • wyszukiwanie serwerów,

... dużo innych opcji.

Co spełnia punkty o wieloplatformowości?
Np, Electron i React.
Czyli wybór dla klienta pada na Javascript.
Jak wybrać język na backend?
Można wybrać dowolny, w którym da się zrobić REST API - Electron i React sobie poradzą z REST.
A zatem wymagania odnośnie serwera:

  • skalowalność,
  • łatwość wdrożenia zmian,
  • licencja na biblioteki,
  • wydajność.

Przykłady: Javascript z NodeJS i Java z Openfire.
Jeśli ktoś wybierze Reacta i NodeJS, to może nie będzie najlepszy wybór, ale spełni pewne założenia. Jeśli przestanie je spełniać albo pojawią się nowe, będzie można to zmienić. Tak robił Microsoft z WPF, WF i MFC - każda z tych bibliotek charakteryzuje się trochę innym podejściem. Tak zrobił Google (Java -> Kotlin) kiedy Oracle przyczepił się za Javę w Androidzie.
Nawet najlepszy pomysł nie jest nic wart jeśli nie jest zrealizowany. Na spotkaniu @jarekr000000 podrzucił fajną rozkminę:

  • brakuje czegoś w języku - warto zrobić nowy język
  • brakuje czegoś w systemie operacyjnym, żeby ten język działał dobrze - warto zrobić nowy system,
  • brakuje czegoś w architekturze (np. x64), żeby ten system działał dobrze - wart zrobić nową.

Efekt rozkmin? Na razie to AMD i Intel trzepią kasę na sprzęcie pod kiepską architekturę.
Można jeszcze posiłkować się tabelkami w stylu porównania języków:
https://rosettacode.org/wiki/Language_Comparison_Table

2

Co spełnia punkty o wieloplatformowości?
Np, Electron i React.

czasami szewc bez butów chodzi. Np. wiele osób używa z powodzeniem Reacta, a Facebook też go używa (w końcu sami go wymyślili), ale chyba jakoś nie do końca im się to udaje, bo strona FB coraz bardziej zamula (ale ponoć mają ileś tysięcy komponentów narobione). A przecież React to taki dobry framework i tak bardzo niby wydajny...

No ale technologia to nie wszystko. Kobyła będzie kobyłą.

Co do Electrona, to nie jest to najszybsza technologia - ale też mamy podobny schemat - Atom (na potrzeby którego został w ogóle wymyślony Electron!) zamulał strasznie (z tego co pamiętam, bo nie korzystam już), a jednak Microsoftowi udało się zrobić swój edytor VS Code, który też jest w Electronie, ale działa szybciej niż Atom (chociaz też nie jest to demon prędkości, ale mimo wszystko - ta sama technologia, a różne podejścia = różny efekt. I twórcy danej technologii nie zawsze potrafią zrobić dobre aplikacje w niej, nawet jeśli technologia jest dobra*).

Dlatego nie ma co zwalać wszystkiego na technologie, skoro można wziąć technologię "dobrą" czy "złą" i zrobić dobre albo złe rzeczy, niezależnie od technologii. Design, filozofia programowania, umiejętność optymalizacji, ogólna sprawność techniczna programistów, czy poza techniczne rzeczy (np. dobre/złe zarządzanie projektem) itp. To wszystko będzie mieć znaczenie.

*może też chodzi o to, że stworzenie dobrego narzędzia (np. biblioteki, frameworka, silnika, środowiska uruchomieniowego, bazy danych, języka programowania itp.) wymaga trochę innego zestawu umiejętności niż zrobienie dobrej aplikacji, która z tego narzędzia korzysta?

1

Design, filozofia programowania, umiejętność optymalizacji, ogólna sprawność techniczna programistów, czy poza techniczne rzeczy (np. dobre/złe zarządzanie projektem) itp. To wszystko będzie mieć znaczenie.

Masz duzo racji, ale jednak język ma znaczenie. W Kotlinie na przykład by default pisze się val czyli referencje dla obiekt jest stała. W Javie da sie się pisać final przed nazwą zmiennej, i efekt jest ten sam, ale to jest bardziej męczące przez co ludzie zapominają, Tak samo w Kotlinie klasy są by default zamknięte na dziedziczenie, żeby można było po nich dziedziczyć trzeba je otwierać. W Javie jest odwrotnie.
No o tym że w Kotlin i zdaje się Scala 3.0 są null safe to nawet nie wspomnę.

0

Odpowiadając na pytanie, na podstawie wymagań projektu, oraz możliwości jakie posiada firma oraz zespół. Jeśli masz programistów pythona i chcesz potrzebny jest crm, który łatwiej byłby napisać w php to python w tym przypadku będzie lepszy, bo skoro firma ma programistów pythona to w ten sposób nie poniesie jakiegoś rażącego kosztu.

Jak co projekt miałbyś robić zróżnicowane projekty wtedy lepiej jest wybrać trudniejszy język, który zwróci się dzięki dostępowi do poteżniejszej platformy, czy jakiś złożonych bibliotek.

Jak co projekt trzaskasz mniej więcej to samo to wtedy lepiej jest wybrać najsłabszy język, który pozwoli spełnić wymagania projektów, a który jednoczesnie pozwoli Ci pisać względnie prosty i przewidywalny kod - wtedy ta różnica (pomiędzy złożonym językiem, a banalnym) pozwoli Ci oferować klientom konkurencyjne ceny.

0
Aleksander32 napisał(a):

Masz duzo racji, ale jednak język ma znaczenie. W Kotlinie na przykład by default pisze się val czyli referencje dla obiekt jest stała. W Javie da sie się pisać final przed nazwą zmiennej, i efekt jest ten sam, ale to jest bardziej męczące przez co ludzie zapominają, Tak samo w Kotlinie klasy są by default zamknięte na dziedziczenie, żeby można było po nich dziedziczyć trzeba je otwierać. W Javie jest odwrotnie.

Po to jest porządne IDE żeby sobie poustawiać to i owo

Na przykład
Auto-add the "final" modifier to newly declared variables/values
https://intellij-support.jetbrains.com/hc/en-us/community/posts/206185619-Auto-add-the-final-modifier-to-newly-declared-variables-values

Można sobie poustawiać Code Templates jak się lubi, domyślnie final, wolne linie odstępu, wąsate nawiasy - gdzie idzie pierwszy itd

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