Dotaz: par dotazu k programingu na linuxu

[thomas]

zdravim, mrzi me ze nemohu dat presnejsi nadpis ale fakt mam vicero dotazu, snad je mohu vlozit naraz. Kdybyste meli cas a neobtezovala vas odpoved, tak dekuji moc

Nejdrive bych chtel rict ze o definitivnim prechod na linux teprv uvazuji, jinak mam zatim jen nekolika denni zkusenosti.

1)proc se lidi prou o to zda je lepsi emacs nebo vim (neznam je, jen ze screenshotu) to jsou tak stejny, ze se rika ze nema cenu se ptat co je lepsi?

2) v cem psat C/C++ ? Anjuta, Kdevelop, code::blocks bo mate neco jineho lepsiho, co vam vyhovuje ?

3) slyseli ste o projektu .MONO ? pry to buildne zdrojovy kod C# (.NET) na linuxove binarky. Dale sem slysel nekoho rikat ze .GNU portable NET je pry lepsi nez .MONO, co je na tom pravdy, co vyhovuje vam ?

4) nejdulezitejsi otazka. Rok jsem delal do win32 API, tam stacilo pridat windows.h a uz jste mohli pouzivat fce daneho OS, zajimalo by me jak zni, kde najdu (www stranky) API linuxu? taky staci pripojit hlavickovej soubor a pouzivat fce OS? Hlavne sem o nicem neslysel za ty leta, porad se jen sklonuje Qt nebo GTK+, zajima me tedy vse o nativnim vyvoji, dekuji

dekuji za vas cas

Odpovědi

[Luboš Doležel (Doli)]

1) Protože je to baví a protože je přece VIM lepší

2) Co chcete, já volím KDevelop nebo VIM

3) Nemám rád Mono.

4) Navrhoval bych si koupit nějakou knihu o programování na Linuxu od Computer Pressu. Je to na začátek pěkný úvod.

[thomas]

dekuji moc za odpoved, doufam ze se pohrnou i dalsi

[PMD]

1) Nevim, obojí bych bejt tebou obloukem obešel.

2) Z těch tří? Eclipse.

3) Slyšeli. Sice buildne C#, ale nebuildne .NET ;) ...většinou.

4) Linux nemá jedno API pro GUI. Můžeš si vybrat. Co se low-level systémového API týče (pokud máš namysli tohle), tak hledej glibc ;)

[Miška]

1) Proc se lidi prou jestli je lepsi Sparta, nebo Slavie? Oba to sou editory, ktery umej hodne veci navic. Kdyz se s nima clovek nauci, tak to casto velmi usnadnuje praci. Muze tak napriklad veskery vyvoj probihat aniz by clovek opustil editor. Kazdej z tech editoru ma trochu odlisnej pristup k uzivateli a jiny ovladani (zastance z jednoho tabora bude tvrdit ze ten druhej editor ho ma naprosto sileny )

2) Osobne pouzivam vim/gvim a popravde receno, s nicim jinym nemam zkusenosti.

3) Slysel, .NET me ale nezajima - kopie javy od M$ a ani ta puvodni me moc nenadchla...

4) Jaky funkce? Pokud se nepletu, tak na sit je treba jeste neco i na widlich. Qt/GTK se sklonuje, protoze to je o dost jednoduzsi zpusob jak psat GUI nez primo XWindow. Pravda je, ze Qt toho nabizi mnohem vic (s GTK tolik zkusenosti nemam, tak nevim). Co se dokumentace tyce, Qt ma snad nejlepsi dokumentaci, jakou sem kdy videl. http://doc.trolltech.com. Jinak ke spouste systemovejch funkci staci pouzit man

[ed]

1) neviem, preco, asi to bude nejaka geek blbina, alebo co ;) ja osobne nepouzivam ani jeden z nich, emacs neviem ovladat vobec a gvim len s pomocou menu ;) jakozto letity odchovanec MS-DOSu pouzivam mcedit.

2) Kdevelop / Eclipse ?

3) poculi, neskusali, ale zrejme kvoli skole sa o to budem musiet zaujimat.

