Wpis z mikrobloga

rzucić cpp i iść jak reszta na pythona


@kacpervfr: śmiało, zrobisz mi więcej miejsca na rynku pracy. Ogólnie niech ludzie nie dotykają żadnych system development langs i mówią że w embedded nie ma kasy to będzie się lepiej pracowało
@kacpervfr: C++ to język, przy którym jak wydaje ci się, że go zaczynasz rozumieć, to okazuje się że jest jeszcze miliard rzeczy, których nie wiesz, dodatkowo jak się go uczy na studiach, to zazwyczaj nie ma żadnych bibliotek typu Boost i trzeba pisać w jakimś pokracznym mixie C i C++ jak się chce np. sieciowe rzeczy pisać

odkąd poznałem Rusta to szczerze mu kibicuję, żeby tego starego dziada, którym jest C++
to co napiszesz w Pythonie będzie się liczyć 2h, a to, co napiszesz w C++ 10 minut. Albo nawet 10 sekund. :P


@Krolik: to taka teoria powtarzana na studiach, w rzeczywistosci w 99% przypadkow kod rzadko kiedy liczy cos dluzej niz pare minut, owszej cpp jest szybszy, ale w rzeczywiscie malo kiedy to wykorzystujesz, natomiast szybkosc pisania w pythonie daje efekty od reki (np. szybkie automotyzowanie pewnych zadan w pracy)

przyklady
@spidero: to nie jest żadna teoria powtarzana na studiach, tylko surowa rzeczywistość.

- automatyzacja zadan generowania konfiguracji do systemu robienie backupow


To są jakieś popierdółki, które można napisać w czymkolwiek. Więcej czasu zejdzie na dogadanie co trzeba zrobić niż na kodowanie.

napisalem w kilka godzin, nie mam pojecia ile dni by mi to zajelo w cpp,


Bo nie znasz cpp. Analogiczna sytuacja wystąpiłaby u kogoś kto zna cpp a nie zna
A on na to, że owszem 3-5 sekund na jedno wywołanie, ale oni w swoich skryptach testowych wywołują je łącznie kilka tys. razy i robią się z tego już godziny.


@Krolik: ok to tej skali jak najbardziej

ogolnie pod wzgledem utrzymania (zwlaszcza prod) tez zawsze wybiore binarke nad jara czy jakikolwiek jezyk skryptowy

pamietam sytuacje gdzie mielismy dwa serwery z przecietnymi zasobami (10lat temu ok 8G ramu) w HA z apka
@vytah: jakbyś nie zauważył to mój komentarz był odpowiedzią na taki sam komentarz jak Twój, który ktoś napisał wcześniej.

Zjawisko że w Pythonie pisze się szybciej niż w C++ dotyczy tylko bardzo małych projektów. #!$%@?ąc od kwestii bibliotek (bo zawsze może się zdarzyć sytuacja że masz w jednym języku bibliotekę której nie masz w drugim) to obydwa te języki są na podobnym poziomie abstrakcji i mają zbliżona ekspresywność.
via Wykop Mobilny (Android)
  • 1
@Krolik: mają zbliżona ekspresywność

Hehe he, piszę na codzień w obu i nie zgodzę się.

Chociażby takie pierdóły jak głupi timestamp w ms

Python:
Import time
time.time() * 1000

Cpp:
#include
std::chrono::durationcast(std::chrono::systemclock::now().timesinceepoch()).count();

Zbliżona ekspresywność XD żeby nie było, lubię cpp i od niego zaczynałem, ale jak widzę takie głupotki to kisnę.
@b0vv3r: ja paradoksalnie wolę to drugie, bo mnie dupsko boli, gdy jest jakaś metoda z czasem i trzeba patrzeć do dokumentacji czy to sekundy, milisekundy czy czas uniksowy

