ŠIAURĖS ATĖNAI

Šiaurės Atėnai. 2007-10-27 nr. 866

| Spausdinti | Archyvas | Redakcija |

WOLFGANG STEGMÜLLER. Tradicija ir originalumas šiuolaikinėje filosofijoje (61) • KĘSTUTIS NAVAKAS. Švento Kazimiero akmenys (39) • -pz-. Sekmadienio postilė (3) • Su anesteziologu, intensyviosios terapijos specialistu ADAMU MACIEJUMI kalbasi Piotras Stanisławskis. Ar toli iš šiapus iki anapus? (9) • JERZY ILLG. Laiškas Czesławui Miłoszui (26) • EGDŪNAS RAČIUS. Apie prievartą ir smurtą Kurane (13) • SIGITAS GEDA. Žydėjo mėlynos cikorijos (17) • LEVUTIS MALINAUSKAS. Šaudantis odekolonas (6) • SONATA ŽALNERAVIČIŪTĖ. Šuniškas laukimas plaukiojant ir plūduriuojant (1) • JONAS MEKAS. Eilės (42) • CASTOR&POLLUX. Verba de verbis (26) • ADOMAS PŪRAS. Kalno gatvės fizikas (3) • ALGIMANTAS ČERNIAUSKAS. Didžiajam Dzūkui – 125 (4) • GRO MANDT. Senovės tikėjimų fragmentai: gyvatė – daugiaprasmis skandinavų mitologijos simbolis (3) • GILBONĖ. Gyvenimo žanrai. Šokinėju per virvutę (2) • „Va kur“ – tekstai iš šiukšlyno (8) • aš irgi turiu gražių prisiminimų (370) • 2007 m. lapkričio 3 d. Nr. 41 (867) turinys (16) •

Tradicija ir originalumas šiuolaikinėje filosofijoje

WOLFGANG STEGMÜLLER

[skaityti komentarus]

iliustracija
Archyvas. 1992
Isabella Colonnello

Paprastai manoma, kad filosofijos problemos yra pastovios, o specialiųjų mokslų pažanga ir permainos apima ne tik teorijas, bet ir pačias problemas. Šiandien gamtos ir dvasios moksluose, taip pat ir matematikos disciplinose susiduriame su problemomis, kurios daugeliu požiūrių tapo kitokios, nei buvo dar visai neseniai. Viena vertus, jos nuolat kiek patikslinamos, kita vertus, kai kuriuos klausimus apskritai teįmanoma kelti pasiekus aukštesnes teorines pozicijas, anksčiau apskritai buvusias neprieinamas.

Ir priešingai – regis, pagrindiniai filosofijos klausimai išliko tokie patys, kokius prieš 2500 metų kėlė graikų mąstytojai, pirmieji sukūrę naują racionalią tradiciją. Nuo tol sprendžiant pasaulio mįsles jau nederėjo pasitelkti mitus ar religinį tikėjimą, šį sprendimą reikėjo atlikti grynu mąstymu, intuityviu pažinimu ir logine argumentacija. Taigi reikėjo spręsti metafizines problemas, susijusias su esminėmis galutinėmis visatos savybėmis ir principais, religijos filosofijos klausimus apie dieviškąjį pasaulio principą ir bet kokios baigtinės būties prasmę bei tikslą, etinius klausimus apie absoliučiai galiojančių ir žmogų, kaip veikiantį subjektą, įpareigojančių normų egzistavimą, taip pat logines ir pažinimo teorijos problemas, susijusias su žmogiško pažinimo būdais, apimtimi ir patikimumu.

Palyginti su šiais pastoviais uždaviniais, filosofinių sistemų mėginiai kinta laike. Aplinkybė, kad jau keletą tūkstantmečių vis iš naujo mėginama kurti tokias sistemas, liudija žmogaus atkaklumą ir nenuilstamumą sprendžiant „galutinius klausimus“, kita vertus, gali paskatinti padaryti pesimistinę išvadą, kad net tūkstantmetės žmogaus pastangos pateikti apibrėžtą ir neabejotiną atsakymą į bent vieną iš šių klausimų nebuvo vaisingos. Taigi susidaro vaizdas, kad filosofija – tai nuolatinė garbinga pastanga, vis dėlto neišvengiamai žlunganti dėl žmogaus baigtinumo, nuo seno verčiančio jį kelti daugiau klausimų, nei jis įstengia atsakyti pasitelkęs savo menkas dvasines išgales.

Požiūris, kad filosofinės problemos pastovios ir kad kartu nuolat kinta šių problemų sprendimai, nėra visiškai neteisingas. Iš tikrųjų daugelis šiuolaikinių filosofinių sistemų turi bendrumų tais klausimais, kuriuos aptinkame Descartes’o ir Leibnizo ar daug ankstesniuose Platono ir Aristotelio veikaluose. Vis dėlto suabsoliutinę šį aspektą pateiktume iškreiptą šiuolaikinės filosofijos paveikslą. Filosofiniame gyvenime kaip ir specialiuosiuose moksluose įvyko pokyčių, pažyminčių šiandienos filosofiją nepakartojamumo antspaudu, – ne tik dėl skelbiamų pažiūrų naujoviškumo ir iš dalies radikalumo, kokių nepasitaikė praeityje, bet ir dėl esminių problematikos pokyčių. Kai kurios iš anų „amžinų ir senų problemų“ apskritai išnyko – kaip nereikalingos, neteisingai keliamos ar apskritai beprasmės, – kai kurios išliko, tačiau tesudaro, taip sakant, veikiau neregimą pagrindą išplėtotų formuluočių, iš esmės besiskiriančių nuo tų problemų. Trumpai paminėsime keletą svarbiausių veiksnių, turėjusių didžiausią įtaką šiuolaikinei filosofijai.

(a) Kantas ir šiuolaikinė filosofija

Iš daugybės istorinių gijų, siejančių šiandienos filosofiją su filosofine praeitimi, ypač svarbus santykis su Kanto filosofija. Kantiškasis tikrovės pažinimo aiškinimas ir racionaliosios metafizikos kritika tapo pažinimo teorijos ir metafizikos lūžiu. Nedaug šiandien terasime filosofinių požiūrių, kurių nebūtų galima charakterizuoti ir pagal jų susidūrimo su kantiškuoju požiūriu būdą. Tai nereiškia, kad didžiąją šiandienos filosofinės literatūros dalį būtų galima suvokti kaip teigiamą Kanto idėjų tąsą. Taip anaiptol nėra. Poleminės pozicijos net dažnesnės už mėginimus atnaujinti ir toliau plėtoti Kanto idėjas. Tačiau ir tie mokymai, kurie užėmė poleminę poziciją, perėmė tam tikras Kanto problemas ir yra grindžiami jo idėjomis.

Kantas tikėjosi galįs parodyti, kad visas patirtinis pažinimas grindžiamas aprioriniu tikrovės pažinimu. Pastarąjį sudarą teisingi sintetiniai aprioriniai sprendiniai (Urteile), t. y. sprendiniai, kurių tiesą įstengiame įžvelgti, nors negalime įrodyti logiškai, kita vertus, jiems paremti mums nereikia jokių stebėjimo duomenų. Kanto problema buvo klausimas, kaip būtų galima paaiškinti šį paslaptingą teisingų sintetinių apriorinių sprendinių fenomeną ir kuo pagrįstas šių sprendinių galiojimas. Šią problemą jis sprendė pateikdamas transcendentalinio idealizmo teoriją, vaizdžiai užfiksuotą „kopernikiškojo posūkio“ paveikslu: pažinti tikrovę nereiškia atspindėti mūsų sąmonėje šiai transcendentinį pasaulį; priešingai, vadinamasis „tikrasis pasaulis“ – t. y. vienintelis mums žinomas empiriškai realus pasaulis, apie kurį galime kalbėti prasmingai, – savo pagrindinėmis savybėmis yra mūsų pačių (erdvinės-laikinės) tiesioginio suvokimo (Anschauung) gebos ir mūsų intelekto konstitucinis produktas. Pasak Kanto, aplinkybę, kad įstengiame pateikti adekvačius ir kartu nuo patyrimo nepriklausomus teiginius apie visatą, galima suprasti tik tokiu atveju, jei visata yra ne tikrovė, transcendentinė sąmonei, o transcendentalaus subjekto laimėjimas.

Naujesnioji filosofinė reakcija į Kanto teoriją trejopa. Pirmoji pritaria pagrindinei Kanto pozicijai. Tokiu atveju mėginama remtis Kanto išeities tašku, kartu apvalant jo sistemą nuo „metafizinių“, „ikikritinių“ liekanų, tai būdinga neokantizmui. Arba pradėjus nuo visiškai kitokių samprotavimų nei Kanto galiausiai vis dėlto centre atsiduria transcendentalaus subjekto, su kuriuo susiję visi esiniai, sąvoka. Tai būdinga, tarkime, vėlyvojo Husserlio veikalams, kuriuose fenomenologinis redukcijos metodas, anaiptol nekantiškas būdas, veda prie „transcendentaliai išvalytos sąmonės“, kaip subjektyvaus tikrovės poliaus, kuri išlieka kaip nepanaikinamas likutis atlikus mintyse pasaulio sunaikinimą ir kurios intencionaliu laimėjimu pasirodo esąs likęs pasaulis. Tai aptinkame ir Reiningerio veikaluose, jo filosofinis atramos taškas – tikrovės artumo ir metodinio solipsizmo pozicija – irgi atrodo nepanašus į Kanto metodą, tačiau galiausiai virsta transcendentaliu mokymu apie imanenciją.