4) nieco podobne je aj tu, akurat tych .h suborov je obvykle viac podla toho, ktore funkcie su potrebne, aby sa do projektu neincludovalo zbytocne vela smetia (zo skusenosti s Windows 3.11 a Borland C++ mi k parriadkovej aplikacii po prilinkovani windows.h nacapalo okolo 10 000 riadkov includov). Samotne jadro Linuxu neposkytuje ziadne graficke okenne funkcie, tie su od systemu oddelene a postytuju ich tzv. graficke toolkity (napriklad spominane GTK+ a Qt), kde obvykle tiez staci prilinkovat gtk/gtk.h, alebo qt/qt.h a sluzby daneho toolkitu su k dispozicii. Samozrejme pri linkovani programu netreba zabudnut program zlinkovat s danou kniznicou.

[Cubeekk]

Cus, 1) na pouzivani emacsu ma vetsina normalnich lidi malo prstu
2) nejlepsi mi prijde VIM, nebo Eclipse s CDT pluginem
3) mono je urcite zajimave, ale me prislo pri mych poslednich pokusech jeste celkem nestabilni (jinak u me teda 100% vede java pred c#
4) v linuxu je GUI API otazka volby (minimalne mez QT a GTK .. nic standartniho IMHO neni (kdyz nepocitam glibc, nebo krasne ncurses :) ))

[Miška]

Myslim ze existuje standartni - XWindow primo, jen v tom nikdo nepise

[regnarg]

1) schopnosti editorů jsou podobné, jde o zvyk uživatele

2) tato IDE se mi moc neosvědčila, upřednostňuji klasický postup — textový editor, komplilátor, linker, příp. make. Z propracovanějších editorů třeba Geany

3) mono je klon .net což je hloupý výmysl od M$, takže pokud opravdu požadujete takovéto prostředí, zkuste Javu, jinak doporučuji zůstat u C[++]

4) linux nemá jednotné API, to vyplývá z jeho filozofie. Pro GUI aplikace existují knihovy jako Gtk, Qt, wxWidgets, FLTK apod., osobně bych nejvíce doporučoval Gtk+ (příp. gtkmm pro C++), je to zcela svobodná GUI knihovna, má nejlepší podporu unicode a tím pádem i češtiny (tyto problémy zde defacto neexistují), vzhled lze libovolně měnit pomocí témat, má dobrou dokumentaci a GUI lze snadno vytvářet jako XML soubory pomocí Glade a dynamicky načítat za běhu aplikace, což např. usnadňuje překládání do jiných jazyků. A hlavně má Gtk přehledné a intuitivní API.

[ph0enix]

Add 1) Krome zvyku uzivatele bych zminil jeste vhodnost pouziti za danych podminek a dostupnost na cilovem systemu. Vi, ci nektery z jeho klonu najdete prakticky vsude, takze pokud budete nekdy muset neco delat napriklad na HP-UX ci jinem, neprilis v domacnostech rozsirenem systemu, a umite to s vi - urcite si vystacite. U Emacsu tomu tak neni. Stejne tak v pripade nutnosti editace vetsich souboru se vam muze stat, ze s Emacsem nepochodite. Jeden cas jsem pouzival stridave oba. Definitivnim impulzem k prechodu od Emacsu na Vi byly v mem pripade dve veci

• Nutnost editace dumpu databaze (> 100 MB) na vzdalenem stroji
• Zmena zamestnani diky ktere jsem se dostal i k jinym OS nez Linux ci *BSD - napriklad jiz zminovany HP-UX

Osobne bych seznameni se s editorem Vi bral jako dobrou investici do budoucna. Pokud tedy nezustanete u lokalni instalace Linuxu a GUI.

[cronin]

Vrelo Ti odporucam tuto tuto knihu, najdes v nej odpovede na mnohe svoje aj zatial nevypovedane otazky. Nicmenej, uz nazov tej knihy naznacuje, ze je odpovedou na Tvoj problem.

[thomas]

dekuju mockrat za vas cas, za vrele odpovedi, ale zase se stalo to co v jinych topicich hned klikate na hotovo :-P ja se potrebuju kvuli skole vice dozvedet o tom .MONO, pevne verim ze zde nekdo v tom dela a neco trochu vic rozepise, pls hodne moc

reakce :

