Wpis z mikrobloga

Podaję przepis na idealny język programowania ;) Sprawdził się u mnie (u Was nie musi, ofc)

1. Nauczcie się porządnie C razem z jego arytmetyką wskaźników. To jest proste. C jest bardzo prostym językiem.
2. Nauczcie się wybranych elementów C++: klasy (niekoniecznie dziedziczenie i przeciążanie operatorów), referencje, namespace'y, wątki i ich bezpieczeństwo, model pamięci.
3. Opanujcie wzorzec RAII i smart pointery
4. Nieobowiązkowo wyjątki - można żyć bez nich,
5. Podstawowe informacje o szablonach.
5. Cmake + jakiś framework do testów (może być Google Test)

Dodatkowo (niezależnie od C++):
6. Wzorce projektowe, algorytmy i struktury danych.
7. Nie stosujcie programowania obiektowego wtedy, gdy nie jest to uzasadnione. Czasem wystarczy zwykłe proceduralne. To, czy programowanie obiektowe jest uzasadnione, czy nie jest, niezwykle trudno stwierdzić. Najlepiej zatem: nie programujcie obiektowo! :)
8. Kod imperatywny zazwyczaj jest łatwiejszy do zrozumienia od deklaratywnego. Tu można się spierać.
9. Piszcie prosty, bezpieczny, wielowątkowy kod, który jest utrzymywalny i zrozumiały przez 70% programistów (nie tylko C++). Nie, Rust, to nie o Tobie :)
10. Profit.

#programowanie #programista15k #cpp #c++ #rust
  • 20
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

prosty, bezpieczny, wielowątkowy kod


@gacek_w: xDD


@zwei: Da się, ale z drugiej strony są lepsze języki do wielowątkowości jeżeli chcemy prosty, bezpieczny i wielowątkowy kod. C / C++ raczej służą optymalizacji, szybkości wykonania, a wtedy albo nie jest prosto, albo nie do końca bezpiecznie.
  • Odpowiedz
@gacek_w: kiedyś ci minie fascynacja/syndrom sztokholmski odnośnie C++.

Kod imperatywny zazwyczaj jest łatwiejszy do zrozumienia od deklaratywnego. Tu można się spierać.


@gacek_w: kod deklaratywny jest prostszy do analizy z definicji. W kodzie deklaratywnym nie masz kolejności wykonywania instrukcji i zrozumienie przepływu kodu polega na ciągłym przeglądaniu zależności, gdzie w paradygmacie imperatywnym masz to samo plus złożoność wynikacjąca z kolejności
  • Odpowiedz
  • 4
a to mi wyjaśnisz? Przecież na obiektach najprościej i najczytelniej nawet proste skrypty


@MilionoweMultikonto: Zła struktura kodu jest o wiele gorsza od braku struktury. Niezwykle trudno jest zaprojektować dobrą strukturę obiektów dla nietrywialnego problemu. Zazwyczaj kończy się to smutną, niepotrzebnie pokomplikowaną kulą błota. Mówię o dużych projektach, przy których pracuje wielu programistów.
Oczywiście jeśli pracujesz sam nad jakimś małym projektem, to może Ci się to udać. Ale i tak wymaga
  • Odpowiedz
  • 1
Człowieku, ja crudy w javie piszę.


@lycaon_pictus: Szczerze współczuję, serio. Ja 12 lat pisałem crudy w Javie. Co ciekawe jak się inteligentnych ludzi zmusza do takich rzeczy, to później powstają: fabryki fabryk abstrakcyjnych, deklaratywne, reaktywne streamy z map-reduce dla danych ze źródeł nierelacyjnych, itp. itd. A to wszystko dla problemów, które nie są bardziej skomplikowane od tych, które dzieci rozwiązują na lekcjach informatyki w szkole. Bez urazy, ofc.
  • Odpowiedz
@gacek_w: Ale czego tu współczuć? Ja cały czas się rozwijam technologicznie, a praca jest luźna i wygodna, a i jest nieźle płatna. Nie muszę budować rakiet kosmicznych, żeby być zadowolony.
  • Odpowiedz
Oczywiście jeśli pracujesz sam nad jakimś małym projektem, to może Ci się to udać. (...) "Get shit done"


@gacek_w: proponujesz podejście "yolo i do przodu" dla dużych projektów, dla których ciężko jest nawet stworzyć strukturę obiektową? Moim zdaniem to albo jesteś trolem, albo głupkiem, albo c---a się znasz.
  • Odpowiedz
  • 3
proponujesz podejście "yolo i do przodu" dla dużych projektów, dla których ciężko jest nawet stworzyć strukturę obiektową


@j557: Nie. Proponuję co najmniej 2x zastanowić się nad wyborem paradygmatu programowania. Tylko tyle. Na siłę wpychanie programowania obiektowego tam, gdzie lepiej sprawdzi się proceduralne nie ma sensu. To nie tylko moje zdanie.
A to, że większość wielkich projektów obiektowych kończy się big ball of mud, to niestety przykry fakt.
  • Odpowiedz
Często po prostu nie warto: lepiej po prostu usiąść i zacząć coś programować tak prosto, jak to możliwe.


@gacek_w: to jest dopiero świetny przepis na wielką kulę błota, i to od samego początku ( ͡° ͜ʖ ͡°)
  • Odpowiedz
  • 0
Często po prostu nie warto: lepiej po prostu usiąść i zacząć coś programować tak prosto, jak to możliwe.


@gacek_w: to jest dopiero świetny przepis na wielką kulę błota, i to od samego początku ( ͡° ͜ʖ ͡°)


@boryspo: Zwróć uwagę na wytłuszczony fragment mojego wpisu. Nie widzę tu przepisu na kulę błota. :)
  • Odpowiedz
@gacek_w: C++ mimo wydajności nie jest wzorem dobrego języka programowania. Jego kompatybilność wsteczna i późniejsze zmiany w koncepcji doprowadzają do powstawania legalnych składniowo potworków jak "C z plusem". Wspomniane szablony zostały zaprojektowane w najgorszy możliwy sposób. Kod w C++, czy C nie będzie bezpieczny, chyba, że stać cię na armię seniorów, którzy wiedzą, gdzie w tym języku są pułapki i mają dużo czasu na wydłubanie wydajnego kodu.
Często bardzo trudno
  • Odpowiedz