Antroji reakcija – poleminė. Ją sudaro mėginimai atrasti kitą, naują tos pačios problemos sprendimą. Brentano savo akivaizdumo (Evidenz) filosofijoje pateikė kitokią sintetinių apriorinių sprendinių interpretaciją. N. Hartmannas savo ontologijoje pamėgino objektyvistiškai aiškinti pažinimą pasitelkdamas prielaidą, kad pagrindiniai mąstymo dėsniai (pažinimo kategorijos) bent iš dalies atitinka pasaulio principus (būties kategorijas). Häberlinas siekia apriorinį žinojimą apie pasaulį paaiškinti monistinės būties metafizikos pagrindu.

Trečioji reakcija irgi poleminė, tačiau iš esmės radikalesnė nei minėti požiūriai. Kalbame apie poziciją, kurią kantiškosios problematikos atžvilgiu užėmė modernusis empirizmas ir analitinė filosofija. Iki šiol Kanto sekėjai ir priešininkai ginčijosi tik dėl to, kaip reikėtų aiškinti sintetinį apriorinį pažinimą, o šie mokymai mėgina apskritai paneigti tokios diskusijos prasmę, neigdami pačią ginčo prielaidą, būtent sintetinių apriorinių sprendinių egzistavimą. Kantas ir realistiškai nusiteikę metafizikai ieškojo įvairių hipotezių, paaiškinančių sintetinių apriorinių sprendinių fenomeną. Tačiau ar šie sprendiniai yra išties priimtinas faktas? Schlickas, Carnapas ir kiti Vienos ratelio atstovai ir bemaž visi analitinės filosofijos atstovai tai neigia. Kartais neigiama, kad sintetiniai aprioriniai teiginiai egzistuoja; dažnai neigimas įgauna dar aštresnę formą, virsdamas teze, kad Kanto nusakytos sintetinio apriorinio tikrovės pažinimo sąvokos apskritai neįmanoma preciziškai apibrėžti. Taigi sintetinių apriorinių sprendinių problema be galo svarbi. Mat, jei teisingas šis neigiantis požiūris, apskritai nėra jokių specifiškai filosofinių teiginių apie tikrovę. Visi sintetiniai teiginiai tokiu atveju tesą patyrimo sprendiniai, kurių patikrinimą reikia perleisti empiriniams mokslams. Filosofija prarandanti bet kokią galimybę pateikti pagrįstus ir argumentuotus teiginius apie tikrovę ir turinti palikti tai atskiriems mokslams. Ji turinti atsigręžti į logiką, mokslo teoriją ir mokslo pagrindų tyrimą.

Tokių nuorodų turėtų pakakti, kad suvoktume pagrindinio Kanto klausimo svarbą ir primygtinumą šiandienos filosofijai.

(b) Filosofija, mokslas ir kultūra

Kantas paneigė metafizikos, kaip mokslo tradicine prasme, galimybę. Šis mokslinės metafizikos neigimas buvo neišvengiamas jo pažinimo teorijos padarinys. Antimetafizinė kritinė Kanto pozicija ir dabar labai įtakinga. Vis dėlto nepasitikėjimas bet kokia metafizikos forma, šiandien visuotinai paplitęs filosofijoje ir specialiuosiuose moksluose, turi ir kitų priežasčių.

Modernus žmogus apskritai skeptiškiau nusiteikęs už antikos ar viduramžių žmogų. Jam stinga anos naiviai patiklios laikysenos, sudarančios bet kokios religijos ir kartu metafizikos pagrindą; mat bet kuri metafizika arba tiesiog grindžiama religija, arba istoriškai išvedama iš toliau racionaliai nepateisinamo tikėjimo. Nenuostabu, kad plintant laikysenai, imanentinei štai-būties atžvilgiu, itin nepatikliai vertinančiai transcendentinius objektus, pradėjo atslūgti ir susidomėjimas metafiziniais samprotavimais, ir pasitikėjimas sėkmingu metafizinių problemų sprendimu.

Tačiau lemiamą reikšmę turėjo ne tik šis gyvenimo jausenos pokytis; mokslinės filosofijos srityje skeptišką laikyseną pirmiausia stiprino du veiksniai: viena vertus, vis didėjantis matematinių ir atskirų empirinių disciplinų griežtumas, pirmiausia didesni reikalavimai, keliami sąvokų aparato preciziškumui, loginių-matematinių įrodinėjimų tikslumui ir sintetinių mokslinių teiginių patikrinamumui. Metafizikos teiginiai bent jau tradiciniu pavidalu netenkino šių reikalavimų. Kitas veiksnys buvo filosofinių koncepcijų istorinio reliatyvumo suvokimas, grindžiamas daugiau nei dviejų tūkstantmečių filosofijos istorija, kurioje, tiesa, galima fiksuoti nuolatinę filosofinių sistemų kaitą, tačiau anaiptol ne vienareikšmiškai tiesiaeigę pažangą. Šiųdviejų momentų – didėjančio mokslinio griežtumo ir istorinio reliatyvumo suvokimo – svarba savo ruožtu turėjo didėti per istoriją, tad galiausiai dabar jie neišvengiamai tapo svarbiausi. Vis dėlto ir jie nenumarino metafizikos. Tiesa, šiuolaikinėje filosofijoje yra daugybė antimetafizinių srovių ir pirmiausia tokių, kurioms nė iš tolo neprilygsta Kanto tezė apie transcendentinės tikrovės nepažinumą. Tačiau kartu pasitaiko mėginimų naujai pagrįsti metafiziką. Kad šie mėginimai, jeigu jie rimti, turi įgyti kitokį pavidalą nei praeityje, savaime suprantama atsižvelgiant į paaštrėjusius išpuolius, kuriuos jie turėjo patirti dar tik kaip mėginimai; jie visada tegalėjo būti idėjiniai eskizai, pakankamai atsparūs, kad atlaikytų kriticizmo ir skepsio kovos krikštą.

Pabaiga kitame numeryje


Iš Wolfgang Stegmüller, Hauptströmungen der Gegenwartsphilosopie, I, Stuttgart: Alfred Kröner Verlag, 1989

Vertė Austėja Merkevičiūtė

 

Kultūros kalendorius
nuo 2011 m. Sausio

PATKPŠS

 1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31  

 1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28  

 1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31  

Nuorodos


Kultūros diskusijų forumas,
Kultūros vartai,
Kultūros institucijos,
Meno galerijos,
Meno bankas 
DAILĖ“, „VILNIUS“,
7 MENO DIENOS“,
ŠIAURĖS ATĖNAI“,
LITERATŪRA IR MENAS“,
NEMUNAS“,
UŽUPIO ŽURNALAS
Lietuva internete

 

Skaitytojų vertinimai


100349. Artūras iš Vilniaus2007-10-31 21:15
labas Austėja, Tu ne viena, mes irgi audžiame kažkaip kažką. Labai krūūūtai čia išvertei, bet Aš jo (Stegmiulerio) niekaip nevirškinu. Bet Aš nustebęs, kad Jis smuko į strūktualismą - o tai impozantiškai refleckt su mumis (kaip kokia boba jisai). Aš, pvz, ištatuoruočiau, kokiam ežerui ant kaktos šiuo žodžius ---- jaj per pasauliū

100370. velniūkštis AišV2007-11-01 02:03
šiaip gera rašliava dundukai ir šudo primala neblogai - ko tylit. Pasiimam kokį sakinį -

Tačiau lemiamą reikšmę turėjo ne tik šis gyvenimo jausenos pokytis; mokslinės filosofijos srityje skeptišką laikyseną pirmiausia stiprino du veiksniai: viena vertus, vis didėjantis matematinių ir atskirų empirinių disciplinų griežtumas, pirmiausia didesni reikalavimai, keliami sąvokų aparato preciziškumui, loginių-matematinių įrodinėjimų tikslumui ir sintetinių mokslinių teiginių patikrinamumui. Metafizikos teiginiai bent jau tradiciniu pavidalu netenkino šių reikalavimų. Kitas veiksnys buvo filosofinių koncepcijų istorinio reliatyvumo suvokimas, grindžiamas daugiau nei dviejų tūkstantmečių filosofijos istorija, kurioje, tiesa, galima fiksuoti nuolatinę filosofinių sistemų kaitą, tačiau anaiptol ne vienareikšmiškai tiesiaeigę pažangą. Šiųdviejų momentų – didėjančio mokslinio griežtumo ir istorinio reliatyvumo suvokimo – svarba savo ruožtu turėjo didėti per istoriją, tad galiausiai dabar jie neišvengiamai tapo svarbiausi.

.. tai nesąmonė, nes man atrodo, ,kaip niekad yra laisvas mokslas (greit auga net). Austėja mąsto ir kompiliuoja mintis iš baimės, kad.. o kas kad. Panelė yra exist kryžkelėje, džentelmenai!!!!! Bet, kas jos kvazimetalgalvoj - nulenkčiau savo makaulę... , pasiimčiau jąją, bet ar Ji važiuotų su manim į Osterraichą?

100394. Ula2007-11-01 13:42
Labai gera publikacija.

100398. velniūkščiui Aiškiai Velniūkščiui2007-11-01 15:00
"kaip niekad yra laisvas mokslas (greit auga net)". Laisvas nuo ko? Kaip niekad lyginant su kuo? Antraip primena tuščią lozungą (pvz., universiteto užkaboriuose ilgai besivoliojusį transparantą: "Stalin - lučšij drug fizkul`turnikov!"). Pagarbiai