Miska wrote:
> Pravda je, ze Qt toho nabizi mnohem vic

jj ale tak kdybych se ucil Qt, tak musim mit aplikace jako open source nebo koupit tu jejich predrazenou licenci (vztahuji to i do budoucna k zamestnani, sef asi kvuli mně nebude kupovat drahou licenci....)

--------------------------------------------------------------------
ed wrote:

> 3) poculi, neskusali, ale zrejme kvoli skole sa o to budem musiet
> zaujimat.

heh ja taky, UJEP Usti ?
--------------------------------------------------------------------
regnarg wrote:

> 3) mono je klon .net což je hloupý výmysl od M$, takže pokud
> opravdu požadujete takovéto prostředí, zkuste Javu, jinak
> doporučuji zůstat u C[++]

Java ee, nevoni mi a neptejte se nehodlam to rozebirat :-P

> 4) A hlavně má Gtk přehledné a intuitivní API.

mno ja je neznam do hloubky, ale zkuste juknout na Hello World GTK+ a QT, co Vam prijde intuitivnejsi ? (samozrejme je to imho)

[kozzi]

jj ale tak kdybych se ucil Qt, tak musim mit aplikace jako open source nebo koupit tu jejich predrazenou licenci (vztahuji to i do budoucna k zamestnani, sef asi kvuli mně nebude kupovat drahou licenci....)

Tak pouzivej GTK. Jinak pokud vim tak by tvuj sef zadnou licenci kupovat nemusel. Ty klidne muzes prodavat ten program bez toho QT a to si muze uzivatel doinstaloval zadarmo je to opensource.

Java ee, nevoni mi a neptejte se nehodlam to rozebirat :-P

No mě taky ne a proto zůstaň u C++ a nebo se nauč jython. Jinak Java mi tayk nevyhovuje ale asi se jí někdy naučit budu muset jelikož je to opravdu kvalitní jazyk.

mno ja je neznam do hloubky, ale zkuste juknout na Hello World GTK+ a QT, co Vam prijde intuitivnejsi ? (samozrejme je to imho)

No ano GTK+ se může zdát nepřehlednější jelikož je to toolkit v Céčku a ne v C++ jako QT, ale můžeš používat GTKmm. Já například používám kombinaci ruby + ruby/gtk a zde už to není tak nepřehledný.

[Luboš Doležel (Doli)]

Java mi taky až tak nevoní, ale to není nic oproti Mono

[regnarg]

Qt nelze srovnávat s Gtk+, možná tak s gtkmm. Nevím jakou konkrétní implementaci hello worldu má te na mysli, ale podle toho se toho moc posoudit nedá...

[h.xman]

Jen kolegu doplnim, ze ta Raymondova kniha je k dispozici i online.

[frEon]

1) no comment, pouzivam vim
2) kdyz nepouziji vim, tak kdevelop
3) nepouzivam
4) jestli chces gui tak si vyber mezi qt a gtk+. jestli myslis api na nizsi urovni, tak to jednotne je. doporucuji ti tudle knizku: Linux zaciname programovat, bohuzel uz je na tomhle eshopu vyprodana, podarilo se mi ho najit na vltave a vykoupit posledni vytisk (minimalne jeden z poslednich. kdyz sem se tam druhej den kouknul uz bylo vyprodano ). knizka je to dobra, jen misty trochu blbe prelozena. kdyz obejdes par knihkupectvi, nejspis na ni narazis a urcite (aspon teda u nas v liberci) ji budou mit v knihovnach.

[thomas]

kozzi wrote:
>Jinak pokud vim tak by tvuj sef zadnou licenci kupovat nemusel.
>Ty klidne muzes prodavat ten program bez toho QT a to si muze
>uzivatel doinstaloval zadarmo je to opensource.

tomu nerozumim, tak proc je treba kupovat licenci na Qt, myslel sem kdyz hodlate
prodavat svoje binarky
--------------------------------------------------------------------------------------

regnarg:
proc je .NET zlo ?

[thomas]

prosim vas a zna nekdo a muze neco rict neco o GtkSharp ? http://en.wikipedia.org/wiki/Gtk_Sharp

[thomas]

