Otetaas tämmönen vanha klassinen kysely näistä ympäristöistä. Ei välttämättä yhteensopivuuden, tuottavuuden tai laadun kannalta vaikka noi voi olla osa tätä.
Eli mikäs on mukavin IDE tai muu ympäristö jolla ootte koodanneet ja tehneet hommia? Siis millä on ollut miellyttävintä tehä hommia ja millä on ollut mukavinta saada valmista aikaan? Ei väliä vaikka se ois pesukoneen sulautettu, linukan assy tai vaikka se rubyyni josta puhutaan paljon mutta harvemmin mitään nähään. Niin tai mäkki ja sen vähemmän tunnetut kehittimet.
Alusta kehitysympäristö ja kieli ois siis mukava kuulla.
Aattekin tossa, että vois opetella jotain uutta systeemiä tässä kun ehkä joutaa.
Eli mikäs on mukavin IDE tai muu ympäristö jolla ootte koodanneet ja tehneet hommia? Siis millä on ollut miellyttävintä tehä hommia ja millä on ollut mukavinta saada valmista aikaan? Ei väliä vaikka se ois pesukoneen sulautettu, linukan assy tai vaikka se rubyyni josta puhutaan paljon mutta harvemmin mitään nähään. Niin tai mäkki ja sen vähemmän tunnetut kehittimet.
Alusta kehitysympäristö ja kieli ois siis mukava kuulla.
Aattekin tossa, että vois opetella jotain uutta systeemiä tässä kun ehkä joutaa.
Vastaukset 27
Vanhimmat
Vaikka välillä olen joutunut Visual Studiota, Eclipseä, XCodea sun muita käyttämään, niin silti C -kehitykseen ei xemacs gcc make yhdistelmää voittanutta ole.
90-luvulla ja 2000-luvun alkupuoliskolla Delphi ja Windows 2000 tai WinXP.
Viime vuosina tosin Visual Studio 2005/2008 ja C# ja WinXP.
Paljon tosin riippuu siitä mitä "mitä" on pitänyt koodata eli ympäristö/työkalut tehtävän mukaan.
80-luvun puolella valmistettu Microsoft QB:n IDE oli minusta ihan huikea.
Käytin aluksi Commodore 64:n Basicia, jossa oli eräänlainen rivieditori. Siitä hyppäsin suoraan QBasiciin. Jälkeenpäin ajatellen muutos oli varmaan suurimpia tietotekniikassa kokemiani muutoksia.
Automaattinen muotoilu toimi suoraan koodia kirjoittaessa. Se auttoi jopa löytämään syntaksivirheet reaaliajassa. Copy-paste toimintoa tuli käytettyä todella paljon.
Muistaakseni kaikki prosessointi oli todella nopeaa. Kaukana nykyisen Eclipsen hidastelusta.
Ohje-dokumentaatio oli toteutettu www-tyyliin. QB:n helpissä oli hyperlinkkejä ja hakutoiminto muistaakseni suoraan koodista. Pystyi käyttämään sekä hiirellä että näppiksellä.
Kun sitä vertaa Eclipseen niin kehitystä on tapahtunut mutta ei niin paljon. Esim värikoodaus olisi saanut olla QB:ssakin. Ei olisi ollut vaikea toteuttaa.
Tutustu edes nyt sitten Lazarukseen ( http://www.lazarus.freepascal.org/ ) jos Eclipsen käyttö on hidasta. Ilmeisesti 80-luvun lopulla jäi tutustumatta Turbo Pascal:n (Turbo Vision jne).
Rajallisesti ajatellen Eclipse ympäristö, java-koodia kehittäen, oli muuten erittäin sujuva ja tuottava, mutta pahin ongelma oli sen kummallinen, suljettu (minun ymmärtääkseni) projektikäsite. Projektin haaroittaminen kahdeksi erilliseksi projektiksi, joka on osaa työtapaani, oli äärimmäisen kömpelöä eclipsellä. tai en vain osannut, missään ei selitetty. Homma olisi pitänyt sujua "yhdellä näppäyksellä" plus hakemiston kyselyllä, mutta kun ei..
Työpaikan ympäristöistä ei viitsi puhua, ne ovat aika primitiivisiä ja sotkuisia, turbulenttisia.
Nykyisin kotona C ympäristönä olen melko tyytyväinen kun on KDevelop editorina ja gnu-työkalut, g , make ym buildauksessa. Ehkä primitiivistä, mutta selkeää, läpinäkyvää (tätä arvostan), kaikki pysyy hanskassa. Häpeän, mutta en ole koskaan päässyt emacsin makuun.
Harrasteprojektina toteutan Lojban-Chatbottia, siis eräänlainen AI-projekti. Lojban-kielestä:
oma blogini: http://lojban-ajattelua.blogspot.com/
viralliset sivut:
http://www.lojban.org/tiki/tiki-index.php?page=Lojban&bl=y
Eclipsessa on myöskin käsite "Working Set". Ilmeisesti ideana on ladata samanaikaisesti tehtävät projektit samaan settiin. En itse(kään) ole huomannut tuota vaan olen luullut yhden Working Setin riittävän.
Emacs GNU make git kääntäjä/tulkki saavat täältäkin äänen. Pitäisiköhän samaan settiin laskea vielä kieleen sopiva debuggeri, strace, ltrace, grep, awk ja sed. Ja tietysti find, xargs, sopiva shell, terminaalit --- ja kaipa käteen sopiva ikkunamanagerikin voitaisiin laskea tärkeäksi osaksi koodausympäristöä. Ovathan kaikenkarvaiset IDEt koittaneet tarjota tällekin saralle aina omia ratkaisujaan. Joskus, tosin harvemmin, on ollut paikallaan kieleen sopivan lintin käyttö ja muutamat qemut testailun tukena. Varsin hyvältä kuulosti myös icecc, mutten ole sitä ehtinyt vielä itse kokeilla.
Toisin sanoen: yksikään IDE ei ole minun asteikollani päässyt käyttömukavuudessa lähellekään sitä ympäristöä, jonka saa aikaan muodostamalla kokonaisuuden suosikkityökaluistaan.
"Toisin sanoen: yksikään IDE ei ole minun asteikollani päässyt käyttömukavuudessa lähellekään sitä ympäristöä, jonka saa aikaan muodostamalla kokonaisuuden suosikkityökaluistaan."
Veit jalat suustani, sillä tilanne on mulla hyvin sama ja kun näistä IDE:stä jauhetaan niin olen välillä epäillyt on mulla päässä vikaa kun mikään IDE ei ole oikein iskenyt.
Minä kuulun Jepulis Jeepin leiriin ja minutkin on aivopesty IDE-ohjelmointiin. On pakottava tarve käyttää Visual Studiota jossain muodossa.
Emacs on editori, tekstin tuottaminen.
Git on version hallinta, Pitää tietoa tehdyistä muutoksista.
Eli voisitko selittää vähän samalla lailla nämäkin.
GNU make ?
strace ?
ltrace ?
grep ?
awk ?
sed ?
find ?
xargs ?
GNU Make ohjaa käännösprosessia - ja tarvittaessa monia muutakin prosessia, missä työvaiheet riippuvat toisistaan ja kaikkea ei haluta aina rakentaa alusta alkaen uudestaan. Esimerkiksi Qt 4.5 sisältää 4688 .cpp-tiedostoa. Olisi turhauttavaa, jos yhden tiedoston editoinnin jälkeen pitäisi kääntää jokainen niistä uudestaan.
strace tulostaa ohjelman suorittamat käyttöjärjestelmäkutsut. Esimerkiksi voit tutkia mitä tiedostoja qtconfig avaa missäkin suorituksen vaiheessa komennolla "strace -e trace=open qtconfig".
ltrace tulostaa ohjelman kutsumat funktiot dynaamisesti linkatuista kirjastoista. Esimerkiksi komento "ltrace ls" näyttää mitä tapahtuu hakemistoa listatessa, ja "ltrace -C -n2 qtconfig" antaa jonkinlaisen käsityksen siitä, mitä qtconfigin ja Qt-kirjaston välillää liikkuu.
grep suodattaa syötteensä rivejä. Kaikista hakemiston tiedostoista voi etsiä merkkijonoa "TODO" komennolla "grep TODO *".
xargs jakaa syötteensä uuden komennon parametreiksi.
find etsii tiedostoja. Esimerkiksi "etsi kaikki .cpp-päätteiset tiedostot, jotka ovat muuttuneet viimeisimmän seitsemän päivän aikana" voi sanoa lyhemmin "find . -name '*.cpp' -mtime -7". Näiden komentojen yhdistelystä olkoon esimerkkinä projektin TODO-merkkijonon etsiminen .cpp-päätteisistä tiedostoista: "find . -name '*.cpp' | xargs grep TODO". find tulostaa tiedostojen nimet, niistä tulee xargsin syöte, joten se antaa nimet grepille parametreiksi. grep taas etsii TODO-merkkijonoa näistä tiedostoista ja tulostaa jokaisen tiedoston nimen, kaksoispisteen ja rivit, jotka sisältävät merkkijonon TODO.
awkilla voi suorittaa kätevästi operaatioita syötteen riveille. Esimerkiksi kaikki TODO-merkkijonon sisältävien .cpp-päätteisten tiedostojen nimet voi eritellä edellisen esimerkin tulostuksesta näin: "find . -name '*.cpp' | xargs grep TODO | awk -F: '{print $1}'"
sed muokkaa tekstiä. Sillä voi tehdä mm. etsiä ja korvata merkkijonoa (säännöllisin lausekkein vahvistettuna) suoraan tiedostoista. Kaikissa .cpp-päätteisissä tiedostoissa esiintyvä TODO-merkkijono voitaisiin muuttaa FIXME-merkkijonoksi komennolla "find . -name '*.cpp' | xargs grep TODO | awk -F: '{print $1}' | xargs sed -i 's/TODO/FIXME/g'".
Näiden lisäksi on lukuisia muitakin käteviä ohjelmia, joita voi yhdistellä toistensa syötteisiin ja tulosteisiin niin kuin lystää. Ja jos jotain puuttuu, sen voi tehdä itse. Tähän verrattuna IDEn klipsuttelu hiirellä on hidasta, kömpelöä ja kovin rajoittunutta.
"IDEn klipsuttelu hiirellä on hidasta, kömpelöä ja kovin rajoittunutta."
Onko tarkempaa perustelua? Tuohan riippuu sekä käyttäjän motoriikasta, että varsinkin siitä IDE:stä. Suurin osa ihmisen viestinnästä on sanatonta joten miksi koneen kanssa pitäisi keskustella kielellisesti? Jos tekee työtä jollekin suurelle byrokratialle, niin silloin yhteisten termien käyttäminen saattaa olla tärkeää. Sekään ei edellytä komentoriviä.
"Tuohan riippuu sekä käyttäjän motoriikasta, että varsinkin siitä IDE:stä. Suurin osa ihmisen viestinnästä on sanatonta joten miksi koneen kanssa pitäisi keskustella kielellisesti? Jos tekee työtä jollekin suurelle byrokratialle, niin silloin yhteisten termien käyttäminen saattaa olla tärkeää."
Ei minulla ole mitään erityistä syytä yliarvostaa komentorivityöskentelyä, mutta ei myöskään päinvastaiseen suuntaan. On periaattessa melkein sama, haenko komentorivipuskurin vanhojen komentojen muistista käytetyn loitsun, (johon teen ehkä pieniä muutoksia) tai käynnistän IDE:n vastaavan komennon menusta tai toolbarista. Isoja eroja ergonomiassa ei ole.
Suurimmat erot ovat avoimuudessa ja joustavuudessa. GNU-työkaluissa tiedän tarkemmin miten ne työn tekevät. Koen hyvin ärsyttäväksi, jos IDE "helpottaa" työtäni piilottamalla oleellisia puolia toiminnastaan yksinkertaisen klikkauksen taakse. Eclipse on "avoin" ympäristö, mutta on suurempi haaste (mikä ei minua kiinnosta) alkaa häkätä sitä, kuin yhdistellä hyvin dokumentoituja, yksinkertaisia GNU-työkaluja.
"Iso työnantajani" on näihin päiviin asti käyttänyt komentoriviä virallisena ympäristönään, mutta nyt hiljalleen ollaan siirtymässä IDE-käyttöön (mikä kohtaa voimakasta vastarintaa, vaikka käytetyt komentorivityökalut ovat olleet kaukana GNU-työkalujen selkeydestä).
Minusta aloittelevan ohjelmoijan on hyvä hankkia kokemuksia, positiivisia, molemmista vaihtoehdoista. Komentorivityöskentelyn alkuvaikeudet kannattaa puskea läpi ennenkuin tekee hätiköityjä johtopäätöksiä. Kynnyksen toisella puolella on mukava ketteryys ja selkeys odottamassa.
Tässä puhutaan paljon IDE:stä yksikössä. En minä (tuskin ketjun aloittajakaan) ole käyttänyt vain yhtä IDE:ä, vaan yritän tässäkin valita tarkoitukseen sopivamman. Esim Google Sidebarin SDK:ssa on mukana oma erikoinen IDE. Sitä tuli käytettyä kun tein sivupalkkiin toiminnallisuuden joka on kytköksissä omaan ajanhallintaohjelmaani. Ei tarvinnut käyttää yleistyökaluja.
Toisaalta GNU:n työkalut näyttää olevan sidoksissa tiedostoihin, vaikka hyvä tapa olisi käyttää tietokantoja. Ainakin Windowsissa tiedostojärjestelmä on hyvin suljettu alue.
Mutta minä olen vaan Windows-käyttäjä. On todella mielenkiintoinen idea "keskustella" komentorivin kanssa asioista syvällisemmin.
Ensimmäinen IDE, jota käytin, oli kai 80-luvulla Atari ST:n GFA-Basic ympäristö, erittäin tuottava, kielen kehittymättömyydestä huolimatta.
Ammattikielenäni oli silloin sulautetussa ohjelmoinnissa PL/M, hieno kieli, eikä tietenkään IDE:ä.
Toinen IDE oli kai DOS-ympäristössä Zortech C (1991), jonka Library Reference kirjaa käytän ajoittain edelleen C:n standardi-libraryn lunttaamiseen. Sen jälkeen on ollut monia, ehkä erikoisimpana Menthorin Renoir VHDL-ympäristö, jolla tein monta vuotta hommia.
Mutta tuntuu siltä, että komentorivityökalut roikkuvat hyvin sitkeästi mukana tekniikan kehityksestä huolimatta. Niitä nyt on vain niin vaikea kiistattomasti ylittää.
Windows-koodia en ole tehnyt tuon 1990-luvun alun kokeilujen jälkeen.
"Ainakin Windowsissa tiedostojärjestelmä on hyvin suljettu alue."
No sitten vastaavasti unixeissa "everything is a file".
http://ph7spot.com/articles/in_unix_everything_is_a_file
>> IDEn klipsuttelu hiirellä on hidasta, kömpelöä ja kovin rajoittunutta."
> Onko tarkempaa perustelua?
Perustelu taisi jäädä edellisen viestini rivien väleihin. Hitauteen, kömpelyyteen ja rajoittuneisuuteen on kaikkiin sama perustavaa laatua oleva syy:
* GNU-työkalujen (tai ylipäätään UNIXin) ideologiaan kuuluu, että *pieni* määrä apuohjelmia tekee kukin yksinkertaisen asian. Käyttäjä ratkaisee *erittäin suuren* määrän ongelmia yhdistelemällä komentoja. (Jos haluat tietää tarkemmin, lue edellisen viestini esimerkit komentojen yhdistelmistä uudelleen.)
* Graafisiin käyttöliittymiin pohjautuviin IDEihin kuuluu ajatus tarjota *suuri* määrä valmiiksi mietittyjä toimintoja, jotka tekevät monimutkaisia asioita. Käyttäjä ratkaisee ongelmansa näennäisen helposti muutamalla "napin painalluksella", kun ongelma sattuu olemaan IDEen valmiiksi toteutettujen ratkaisujen joukossa.
Jälkimmäisen ratkaisun heikkous seuraa siitä, että erilaisia ongelmia on paljon enemmän kuin mitä käyttöliittymään voi toteuttaa "nappeja". Sen sijaan pieniä komentoja voi vaivattomasti yhdistellä erittäin monella eri tavalla.
> Suurin osa ihmisen viestinnästä on sanatonta joten miksi koneen kanssa pitäisi keskustella kielellisesti?
Tämä on täysin käsittämätön argumentti etenkin näin keskustelupalstalla, missä en näe ilmeitäsi tai eleitäsi. Jos haluat analogian viestinnän puolelta, niin osuvampaa olisi verrata UNIX-filosofiaa sanakirjaan ja klipsuttelu-IDE-filosofiaa fraasisanakirjaan. Pitsan tilaamiseen saattaa riittää lukea yksi rivi fraasisanakirjasta, mutta sanakirjan avulla voi tilata koko porukalle ja vielä haluamillaan täytteillä.
Niin, "erilaisia ongelmia on paljon enemmän kuin mitä käyttöliittymään voi toteuttaa nappeja", mutta kyllä ne rajat ovat syvemmällä, kuin käyttöliittymässä. Ajatus siitä että käyttäjä (yleistyökaluineen) olisi diktaattori, ei ole muutenkaan realistinen.
IDE-filosofia onkin vähän kuin demokratia, jossa keskivertoihmisen tarvitsee vain piirtää numero kerran vuodessa. Mitään ehtoja ei vaalilipukkeeseen voi laittaa, vaikka ongelmia olisi enemmän.
IDE:t ja muut isot ohjelmistot ovat kuin yksityisyrityksiä: Niillä ei ole yhteistä "omaisuutta", eli esim dataa, vaikka toimisivat Linuxissa. Siksi yleistyökalut eivät ole suosittuja Windowsissa.
Windowsissa voisi käyttää vaikka internettiä ja tietokantoja tämän "omaisuuden" jakamiseen, mutta se ei kuitenkaan käytännössä onnistu sen paremmin kuin yksityisyrityksissäkään. Ohjelmien kesken tulee "riitaa" siitä mitä saa muuttaa ja miten.
Niiden kanssa on ollut helpompaa hoitaa hommia jälkikäteen. Jonkun muun siis. Ei ole pahemmin tarvinnut tehä mitään erillisiä ohjeita ympäristöstä ja mulle ei ole soiteltu pahemmin näitten osalta. Ottaa vaan projektin, avaa sen oikeessa idessä ja muuttaa mitä muuttaa ja se on siinä.
Oon oppinut arvostamaan helppoa siirrettävyyttä ihmiseltä toiselle ja vaikka ylläpitoon melkeen alottelijoillekin. Vie hirveesti aikaa kun pitää kouluttaa jotakin juippia siihen miksi mitäkin työkalua tarvitaan.
Hauska osoitus siitä miten klikkaaminen ei ole välttämätöntä gui:ssa, vaan se ehkä korvautuu elehtimisellä:
http://www.dontclick.it/
"Toisin sanoen: yksikään IDE ei ole minun asteikollani päässyt käyttömukavuudessa lähellekään sitä ympäristöä, jonka saa aikaan muodostamalla kokonaisuuden suosikkityökaluistaan."
Just näin. Usein suorastaan mietin, että mikä perverssi hinku on yrittää tunkea kaikki mahdolliset ominaisuudet ja integroituvuudet yhdeksi isoksi bugiseksi aikapommiksi? Luultavasti se on sitten imagokysymys, että pätevätkin koodarit alistetaan tuijottamaan kaiken maailman nippeleitä ja nappeleita, jotka alituisesti vievät näyttötilaa, jonka voisi käyttää olennaiseen.
Meillä on töissä eräs hmm... Eclipsestä jatkojalostettu IDE, ja sanoisin että se lyhentää itse koodarin elinikää. Tärkeät asetukset on piilotettu hujan hajan valikkojen alavalikkojen ikkunoiden välilehdille, oletuksenahan ne ovat aina poskellaan, lisäksi IDE keksii päivittää koodia miten sitä huvittaa silloin kun sitä huvittaa. Koskaan ei voi olla varma siitä, että "projekti" on vielä ehjä. "Projekti", joka ei edes vastaa tosielämän projektia eli laskutettavaan hankeeseen liittyvää kokonaisuutta.
Vastausajat ovat usein niin pitkiä, varsinkin "workspacea" vaihtaessa, että ajatus katkeaa. Työkalu on niin hidas ja niin buginen, että kynnys ylipäänsä käynnistää se on aika korkealla. Mutta ei se mitään, koska parin vuoden päästä sekin tuote on jo kuollut ja kuopattu, kuten lähes kaikki IDEt sitä ennen.
Jos IDEä ei olisi (pakko käyttää), kokoaisin sen "projektin" tärkeät asetukset yhteen paikkaan, mieluiten tekstitiedostoon, niin että mahdollisimman paljon saa kerralla näkyviin ja hallintaan. Mutta nyt se on estetty, tyypillisesti myös Java EE:n spesifikaation toimesta, ja "projektin" elinkaari on yhtä lyhyt kuin IDEn tulevaisuus: kohta taas migratoidaan. Mutta pääasia, että liksa juoksee.
> Oon oppinut arvostamaan helppoa siirrettävyyttä ihmiseltä toiselle ja
> vaikka ylläpitoon melkeen alottelijoillekin.
Jos se on niin helppoa, ootko koskaan miettinyt miksi isot avoimet projektit eivät ole sidottuja mihinkään ideen? Vastaushan on:
> Vie hirveesti aikaa kun pitää kouluttaa jotakin juippia siihen miksi mitäkin
> työkalua tarvitaan.
Vain sun mielestä edellinen puhuu iden puolesta. Kaikkien muiden mielestä se tarkoittaa, että jokainen voi osallistua projektiin niillä työkaluilla mistä eniten pitää. Tiukasti mihinkään ideen sidotussa projektissa se ei olisi mahdollista.
Linkki vei tyhjälle sivulle, jonka keskellä oli nappi, jota painamalla olisi käynnistynyt joku hirveä flassi varmaan. En tietenkään painanut, kun sivun nimikin jo kielsi... :)
Visual Studio 2005/2008 ja C# vie kokonaisuutena voiton. Nykyään käytän KDevelopia, kotona myös QtCreatoria C /Qt -koodaukseen. QtCreator on menossa hyvään suuntaan mutta vielä on kulmia hiomatta.
Jopa wanha Builder 3.1 jostain 10v takaa on toimivampi ympäristö kuin nämä Eclipset tms. Linuxissa pyörivät C IDEt. Yhtä hyvin toimivaa integroitua debuggeria en ole löytänyt mistään.
LabView windows xp
On ollut mukavin mitä olen käyttänyt ja helppo käyttöinen.
Tosi siisti. Ja sillä toteutettava kodii on helppoa visuaalisen koodin ansiosta.
Komentorivi (esim. ISPF option 6), rehellinen tekstieditori, esikääntäjät, kääntäjä...
Joku ohjelmointikieli, jossa on selkeästi 1) funktioita ja 2) dataa.
Ei mitään sekoiluja siltä väliltä. Oliot on rumia. XML haisee komitealta.
Peräkkäistiedosto on koodarin paratiisi. Relaatiomalli rulettaa.
Codd's 12 rules - paremmat ihanteet kuin SOAssa ja oliohömpötyksissä.
ISPF:n editori on kyl aika hyvä. :)
Ehkä pitäisi äänestää PowerBuilderia, olikohan se versio 11, millä viimeksi koodattiin.
Muistaakseni uusin .NET -kehitysympäristö tuntui osittain jopa paremmalta pelkkään koodaukseen, mutta siinä tietokantojen käsittely oli turhan monimutkaista, eikä käyttöliittymän suunnittelukaan yhtä innovatiivista minusta. Ja tietysti on sekin, ettei sillä tullut varsinaisesti koskaan mitään oikeaa koodattua. :D
Fyysinen ympäristö on kuitenkin tärkeintä. Sopiva, hyvin säädetty tuoli. Hyvä pöytä. Vähintään kaksi näyttöä. Kunnon rotta ja näppis joka tuntuu hyvältä eikä särje paikkoja... :)