100607. ckiukas(eksGalkauckiukas) pats sau2007-11-02 23:27
Su autoriaus teze,kad filosofinių koncepcijų istorinio reliatyvumo suvokimas stiprino skeptišką laikyseną mokslinės filosofijos srityje galima sutikti tik iš dalies. Skepticizmui daugiau įtakos darė ne koncepcijų istorinio reliatyvumo suvokimas, bet pats reliatyvumas kaipo toks. O padariniai juntami ir po šiai dienai. Eina sau.

100652. velniūkštis AišV ->vAV (greičiausiai Austėjai)2007-11-03 10:32
vis pirma Aš Lietuva turėjau omeny, tas Lietuvos mokslo lituanocentrizmas yra toks gajus dar vis, o tai peilis bet kokio pavidalo mokslui.

Taip, sutinku, vazdialis nikoks, bet net smulkaus kalibro analitikas pastebėtų du faktoriu:
  • Štatuose yra labai pakilęs mokslo finansavimas (vien tarp 1996-98 pakeltas daugiau nei 3 proc, o tai turbūt rekordas rinkos ekonomikos šalių istorijoje). Po štatų, tiksliai nežinau, bet Europa taip pat,  ir visos kitos "mokslinės šalys" vorele. Tai logiška, nes bendras finansinis produktas yra svarbus balansui. Ir jei Amerika surado galimybes, tai ir kiti net ne mąstydami "suranda". Nes kiekvienoje normalioje šalyje yra suprantama, kad ten niekada nebus perdaug. Tik štai su galimybėm kebliau.
  • Aišku, didžiulis chaosas ir sumaištis yra: vieniems džiuginantis (man, (iš to sektų mano laisvumo suvokimas)), kitus erzinantis. Bet tai niekas kas kitas, kaip paradigmų pasikeitimų fazės. O tai yra na jau toks natūralus dalykas. Juk tokias "alchemines" disciplinas, kaip psichologija, sociologija, edukologija ir ecc. keičia viena ir labai dar jauna, xxlogija (motyvologija). Na ir kaip įsivaizduojama, kad tai greit ir be perversijų pasikeis - tiesiog šansas, taip vadinamai socialinio dekadanso aplinkoj. O tai, kad kai kurios (na labiausiai kažkada ideologizuotos (paradoxas sic!!!) ir greičiausiai sugebančios įsisavinti babkes, jau tiksi:
    • Istorija, kaip Stegmiuleris geri pastebėjo. Dabar archeologai/istorikai prioritetiniuose diskantuose tyrinėja ne karų ženklų poveikius (ginklai, logistika, ..), ir ne verslo (socialinės/kultūrinės expansijos, jų saviorganizacinius forpostus (miestai, turgūs, ...), o švietimo struktūras, jų dinamiką, motyvaciją ir net pasekmes.
    • Socialiniuose irgi tas pats. Net tūlas Stegmiuleris tame dalyvauja pats (žinau, mačiau, kikenau). Jau niekas rimtai nedalyvauja islamo/judėjų konflikte, pvz. O apjungia į bendrą "taip vadinamų" Abraominių religijų socialinių "motyvų" erdvę. Tai ne tik zoroastrizmas (nacionalistinės jėgos kulto), bet ir lenino/stalino, Cinio (kinų antifeodalinio judėjimo napoleono), ar Maoceduno (kito kinų antifeodalinio judėjimo napoleono) komunizmo, kaip savotiško mazgo sociologijoj.
    • Šiaip man fizikos gaila - ji niekaip negali išlipti iš paskutinės fazės - enciklopedizmo; ir gęsta, kaip gamtos valdymo teorija. Velnias žino kas bus su ja. Bet nerimas yra jau kiekvieno fiziko dūšioj jau senai. Matematika keičia savo įrankių bazę (idėjas turiu omeny) taip greit, kad net Paskalis apsiverčia grabe jaučiu. Vertybių ir prioritetų perkainojimas yra toks totalus, kad net aklas nepastebėtų.

O tai ir yra <b>greit ir auga ir laisvai</b>, man atrodo. Pagarbiai

O dėl stalino tai gerbiu - bet stalinas ir sukūrė švietimo sistemą, kuriai iki šiol varvina Vakarų civilizacijos edukologai. Kaip savo laiku scholastai, finikiečiai ir kiti unifikatoriai


100653. korektūra (AišV)2007-11-03 10:41
visų pirma Aš ne Lietuvą turėjau omeny ........

.......O dėl stalino, tai gerbiu tokį kompliuotą pastebėjimą (žinoma, stalinas tai pasekmė socialinio dekadanso rosioj) - bet ........

Gal e.redakcija pakeis? P.S. ir visur kitur reiktų, bet tingiu

100654. AišV2007-11-03 10:51
visiems kitiems - Kantas man, ir ne tik man, pagal stilistiką ir saviprieštaravimus ir neišbaigiamumą yra Koranos broliukas. Juokas tik jama ir tiek. A ne, Račai.

100659. klausimas Aišv2007-11-03 11:41
Ar skaitėte Kanto originalą, ar lietuvišką vertimą, kuris tikrai nepaskaitomas, nors mintį turėdamas kantrybės daugmaž gali suprasti? Deja, vertėjas paliko grynai vokišką sakinių struktūrą, visiškai svetimą lietuvių kalbai. Tad gal ne visai pagrįstai koneveikiate a. a. Karaliaučiaus keistuolį?

100665. AišV2007-11-03 12:26
ne, lietuviško neskaičiau (tik kiek VU spaudė) - skaičiau ruso, Vorobjovo kompiliacijas. Na, dar seriją staipsnių Science, Sociological rewiev. Račas iš principo, taip pat šneka lygiai taip pat apie Koraną, beje - sufidų poreikį interpretacijai, Kantas taip pat teigia tokius dalykus, kurie kokiam kinui ar arabui reikalingi interpretacijų/paaiškinimų, ir pvz. kinų universitetai jau formuoja savotišką sufidų (interpretatorių) gvardiją ne tik Kantui, bet daugiausia Kantui, nes jie labai gerbia Stegmiulerį, o jis akcentuoja Vakarų kultūrą su Kanto kauke.

Kita vertus, su Jumis diskutuoti yra beprasmiška - iš kur jus ištraukėt, kad Aš Kantą koneveikiu. Tai labai fundamentalistiška (nemoksliška) iš Jūsų pusės. Man tik juokinga situacija, kad panašių doktrinų apologetai taip konfliktuoja įjungę rimtą fizionomiją. Prie ko čia Kantas ar Koranas. Kažkoks homosovieticas tamsta, niečital no osuždaju.

100667. atsiprašau2007-11-03 12:43
"Kantas man, ir ne tik man, pagal stilistiką ir saviprieštaravimus ir neišbaigiamumą yra Koranos broliukas" - nekoneveikiate, tik kritikuojate (vaizdingesnį žodį parinkau).

100680. artturui is vilniaus.. :-) 2007-11-03 15:55
kas yra `jaj per pasauliu`

100686. artturas is vilniaus.. :-)2007-11-03 17:41
nieko negaliu padėt 100680, nesuprantu; galų gale čia buvo rašyta Jums, o ne sau.

100694. ivs 2007-11-03 18:20
hezau, kokia ilga izanga ir nieko joje nei ja nepasakyta. nu, vaziuojam toliau.

100698. art turui iš Vilniaus2007-11-03 18:42
O ką vakar gėrėt? (fu, koks netaktiškas smalsumas)

100699. ivs 2007-11-03 18:43
nu ne, perskaiciau izanga dar karta. si karta is apacios i virsu ir vel zemyn - vis tiek neradau nieko, del ko butu buve verta ja rasyti. as palikciau du sakinius:

Požiūris, kad filosofinės problemos pastovios ir kad kartu nuolat kinta šių problemų sprendimai, nėra visiškai neteisingas. Trumpai paminėsime keletą svarbiausių veiksnių, turėjusių didžiausią įtaką šiuolaikinei filosofijai.

nes antraip susidaro ispudis, kad filosofas ne nuolat garbingai stengiasi, o vis dėlto neišvengiamai daugzodziauja, keldamas daugiau klausimų, nei įstengia atsakyti pasitelkęs savo menkas dvasines išgales.

kokias dar menkas dvasines isgales? pagal ka matuojamos dvasines isgalios? kas per zodis "isgalios"? nesakysiu, su kuo asocijuojasi del priesdelio "is". dvasines galios yra kol kas nepamatuotos, mano ziniomis. negali zinoti, ar jos dideles ar mazos, nes juk nera su kuo palyginti. galima palyginti tik numanomos dvasines galios panaudojima. vieniems ji (dvasine galia) yra tikras darbo irankis, kitiems - terra incognita arba america, kurios tiesiog nera ir negali buti, nes ja jau butu kas nors atrades, pasak tu, kurie ziurejo ispustomis akimis i ant smaigalio pasatyta kiausini.

100704. ivsui2007-11-03 19:27
čia išgalės (galininkas "išgales"), ne išgalios (būtų gal. "išgalias"). LKZ pateikia reikšmes: išgalė - turėjimas jėgų, pajėga, galėjimas, jėga; sugebėjimas, galia, gebėjimas...

100706. ivs 2007-11-03 19:51
as ne apie tai, as apie zodziu jungini "menkos dvasines isgales" . apie zodzius isgalĖ ir isgaliA - galima butu daugzodziauti atskirai.

100708. ivs 2007-11-03 19:56
"realistiškai nusiteikę metafizikai" - cia oksimoronas, ar rimtai?

100710. >ivs2007-11-03 20:07
metafizikams metafizika - pati realiausia realybė, taigi, jokio prieštaravimo...

100711. ivs 2007-11-03 20:12
"naiviai patiklios laikysenos, sudarančios bet kokios religijos ir kartu metafizikos pagrindą" - cia nuo kada taip? ar kas nors esate mate gyva patiklu tikinti ir realistiskai nusiteikusi metafizika? nu, bet gal as gyvenu kokiam kitam pasauly, ka as dabar zinau.