jeste prosim otazka, pokud pujdu do GTKmm, mohu pouzivat extenze z GTK ? Stejne jako tomu je v pripade C++ a C ?

[regnarg]

Jde o to, jaké extenze. Ale teoreticky by to minimálně v některých případech fungovat mohlo. A navíc mnoho gtk rozšíření má i svou "mm" verzi.

[Luboš Doležel (Doli)]

GtkSharp jsou bindings GTK+ pro C#

[Jan Martinek]

Když tady přišla řeč na Hello world v GTK (tedy okno s nějakým titulkem, které lze zavřít křížkem), tak to lze napsat třeba takhle:

#!/usr/bin/python
import gtk
w = gtk.Window()
w.set_title('Hello world')
w.connect('destroy', gtk.main_quit)
w.show()
gtk.main()

Je to v Pythonu (tj. high level jazyce) a bude to fungovat úplně stejně na linuxu jako na windows. Z tohoto důvodu mě nějaké C#/něco_Sharp/Mono/.NET nechávají chladným.

[regnarg]

Jazyky jsou lowlevel (C, C++, ...) nebo highlevel (Python, Ruby, PHP, Perl, Tcl, ...). Obě tyto skupiny mají své místo a mohou dobře spolupracovat. Snažit se vymýšlet "superjazyky" typu java nebo hůř .net je holý nesmyl a ještě navíc aby používaly své rozsáhlé vm a runtime platformy, které sse podobají spíš "OS v OS". To je úplné podkopávání základů programování...

[Luboš Doležel (Doli)]

Tak tuhle definici moc nechápu. To, co jste označil jako highlevel, jsou jazyky především skriptovací. Java není superjazyk (wtf to je?) a .NET už vůbec není jazyk

Obávám se, že právě to VM stojí za relativně slušným výkonem Javy v porovnání např. se zmiňovaným PHP.

[happy barney]

hmm, java nie je skriptovací jazyk?
prečo?

pretože má virtual-machine a bytecode?
Projekt parrot by mal vo finálnej fáze poskytovať obe vlastnosti aj pre php. Bude to znamenať, že PHP prestane byť skriptovacím jazykom?

[regnarg]

To souvisí víc s návrhem a filozofií jazyka a způsobem programování v něm (a také na definici pojmu skriptovací jazyk). Skriptovací jazyk je dynamický interpretovaný jazyk (je vcelku jedno, jestli se interpretuje přímo, nebo přes bytecode, ale pořád je velký rozdíl mezy bytecode interpreterem typu python a vm/platformou typu java nebo .net. to je o něčem úplně jiném). Ještě bych podtrhl slůvko dynamický, což je jedna z klíčových vlastností tzv. skriptovacích jazyků, protože např. java, nebo cé ohrada dynamickými jazyky nejsou.

[happy barney]

dynamický? hmm, v jave sa toho dynamicky dá porobiť veľa ... reflection je vcelku silný nástroj. ale ako vravíte, záleží na definícii, tentokrát slova dynamický

[regnarg]

Pokusím se na tuto otázku zhruba odpovědět, ale nejsem odborník, jen absolutní nula a neschopný idiot, který jen do všeho kecá, takže to berte s rezervou. V dynamickém jazyku fungují např. tyto vlastnosti (nedá se to brát jako definice, spíš příklad):

• není třeba deklarovat proměné, jsou určeny svým názvem, nikoliv adresou v paměti. lze k nim získat přístup pomocí stringu s jejich názvem

a=1
print globals()["a"]

• dynamické typování

a=1
a="xyz"

• míchání typů

pole=[0, "pokus", 3.14, {1: "text", 2.1: (1, "a")}]

• obecná volnání (to souvisí s dyn. typováním)

def secti(a,b): return a+b
secti(1,1) #→2
secti("a","b") #→"ab"
secti([1, "a"],[3.14]) #→[1,"a",3.14]

• atributy a metody objektů nejsou na pevno dány třídou, lze je dynamicky vytvářet, měnit a odstraňovat. lze k nim získat přístup pomocí stringu s názvem

class A:
    pass #prázdná třída
a=A()
a.x=1
a.y="a"
setattr(a,"x",3.1415926535)
del a.y

• a mnoho dalších...

