V jaké verzi Visual Studia vyvíjíte komerčně?

[anon]

Ad VIM vs VS. Mám jisté obavy, že ve VIMu vůbec nepůjde zrealizovat spousta věcí, které jsou ve VS samozřejmé a každodenní rutinou. Vývoj UI, generované třídy, např. entity framework, WS klient, rozumná práce se solution. Všechny ty graficko-interaktivní záležitosti, v jistých kruzích nepopulární zato efektivní "klikátka".

Tak "unixový" přístup je určitě značně rozdílný, takže oddělit vim od zbytku prostředí dost dobře nejde. Ona se klikátka ve většině případů (mezi něž návrh GUI asi nepatří) dají nahradit prográmkem/skriptem/doplňkem. Samozřejmě je otázka, jestli existuje dostatečné nástroje pro C#... ale v něm já moc nedělám.

[Reklama]

[Prasolizér]

Chvála Bohu, v žádné.

+1

Používám Netbeans (Java, C++, SQL…), což je svobodný software – jeho licence mě neomezuje v tom, k jakému účelu ho budu používat. I když budu ta největší korporace na světě, stále pro mne platí stejné podmínky.

Coz nemeni nic na tom, ze na C# je lepsi VS.

Probůh, k čemu C#? To bych už rovnou mohl používat jako OS windows 

 
Windows jako OS?
NEMOHL

U nás jsme měli programátora který dřív dělal v linux/ruby a přešel na widle/VS, pár měsíců potom začal chlastat a skončil. Bacha na to i takové případy jsou.

[Tomáš Roll]

U nás jsme měli programátora který dřív dělal v linux/ruby a přešel na widle/VS, pár měsíců potom začal chlastat a skončil. Bacha na to i takové případy jsou.

Práce se Visual Studiu není pro mamánky a slabochy. Jen pro správné chlapy.

[VS]

• netreba riesit synchronizaciu
• staci jedna instancia konkretnej reprezentacie pre celu aplikaciu
• je to bezpecne davat to aj do API alebo neznamym programatorom

Hlavne prvy bod vedie v dnesnej dobe, ked sa riesi paralelizacia.

Immutable je nové falešné náboženství slibující vyřešit všechny vaše problémy, podobně jako před lety náboženství OOP, jenže opět nevyřeší.
Immutable se náramně hodí na read-only sdílené data. V momentě kdy je třeba sdílené data modifikovat, je immutable ještě horší než tradiční synchronizace, při výměně instance za novou verzi vzniká špatně debugovatelný tradiční problém read-modify-write.
Na problém s paralelismem a API není immutable nutné, stejný efekt má prostá kopie objektu.

[Pan Jan]

Bože, to je zase debata. Kde jsou ty časy, kdy se k počítačům a programování dostali jen lidi s IQ > 130...

[Reklama]

[matfyzak11235]

• netreba riesit synchronizaciu
• staci jedna instancia konkretnej reprezentacie pre celu aplikaciu
• je to bezpecne davat to aj do API alebo neznamym programatorom

Hlavne prvy bod vedie v dnesnej dobe, ked sa riesi paralelizacia.

Immutable je nové falešné náboženství slibující vyřešit všechny vaše problémy, podobně jako před lety náboženství OOP, jenže opět nevyřeší.

Suhlas; ze vyriesi vsetky problemy som sa ani nesnazil tvrdit.

Immutable se náramně hodí na read-only sdílené data. V momentě kdy je třeba sdílené data modifikovat, je immutable ještě horší než tradiční synchronizace, při výměně instance za novou verzi vzniká špatně debugovatelný tradiční problém read-modify-write.

Ako casto je treba mat modifikovatelne zdielane data mimo I/O? Teda v Jave a Swingu so swingbindingom to treba je, ale Haskellisti so svojimi pure funkciami by skor nesuhlasili.

Na problém s paralelismem a API není immutable nutné, stejný efekt má prostá kopie objektu.

To som pisal v minulom prispevku, ze sa uklonujes k smrti. Tak je navrhnuty aj "vyborny" java.util.Date. Ked chcem API s datumami a nechcem si tahat ako zavislost Joda time, tak musim kazdy Date "z vonku" naklonovat. Rovnako to plati aj u Date posielaneho von, ak je to sucast mojho stavu.
Je preto Date nejaky lepsi ohladne problemov s read-modify-write? Ja si myslim, ze nie, dokonca je aj preto horsi.

• netreba riesit synchronizaciu
• staci jedna instancia konkretnej reprezentacie pre celu aplikaciu
• je to bezpecne davat to aj do API alebo neznamym programatorom

Hlavne prvy bod vedie v dnesnej dobe, ked sa riesi paralelizacia.

Ja viem na co to je, ale 90% pripadov? Kolko % javistov niekedy riesila synchronizaciu, ked vacsina aj tak lepi servlety v springu, alebo apky v androide? Je to uzitocne, ale iba na velmi specificke pripady. Nie je to ani prirodzene v zmysle oop. Zober si instanciu cloveka. Chces povedat, ze pribral. Vytvoris kvoli tomu noveho cloveka s inou vahou?

