to snad nemyslíš vážně, je sice pravda že má C a java "podobnou" syntaxy, ale pro efektivní využití každého jazyka je třeba úplně jiný způsob myšlení, Já když píšu v C a píšu toho v C opravdu hodně, poslední dobou nečekaně i pro databázové aplikace, tak mám při psaní neustále v mysli obraz konkrétní vnitřní reprezentace dat se kterými pracuji, bez toho nemá smysl v C vůbec psát, často se ti podaří využít jedno vykonání jedné operace k více účelům součastně a z kontextu víš kde má a kde nemá cenu dělat kontroly, například zda nelezeš z pole, což ti kód v javě v konečném důsledku dělá furt, zatím co Java je ideální pro abstraktní přístup a línější programování ;-)
Jsem ochotný připtustit že průměrný programátor v Javě, napíše stejně efektivní kód jako průměrný programátor v C, kazdý z těch programů bude fungobat úplně jinak i přesto, že budou dělat totéž a stejně efektivně. Ale trvám na tom, že dobrý programátor v C napíše řádově efektivnější kód než ten nejlepší programágor v Javě, a pokud vše správně pokryje testama a nebude mu nějaký manager optimalizovat dojivost tak bude ten výsledek v C i daleko spolehlivjejší, třeba už jen proto že bude závislý na méně subdodavatelých :-) i když zrovna v případě Androidu je tento argument směšný :-)
IMHO ta komerční "porovnání" mi připadají určena pro NEprogramující managment :-)
A přenos mezi procesory, se stejnou šíří zběrnice s ideální efekivitou, ti na úrovni zdrojů, zajistí správné nastavení překladače.
Dalo by se říct že Java je výborná k tomu, aby produkty neschopných programátorů byli použitelné ;-) Nejvíc mě baví sledovat jak všude cpou ORM a pak se diví jak je databáze pomalá :-D
To jsou komedialni kecy.
Psat DB aplikaci v C, to uz chce opravdoveho cloveka, co neni schopen se podivat po cemkoliv jinem...
V jave, ve Spring Boot ti napisu DB aplikaci s REST rozhranim za dopoledne, co si ani nestihnes rozplanovat praci v C... A samozrejme s vyuzitim ORM, konkretne ja pouzivam Hibernate s nativnimi SQL dotazy, na DB independence si nehraju. ORM znamena Object Relational Mapping - JSQL opravdu neni povinne. A odpadne ten nebetycny opruz pri praci s jednotlivymi columny resultsetu.
V hibernatu napisu nativni sql dotaz select id, name, surname from XXX where .... a vysledek je set naplnenych java beanu. A primo ten set se oanotuje @RestService a je to vystavene na rest api. Cela aplikace bez logiky zpracovani dat na baj voko 100 radek kodu - pokud staci default konfigurace spring boot a ta obvykle staci.
Primo v spring bootu zadratovany caching engine, pomoci ktereho se nacachuji casto pouzivane DB dotazy a selecty se znova neprovadeji - opet plne automaticke, staci zapnout podporu anotaci @Cacheable a casto pouzivane dotazy se vubec nebudou posilat do DB ale vysledek to vyplivne z cache.
A samozrejme DB konektivita pres connection pool, ktery reusuje connections a zabranuje pomalemu a drahemu navazovani spojeni - opet funguje out of box.
Na ten REST se posadi angular, pripadne se beany pouzijou jako backing beans pro primefaces a luxusni GUI je na svete.
V mavenu target na spring boot JAR, ktery je mozno spoustet z ruky (embedded Tomcat na RESTy included), pripadne jak lezi a bezi pouzit jako LSB compliant init.d service (podporuje star/stop/restart) nebo systemd servicu.
Nebo si nastavim target do WARu.
JUnit testy v zakladnim baliku, stejne tak Mockito testy.
Babrat se v databazich za pomoci C muze dneska jenom clovek, co nema tuseni o novych vecech.
Ve spring boot to same napises za zlomek casu a bude to robustnejsi, rychlejsi a spravovatelnejsi.
33 Odpovědí
8411 Zhlédnutí