reflection je jen pokus o implementaci minimální části dynamičnosti do javy, a to ne jako součást jazyka, ale prostřednictvím složitých knihoven a nevím-čeho-všeho. V dynamických jazycích často (ne vždy) platí pravidlo, že každá proměnná je referencí na objekt a způsob zacházení s ní je dán typem objektu a ne typem proměnné (protože ta žádný typ nemá). Tak lze volat metody objektu uloženého v proměnné ať už je libovolného typu a není nutno nic přetypovávat atp. A z vlastní zkušenosti vím, kolikrát se mi to hodilo...

[happy barney]

to, čo ste popísal sa viac hodí na rozdelenie podľa typovej kontroly (silná / slabá).

uvádzané príklady skôr ukazujú na nedostatočný návrh javy ako na to, či je alebo nie je dynamicka:
na sečti postačuje, aby jazyk umožňoval overloadovanie operátorov
na dynamické typovanie postačuje, aby (silne typový) jazyk buď podporoval implicitné pretypovanie (napr C++), alebo považoval aj primitívne datové typy za objekty (odvodené od base class)

bolo by asi vhodné zabudnúť na názov "skriptové jazyky" a uvažovať len on "kompilovaných" a "interpretovaných" jazykoch, kde "interpretované" jazyky potrebujú interpreter (vm), "kompilované" sú tie ostatné. Skripty sú interpretované jazyky.

[regnarg]

To jsou prostě zcela odlišné jazyky, což každý, kdo v nich programoval, musí chápat. To je o něčem úplně jiném. Házet javu a python to stejné kategorie je holý nesmysl. Ano, jsou to interpretované jazyky, ale není interpretovaný jazyk jako interpretovaný jazyk. V mnohýh ohledech se java podobá více C++ než Pythonu. To ohledně typové kontroly je spíše otázkou kontroly dynamické/statické, než silné/slabé. Protože např. python má silnou typovou kontrolu, ale dynamickou, tzn. typy se řeší až při manipulaci s obejkty, ne při deklaraci proměnných. A žádné automatické přetypování nenahradí to, že mohu volat libovolnou metodu objektu bez nutnosti znát typ. Pokud to mám v javě uložené v proměnné typu objekt, může tam být cokoliv (kromě základních datových typů, které to značně komplikují) ale stejně pokud potřebuji přistupovat k metodě nedefinované ve třídě objekt, budu nucen použít přetypování. V pythonu a podobných jazycích lze volat libovolnou metodu objektu kdykoliv bez znalosti jeho typu a bez nutnosti použít přetypování, bez ohledu na typ referenční proměnné (prootože žádný typ nemá). Ale tohle je jen jedna z mnoha charakteristických vlastností.

[ava]

Ja v podstate souhlasim s barneym, ze rozdeleni na skriptovaci jazyky a ostatni jazyky dnes asi nema vyznam. V pythonu jsem napsal aplikaci co mela 20000 radku, rozsahle GUI, export do XML, HTML, PDF, interaktivni grafy, komunikaci s HW a nejake matematicke operace nad namerenymi daty - mam ted snad mit spatny pocit ze jsem to napsal ve "skriptovacim" jazyku? Pritom se mi to psalo velmi pohodlne a je to docela rychle. Tvrdis tu cosi o nenahraditelne silne dynamicke typove kontrole pythonu (silna kontrola je dost vagni a nedourceny "termin"), ale pritom nektere verze pythonu bezi pod Java VM, takze asi Java principialne umi vsechno co Python, jen ta syntaxe je kostrbatejsi a prekladac provadi vic statickych kontrol..

Zbyva asi jen rozdelovat jazyky na skriptovaci a jine intuici - ale ja jsem programator a ne porota Superstar, takze si tohle rozdelovani radsi odpustim uplne :)

[regnarg]

To, že běží pod javou, ještě nic neznamená protože zrovnatak jsou některé verze pythonu napsány v C. Takže je ještě možné srovnávat python s C, že ? To že v javě běží python neznamená, že má stejné schopnosti, zrovnatak by se (při troše snahy) dal napsat v assembleru. Je logické, že v nedynamickém jazyku lze dynamický jazyk napsat, protože tu dynamičnost již zajišťuje náš kód navíc. To ale ještě z javy dynamický jazyk nedělá. A nevím proč špatný pocit ze skriptovacího jazyku, já jen zdůrazňuji, že je mezitím velký rozdíl, to neznamená, že je na skriptovacích jazycích něco špatného. Mají své opodstatnění a své využití...