100712. ivs :))2007-11-03 20:20
aha, sąvokų aparato preciziškumu ir ir sintetinių mokslinių teiginių patikrinamumu reiktų rimtai susirupinti, nes viskas labai reliatyvu. tikrai tikrai.

100719. kruopštuolis ivs, 2007-11-03 20:47
žaviuosi (oj, gal čia ivsė?). Vis tiek žaviuosi.

100729. ivs2007-11-03 21:35
cia as, as, ivs`ė, bet vadinu tatai ne kruopstumu, o dinderio musimu. as labai megstu dinderi musti. is to, tuo ir uztatai gyvenu.

100733. pavydas pjauna, aš irgi norėčiau dinderį mušti, 2007-11-03 21:47
ypač jei iš to (nebūtinai vien tuo) galima gyventi. Kur galima būtų pasimokyti? Ar čia be privataus pašaukimo neišsiversi?

100786. ragana Kornelija2007-11-04 16:49
mane suintrigavo vienintelis dalykas - "amžinos ir senos problemos", kurios išnyko. bet kai iš sekančio sakinio supratau, kad apie jas kalbos nebus, tai toliau ir neskaičiau - tenusišaunie su savo pirmąja pasaulio priežastimi Kantu.

100810. yammam2007-11-04 19:28
kai prasidės kalėdinės akcijos , nueikite į beliakoki centrypkrebi ir pati isitikinsite kiek daug dar turime ne tik realistiškai bet ir pragmatiškai nusiteikusių metafiziku ...žinoma jei tik turėsite toki ynori ir jei jums leis yžgalės ...:))

100840. @2007-11-04 23:13
ynori turiu, yžgalių - gal, bet kas tas centrypkrebi? Kažkaip su prekyba susiję?

100866. kiskis p2007-11-05 11:04
tai susije su krebais.

100893. atsilikęs2007-11-05 13:44
žinau tik skrebus

100931. @2007-11-05 21:07
kaip jūs susije su ivs taip ir centrypkriebis su prekyba ...su visa yžgarbe jūsu y

100936. Vardenis2007-11-05 22:33
Vo vo mieli kolegos> Isiterpiu antiprincipingai,nes sioj vietoj reiktu isizureti i visu uzmirsta gerb.Delioza ir jo ""konceptus"".Kodel gi?A todel ""gi"",kad Pac C++ kurejas daugetukstantiniuose paaiskinimuose (ipatingiems bukiems) logine eilute isaiskino i kur reik kreipt demesi "gaminant "eurosajungos "programavimol daukumentus kabutese ,norint diskursa pradet,vystyt ir test.Net ne siulau ,o tai yta privalomas pradinis kursas :)Tas velnio c++ kurejoas bliobliosartumas is programavimo kalba C++.Eurosajungos dokumentai formaliai rengiami ne pagal kakiu sekretoriu paskaityrtas uinstrukcijas is sios knygos referatu.O.O is sios kyngos citatu.:)(Sypsenele)

100937. Nezinote?-juokelis2007-11-05 22:36
Acakykite ,prasom,kas yra ""ES programavimo dokumentas""?:))))

100938. b...ibis2007-11-05 22:38
Mes -runkeliai -mes -nezinom:)

100939. 22007-11-05 22:40
Tuoj-lohai:)Man idomu satenu textai-as maniakaz:)))

100940. Nepraraskit budrumo del loginio griozio.2007-11-05 22:52
Ha ha:) Bicai -tuoj uzversiu ruskom sentencijos i citatom-tai gennialusis Bjornas Straustropas:)---=---pasiruoslit bangos greunamai jegai ,vaikeliai:)

100941. archyvaras2007-11-05 22:55
Eik tu sau, kokie baisumai laukia mūsų!?

100942. Izanga2007-11-05 22:59
* ПРОЕКТИРОВАНИЕ И РАЗВИТИЕ "Серебряной пули не существует." - Ф. Брукс В этой главе обсуждаются подходы к разработке программного обеспечения. Обсуждение затрагивает как технические, так и социологические аспекты процесса развития программного обеспечения. Программа рассматривается как модель реальности, в которой каждый класс представляет определенное понятие. Ключевая задача проектирования состоит в определении доступной и защищенной частей интерфейса класса, исходя из которых определяются различные части программы. Определение этих интерфейсов есть итеративный процесс, обычно требующий экспериментирования. Упор делается на важной роли проектирования и организационных факторов в процессе развития программного обеспечения.

100943. 1.2007-11-05 23:01
Taip ,arhyvarai,Tu teisus Taves laukia tavo baisiausiais "baisumas"---sidabrine kulka:))

100944. 22007-11-05 23:04
Создание любой нетривиальной программной системы - сложная и часто выматывающая задача. Даже для отдельного программиста собственно запись операторов программы есть только часть всей работы. Обычно анализ всей задачи, проектирование программы в целом, документация, тестирование, сопровождение и управление всем этим затмевает задачу написания и отладки отдельных частей программы. Конечно, можно все эти виды деятельности обозначить как "программирование" и затем вполне обоснованно утверждать: "Я не проектирую, я только программирую". Но как бы не назывались отдельные виды деятельности, бывает иногда важно сосредоточиться на них по отдельности, так же как иногда бывает важно рассмотреть весь процесс в целом. Стремясь поскорее довести систему до поставки, нельзя упускать из вида ни детали, ни картину в целом, хотя довольно часто происходит именно это. Эта глава сосредоточена на тех частях процесса развития программы, которые не связаны с написанием и отладкой отдельных программных фрагментов. Обсуждение здесь менее точное и детальное, чем во всех остальных частях книги, где рассматриваются конкретные черты языка или определенные приемы программирования. Это неизбежно, поскольку нет готовых рецептов создания хороших программ. Детальные рецепты "как" могут существовать только для определенных, хорошо разработанных областей применения, но не для достаточно широких областей приложения. В программировании не существует заменителей разума, опыта и вкуса. Следовательно, в этой главе вы найдете только общие рекомендации, альтернативные подходы и осторожные выводы. Сложность данной тематики связана с абстрактной природой программ и тем фактом, что приемы, применимые для небольших проектов (скажем, программа в 10000 строк, созданная одним или двумя людьми), не распространяются на средние или большие проекты. По этой причине иногда мы приводим примеры из менее абстрактных инженерных дисциплин, а не только из программирования. Не преминем напомнить, что "доказательство по аналогии" является мошенничеством, и аналогии служат здесь только в качестве примера. Понятия проектирования, формулируемые с помощью определенных конструкций С++, и поясняемые примерами, мы будем обсуждать в главах 12 и 13. Предложенные в этой главе рекомендации, отражаются как в самом языке С++, так и в решении конкретных программных задач по всей книге. Снова напомним, что в силу чрезвычайного разнообразия областей применения, программистов и среды, в которой развивается программная система, нельзя ожидать, что каждый вывод, сделанный здесь, будет прямо применим для вашей задачи. Эти выводы применимы во многих самых разных случаях, но их нельзя считать универсальными законами. Смотрите на них со здоровой долей скептицизма. Язык С++ можно просто использовать как лучший вариант С. Однако, поступая так, мы не используем наиболее мощные возможности С++ и определенные приемы программирования на нем, так что реализуем лишь малую долю потенциальных достоинств С++. В этой главе излагается такой подход к проектированию, который позволяет полностью использовать возможности абстрактных данных и средства объектного программирования С++. Такой подход обычно называют объектно-ориентированным проектированием. В главе 12 обсуждаются основные приемы программирования на С++, там же содержится предостережение от сомнительных идей, что есть только один "правильный" способ использования С++, и что для получения максимального выигрыша следует всякое средство С++ применять в любой программе ($$12.1). Укажем некоторые основные принципы, рассматриваемые в этой главе: - из всех вопросов, связанных с процессом развития программного обеспечения, самый важный - четко сознавать, что собственно вы пытаетесь создать. - Успешный процесс развития программного обеспечения - это дли- тельный процесс. - Системы, которые мы создаем, стремятся к пределу сложности по отношению как к самим создателям, так и используемым средствам. - Эксперимент является необходимой частью проекта для разработки всех нетривиальных программных систем. - Проектирование и программирование - это итеративные процессы. - Различные стадии проекта программного обеспечения, такие как: проектирование, программирование и тестирование - невозможно строго разделить. - Проектирование и программирование нельзя рассматривать в отрыве от вопросов управления этими видами деятельности. Недооценить любой из этих принципов очень легко, но обычно накладно. В то же время трудно воплотить эти абстрактные идеи на практике. Здесь необходим определенный опыт. Подобно построению лодки, езде на велосипеде или программированию проектирование - это искусство, которым нельзя овладеть только с помощью теоретических занятий. Может быть все эти емкие принципы можно сжать в один: проектирование и программирование - виды человеческой деятельности; забудь про это - и все пропало. Слишком часто мы забываем про это и рассматриваем процесс развития программного обеспечения просто как "последовательность хорошо определенных шагов, на каждом из которых по заданным правилам производятся некоторые действия над входными данными, чтобы получить требуемый результат". Сам стиль предыдущего предложения выдает присутствие человеческой природы! Эта глава относится к проектам, которые можно считать честолюбивыми, если учитывать ресурсы и опыт людей, создающих систему. Похоже, это в природе как индивидуума, так и организации - браться за проекты на пределе своих возможностей. Если задача не содержит определенный вызов, нет смысла уделять особое внимание ее проектированию. Такие задачи решаются в рамках уже устоявшейся структуры, которую не следует разрушать. Только если замахиваются на что-то амбициозное, появляется потребность в новых, более мощных средствах и приемах. Кроме того, существует тенденция у тех, кто "знает как делать", перепоручать проект новичкам, которые не имеют таких знаний. Не существует "единственного правильного способа" для проектирования и создания всей системы. Я бы считал веру в "единственный правильный способ" детской болезнью, если бы этой болезнью слишком часто не заболевали и опытные программисты. Напомним еще раз: только по той причине, что прием успешно использовался в течение года для одного проекта, не следует, что он без всяких изменений окажется столь же полезен для другого человека или другой задачи. Всегда важно не иметь предубеждений. Убеждение в том, что нет единственно верного решения, пронизывает весь проект языка С++, и, в основном, по этой причине в первом издании книги не было раздела, посвященного проектированию: я не хотел, чтобы его рассматривали как "манифест" моих личных симпатий. По этой же причине здесь, как и в главах 12 и 13, нет четко определенного взгляда на процесс развития программного обеспечения, скорее здесь просто дается обсуждение определенного круга, часто возникающих, вопросов и предлагаются некоторые решения, оказавшиеся полезными в определенных условиях. За этим введением следует краткое обсуждение целей и средств развития программного обеспечения в $$11.2, а дальше глава распадается на две основных части: - $$11.3 содержит описание процесса развития программного обеспечения. - $$11.4 содержит некоторые практические рекомендации по организации этого процесса. Взаимосвязь между проектированием и языком программирования обсуждается в главе 12, а глава 13 посвящена вопросам проектирования библиотек для С++. Очевидно, большая часть рассуждений относится к программным проектам большого объема. Читатели, которые не участвуют в таких разработках, могут сидеть спокойно и радоваться, что все эти ужасы их миновали, или же они могут выбрать вопросы, касающиеся только их интересов. Нет нижней границы размера программы, начиная с которой имеет смысл заняться проектированием прежде, чем начать писать программу. Однако все-таки есть нижняя граница, начиная с которой можно использовать какие-либо методы проектирования. Вопросы, связанные с размером, обсуждаются в $$11.4.2. Труднее всего в программных проектах бороться с их сложностью. Есть только один общий способ борьбы со сложностью: разделяй и властвуй. Если задачу удалось разделить на две подзадачи, которые можно решать в отдельности, то можно считать ее решенной за счет разделения более, чем наполовину. Этот простой принцип применим для удивительно большого числа ситуаций. В частности, использование модулей или классов при разработке программных систем позволяет разбить программу на две части: часть реализации и часть, открытую пользователю - которые связаны между собой (в идеале) вполне определенным интерфейсом. Это основной, внутренне присущий программированию, принцип борьбы со сложностью. Подобно этому и процесс проектирования программы можно разбить на отдельные виды деятельности с четко определенным (в идеале) взаимодействием между людьми, участвующими в них. Это основной, внутренне присущий проектированию, принцип борьбы со сложностью и подход к управлению людьми,занятыми в проекте. В обоих случаях выделение частей и определение интерфейса между частями - это то место, где требуется максимум опыта и чутья. Такое выделение не является чисто механическим процессом, обычно оно требует проницательности, которая может появиться только в результате доско- нального понимания системы на различных уровнях абстракции (см. $$11.3.3, $$12.2.1 и $$13.3). Близорукий взгляд на программу или на процесс разработки программного обеспечения часто приводит к дефектной системе. Отметим, что как программы, так и программистов разделить просто. Труднее достигнуть эффективного взаимодействия между участниками по обе стороны границы, не нарушая ее и не делая взаимодействие слишком жестким. Здесь предложен определенный подход к проектированию, а не полное формальное описание метода проектирования. Такое описание выходит за предметную область книги. Подход, предложенный здесь, можно применять с различной степенью формализации, и он может служить базой для различных формальных спецификаций. В тоже время нельзя считать эту главу рефератом, и здесь не делается попытка рассмотреть каждую тему, относящуюся к процессу разработки программ или изложить каждую точку зрения. Это тоже выходит за предметную область книги. Реферат по этой тематике можно найти в [2]. В этой книге используется достаточно общая и традиционная терминология. Самые "интересные" термины, как: проектирование, прототип, программист - имеют в литературе несколько определений, часто противоречащих друг другу, поэтому предостерегаем вас от того, чтобы, исходя из принятых в вашем окружении определений терминов, вы не вынесли из книги то, на что автор совершенно не рассчитыва

100945. Gintaras2007-11-05 23:08
SKAITYT REIKIA VISAK _DAUG_IR IDEMIAI.LINKI SEKMES>BUKITE SUSIKAUPE IR IDEMUS> JUSU NEERUDICIJA TUOJ PAT ATSISPINDES JUSU KOMENTARUOSE>NERIZIKUOKITE SAVO NEKANTRUMU> he he:)))

100946. ES2007-11-05 23:09
Цель программирования - создать продукт, удовлетворяющий пользователя. Важнейшим средством для достижении этой цели является создание программы с ясной внутренней структурой и воспитание коллектива программистов и разработчиков, имеющих достаточный опыт и мотивацию, чтобы быстро и эффективно реагировать на все изменения. Почему это так? Ведь внутрення структура программы и процесс, с помощью которого она получена, в идеале никак не касаются конечного пользователя. Более того, если конечный пользователь почему-то интересуется тем, как написана программа, то что-то с этой программой не так. Почему, несмотря на это, так важны структура программы и люди, ее создавшие? В конце концов конечный пользователь ничего об этом не должен знать. Ясная внутренняя структура программы облегчает: - тестирование, - переносимость, - сопровождение, - расширение, - реорганизацию и - понимание. Главное здесь в том, что любая удачная большая программа имеет долгую жизнь, в течение которой над ней работают поколения программистов и разработчиков, она переносится на новую машину, приспосабливается к непредусмотренным требованиям и несколько раз перестраивается. Во все время жизни необходимо в приемлемое время и с допустимым числом ошибок выдавать версии программы. Не планировать все это - все равно, что запланировать неудачу. Отметим, что, хотя в идеальном случае случае пользователи не должны знать внутреннюю структуру системы, на практике они обычно хотят ее знать. Например, пользователь может желать познакомиться в деталях с разработкой системы с целью научиться контролировать возможности и надежность системы на случай переделок и расширений. Если рассматриваемый программный продукт есть не полная система, а набор библиотек для получения программных систем, то пользователь захочет узнать побольше "деталей", чтобы они служили источником идей и помогали лучше использовать библиотеку. Нужно уметь очень точно определить объем проектирования программы. Недостаточный объем приводит к бесконечному срезанию острых углов ("побыстрее передадим систему, а ошибку устраним в следующей версии"). Избыточный объем приводит к усложненному описанию системы, в котором существенное теряется в формальностях, в результате чего при реорганизации программы получение работающей версии затягивается ("новая структура намного лучше старой, пользователь согласен ждать ради нее"). К тому же возникают такие потребности в ресурсах, которые непозволительны для большинства потенциальных пользователей. Выбор объема проектирования - самый трудный момент в разработке, именно здесь проявляется талант и опыт. Выбор трудно сделать и для одного программиста или разработчика, но он еще труднее для больших задач, где занято много людей разного уровня квалификации. Организация должна создавать программный продукт и сопровождать его, несмотря на изменения в штате, в направлении работы или в управляющей структуре. Распространенный способ решения этих проблем заключался в попытке сведения процесса создания системы к нескольким относительно простым задачам, укладывающимся в жесткую структуру. Например, создать группу легко обучаемых (дешевых) и взаимозаменяемых программистов низкого уровня ("кодировщиков") и группу не таких дешевых, но взаимозаменяемых (а значит также не уникальных) разработчиков. Считается, что кодировщики не принимают решений по проектированию, а разработчики не утруждают себя "грязными" подробностями кодирования. Обычно такой подход приводит к неудаче, а где он срабатывает, получается слишком громоздкая система с плохими характеристиками. Недостатки такого подхода состоят в следующем: - слабое взаимодействие между программистами и разработчиками приводит к неэффективности, промедлению, упущенным возможностям и повторению ошибок из-за плохого учета и отсутствия обмена опытом; - сужение области творчества разработчиков приводит к слабому профессиональному росту, безынициативности, небрежности и большой текучести кадров. По сути, подобные системы - это бесполезная трата редких человеческих талантов. Создание структуры, в рамках которой люди могут найти применение разным талантам, овладеть новым родом деятельности и участвовать в творческой работе - это не только благородное дело, но и практичное, коммерчески выгодное предприятие. С другой стороны, нельзя создать систему, представить документацию по ней и бесконечно ее сопровождать без некоторой жесткой организационной структуры. Для чисто новаторского проекта хорошо начать с того, что просто найти лучших специалистов и позволить им решать задачу в соответствии с их идеями. Но по мере развития проекта требуется все больше планирования, специализации и строго определенного взаимодействия между занятыми в нем людьми. Под строго определенным понимается не математическая или автоматически верифицируемая запись (хотя это безусловно хорошо там, где возможно и применимо), а скорее набор указаний по записи, именованию, документации, тестированию и т.п. Но и здесь необходимо чувство меры. Слишком жесткая структура может мешать росту и затруднять совершенствование. Здесь подвергается проверке талант и опыт менеджера. Для отдельного работника аналогичная проблема сводится к определению, где нужно проявить смекалку, а где действовать по рецептам. Можно рекомендовать планировать не на период до выдачи следующей версии системы, а на более долгий срок. Строить планы только до выпуска очередной версии - значит планировать неудачу. Нужно иметь организацию и стратегию развития программного обеспечения, которые нацелены на создание и поддержание многих версий разных систем, т.е. нужно многократное планирование успеха. Цель проектирования в выработке ясной и относительно простой внутренней структуры программы, называемой иногда архитектурой, иными словами каркаса, в который укладываются отдельные программные фрагменты, и который помогает написанию этих фрагментов. Проект - конечный результат процесса проектирования (если только бывает конечный продукт у итеративного процесса). Он является средоточием взаимодействий между разработчиком и программистом и между программистами. Здесь необходимо соблюсти чувство меры. Если я, как отдельный программист, проектирую небольшую программу, которую собираюсь написать завтра, то точность и полнота описания проекта может свестись к нескольким каракулям на обратной стороне конверта. На другом полюсе находится система, над которой работают сотни программистов и разработчиков, и здесь могут потребоваться тома тщательно составленных спецификаций проекта на формальном или полуформальном языке. Определение нужной степени точности, детализации и формальности проектирования является уже само по себе нетривиальной технической и административной задачей. Далее будет предполагаться, что проект системы записывается как ряд определений классов (в которых частные описания опущены как лишние детали) и взаимоотношений между ними. Это упрощение, т.к. конкретный проект может учитывать: вопросы параллельности, использование глобального пространства имен, использование глобальных функций и данных, построение программы для минимизации перетрансляции, устойчивость, многомашинный режим и т.п. Но при обсуждении на данном уровне детализации без упрощения не обойтись, а классы в контексте С++ являются ключевым понятием проектирования. Некоторые из указанных вопросов будут обсуждаться ниже, а те, которые прямо затрагивают проектирование библиотек С++, будут рассмотрены в главе 13. Более подробное обсуждение и примеры определенных методов объектно- ориентированного проектирования содержатся в [2]. Мы сознательно не проводили четкого разделения анализа и проектирования, поскольку обсуждение их различий выходит за рамки этой книги, и оно зависит от применяемых методов проектирования. Главное в том, чтобы выбрать метод анализа, подходящий для метода проектирования, и выбрать метод проектирования, подходящий для стиля программирования и используемого языка.

100947. Mana genialiusizdelozas:)2007-11-05 23:14
11.3 Процесс развития Процесс развития программного обеспечения - это итеративный и расширяющийся процесс. По мере развития каждая стадия повторяется многократно, и при всяком возврате на некоторую стадию процесса уточняется конечный продукт, получаемый на этой стадии. В общем случае процесс не имеет ни начала, ни конца, поскольку, проектируя и реализуя систему, вы начинаете, используя как базу другие проекты, библиотеки и прикладные системы, в конце работы после вас остается описание проекта и программа, которые другие могут уточнять, модифицировать, расширять и переносить. Естественно конкретный проект имеет определенное начало и конец, и важно (хотя часто удивительно трудно) четко и строго ограничить время и область действия проекта. Но заявление, что вы начинаете с "чистого листа", может привести к серьезным проблемам для вас, также как и позиция, что после передачи окончательной версии - хоть потоп, вызовет серьезные проблемы для ваших последователей (или для вас в новой роли). Из этого вытекает, что следующие разделы можно читать в любом порядке, поскольку вопросы проектирования и реализации могут в реальном проекте переплетаться почти произвольно. Именно, "проект" почти всегда подвергается перепроектированию на основе предыдущего проекта, определенного опыта реализации, ограничений, накладываемых сроками, мастерством работников, вопросами совместимости и т.п. Здесь основная трудность для менеджера или разработчика или программиста в том, чтобы создать такой порядок в этом процессе, который не препятствует усовершенствованиям и не запрещает повторные проходы, необходимые для успешного развития. У процесса развития три стадии: - Анализ: определение области задачи. - Проектирование: создание общей структуры системы. - Реализация: программирование и тестирование. Не забудьте об итеративной природе этих процессов (неспроста стадии не были пронумерованы), и заметьте, что никакие важные аспекты процесса развития программы не выделяются в отдельные стадии, поскольку они должны допускать: - Экспериментирование. - Тестирование. - Анализ проектирования и реализации. - Документирование. - Сопровождение. Сопровождение программного обеспечения рассматривается просто как еще несколько проходов по стадиям процесса развития (см. также $$11.3.6). Очень важно, чтобы анализ, проектирование и реализация не были слишком оторваны друг от друга, и чтобы люди, принимающие в них участие, были одного уровня квалификации для налаживания эффективных контактов. В больших проектах слишком часто бывает иначе. В идеале, в процессе развития проекта работники должны сами переходить с одной стадии на другую: лучший способ передачи тонкой информации - это использовать голову работника. К сожалению, в организациях часто устанавливают барьеры для таких переходов, например, у разработчика может быть более высокий статус и (или) более высокий оклад, чем у "простого" программиста. Не принято, чтобы сотрудники ходили по отделам с целью набраться опыта и знаний, но пусть, по крайней мере, будут регулярными собеседования сотрудников, занятых на разных стадиях проекта. Для средних и малых проектов обычно не делают различия между анализом и проектированием - эти стадии сливаются в одну. Для малых проектов также не разделяют проектирование и программирование. Конечно, тем самым решается проблема взаимодействия. Для данного проекта важно найти подходящую степень формализации и выдержать нужную степень разделения между стадиями ($$11.4.2). Нет единственно верного способа для этого. Приведенная здесь модель процесса развития программного обеспечения радикально отличается от традиционной модели "каскад" (waterfall). В последней процесс развития протекает линейно от стадии анализа до стадии тестирования. Основной недостаток модели каскад тот, что в ней информация движется только в одном направлении. Если выявлена проблема "ниже по течению", то возникает сильное методологическое и организационное давление, чтобы решить проблему на данном уровне, не затрагивая предыдущих стадий процесса. Отсутствие повторных проходов приводит к дефектному проекту, а в результате локального устранения проблем получается искаженная реализация. В тех неизбежных случаях, когда информация должна быть передана назад к источнику ее получения и вызвать изменения в проекте, мы получим лишь слабое "колыхание" на всех уровнях системы, стремящейся подавить внесенное изменение, а значит система плохо приспособлена к изменениям. Аргумент в пользу "никаких изменений" или "только локальные изменения" часто сводится к тому, что один отдел не хочет перекладывать большую работу на другой отдел "ради их же блага". Часто бывает так, что ко времени, когда ошибка уже найдена, исписано столько бумаги относительно ошибочного решения, что усилия, нужные на исправление документации, затмевают усилия для исправления самой программы. Таким образом, бумажная работа может стать главной проблемой процесса создания системы. Конечно, такие проблемы могут быть и возникают в процессе развития больших систем. В конце концов, определенная работа с бумагами необходима. Но выбор линейной модели развития (каскад) многократно увеличивает вероятность, что эта проблема выйдет из-под контроля. Недостаток модели каскад в отсутствии повторных проходов и неспособности реагировать на изменения. Опасность предлагаемой здесь итеративной модели состоит в искушении заменить размышление и реальное развитие на последовательность бесконечных изменений. Тот и другой недостатки легче указать, чем устранить, и для того, кто организует работу, легко принять простую активность за реальный прогресс. Вы можете уделять пристальное внимание деталям, использовать разумные приемы управления, развитую технологию, но ничто не спасет вас, если нет ясного понимания того, что вы пытаетесь создать. Больше всего проектов проваливалось именно из-за отсутствия хорошо сформулированных реалистичных целей, а не по какой-либо иной причине. Что бы вы не делали и чем бы не занимались, надо ясно представлять имеющиеся у вас средства, ставить достижимые цели и ориентиры и не искать технических решений социологических проблем. С другой стороны, надо применять только адекватную технологию, даже если она потребует затрат,- люди работают лучше, имея адекватные средства и приемлемую среду. Не заблуждайтесь, думая, что легко выполнить эти рекомендации.

100948. Jau nuobodu:)2007-11-05 23:16
11.3.1 Цикл развития Процесс развития системы - это итеративная деятельность. Основной цикл сводится к повторяемым в следующей последовательности шагам: [1] Создать общее описание проекта. [2] Выделить стандартные компоненты. [a] Подогнать компоненты под данный проект. [3] Создать новые стандартные компоненты. [a] Подогнать компоненты под данный проект. [4] Составить уточненное описание проекта. В качестве примера рассмотрим автомобильный завод. Проект должен начинаться с самого общего описания новой машины. Этот первый шаг базируется на некотором анализе и описании машины в самых общих терминах, которые скорее относятся к предполагаемому использованию, чем к характеристикам желаемых возможностей машины. Часто самой трудной частью проекта бывает выбор желаемых возможностей, или, точнее, определение относительно простого критерия выбора желаемых возможностей. Удача здесь, как правило, является результатом работы отдельного проницательного человека и часто называется предвидением. Слишком типично как раз отсутствие ясных целей, что приводит к неуверенно развивающимся или просто проваливающимся проектам. Итак, допустим необходимо создать машину среднего размера с четырьмя дверцами и достаточно мощным мотором. Очевидно, что на первом этапе проекта не следует начинать проектирование машины (и всех ее компонентов) с нуля. Хотя программист или разработчик программного обеспечения в подобных обстоятельствах поступит именно так. На первом этапе надо выяснить, какие компоненты доступны на вашем собственном складе и какие можно получить от надежных поставщиков. Найденные таким образом компоненты не обязательно в точности подойдут для новой машины. Всегда требуется подгонка компонентов. Может быть даже потребуется изменить характеристики "следующей версии" выбранных компонентов, чтобы сделать их пригодными для проекта. Например, может существовать вполне пригодный мотор, вырабатывающий немного меньшую мощность.Тогда или вы, или поставщик мотора должны предложить, не изменяя общего описания проекта, в качестве компенсации дополнительный зарядный генератор. Заметим, что сделать это,"не изменяя общего описания проекта", маловероятно, если только само описание не приспособлено к определенной подгонке. Обычно подобная подгонка требует кооперации между вами и поставщиком моторов. Сходные вопросы возникают и у программиста или разработчика программного обеспечения. Здесь подгонку обычно облегчает эффективное использование производных классов. Но не рассчитывайте провести произвольные расширения в проекте без определенного предвидения или кооперации с создателем таких классов. Когда исчерпается набор подходящих стандартных компонентов, проектировщик машины не спешит заняться проектированием новых оптимальных компонентов для своей машины. Это было бы слишком расточительно. Допустим, что не нашлось подходящего блока кондиционирования воздуха, зато есть свободное пространство, имеющее форму буквы L, в моторном отсеке. Возможно решение разработать блок кондиционирования указанной формы. Но вероятность того, что блок подобной странной формы будет использоваться в машинах другого типа (даже после значительной подгонки), крайне низка. Это означает, что наш проектировщик машины не сможет разделить затраты на производство такого блока с создателями машин другого типа, а значит время жизни этого блока коротко. Поэтому стоит спроектировать блок, который найдет более широкое применение, т.е. разработать разумный проект блока, более приспособленный для подгонки, чем наше L-образное чудище. Возможно, это потребует больших усилий, и даже придется для приспособления более универсального блока изменить общее описание проекта машины. Поскольку новый блок разрабатывался для более общего применения, чем наше L-образное чудище, предположительно, для него потребуется некоторая подгонка, чтобы полностью удовлетворить наши пересмотренные запросы. Подобная же альтернатива возникает и у программиста или разработчика программного обеспечения: вместо того, чтобы создать программу, привязанную к конкретному проекту, разработчик может спроектировать новую достаточно универсальную программу, которая будет иметь хорошие шансы стать стандартной в определенной области. Наконец, когда мы прошлись по всем стандартным компонентам, составляется "окончательное" общее описание проекта. Несколько специально разработанных средств указываются как возможные. Вероятно, в следующем году придется для новой модели повторить наши шаги, и как раз эти специальные средства придется переделать или выбросить. Как ни печально, но опыт традиционно проектировавшихся программ показывает, что лишь несколько частей системы можно выделить в отдельные компоненты и лишь несколько из них пригодны вне данного проекта. Мы не пытаемся утверждать, что все разработчики машин действуют столь разумно, как в приведенном примере, а разработчики программ совершают все указанные ошибки. Утверждается, что указанная методика разработки машин применима и для программного обеспечения. Так, в этой и следующей главах даны приемы использования ее для С++. Тем не менее можно сказать, что сама природа программирования способствует совершению указанных ошибок ($$12.2.1 и $$12.2.5). В разделе 11.4.3 опровергается профессиональное предубеждение против использования описанной здесь модели проектирования. Заметим, что модель развития программного обеспечения хорошо применима только в расчете на большие сроки. Если ваш горизонт сужается до времени выдачи очередной версии, нет смысла создавать и поддерживать функционирование стандартных компонентов. Это просто приведет к излишним накладным расходам. Наша модель рассчитана на организации со временем жизни, за которое проходит несколько проектов, и с размерами, которые позволяют нести дополнительные расходы и на средства проектирования, программирования, и на сопровождение проектов, и на повышение квалификации разработчиков, программистов и менеджеров. Фактически это эскиз некоторой фабрики по производству программ. Как ни удивительно, она только масштабом отличается от действий лучших программистов, которые для повышения своей производительности в течении лет накапливали запас приемов и методов проектирования, создавали инструменты и библиотеки. Похоже, что большинство организаций просто не умеет воспользоваться достижениями лучших сотрудников, как из-за отсутствия предвидения, так и по неспособности применить эти достижения в достаточно широком объеме. Все-таки неразумно требовать, чтобы "стандартные компоненты" были стандартными универсально. Существует лишь малое число международных стандартных библиотек, а в своем большинстве компоненты окажутся стандартными только в пределах страны, отрасли, компании, производственной цепочки, отдела или области приложения и т.д. Просто мир слишком велик, чтобы универсальный стандарт всех компонентов и средств был реальной или желанной целью проекта.

100949. Kokiatrumpagalva:)2007-11-05 23:18
11.3.2 Цели проектирования Каковы самые общие цели проектирования? Конечно, простота, но в чем критерий простоты? Поскольку мы считаем, что проект должен развиваться во времени, т.е. система будет расширяться, переноситься, настраиваться и, вообще, изменяться массой способов, которые невозможно предусмотреть, необходимо стремиться к такой системе проектирования и реализации, которая была бы простой с учетом, что она будет меняться многими способами. На самом деле, практично допустить, что сами требования к системе будут меняться неоднократно за период от начального проекта до выдачи первой версии системы. Вывод таков: система должна проектироваться максимально простой при условии, что она будет подвергаться серии изменений. Мы должны проектировать в расчете на изменения, т.е. стремиться к - гибкости, - расширяемости и - переносимости Лучшее решение - выделить части системы, которые вероятнее всего будут меняться, в самостоятельные единицы, и предоставить программисту или разработчику гибкие возможности для модификаций таких единиц. Это можно сделать, если выделить ключевые для данной задачи понятия и предоставить класс, отвечающий за всю информацию, связанную с отдельным понятием (и только с ним). Тогда изменение будет затрагивать только определенный класс. Естественно, такой идеальный способ гораздо легче описать, чем воплотить. Рассмотрим пример: в задаче моделирования метеорологических объектов нужно представить дождевое облако. Как это сделать? У нас нет общего метода изображения облака, поскольку его вид зависит от внутреннего состояния облака, а оно может быть задано только самим облаком. Первое решение: пусть облако изображает себя само. Оно подходит для многих ограниченных приложений. Но оно не является достаточно общим, поскольку существует много способов представления облака: детальная картина, набросок очертаний, пиктограмма, карта и т.п. Другими словами, вид облака определяется как им самим, так и его окружением. Второе решение заключается в том, чтобы предоставить самому облаку для его изображения сведения о его окружении. Оно годится для большего числа случаев. Однако и это не общее решение. Если мы предоставляем облаку сведения об его окружении, то нарушаем основной постулат, который требует, чтобы класс отвечал только за одно понятие, и каждое понятие воплощалось определенным классом. Может оказаться невозможным предложить согласованное определение "окружения облака", поскольку, вообще говоря, как выглядит облако зависит от самого облака и наблюдателя. Чем представляется облако мне, сильно зависит от того, как я смотрю на него: невооруженным глазом, с помощью поляризационного фильтра, с помощью метеорадара и т.д. Помимо наблюдателя и облака следует учитывать и "общий фон", например, относительное положение солнца. К дальнейшему усложнению картины приводит добавление новых объектов типа других облаков, самолетов. Чтобы сделать задачу разработчика практически неразрешимой, можно добавить возможность одновременного существования нескольких наблюдателей. Третье решение состоит в том, чтобы облако, а также и другие объекты, например, самолеты или солнце, сами описывали себя по отношению к наблюдателю. Такой подход обладает достаточной общностью, чтобы удовлетворить большинство запросовЬ. Однако, он может привести к значительному усложнению и большим накладным расходам при выполнении. Как, например, добиться того, чтобы наблюдатель понимал описания, произведенные облаком или другими объектами? Ь Даже эта модель будет, по всей видимости, не достаточной для таких предельных случаев, как графика с высокой степенью разрешимости. Я думаю, что для получения очень детальной картины нужен другой уровень абстракции. Дождевые облака - это не тот объект, который часто встретишь в программах, но объекты, участвующие в различных операциях ввода и вывода, встречаются часто. Поэтому можно считать пример с облаком пригодным для программирования вообще и для разработки библиотек в частности. Логически схожий пример в С++ представляют манипуляторы, которые используются для форматирования вывода в потоковом вводе-выводе ($$10.4.2). Заметим, что третье решение не есть "верное решение", это просто более общее решение. Разработчик должен сбалансировать различные требования системы, чтобы найти уровень общности и абстракции, пригодный для данной задачи в данной области. Золотое правило: для программы с долгим сроком жизни правильным будет самый общий уровень абстракции, который вам еще понятен и который вы можете себе позволить, но не обязательно абсолютно общий. Обобщение, выходящее за пределы данного проекта и понятия людей, в нем участвующих, может принести вред, т.е. привести к задержкам, неприемлемым характеристикам, неуправляемым проектам и просто к провалу. Чтобы использование указанных методов было экономично и поддавалось управлению, проектирование и управление должно учитывать повторное использование, о чем говорится в $$11.4.1 и не следует совсем забывать об эффективности (см. $$11.3.7).

100950. Esme-nesuprantantiem2007-11-05 23:23
Рассмотрим проектирование отдельного класса. Обычно это не лучший метод. Понятия не существуют изолированно, наоборот, понятие определяется в связи с другими понятиями. Аналогично и класс не существует изолированно, а определяется совместно с множеством связанных между собой классов. Это множество часто называют библиотекой классов или компонентом. Иногда все классы компонента образуют единую иерархию, иногда это не так (см. $$12.3). Множество классов компонента бывают объединены некоторым логическим условием, иногда это - общий стиль программирования или описания, иногда - предоставляемый сервис. Компонент является единицей проектирования, документации, права собственности и, часто, повторного использования. Это не означает, что если вы используете один класс компонента, то должны разбираться во всех и уметь применять все классы компонента или должны подгружать к вашей программе модули всех классов компонента. В точности наоборот, обычно стремятся обеспечить, чтобы использование класса вело к минимуму накладных расходов: как машинных ресурсов, так и человеческих усилий. Но для использования любого класса компонента нужно понимать логическое условие, которое его определяет (можно надеяться, что оно предельно ясно изложено в документации), понимать соглашения и стиль, примененный в процессе проектирования и описания компонента, и доступный сервис (если он есть). Итак, перейдем к способам проектирования компонента. Поскольку часто это непростая задача, имеет смысл разбить ее на шаги и, сконцентрировавшись на подзадачах, дать полное и последовательное описание. Обычно нет единственно правильного способа разбиения. Тем не менее, ниже приводится описание последовательности шагов, которая пригодилась в нескольких случаях: [1] Определить понятие / класс и установить основные связи между ними. [2] Уточнить определения классов, указав набор операций для каждого. [a] Провести классификацию операций. В частности уточнить необходимость построения, копирования и уничтожения. [b] Убедиться в минимальности, полноте и удобстве. [3] Уточнить определения классов, указав их зависимость от других классов. [a] Наследование. [b] Использование зависимостей. [4] Определить интерфейсы классов. [a] Поделить функции на общие и защищенные. [b] Определить точный тип операций класса. Отметим, что это шаги итеративного процесса. Обычно для получения проекта, который можно уверенно использовать для первичной реализации или повторной реализации, нужно несколько раз проделать последовательность шагов. Одним из преимуществ глубокого анализа и предложенной здесь абстракции данных оказывается относительная легкость, с которой можно перестроить взаимоотношения классов даже после программирования каждого класса. Хотя это никогда не бывает просто. Далее следует приступить к реализации классов, а затем вернуться, чтобы оценить проект, исходя из опыта реализации. Рассмотрим эти шаги в отдельности.

100951. Ohmaygod:)!!!!!!!!!!Kad gereu virskintu2007-11-05 23:27
Аналогично и класс не существует изолированно, а определяется совместно с множеством связанных между собой классов. Это множество часто называют библиотекой классов или компонентом. Иногда все классы компонента образуют единую иерархию, иногда это не так (см. $$12.3). Множество классов компонента бывают объединены некоторым логическим условием, иногда это - общий стиль программирования или описания, иногда - предоставляемый сервис. Компонент является единицей проектирования, документации, права собственности и, часто, повторного использования. Это не означает, что если вы используете один класс компонента, то должны разбираться во всех и уметь применять все классы компонента или должны подгружать к вашей программе модули всех классов компонента. В точности наоборот, обычно стремятся обеспечить, чтобы использование класса вело к минимуму накладных расходов: как машинных ресурсов, так и человеческих усилий. Но для использования любого класса компонента нужно понимать логическое условие, которое его определяет (можно надеяться, что оно предельно ясно изложено в документации), понимать соглашения и стиль, примененный в процессе проектирования и описания компонента, и доступный сервис (если он есть). Итак, перейдем к способам проектирования компонента. Поскольку часто это непростая задача, имеет смысл разбить ее на шаги и, сконцентрировавшись на подзадачах, дать полное и последовательное описание. Обычно нет единственно правильного способа разбиения

100953. Ryskinam "Koncepta "del asabno tupyx2007-11-05 23:32
Множество классов компонента бывают объединены некоторым логическим условием, иногда это - общий стиль программирования или описания, иногда - предоставляемый сервис. Компонент является единицей проектирования, документации, права собственности и, часто, повторного использования. Это не означает, что если вы используете один класс компонента, то должны разбираться во всех и уметь применять все классы компонента или должны подгружать к вашей программе модули всех классов компонента. В точности наоборот, обычно стремятся обеспечить, чтобы использование класса вело к минимуму накладных расходов: как машинных ресурсов, так и человеческих усилий. Но для использования любого класса компонента нужно понимать логическое условие, которое его определяет.

100954. AVA!!!!-Atplaukem!:)2007-11-05 23:38
Определите понятия/классы и установите основные связи между ними. Главное в хорошем проекте - прямо отразить какое-либо понятие "реальности", т.е. уловить понятие из области приложения классов, представить взаимосвязь между классами строго определенным способом, например, с помощью наследования, и повторить эти действия на разных уровнях абстракции. Но как мы можем уловить эти понятия? Как на практике решить, какие нам нужны классы? Лучше поискать ответ в самой области приложения, чем рыться в программистском хранилище абстракций и понятий. Обратитесь к тому, кто стал экспертом по работе в некогда сделанной системе, а также к тому, кто стал критиком системы, пришедшей ей на смену. Запомните выражения того и другого. Часто говорят, что существительные играют роль классов и объектов, используемых в программе, это действительно так. Но это только начало. Далее, глаголы могут представлять операции над объектами или обычные (глобальные) функции, вырабатывающие новые значения, исходя из своих параметров, или даже классы. В качестве примера можно рассматривать функциональные объекты, описанные в $$10.4.2. Такие глаголы, как "повторить" или "совершить" (commit) могут быть представлены итеративным объектом или объектом, представляющим операцию выполнения программы в базах данных. Даже прилагательные можно успешно представлять с помощью классов, например, такие, как "хранимый", "параллельный", "регистровый", "ограниченный". Это могут быть классы, которые помогут разработчику или программисту, задав виртуальные базовые классы, специфицировать и выбрать нужные свойства для классов, проектируемых позднее. Лучшее средство для поиска этих понятий / классов - грифельная доска, а лучший метод первого уточнения - это беседа со специалистами в области приложения или просто с друзьями. Обсуждение необходимо, чтобы создать начальный жизнеспособный словарь терминов и понятийную структуру. Мало кто может сделать это в одиночку. Обратитесь к [1], чтобы узнать о методах подобных уточнений. Не все классы соответствуют понятиям из области приложения. Некоторые могут представлять ресурсы системы или абстракции периода реализации (см. $$12.2.1). Взаимоотношения, о которых мы говорим, естественно устанавливаются в области приложения или (в случае повторных проходов по шагам проектирования) возникают из последующей работы над структурой классов. Они отражают наше понимание основ области приложения. Часто они являются классификацией основных понятий. Пример такого отношения: машина с выдвижной лестницей есть грузовик, есть пожарная машина, есть движущееся средство. В $$11.3.3.2 и $$11.3.3.5 предлагается некоторая точка зрения на классы и иерархию классов, если необходимо улучшить их структуру.

100955. kiskis p2007-11-05 23:39
apie ka cia buvo?

100956. A va cia tai super kuklus Didziojo Deliozo konceptas-klas:)2007-11-05 23:41
Такие глаголы, как "повторить" или "совершить" (commit) могут быть представлены итеративным объектом или объектом, представляющим операцию выполнения программы в базах данных. Даже прилагательные можно успешно представлять с помощью классов, например, такие, как "хранимый", "параллельный", "регистровый", "ограниченный". Это могут быть классы, которые помогут разработчику или программисту, задав виртуальные базовые классы, специфицировать и выбрать нужные свойства для классов, проектируемых позднее. Лучшее средство для поиска этих понятий / классов - грифельная доска, а лучший метод первого уточнения - это беседа со специалистами в области приложения или просто с друзьями.

100957. kiskis p2007-11-05 23:42
"prosto s druzjami" man patinka.

100958. Aj jau man nusibodo-dar yra daug informacijos kur jus,buki skaitytojai intymiai suartins su ""klasemis"" kaip ""konceptais"".ko nekaip negali suvokti studentai2007-11-05 23:44
Jo

100959. kiskis p2007-11-05 23:47
ar siais laikais studentai naudoja "grifelnaja doska"?

100962. Gintaras2007-11-05 23:52
Esme yra tame,kad ""klase""programuotojas turi pac sau susikurt ,kaip ""koncepta"" viduje programos,nes pati programa neturi kokiu nors kompiliuojamu ar interpretuojamu ""klasiu""",kadangi C++ naujoviu esme yrea tose mistinese ""klasese".kurias-kuruios-konceptus (Delioziskus) p[rogramuotojas-programos projektuotojas ir turi susikurt.Programa ""klasemis -konceptais leidzia pavadinti-VISKA nuog rysiu tarp skaitiu iki programerio israiskos stiliaus ir jo klavos barskinimo muzikos.Bet -tai jau ypac ydomu-ne?:))))

100963. kiskis p2007-11-05 23:53
labai idomu, teskite, teskite.

100964. Antane2007-11-05 23:56
Tai va daug nesiplesdamas,nes mane tuoj istrins,norec tom studenciokem patart paskaityt kai kuriuos klasikus ir reabilituot neispijarintus tikrus filosofus ikvepusius simtus milijonu programuotoju tevus programavimo terpiu ,kalbu ir net0dristu pasakyti-""konceptu ""kurimui:)

100965. toto2007-11-06 00:19
Kas čia tau užėjo, panevėžieti, ar jau LRytą pritriedei, kad neprašytas ŠAtėnus flood`ini?

100968. trydesim2007-11-06 00:57
Ateis ir LRytui eile-jie nekantriai laukia siektiek iskankinti to nekantraus laukimo...Ka jiems galim garantuoti?Kad pritriesim daug ir galbut, be ikvepimo...

100969. AisV supykes2007-11-06 00:58
blyn, tave tik kiekybe sujaudina - esi vis tik kavniaga/polianiaga pasiputeliska....

100998. tomas venclova2007-11-06 15:38
Matot, Pravda turi tokį bruožą, kad būtinai prie teksto ką nors prirašo arba iš jo išbraukia. Todėl joje spausdintis nenumatau.

Rodoma versija 179 iš 203 
13:25:26 Jan 31, 2011   
May 2008 Sep 2013
Sąrašas   Archyvas   Pagalba