Názory k článku Postavte si vlastní lehké IDE z textového editoru a shellu
-
> Pokud ale člověk pracuje se stovkami či tisícovkami tříd
... tak by sa mal zamyslieť nad projektom na ktorom pracuje.
To je ako čínština. Načo zjednodušiť písaný jazyk na nejakých 30 znakov, keď stačí poznať 3000 - 4000 symbolov... no a tiež sa to dá čítať / písať / programovať.
@smart: máte v hlave a/alebo v IDEčku stovky až tisícky tried. Ste borec, ste frajer. Job máte istý až do... konca. "Made in China" smart.
-
Spíše je snaha o to projekty rozdělit na komponenty. Projekt ať má klidně 100000 tříd, ale ta část, na které člověk pracuje, kterou čte a kterou kompiluje, by měla být malá.
Knihovny, moduly, package, to všechno je tu drahně let a slouží i k tomu, aby člověk pracoval na rozumně velkém projektu i ve chvíli, kdy výsledkem je projekt velký. Proto si myslím, že potřebovat "stovky či tisíce tříd" bude vzácný požadavek.
-
Myslim ze tento boj uz vyhralo Visual Studio, mam pocit ze 2/3 programatorov pouziva prave toto riesenie, zbytok je rozdeleny medzi vsetko ostatne. Mne sa tiez paci VS len je to taky klasicky produkt MS, obcas prestane z nicoho nic fungovat a potrebuje najlepsie reinstall a potom chvilku znovu poslucha. Sam casto pouzivam Textadept hlavne na jednoduche veci.
-
S eclipse jsem experimentoval tak před 15 lety a dodnes je to nezapomenutelně děsivý zážitek. Druhý pokus cca v polovině toho období, když to rozhodli v rámci jednoho hw vývoje, po týdnu jsem odešel. Nechápu, ale obdivuju, jak to někdo může používat k práci a mít nějaké nezanedbatelné výsledky. Evidentně je nějaká menšina, které ta věc připadá přehledná a intuitivní... taky děsivé :)
-
Pro vlastní projekty používám většinou VScode a vyhýbám se NodeJS/npm jak jen to jde. Transpilace SASS->CSS jde jednoduše přes shell script, používám Dart Sass (jeden spustitelný soubor), který je asi 10x rychlejší než Sass v NPM, Dart Sass umí i "watch mode" atd. Stejně tak se dá postupovat při transpilaci TS->JS, kde se dá použít Esbuild nebo Bun apod. To jen jako příklad toho, jak jde věci dělat efektivně a přímo, pokud je projekt malý a přehledný.
-
Zalezi ci editor dokaze pouzivat Language Server Protocol (LSP) https://en.wikipedia.org/wiki/Language_Server_Protocol
-
Přesně, linting a intellisense potřebuje podporu přímo v editoru. Intellisense jednoznačně, včetně "go to definition". Výstup linteru také chci vidět přímo v kódu.
Ale to VSCode má v zásadě zmáklé dost dobře.
To řešení o kterým píšu se hodí na to, co chceš dělat poté, kdy upravíš zdrojový kód a očekáváš, že jsi dokončil nějaký díl práce. Takže chceš zkompilovat program, spustit testy (a ne všechny testy, ale jen testy toho, co jsi upravoval), zobrazit výstup v prohlížečí, převést markdown do pdf a podívat se jak to vypadá, ....
Většina všech různých nástrojů se dá spustit z terminálu, třeba i PHP frameworky mají často nějaké cli utility, které pomáhají práci s projektem.
A některá rozšiření do vscode na pozadí volají právě tyhle externí programy.
Někdy je lepší použít integrované, zadrátované řešení, někdy je ale lepší si to spustit v tom shellu.
-
Jenomže, ono je to vlastně obráceně. Právě ta programátorská IDE umí to co požadováno, že v nich lze nakonfigurovat volání externího příkazu překladače. Ovšem, s tou výhodou, že z něj načtou zpátky i výstup a zobrazí ve svém oknu. To se týká jak výsledku předkladu, tak ale hlavně výpisy chyb a warningů, které lze pak hned v tom ide opravovat.
Aby se to vypsalo do terminálu a pak se člověk musel pokaždé přepínat, to asi není moc výhodné.''
Ovšem a navíc je tam problém s vypsanými čísly řádků, ve kterých ta chyba ve zdrojovém souboru je.
Některé ty jednoduché textové editory neumí číslovat řádky vůbec. Ale pokud to umí - tak nékdy nerozeznají že je v tom zdrojovém kódu includovaný jiný soubor. Takže pak je ve výpise po překladu zobrazované číslo řádku s chybou naprostý nesmysl.
Ergo, volání shellu je sice dobré pro spoustu věci, ale zrovna pro psaní programů asi ne,. Leda by se našel takový programátor, který by je dokázal psát naprosto bez jakýkoliv chyb... -
RaviseStříbrný podporovatel
Navíc se z představeného IDE vytratila ta integrace - když spustím linter, chci se z konzole prokliknout přímo na to problémové místo v kódu. A třeba ani konzoli vůbec neuvidím, protože linter je tak dobře integrován, že mi zdroják podtrhá a vybarví podle pokynů linteru samo IDE.
-
Článek se blbě čte a jeho obsah či sdělení je zvláštní. Lehké IDE tedy znamená, že po uložení souboru se spustí skript? Nebo jak to mám chápat?
Navíc autorův VSC plugin je "strašně užitečný". K čemu mi je po uložení spouštět play.sh? Bez pluginu stisknu F5 a program se mi spustí s debuggerem. Když chci něco navíc, tak v souboru "launch.json" si nadefinuji vše potřebné (klidně i to spuštění play.sh) v "preLaunchTask".
-
Tak možná pro jazyky co neznám toprý. Mám kliku, že mám IDE, kde v půce příkazu mi to doplní vč includovaných unit a modulů, stejně tak rozvine třídu za těčkou, poradí, kolik parametrů (a jaké) za závorkou právě rozepsané funkce/metody apod. Nemluvě o krokování, watcher, kompilační warningy na čísla řádků apod :-p
-
Dobrý den,
Trochu podezřívám redakci, že článek zaslaný k publikaci na 1.4. chybně vyhodnotila a zařadila normálně do fronty... a vyšlo to o devět dní později.
Jinak sám (hobby) programuji zásadně Emacs + terminál v podstatě jak je to naznačené v článku. Má to svoje důvody. V první polovině devadesátek jsem byl na střední postižen Borland Pascalem (Dos na 286) jakožto mým druhým jazykem po basicu (ZX spectrum a DidaktikM). A tam bylo IDE velmi pokročilé, velmi skvělé (BP tuším 6+). Ale mělo to svou velmi stinnou stránku. Totálně jsem byl díky tomu odstřižen od příkazové řádky a naprosto jsem nechápal co se děje na pozadí. Byla to pro mě černá skříňka. Až pak na vysoké, když jsem začal dělat numerickou matematiku a přešel jsem nejdříve na Frotran77 a pak na C a hlavně na unix (protože MS nedokázal nikdy ustát úlohu co měla běžet cca 72 h na plné CPU + odkládání na disk aniž by Win9x spadly - unix byl svou stabilitou pro mě zjevení a Linux ještě víc), tak jsem postupně začal chápat souvislosti.
Od té doby jsem zastáncem minimalismu. Editor co je editor a pomáhá jen trochu ... no alespoň vybarvuje a čísluje řádky a sloupce. Ale hlavně je to plnohodnotný editor co umí vyhledávat, kopírovat, nahrazovat... Make (nebo jiný buildovací systém) co si člověk nakonfiguruje a ví co to dělá. Případně obslužné scripty okolo. Když RAD pro GUI, tak externí co zase vyplivne nejlépe XML, nebo jazykový kód. Prostě proto abych chápal co dělám, byl schopen si kód případně přiohnout a byl schopen identifikovat chybu a řešit ji. Debugér také externí. Ne aby to bylo začarované někde v IDE knihovnách a compilér + OS specific nastavení co ani není zdokumentované nebo bůh ví kde. Případně po pár letech, co se nástroj chytí a rozšíří, tak ho firma zpoplatní, nebo někomu prodá (nejlépe MS, nebo IBM) a ten to zařízne, pře**ví, nebo pekelně zpoplatní - případ většiny RAD a IDE co za něco stály a byly ještě snesitelně průhledné a jednoduché dle mého názoru...
Ale naprosto chápu, že to je přístup malého amatéra co dělá na drobnějších věcech o pár desítkách tisíc řádků kódu max. a má čas se s tím mazlit. Zatímco profík v korporátu má nadiktované téměř vše a když někde něco nefunguje, tak (nejspíše) má sepsat report na definovaném formuláři a za nějakou dobu to (možná) začne fungovat (nebo také ne). A nic víc s tím udělat nemůže a ani nemá motivaci a čas se snažit chápat věci na pozadí protože je v úkolu...
-
Jen kousejte:-) Proti vztekline jsem ockovany :-) Brnenska IBM byla vzdy trochu "alternativni" pobocka. Nekteri manazeri meli zustat u suplery, hrideli, CNC a necpat se do velkeho IT. Musel jsem rypat.
Kdyz mate resit po kazdem update toolu ze vam stoji team tyden nebo nefunguje vcs. Presto ze jine tymy si pouzivaly sve tooly a jina IDE. A exkrementomet egit plugin ... o tom bych mohl vypravet. Prakticky reimplementace gitu v jave. Vyreseno presunem na ClearCase. A frk resime mvfs jaderny modul.
-
Patřím do podobné kategorie jako autor. Jako IDE používám celý OS. Příkazové řádky se nebojím a střídavě používám s okýnkami podle toho, co je pohodlnější.
Pro jeden projekt v Javě používám NetBeans.
Pro jiný projekt v C# musím používat VisualStudio.VisualStudio má integrovaný verzování, ale ani já (lunuxák), ani kolegové (windowsáci) to nikdo nepoužívá. V NetBeans jsem to ani nezkoušel hledat a používám kombo gitg plus CLI.
Nějaká integrace mě nechává chladným. Co mě přijde zajímavé je refactoring. Hromadné přejmenování symbolů je super. Jinak mě na tom nic neláká. Používám je nerad a jen když musím.
VisualCode jsem zkoušel, ale trpí stejnými problémy jako plnotučná IDE, že je to ucourané. Občas jsem ho použíl na Windows v projektu v Rustu, protože tam byl lepší proklik na definici.
-
Nejlepší editor je vim, používám ho zhruba někdy od roku 1995 a ať jsem zkoušel co jsem zkoušel, neexistuje nic lepšího. Jeho výhoda je mimořádná přizpůsobitelnost, kdy rutinní úlohy dělá za mě. Můj konfigurační soubor má momentálně 76 kB a 2334 řádků, vylepšuji ho už od toho roku 95 a vylepšuji a přizpůsobuji si ho pořád.