[happy barney]

niekto nerozlišuje medzi Java VM a Java. Prvé je interpreter bytekódu, druhé sú príkazy pre preprocesor, generujúci spomínaný bytekód.

[regnarg]

Ale ovšemže rozlišuji, jenže pro rodělování jazyků to nemá moc význam. Python má taky interpreter bytekódu, jen se spouští automaticky. Ale o tom tady vůbec nebyla řeč. Je jedno co je VM a co ne, pořád to nic nemění na tom, že jsou to odlišné jazyky a je nesmysl tvrdit opak.

[happy barney]

Myšlienka bola, že prekladač pythonu ako interpreter bytekódu využíva Java VM, nie že je interpreter pythonu napísaný v Jave.

[regnarg]

Ani to na faktu nic nemění. Stejně bude muset výsledný bytecode obsahovat "pomocný kód" pythonu, který zajistí potřebné vlastnosti, ale rozhodně to nebude stejné jako by ten program byl psaný v javě. Protože bude dynamický, což zase bude zajištěno speciálními prostředky pythonu, nikoliv javy, které budou součástí výsledného bytekódu.

[ava]

je vcelku jedno, jestli se interpretuje přímo, nebo přes bytecode, ale pořád je velký rozdíl mezy bytecode interpreterem typu python a vm/platformou typu java nebo .net. to je o něčem úplně jiném

Hmm, dost mozna se v dane oblasti neorientuju, ale jakej je rozdil mezi Pythonem, u ktereho se zdrojak prelozi do bytecode ktery je potom interpretovan, a Javou, ktere zdrojak se prelozi do bytecode ktery je potom interpretovan VM? (o tom, ze VM muze provadet JIT samozrejme vim, ale to je pouze optimalizace ktera z principu muze uplne stejne byt implementovana v interpretteru Pythonu). Osobne mezi interpretterem pythonu a VM Javy vlastne nevidim zadny principialni rozdil - oboje zpracovava nejake bytecode instukce, poskytuje spravu pameti + GC, vlakna, atd atd..

Ještě bych podtrhl slůvko dynamický, což je jedna z klíčových vlastností tzv. skriptovacích jazyků, protože např. java, nebo cé ohrada dynamickými jazyky nejsou.

pokud nenajdeme rozdil mezi VM a interpretterem, jak jsem psal vyse, zbyva jako rozdil mezi skriptovacim jazykem a napr. javou to, ze skriptovaci jazyk je dynamicky a java ne? jsou potom terminy "dynamicky jazyk" a "skriptovaci jazyk" synonyma? pokud bych do javy pridal dynamicke moznosti (co tim vlastne myslis? ze ma jazyk dynamicke typy? duck typing?), stane se skriptovacim jazykem?

[regnarg]

Viz. reakce na příspěvěk výše. A také, jak již jsem zmínil, nejde jen o schopnosti a implementaci jazyka ale také o jeho filosofii. Jakým způsobem se v něm programuje, k čemu je určen atp...

[regnarg]

Myslel jsem to tak, že je v poslední době v módě vymýšlet jazyky které mají rádoby nahradit všechno, od céčka přes tcl až po python. A zastávám názor, že je to krok nesprávným směrem. Protože tyto jazyky mají menší použitelnost ve srovnání s jazyky, které nazýváte skriptovací a nižší rychlost ve srovnání s jazyky typu C. Takže získáme takový nicmoc průměrný jazyk. Ale při zachování stávajících unixových postupů stačí napsat výkonné části v C či podobném jazyku, a blbosti, jako je GUI, či nenáročné klientské prostředí, apt. ponechat dynamickým interpretovaným jazykům, které nabízí větší jednoduchost a flexibilitu. Přece proto existuje více jazyků různé úrovně (a proto také mám záporný vztah k javě a .net, což sice jak jste řekl není jazyk, ale platforma, ale jinak je k ničemu)...

