Marek
Guest
Mon Dec 08, 2025 1:45 pm
On Mon, 8 Dec 2025 10:00:26 +0100, "J.F"
<jfox_xnospamx@poczta.onet.pl> wrote:
Quote:
Czekamy na odcinek na Javie, JS, C#, Python.
Occam, Ada, Fortran, Cobol, PL/1 ...
W filmie @1:58:48 autor przedstawia wykres odnoszący się do tego.
--
Marek
heby
Guest
Mon Dec 08, 2025 1:45 pm
On 08/12/2025 11:55, Jacek Marcin Jaworski wrote:
Quote:
Czy coś takiego miałeś na myśli?
Coś w ten deseń.
Przy czym technika z ipp jest alternatywą, a nie koniecznością, jesli
używasz explicit instantiation.
Waldek Hebisch
Guest
Tue Dec 09, 2025 5:49 am
Marek <fake@fakeemail.com> wrote:
Quote:
On Sun, 7 Dec 2025 20:15:38 +0100, heby <heby@poczta.onet.pl> wrote:
Jakich chcesz dowodow i na co?
Dowodów w postaci zajebistego softu w ocenie końcowego użytkownika
softu. Mnie nie interesują programiści, jacy są i czy język jest
zajebisty bo umożliwia to czy tamto. Ja
chcę zachwycić się nad softem, który spełnia moje oczekiwania, jest
szybki (i mały objętościowo) i po prostu działa (najchętniej bez
ciągłej schizofrenicznej aktualizacji).
Soft może być mały tylko wtedy jak rozwiązuje prosty problem.
Jak chcesz przykład relatywnie małej rzeczy z szablonami to
możesz popatrzeć na biblitekę NTL. Jest szybka w sensie że
zrobienie czegoś co działa z porównywalną szybkością to dużo
roboty (z której większość to nie jest programowanie, po prostu
trzeba zrozumieć potrzebne algorytmy). Jest bibliteka w C
z podobnymi funkcjami (flint) i szybkością. flint zamiast
szablonów używa makra preprocesora C. Tak że w przypadku
NTL nie działa argument "nie da się zrobić w innym języku".
Ale to są małe rzeczy. Jak wejdziesz na 10 mln linii kodu,
to nawet jakby się dało zrobić w innym języku to nikt
nie będzie ryzykował konwersji C++ na powiedzmy C. Konwersje
z C na C++ są dość powszechne. heby może pisać że to daje
marny C++, ale główna motywacja takich kowersji to dostępność
w C++ mechanizmów których nie ma w C, a po konwersji używa
się tych mechanizmów.
Jak rozumiem projekt Carbon chce być "lepszym C++", w
szczególności chcą żeby kowersja z C++ na Carbon była
w dużym stopniu automatyczna. Ale jak/jeśli Carbon
stanie się poważną alternatywą dla C++ to większość
twojej krytyki powinna się dalej stosować, tzn.
udany nowy język będzie się mocno zmieniał, będzie
używany do dużych i trudnych projektów (czyli duży
kod wynikowy i duży czas wykonania). Zgodność z
C++ będzie powodowała komplikacje i nieoptymalną
semantykę (tak jak zgodność z C psuje C++).
Quote:
Niestety jak na razie ja
takowego nie widzę, a to co widzę to w ogromnej większości bloat
I/lub crap. Dlatego pytam. A zauważyłem dość ciekawą często (jak nie
zawsze) relacje, że jak syf to się okazuje napisany w C++.
Nie wiem na co typ patrzysz, ja widę sporo syfu, ale w różnych
językach. Powiedziałbym że PHP i JS przodują, Python z nimi
mocno konkuruje. C++ też, ale biorąc pod uwagę że soft w
C++ jest często używany, to propocja "złych" programów może
być dużo mniejsza.
Quote:
Wiec wybacz, ale na końcową ocenę użytkownika nie wypłynie
zajebistość C++ z pkt. widzenia programisty.
Punkt widzenia użytkownika to nie tylko ocena końcowego produktu
(efektu).
Przykład sprzed paru dni.
Mam klaster kilkunastu maszyn, które od 25 lat coś tam liczą. Do tego
liczenia nie potrzeba aktualizacji, zmian w sofcie. Liczy się tylko
liczenie i dostępność i od lat nie wolno tego ruszać. Ostatnio
chciałem coś przećwiczyć w llamie i wykorzystać klaster jedynie jako
bazę uruchomieniową bimarek bo tam jest dużo ram. Oczywiście trzeba
skompilować, ściągam patrzę w źródła "o ja pierdole C++ będzie cyrk".
I był, całkiem podobny jak w pythonie. Zaczynając od problemów z
kompilacją (nietypowe wymogi) a kończąc na problemach z uruchomieniem
(invalid instruction).
Tak wiem, tego typu problemy to nie wina C++ ale i tak niesmak
pozostaje.
Jeśli masz ten sam soft co 25 lat temu to nie myśl o kompilowaniu
współczesnych źródeł sciąganych z sieci. Nawet w C są nowe
konstrukcje i nikt nie będzie ich unikał. Przy tym jakieś 20
lat temu to faktycznie był z C++ problem, tzn. pod rząd pojawiało
się kilka wersji g++, każda niezgodna binarnie z poprzednią.
Na poziomie źródłowym też były zmiany i mogło się okazać że
programu w praktyce nie da się użyć bez dużego cyrku w stylu
nowych bibiotek + specjalnych scieżek dostępu by je użyć.
Ale to (chyba) mineło.
Ja mam sporo sympati do używania starego softu. Ale musisz
się liczyć z tym że rynek na wieloletnią zgodność wstecz
jest mały, jak chesz to dostać to musisz płacić naprawdę
dużo a towar będzie powiedzmy "niezupełnie świeży", tzn.
mogą być problemy które są rozwiązane w nowszym sofcie.
--
Waldek Hebisch
Jacek Marcin Jaworski
Guest
Tue Dec 09, 2025 7:45 am
W dniu 9.12.2025 o 04:49, Waldek Hebisch pisze:
Quote:
Soft może być mały tylko wtedy jak rozwiązuje prosty problem.
Nie tylko. Zgodnie z koncepcją Uniksa należy kodować proste prog., które
można używać razem z innymi prostymi prog. w celu realizacji złożonych
zad. Natomiast takie potwory jak bibl. Qt i Qt Creator są zaprzeczeniem
tych zasad. Dlatego ja postuluję by społeczność zrobiła rozwidlenie (w
j. ang. fork) proj. bibl. Qt i oczyściła ją z całego zbędnego syfu
(szczególnie ze szpiegującego SI). Piszę o tym w "7. Raport
Totaliztyczny: Sprawa Qt Group", dostępnym całkowicie za darmo na mojej
s. WWW:
<https://energokod.gda.pl/raporty-totaliztyczne/7.%20Sprawa%20Qt%20Group.pdf>
Co do Qt Creatora nie da się go naprawić, do uruchamiania ze śledzeniem
można by używać DDD, jednak nie da się w nim ustawiać punktów
wstrzymania (w j. breakpoint) z linii komend, a jest to konieczne gdy
chcesz wysterować go z własnego edytora programisty. Ta wada DDD jest
też zaprzeczeniem koncepcji prog. Uniksowych i jest to dla mnie
niezrozumiałe, bo jego koncepcja jest b. dobra.
--
Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska, EU;
tel.: +48-609-170-742, najlepiej w godz.: 5:15-5:55 lub 17:15-17:55;
<jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW: <https://energokod.gda.pl>;
Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.
heby
Guest
Tue Dec 09, 2025 3:47 pm
On 09/12/2025 04:49, Waldek Hebisch wrote:
Quote:
nie będzie ryzykował konwersji C++ na powiedzmy C. Konwersje
z C na C++ są dość powszechne. heby może pisać że to daje
marny C++
heby napisze, że daje znakomity C++. C to bardzo dobry C++, bo już
napisany i przetestowany, nie trzeba nic zmieniać ani o nic się martwić.
Inymi słowy, ważna jest ewolucja a nie rewolucja. Tym bardziej, że w
99.9% wypadkach polega na zamianie .c na .cpp i reszta dnia wolnego.