no... co se dá dělat... já se taky v mládí učil basic a připadal mi rychlej...
Pokud je nasazen na odpovídající aplikaci, jistě je to ulehčení, než to mastit v C.
Snahy dostat do pythonu obsluhu něco rychlého - nedejbože se pak snažit o něco realtimového (pyaudio, pygame, numpy... apod.) mi připadají dost morbidní.
Viděls někdy zdrojové kódy NumPy? Výpočetně náročné části jsou v C, malé části ve Fortranu a Python je tam pak jen wrapper. Zrovna použití Pythonu jako lepidla pro výpočetní knihovny v něčem rychlém mi přijde že do kategorie „odpovídající aplikace“ docela spadá.
Není to nepodobné kombinace enginu v C++ a skriptování ve vyšším jazyku u her a ppodobně.
S tím, zda je dotyčný podporovatel, to pokud vím nesouvisí. Je to tak, že přihlášený uživatel má nějakou auru. A podle té aury se počítá počet „palců“, které dává – uživatelé s nízkou aurou tedy dávají vždy jeden palec nahoru nebo dolů, uživatelé s vyšší aurou dávají tři palce a uživatelé s ještě vyšší pět palců. Dál už to asi neroste.
Zdrojáky jsem viděl. Než používat python jako lepidlo (velmi výstižné), tak už si to v C domastím celé.
Neber to jako pomluvu - holt jsem stará škola vychovaná ZX spectrem a vše navíc je tedy zbytečné.
Python je super na vše možné, ubastlím s ním bravurně "rychloscript", ale RT nemá co dělat.
Popravdě, použití numpy na RT jsem ještě neviděla a smysl to tam fakt nemá, mluvila jsem o numpy jako takovém. Přičemž na nějaké výpočty jako alternativa k věcem jako Matlab, případně ve spojení s pandas na chroupání velkého množství dat to fakt smysl má, prostě kombinuje výkon a rychlost vývoje.
Pokud zůstanu u srovnání, napsat celou hru v C++ včetně skriptů jde taky, ale je to zbytečná komplikace na zbytečném místě kvůli výkonové optimalizaci někde kde není vůbec potřeba.
(btw, na ZX Spectru + jsem začala)
Pythonu jste asi nikdy pořádně nerozuměl. Ano, hlavní implementace Pythonu (CPython) má GIL která neumožňuje souběžný běh threadů, ale python samozřejmě má multiprocessing (více procesů paralelně) a další pokročilé concurrency modely včetně několika různých abstrakcí (concurrent, multiprocessing, threading, ...).
Tak to je hezké, ale skuteční tvrďáci to napíší pomocí děrných štítků a zmagnetizované jehly.
Každý nástroj je vhodný na něco trošku jiného a python rozhodně není nějaká hračka pouze pro rychloskripty (ale i v tom exceluje). Podívejte se kde všude se používá a pak se zamyslete jestli tomu nerozumíte vy a nebo všichni okolol
Uz vas tu vidim, ako kodite zlozite matematicke vypocty v C. Nazor ma kazdy svoj, ale podstatne je, ze si Python zvolili matematici a inzinieri, ktori ho vyuzivaju po celom svete. Radsej nech trva beh programu o niekolko hodin viac, akoby mal clovek stravit pisanim kodu niekolko dni navyse.
numpy je iba malicka cast, nad nim su postavene dalsie kniznice, ako napr. Pandas alebo Matplotlib.
> Uz vas tu vidim, ako kodite zlozite matematicke vypocty v C.
Přednášející na MKP nám vyprávěl, že psal program tuším pro válcování trubek (trubky jsou ohnuté a po válcování mají být rovné). Prvně to napsali v MATALBu (r), výpočet trval pár dní. Po přepsání do C několik málo hodin. Doufám, že to bude dostatečně složitý matematický výpočet, i když pravda, nešlo o python.
Ale o tom to prave je, v Matlabu si to odladili a vyzkouseli a pak to zoptimalizovali na rychlost, tak se to dela. Matlab je na prototyping, jde to snadno a rychle (vyvoj, ne vypocet). Jedna vec je neco vyvijet a druha nasazeni jednoucelove aplikace. Jinak Matlab (MATrix LABoratory) je samozrejme dobrej na maticove pocty a dalsi, takze zacit delat vyvoj (tj reseni technickeho problemu) je jednoduche, a podobne je na tom Python. Takze, ne vzdy jde o rychlost vypoctu, ale o nalezeni reseni celeho problemu. Jinak neverte vsemu co Vam rikaji prednasejici, my toho nakecame :-D A pro uplnost MKP nedela "slozity matematicky vypocet", dela naopak velke mnozstvi jednoduchych vypoctu.
Jasný, chtěl jsem tím říct, že Cčko má svoje místo, ať se to jeho odpůrcům líbí nebo ne. Nevěřím všemu, na druhou stranu od doby, co mi kamarád vyprávěl, jak si jeho spolužák nechal ufiknout článek prstu na Charpyho kladivu... No, nenechám se snadno překvapit. Ten cca jeden řád mi přijde uvěřitelný.
Jo, který problém počítač neřeší použitím "velkeho mnozstvi jednoduchych vypoctu"? Žil jsem v domnění, že počítač a) umí rychle sčítat; b) umí převádět jiné problémy na sčítání; c) dělá doslova jen a pouze to, co se mu řekne.
Tak to jsi žil ve špatném domění: https://www.element14.com/community/servlet/JiveServlet/previewBody/41836-102-1-229511/ARM.Reference_Manual.pdf
Pobavilo :) Smutné to začne být ve chvíli, kdy člověk na podobné programátory naráží v praxi. Proč by se učili něco nového, když pracují 20 stejně a rozhodně na tom nehodlají nic měnit. K čemu jsou novější nebo specializované jazyky, když se to dá za několikanásobnou dobu nabastlit v C? K čemu verzovací systémy, když si můžu udělat každý den snapshot zdrojáků a zazipovaný uložit na lokální disk? Bohužel na takové se u nás naráží až příliš často.
Jinak nemám nic proti C, ale vytáčí mě argumenty typu, před 20 lety to nebylo potřeba, tak je to špatně. To můžem zahodit auta, protože dřív se bez nich lidi taky obešli.
C je pomerně rychlý a má dobrou podporu matematických funkcí (ne ve všech jazicích jsou komplexní čísla), gcc je snad ve všech distribucích ... Není mnoho důvodů učit se další jazyk včetně všech vstupů/vístupů (použití X11 ,syscallů ,stdio.h asi bude mimo C problém)
A taky jsem začínal v Basicu na Didaktik-m (v roce 2010)
TIOBE index neni zebricek pouzivanosti programovacich jazyku.
Nikdo si neda ani tu nejmensi praci zjistit si pouzitou metodiku a zbytecne pak rozviji plane debaty.
1. Diky Petr Krcmar za zpravicku
2. Diky pajac za odkaz, takze co se tyce metodiky - vypada to celkem lacine (dal jsem si tu nejmensi praci to projit).
"The ratings are calculated by counting hits of the most popular search engines. "
Prehled ruznych metodik a jedna jina metodika pro srovnani:
https://stackify.com/popular-programming-languages-2018/
https://www.codingdojo.com/blog/7-most-in-demand-programming-languages-of-2018/
3. Plane debaty se tu hodne odvijeji (rekl bych) od boje o vlastni ego, ne tolik o fakta ze zpravicky. Ke schopnosti uznat svou nedostatecnost ale clovek musi dozrat, priklady numpy, opencv ho nedonutis...
Je zbytecne se akademicky dohadovat, ktery programovaci jazyk je nejlepsi, jedine co se pocita jsou vysledky. https://codefights.net/ :-)