[Luboš Doležel (Doli)]

Prodávat totiž můžete i open source. Placenou licenci pro Qt potřebujete při vývoji softwaru, který nebude pod GPL (pozor: GPL není "antikomerční" licence).

[thomas]

>Qt potřebujete při vývoji softwaru, který nebude pod GPL
dekuju uz mam jasno

> GtkSharp jsou bindings GTK+ pro C#
prosim Vas co je bindings, te definici na en wiki moc nerozumim, dekuju

[Luboš Doležel (Doli)]

Bindings jsou vazby. Prostě obalení původního C API tak, abyste jej mohl nepřímo používat v C# přes nějaké třídy apod.

[trekker.dk]

Prodat můžeš i open source program pod GPL, ale AFAIK nemůžeš nikomu zabránit, aby ho prodával taky nebo šířil zadarmo.

[thomas]

to Luboš Doležel (Doli) :
v tom pripade by me zajimal rozdil mezi Bindings a wrapperem (mozna se pise s jednim p ), protoze to co popisujete znam jako wrapper

to trekker.dk: dekuju ale jak jsem psal mam uz jasno (cz wiki GPL)

snad se mi dostane odpovedi i na zbyle otazky. moc moc dekuju za vas cas

[regnarg]

Tohle je spíš hra s pojmy. Bindings = rozhraní k nějaké knihovně pro jiný programovací jazyk. Wrapper = obal, čili kód který knihovnu využívá, ale navenek má jiné rozhraní, které může, ale nemusí být ve stejném programovacím jazyce. Takže někdy lze využít pojmy oba, někdy se více čí méně správně zaměňují, a někdy to může být úplně něco jiného. Obecně platí, že bindings slouží pouze k poskytnutí funkcionality knihovny jinému jazyku, kdežto wrapper je obecnější a může plnit i jiné úkoly. Takže hodně zjednodušeně by se dalo říct, že bindings jsou druhem wrapperu (i když není tomu tak vždy).

[Vinicius]

1) Jsou to (nejen) programatorske editory se zcela specifickymi vlasnostmi, oba toho umi hodne, ale trva dele se je naucit a cloveku co pracoval treba s Visual C++ asi moc vonet nebudou

2) Nahrada za Visual C++ KDevelop rozhodne neni, davam mu prednost pred Anjutou, protoze ma GUI uspornejsi co se tyce zabraneho prostoru a konfigurace projektu je prehlednejsi. KDevelop ma ale nektere nedotazenosti, treba neumi vytvorit pouzitelnou distribuci zdrojoveho kodu, nebo mu vubec nejde vytvaret rpm baliky. Na editaci zdrojoveho kodu je KDevelop dobre. Code::Blocks neznam

3) Mono je nehotove, ale pouzitelne

4) Vetsinu funkci os lze zpristupnit pomoci knihovny glibc, staci si najit v dokumentaci, co chcete delat a dozvite se jake hlavickove soubory jsou potreba. Dokumentace k teto knihovne se mi moc libi, protoze je tam mnozstvi praktickych rad a upozorneni na bezpecnostni rizika. Ja bych nehledal jednotne Linux API, ale hledal bych informace ke konkretnim problemum - zvuk, sokety atd. Protoze treba u soketu se proste dozvite, ze v Linuxu mate k dispozici BSD socket interface, tak si najdete dokumentaci primo k nemu. Hledal bych take POSIX, protoze Linux je z "vetsiny kompatibilni".

Linux samozrejmne neposkytuje zadne API pro tvorbu GUI aplikaci - tyhle funkce jsou vsechny v podobe dodatecnych knihoven (GTK+,QT,FLTK,EFLTK,FOX,MOTIF.....)

[thomas]

dekuju myslim ze uz mam jasno, zajimalo me prave .MONO a vy rikate ze je to dost pouzitelne. Musim so e o .NET zjaimat kvuli skole, ale snad casem prejdu na GTK+(gtkmm) protoze se mi docela zamlouva, dekuji moc.

nashle

[regnarg]

Nevím co je to za školu, ale já bych si .net nikdy od žádné školy nutit nenechal...

[DjAARA]

Vidíte a já si zapsal předmět MW5 -- C# a .NET zapsal dobrovolně. Dle strategie poznej svého nepřítele.