EDIT: no i właśnie dokładasz kolejne metody(time_since_epoch) żeby się pozbyć jednostki, a mógbyś normalnie trzymać w time_point z jednostką
@b0vv3r: ale wiesz, że jak się upierasz przy gorszym rozwiązaniu, to masz funkcję time() w time.h, która zwraca dokładnie to samo co w Pythonie i jest tak samo zwięzła?

Ta druga metoda jest jednak znacznie bardziej ekspresywna bo od razu masz podaną jednostkę czasu i co więcej system typów kontroluje zgodność jednostek - czyli wyraża znacznie więcej informacji niż tylko sama liczba. Dzięki temu taki kod szybciej się czyta, łatwiej zrozumieć
@b0vv3r: idealny przykład tego, co akurat w Pythonie jest słabe. Masz funkcje która spodziewa się czasu w minutach. W Pythonie napisałeś szybko, ale masz buga. W C++ musiałeś przekleić z stackoverflow ( ͡° ͜ʖ ͡°), ale za to masz błąd w czasie kompilacji.
@MamCieNaHita:
też wolę to drugie

@Krolik

ale wiesz, że jak się upierasz przy gorszym rozwiązaniu, to masz funkcję time() w time.h, która zwraca dokładnie to samo co w Pythonie i jest tak samo zwięzła?


To rozmawiamy o pisaniu w nowoczesnym cpp czy c :) BTW, use

A Ty specjalnie dodałeś kod, który tylko psuje i jeszcze używasz tego jako argumentu, że w C++ jest więcej kodu :D


Nie rozumiem co masz
@b0vv3r:

To rozmawiamy o pisaniu w nowoczesnym cpp czy c :)


Ale ctime / time.h jest częścią C++, a że odziedziczona z C, to co z tego. Nikt tego nie zabronił. :P

Nie rozumiem co masz na myśli.


Konwertując czas na liczbę utraciłeś informacje o jednostce czasu. Czyli celowo napisałeś dłuższy i równocześnie gorszy kod, żeby pokazać jakie to C++ rzekomo jest rozwlekłe. A tymczasem wystarczyło wywołać jedną funkcję dokładnie tak
via Wykop Mobilny (Android)
  • 0
@Krolik: True, ale tak jak mówiłem, to usecase z którym miałem do czynienia ostatnio, a wartość timestampu wpisywałem do protobowego uint64 więc był mi niepotrzebny.

Z kolei Ty założyłeś, że zrobiłem to celowo, bo argument xD

Skoro tak cpp jest prosty semantycznie to mi napisz jak obciąć whitespaces, trailing newlines z std::string standardowa biblioteką, czekam xD
@b0vv3r: Widzisz, ja pisałem o języku a Ty piszesz o bibliotekach. Nie wiem, nie siedzę w C++ od lat, natomiast zdaje się że boost::trim robi dokładnie to czego potrzebujesz, w Rust też są funkcje do tego.

Zresztą to czy jest jakaś funkcja w bibliotece standardowej czy nie, to nie świadczy o ekspresywności języka. O ekspresywności swiadczy to czy da się taką funkcję napisać.
@Krolik: Widzisz, ja z kolei siedzę mniej lub bardziej w c/cpp ostatnie 8 lat i jednak ten kod w cpp zawsze jest większy. No, ale let's agree to disagree :)

BTW w czym teraz piszesz? Może rust?
Ja zmieniam firmę za kilka tygodni i przesiadam się na golanga.
@b0vv3r: Rust. Zdecydowanie polecam. Jeśli choć trochę znasz C++, to Rust opanujesz szybko. Golang oczywiście jeszcze szybciej, ale wg mnie to Golang bardziej gra w tej samej lidze co Java/C#, natomiast Rust to bardziej takie C++ bez tych wszystkich złych rzeczy w C++.
@Krolik: wiem, znam Rusta, mam jedną aplikację w projekcie aktualnym w nim napisaną i mi się spodobał. Szukałem ofert z rustem ale bieda jest na razie. Well, może kiedyś.