Aj appky v Androide miestami potrebuju synchronizaciu. Preto si myslim, ze ju riesil kazdy, aj ked nie kazdy si to uvedomil - niekto nasekal race conditiony.
V Jave sa bezne novy clovek kvoli zmene nevytvori; v inych programovacich jazykoch ano. Myslim, ze je len otazkou casu, co sa aj Java posunie k niecomu funkcionalnejsiemu a bude sa tam bezne vytvarat iny clovek.

[VS]

Ako casto je treba mat modifikovatelne zdielane data mimo I/O?

Modifikovatelná sdílená data byla hlavní příčinou vzniku Immutable, hlavně neštěstí způsobené nekvalifikovanými programátory při přechodu na multithreading.

Ked chcem API s datumami ... tak musim kazdy Date ... naklonovat.

Proto ho s Immutable variantou Date naklonuješ pokaždé, ne jenom když si o to někdo požádá přes API

[matfyzak11235]

Modifikovatelná sdílená data byla hlavní příčinou vzniku Immutable, hlavně neštěstí způsobené nekvalifikovanými programátory při přechodu na multithreading.

Neviem, ci uz niekto rozmyslal nad multithreadingom v case vzniku jazykov ako Prolog. Z toho pristupu (a neskor z Haskellu) podla mna pochadza snaha mat immutable.

Ked chcem API s datumami ... tak musim kazdy Date ... naklonovat.

Proto ho s Immutable variantou Date naklonuješ pokaždé, ne jenom když si o to někdo požádá přes API

Preco by som to robil? Proste kludne pouzijem jeho instanciu (setter) alebo moju instanciu (getter). Je to vidiet na Stringoch, ktore su z principu immutable - este som nevidel program, ktory by pri vracani hodnoty ulozenej v Stringu volal nieco ako string.clone() - ani neviem, na co by to bolo dobre. Pri java.util.Date je to skoro povinnost.

[VS]

Neviem, ci uz niekto rozmyslal nad multithreadingom v case vzniku jazykov ako Prolog.

Před multithreadingem bylo v Javě s immutable ticho po pěšině.

Je to vidiet na Stringoch, ktore su z principu immutable

Ano je to tam krásně vidět, při změně jednoho znaku musíš celý string okopírovat a to je prakticky to samé jako klonování.

[perceptron]

a preto sa na interview hovori ze kto concatenuje stringy cez + je zver a ma pouzivat stringbuilder

[NooN]

Nie je zver, StringBuilder sa oplati az pri vacsich mnozstvach stringov. Rezia okolo nieco trva.

[matfyzak11235]

Je to vidiet na Stringoch, ktore su z principu immutable

Ano je to tam krásně vidět, při změně jednoho znaku musíš celý string okopírovat a to je prakticky to samé jako klonování.

Je rozdiel zmena a predavanie niekomu inemu. Zmeny sa deju vynimocne, predavanie je tu skoro stale.

Nie je zver, StringBuilder sa oplati az pri vacsich mnozstvach stringov. Rezia okolo nieco trva.

Co myslis, ako funguje to +?

Ked su to staticke stringy v kode:

Kód: [Vybrat]

String abc = "neco"+
                  "dlouhe";
tak tam si to spoji kompilator sam.

Inde su nasledujuce dve volania ekvivalentne:

Kód: [Vybrat]

String abc = a + b + c;
a

Kód: [Vybrat]

String abc = new StringBuffer(a).append(b).append(c).toString();

StringBuffer/StringBuilder je dobry v pripade, ze spajas viac Stringov postupne a kompilator z toho StringBufferu musi vzdy spravit String. Tam sa to kopiruje a je to pomale. Pri jednorazovom spojeni takto rozpisany StringBuffer iba komplikuje citanie programatorom.

[VS]

Je rozdiel zmena a predavanie niekomu inemu. Zmeny sa deju vynimocne, predavanie je tu skoro stale.

Pokud máš objekt kde změně dochází výjimečně, pak rozdíl asi nepochopíš.

kto concatenuje stringy cez + je zver a ma pouzivat stringbuilder

Přiměřený počet "+" je optimalizován překladačem na StringBuilder automaticky

[matfyzak11235]

Je rozdiel zmena a predavanie niekomu inemu. Zmeny sa deju vynimocne, predavanie je tu skoro stale.

Pokud máš objekt kde změně dochází výjimečně, pak rozdíl asi nepochopíš.

Podla mna je taky kazdy objekt. Vynimocne myslim v porovnani s predavanim objektu.

Zmena atributov nastane u objektu raz po nejakej akcii od uzivatela alebo po meniacom kroku v algoritme, potom dlho nic.  Volanie s objektom ako parametrom nastava pri skoro kazdej praci s objektom a to niekedy aj viackrat, lebo objekt moze putovat cez viacero funkcii.

[perceptron]

k stringbuilderu to vyzera tak ze tie optimalizacie su dost nepredvidatelne

http://www.code-thrill.com/2012/08/stringbuilder-optimizations-demystified.html

better safe than sorry ako vravi clanok

a premature optimization, evil, knuth atd

z toho vyplyva ze to v jave nie je stymi immutable take jasne