[Messa]

1) pro mě je spíš podstatnější, že emacs/vim nejsou jen obyčejné editory, ale existují do nich pluginy a módy přinášející nějakou funkčnost, kterou jinde zatím těžko najdu.

2) gedit (textový editor v GNOME)

3) není windowsová nebo linuxová binárka... je jen CIL bajtkód a ten se dá v Linuxu spustit díky MONO. Co se mě na .NETu moc líbí je právě ten "mezijazyk"/bajtkód, díky kterému stačí program do něj přeložit jednou a pak se dá spustit na kterékoliv jiné (i hardwarové) platformě (samozřejmě pokud na ní existuje interpreter nebo tak něco). To sice v open-source není zase tolik potřeba, ale má to i tak svůj smysl a může to být asi dost výhoda pro tvůrce komerčního softwaru. Nicméně .NET je záležitost Microsoftu a tomu se asi nikdy nebude líbit i něco jiného než Windows, což má negativní vliv na MONO a podobné projekty.

Osobně si myslím, že všechny (dobré a v reklamních materiálech označované za revoluční) vlastnosti .NETu se dají v GNU/Linux/Open-source světě najít v nějaké podobě už delší dobu; případně je jen otázkou času, kdy se vyskytne opravdu kvalitní alternativa, třeba k tomu CIL bajtkódu. (Perl 6 runtime?)

(Nejsem odborníkem na .NET, na paradigmata programování a v computer science se teprve začínám pomalu rozhlížet, tak můj příspěvek prosím berte s rezervou; asi tak jako většinu ostatních příspěvků v této diskuzi )

[Jan Martinek]

Kdyby někoho zajímalo, jak v pythonu zkompilovat zdroják do přenositelného bytecódu, tak to lze pohodlně udělat pomocí modulu py_compile. Vytvoří se soubory s koncovkami pyc a pyo, kterým interpret pythonu rozumí a umí je spustit.
Ale nedělejte to - výtvory bez zdrojáků nechceme

[happy barney]

pre info: Java (s týmto konceptom) prišla na svet niekedy pred rokom 2000. A interpreter existoval dokonca až pre dva OS (Solaris a winshit). Ale to v redmonde určite nevedeli. A opičiť sa s podporou solarisu tiež snáď nebudú

[thomas]

diky vsem za postrehy al rad bych reagoval, rikate .MONO diky tomu ze je .NET o M$ je take blbost, ale s tim nesouhlasim, dit .MONO vyviji Novell a ten si prece nenecha kecat do veci od M$ a i
kdyby nechal (maji naky smlouvy) tak:
1) se MONEM chlubi, tudiz se ho sanzi max. rozsirit
2) proc by M$ protestoval, .MONO by mohlo teoreticky prilakat vice lidi na .NET

[Messa]

Microsoft vydělává prodejem Windows, ne .NETu.

IMHO .NET není zas taková blbost, v programování pro Windows je to krok dopředu A jeho tahání na Linux je podle mě dobré kvůli komerčním aplikacím určeným větším firmám, které se pravděpodobně budou psát v .NETu; no a komu Novell prodává/se snaží prodat svůj SLED/SLES? S argumentem, že software psaný v .NETu nebude bránit přechodu z Windows na SUSE jim to půjde lépe. Novell si musí nechat kecat do vývoje MONO od Microsoftu, protože kdyby bylo MONO nekompatibilní s .NETem, tak by bylo k ničemu.

Co se týče smyslu .NETu a MONO pro obyčejného uživatele Linuxu, tak to už je horší...

[regnarg]

imho jsou java a .net krok zcela nesprvným směrem, ať už v programování na gnu/linuxu, nebo pseudoOS-který-nejmenujeme.

[dustin]

Nejsem si jist, zda je vůbec reálné, aby složitější soft napsaný pod .netem běžel bez problémů v monu. Navíc si to opravdu zadělává na problém s patenty apod.

[thomas]

mno maji nake smlouvy s M$ tak patenty asi porusovat nebude.

ad slozitejsi program na MONU: bylo mi receno ze si staci ohlidat fce ktere MONO nezvladne a nepouzivat je v programu.