LINUX.ORG.RU

[вброс]Почему объектно-ориентированное программирование провалилось?

 


2

7

http://citforum.ru/gazeta/165/

по линку многабукаф, немного для Ъ:

факт остаётся фактом: сторона, представлявшая объектно-ориентированное программирование, во время открытой дискуссии с противниками под смех зала даже запуталась в своих же концепциях. Люди вспоминают, что у всех создалось стойкое впечатление, что аргументация Lisp’еров была куда убедительней и последовательней, чем сторонников ООП.

Другой крупный критик ООП – это известный специалист по программированию Александр Степанов, который, работая в Bell Labs, участвовал в создании C++ вместе c Бьерном Страуструпом (Bjarne Stroustrup), а впоследствии, уже после приглашения в HP Labs, написал Standard Template Library (STL). Александр Александрович полностью разочаровался в парадигме ООП; в частности, он пишет: “Я уверен, что парадигма ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, только тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы вы приходите к тому, что оказываетесь в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг – из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле”.

Ричард Столлман (Richard Stallman) также известен своим критическим отношением к ООП, особенно он любит шутить насчет того мифа объектников, что ООП “ускоряет разработку программ”: “Как только ты сказал слово «объект», можешь сразу забыть о модульности”.

Ричард Гэбриел неожиданно сравнивает нынешнюю ситуацию с ООП с провалом эфиродинамики в физике начала 20 века, когда, в сущности, произошла “тихая революция”.

★★★★
Ответ на: комментарий от anonymous

Попробуйте взять массивчик из точек и окружностей, и написать процедурку, которая их отображает, вызывая у каждого элемента метод draw.


FORTH definitions

vocabulary GRAPH
also GRAPH definitions

vocabulary POINTS
also POINTS definitions
: new
	create ( x y -- "name" )
		, , \ запомним x и y
	does>  ( -- addr )
		FORTH GRAPH POINTS \ установим контекст
;
: .x dup cell+ @ ."  x= " . ;
: .y dup @ ."  y= " . ;
: draw ." point: " .x .y drop ;
GRAPH definitions

vocabulary CIRCLES
also CIRCLES definitions
: new
	create ( x y r -- "name" )
		, , ,
	does> ( -- addr )
		FORTH GRAPH CIRCLES
;
: .x dup cell+ cell+ @ ."  x= " . ;
: .y dup cell+ @ ."  y= " . ;
: .r dup @ ."  r= " . ;
: draw ." circle: " .x .y .r drop ;
GRAPH definitions

POINTS 10 20 new p
CIRCLES 10 20 30 new c

p draw
c draw

GRAPH definitions

: array  \ нам понадобится массив
	create ( size -- "name" )
		cells allot
	does> ( i -- addr ) 
		swap cells +
;

5 constant NNN

NNN array FIGURE

POINTS  11 21    new tmp1 	' tmp1 0 FIGURE !
CIRCLES 12 22 32 new tmp2 	' tmp2 1 FIGURE !
POINTS  13 23    new tmp3 	' tmp3 2 FIGURE !
CIRCLES 14 24 34 new tmp4 	' tmp4 3 FIGURE !
POINTS  15 25    new tmp5 	' tmp5 4 FIGURE !

tmp1 draw
tmp2 draw
tmp3 draw
tmp4 draw
tmp5 draw

0 FIGURE @ execute draw
1 FIGURE @ execute draw
2 FIGURE @ execute draw
3 FIGURE @ execute draw
4 FIGURE @ execute draw

\ с массивом всё в порядке

GRAPH definitions

: testFIGURE CR
	NNN 0 ?do 
			i FIGURE @ execute s" draw" evaluate CR 
			\ чтоб не прибить гвоздями первую попавшуюся draw
		loop 
;

testFIGURE

\ с процедуркой всё в порядке

anonymous
()
Ответ на: комментарий от anonymous

[code=forth]

$ gforth <./test.fs Gforth 0.6.2, Copyright (C) 1995-2003 Free Software Foundation, Inc. Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license' Type `bye' to exit ok FORTH definitions ok ok vocabulary GRAPH ok also GRAPH definitions ok ok vocabulary POINTS ok also POINTS definitions ok : new compiled    create ( x y — «name» ) compiled       , , \ запомним x и y compiled    does> ( — addr ) compiled       FORTH GRAPH POINTS \ установим контекст compiled ; ok : .x dup cell+ @ ." x= " . ; ok : .y dup @ ." y= " . ; ok : draw ." point: " .x .y drop ; ok GRAPH definitions ok ok vocabulary CIRCLES ok also CIRCLES definitions ok : new compiled    create ( x y r — «name» ) compiled       , , , compiled    does> ( — addr ) compiled       FORTH GRAPH CIRCLES compiled ; ok : .x dup cell+ cell+ @ ." x= " . ; ok : .y dup cell+ @ ." y= " . ; ok : .r dup @ ." r= " . ; ok : draw ." circle: " .x .y .r drop ; ok GRAPH definitions ok ok POINTS 10 20 new p ok CIRCLES 10 20 30 new c ok ok p draw point: x= 10 y= 20 ok c draw circle: x= 10 y= 20 r= 30 ok ok GRAPH definitions ok ok : array \ нам понадобится массив compiled    create ( size — «name» ) compiled       cells allot compiled    does> ( i — addr ) compiled       swap cells + compiled ; ok ok 5 constant NNN ok ok NNN array FIGURE ok ok POINTS 11 21 new tmp1    ' tmp1 0 FIGURE ! ok CIRCLES 12 22 32 new tmp2    ' tmp2 1 FIGURE ! ok POINTS 13 23 new tmp3    ' tmp3 2 FIGURE ! ok CIRCLES 14 24 34 new tmp4    ' tmp4 3 FIGURE ! ok POINTS 15 25 new tmp5    ' tmp5 4 FIGURE ! ok ok tmp1 draw point: x= 11 y= 21 ok tmp2 draw circle: x= 12 y= 22 r= 32 ok tmp3 draw point: x= 13 y= 23 ok tmp4 draw circle: x= 14 y= 24 r= 34 ok tmp5 draw point: x= 15 y= 25 ok ok 0 FIGURE @ execute draw point: x= 11 y= 21 ok 1 FIGURE @ execute draw circle: x= 12 y= 22 r= 32 ok 2 FIGURE @ execute draw point: x= 13 y= 23 ok 3 FIGURE @ execute draw circle: x= 14 y= 24 r= 34 ok 4 FIGURE @ execute draw point: x= 15 y= 25 ok ok \ с массивом всё в порядке ok ok GRAPH definitions ok ok : testFIGURE CR compiled    NNN 0 ?do compiled          i FIGURE @ execute s" draw" evaluate CR compiled          \ чтоб не прибить гвоздями первую попавшуюся draw compiled       loop compiled ; ok ok testFIGURE point: x= 11 y= 21 circle: x= 12 y= 22 r= 32 point: x= 13 y= 23 circle: x= 14 y= 24 r= 34 point: x= 15 y= 25 ok ok \ с процедуркой всё в порядке ok

[/code]

anonymous
()
Ответ на: комментарий от anonymous

$ gforth <./test.fs 
Gforth 0.6.2, Copyright (C) 1995-2003 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
  ok
FORTH definitions  ok
  ok
vocabulary GRAPH  ok
also GRAPH definitions  ok
  ok
vocabulary POINTS  ok
also POINTS definitions  ok
: new  compiled
	create ( x y -- "name" )  compiled
		, , \ запомним x и y  compiled
	does>  ( -- addr )  compiled
		FORTH GRAPH POINTS \ установим контекст  compiled
;  ok
: .x dup cell+ @ ."  x= " . ;  ok
: .y dup @ ."  y= " . ;  ok
: draw ." point: " .x .y drop ;  ok
GRAPH definitions  ok
  ok
vocabulary CIRCLES  ok
also CIRCLES definitions  ok
: new  compiled
	create ( x y r -- "name" )  compiled
		, , ,  compiled
	does> ( -- addr )  compiled
		FORTH GRAPH CIRCLES  compiled
;  ok
: .x dup cell+ cell+ @ ."  x= " . ;  ok
: .y dup cell+ @ ."  y= " . ;  ok
: .r dup @ ."  r= " . ;  ok
: draw ." circle: " .x .y .r drop ;  ok
GRAPH definitions  ok
  ok
POINTS 10 20 new p  ok
CIRCLES 10 20 30 new c  ok
  ok
p draw point:  x= 10  y= 20  ok
c draw circle:  x= 10  y= 20  r= 30  ok
  ok
GRAPH definitions  ok
  ok
: array  \ нам понадобится массив  compiled
	create ( size -- "name" )  compiled
		cells allot  compiled
	does> ( i -- addr )   compiled
		swap cells +  compiled
;  ok
  ok
5 constant NNN  ok
  ok
NNN array FIGURE  ok
  ok
POINTS  11 21    new tmp1 	' tmp1 0 FIGURE !  ok
CIRCLES 12 22 32 new tmp2 	' tmp2 1 FIGURE !  ok
POINTS  13 23    new tmp3 	' tmp3 2 FIGURE !  ok
CIRCLES 14 24 34 new tmp4 	' tmp4 3 FIGURE !  ok
POINTS  15 25    new tmp5 	' tmp5 4 FIGURE !  ok
  ok
tmp1 draw point:  x= 11  y= 21  ok
tmp2 draw circle:  x= 12  y= 22  r= 32  ok
tmp3 draw point:  x= 13  y= 23  ok
tmp4 draw circle:  x= 14  y= 24  r= 34  ok
tmp5 draw point:  x= 15  y= 25  ok
  ok
0 FIGURE @ execute draw point:  x= 11  y= 21  ok
1 FIGURE @ execute draw circle:  x= 12  y= 22  r= 32  ok
2 FIGURE @ execute draw point:  x= 13  y= 23  ok
3 FIGURE @ execute draw circle:  x= 14  y= 24  r= 34  ok
4 FIGURE @ execute draw point:  x= 15  y= 25  ok
  ok
\ с массивом всё в порядке  ok
  ok
GRAPH definitions  ok
  ok
: testFIGURE CR  compiled
	NNN 0 ?do   compiled
			i FIGURE @ execute s" draw" evaluate CR   compiled
			\ чтоб не прибить гвоздями первую попавшуюся draw  compiled
		loop   compiled
;  ok
  ok
testFIGURE 
point:  x= 11  y= 21 
circle:  x= 12  y= 22  r= 32 
point:  x= 13  y= 23 
circle:  x= 14  y= 24  r= 34 
point:  x= 15  y= 25 
 ok
  ok
\ с процедуркой всё в порядке  ok

anonymous
()
Ответ на: комментарий от anonymous

>с процедуркой всё в порядке ok

Даа.. И кто-то еще удивляется, почему Qt не портировали на форт.. :)

s" draw" evaluate

Вместо двух разыменований, при каждом вызове лопатить словарь в рантайме - это сурово. Это просто феерично. Это не жесть, это танковая броня на велосипеде. Вы правда думаете, что это можно хоть где-то всерьез использовать?

Плюс, для создания массива вам потребовалось создать 5 слов. Руками. Ну, это, разумеется, пустяк.. создать заранее побольше переменных и потом сгребать их в массивы.

Что ж, дерзайте.. Маленькая тележка костылей уже есть, еще вагон и все получится..

anonymous
()
Ответ на: комментарий от anonymous

И кто-то еще удивляется, почему Qt не портировали на форт.. :)

Фортеры ворвались в тред и принялись показывать, куда именно провалился ООП ;)

quasimoto ★★★★
()
Ответ на: комментарий от anonymous

>> с процедуркой всё в порядке ok

Даа.. И кто-то еще удивляется, почему Qt не портировали на форт.. :)


Кхм... Процедурку с draw заказывали? Заказывали. Получите и распишитесь.

s" draw" evaluate


Вместо двух разыменований, при каждом вызове лопатить словарь в рантайме - это сурово. Это просто феерично. Это не жесть, это танковая броня на велосипеде.


Так... к пуговицам^Wвызовам draw претензии есть? Убедились, что у нас танковая броня легким движением руки работает в runtime?

Работает? Работает. И это вы её ещё в бикини не видели! :)

Вы правда думаете, что это можно хоть где-то всерьез использовать?


Да. :) Это же настоящий runtime context за смешные деньги!

Плюс, для создания массива вам потребовалось создать 5 слов. Руками. Ну, это, разумеется, пустяк.. создать заранее побольше переменных и потом сгребать их в массивы.


Вообще-то, мог это сделать и в одну строчку. Но.

Надеюсь, ты понял каждую строку, как оно работает? Надеюсь, тебе не требуются дополнительные тестовые данные для исследования феномена и ты не только веришь всему представленному на экране, но и понимаешь о чём там?

Так, что не устраивает?

Что ж, дерзайте.. Маленькая тележка костылей уже есть, еще вагон и все получится..


Вообще-то, где-то в 1992 года, Черезов А.Ю. из Калиниграда, в предисловии к своему SP_FORTH 20.07.1992-31.07.1992 v1.01, завил открытым текстом:

«Наследование, третий кит ООП, прекрасно реализуется в Форте в виде так
называемых „контексных словарей“ (это единственный случай, когда одно и то
же понятие называется в Форте более „заковыристо“, чем принято в ООП). Може-
те считать словарь обьектом, каждый новый словарь, определенный внутри него
словом VOCABULARY, будет его потомком и будет наследовать его методы (в Фор-
те, как вы помните, нет обычных данных). Это сильно напоминает вам Турбо Пас-
каль, но в отличие от него, обьект может иметь несколько предков (множествен-
ное наследование, как в C++). Более того, для каждого метода, используемого
внутри нового обьекта, вы можете указать обьекта-хозяина, указав его имя (имя
контексного словаря). Обьект-потомок „видит“ все методы и данные в ветви каж-
дого из своих предков, вплоть до „корневого“ обьекта с именем FORTH (это имя
базового словаря Форта), и может их использовать. В этом случае имя предка
можно не указывать, оно нужно только для избежания двусмысленности - когда,
например, в двух родительских словарях (обьектах) есть методы с одним и тем
же именем. Причем в одном и том же словаре (обьекте) могут быть слова (мето-
ды), перекрывающие сами себя (описание полиморфизма Форта уже было дано).
Все это дает возможность вам избавиться от примитивных шаблонов использова-
ния средств ООП, навязываемых вам Турбо Паскалем и С++ (хотя ради справедли-
вости надо отметить, что и они являются прекрасными инструментами, просто
Форт - это шаг далеко вперед, (кстати, FORTH так и переводится - „вперед“)).
Контексные словари - это один из способов реализации наследования в Форте,
но в Форте есть и второй, совершенно другой (принципиально другой !), хотя
и он вызывает ассоциации с уже знакомыми способами: это реализация наследо-
вания с помощью тех же чудодейственных слов CREATE...DOES>.»

P.S. Похоже, ты действительно не верил, что это возможно, даже когда почти все части мозаики были у тебя перед глазами. Забавно.

anonymous
()
Ответ на: комментарий от anonymous

>Так... к пуговицам^Wвызовам draw претензии есть? Убедились, что у нас танковая броня легким движением руки работает в runtime?

Угу, на велосипеде, задом наперед, стоя на лыжах, с аквалангом, в балетной пачке.. Собственно никто и не утверждал, что сделать невозможно - возможно, но через анальное отверстие. Что вы с успехом продемострировали, спасибо.

Работает? Работает. И это вы её ещё в бикини не видели! :)

Скорее к этому подходит определение «страдает хернёй». В бикини..

anonymous
()
Ответ на: комментарий от anonymous

> Скорее к этому подходит определение «страдает хернёй». В бикини..

на любом, сколь угодно тупом языке можно сделать поле типа в структуре и по нему выбирать контекст, откуда вызывается операция, и это вполне можно назвать ООП

так что ООП легко моделируется; а вот современные языки, типа хаскеля и с++, уже требуют некоторых усилий

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от anonymous

> Угу, на велосипеде, задом наперед, стоя на лыжах, с аквалангом, в балетной пачке..

С хера ли такие сложности? Смотри внимательно на код. Смотри на код. Где там лыжи, акваланг или упоминание классического русского балета? Все средства стандартные. Средства языка не используются вне своей компетенции.

Далее, размеры словарей минимальны, накладные расходы на runtime минимальны. Можно посмотреть на содержание словарей (words) и цепочки их контекстов (order), чтоб понять - решение элегантно и заложено в реализации языка.

Собственно никто и не утверждал, что сделать невозможно - возможно, но через анальное отверстие.

Да у тебя, я смотрю, любое отверстие - анальное.

Все средства применялись в соответствии с ANSI-стандартом, а конечный эффект можно реализовать на основе любого из принятых ANSI-стандартов.

Что вы с успехом продемострировали, спасибо.

Пжалста. У меня ещё много бисера в карманах.

anonymous
()
Ответ на: комментарий от www_linux_org_ru

> на любом, сколь угодно тупом языке можно сделать поле типа в структуре и по нему выбирать контекст, откуда вызывается операция, и это вполне можно назвать ООП

Любой, сколь угодно тупой эксперт может требовать и выставлять условия, и его вполне можно назвать экспертом. :D

так что ООП легко моделируется;

Оп-па! Дамы и господа! Случилось чудо! Теперь можно считать, что ООП легко моделируется!

И вы ещё до сих пор спрашиваете: Почему объектно-ориентированное программирование провалилось?

а вот современные языки, типа хаскеля и с++, уже требуют некоторых усилий

Гы. Ты ещё заяви, что ассемблер не требует усилий, эксперт, бл*. :)

P.S. Ты совсем дурак или у меня просто угол обзора неудачный?

anonymous
()
Ответ на: комментарий от anonymous

>Все средства стандартные.

Даа.. задание имен методов через строковую константу - это стандартно?

накладные расходы на runtime минимальны

поиск по связанным спискам при каждом вызове - это эффективно?

Да у тебя, я смотрю, любое отверстие - анальное.

И после этого вы удивляетесь, почему вас не приглашают в приличное общество??

anonymous
()
Ответ на: комментарий от anonymous

Все средства стандартные.

Даа.. задание имен методов через строковую константу - это стандартно?

Так наглядно и понятно. Всё по аналогии. Даже люди не знающие Forth могут заметить аналогию и понять пример.

А специально для тебя создать эффективные реализации одинаково работающие в разных режимах? Зачем, если задачей было продемонстрировать эффект?

накладные расходы на runtime минимальны

поиск по связанным спискам при каждом вызове - это эффективно?

Да. Это самый простой в понимании и самый общий случай. Тема нашего разговора — контексты, не так ли? К тому же, в принципе, можно подсунуть любой другой контекст с другой своей реализацией POINTS или CIRCLES, оставив код их использования без изменений. Мне что, рассказать тебе про динамические контексты и зачем они нужны?

Создай словарь, определи в нём несколько слов и спроси WORDS — ты увидишь там только те несколько слов. Да, это эффективно.

Можешь попробовать доказать обратное.

Да у тебя, я смотрю, любое отверстие - анальное.

И после этого вы удивляетесь, почему вас не приглашают в приличное общество??

А это где? Ещё одно общество лицемеров? :)

anonymous
()
Ответ на: комментарий от anonymous

>Так наглядно и понятно.

Потому, что по нормальному не получается.

Да, это эффективно.

Да нифига это не эффективно. Это нормально во время компиляции, но никак не в рантайме. И тем более при КАЖДОМ вызове. Эффективно - это два разыменования. Но у вас, видимо, свои понятия об эффективности - АНАЛогичные.

Всё по аналогии.

И чуть-чуть по гинекологии.. :)

anonymous
()
Ответ на: комментарий от anonymous

>> Так наглядно и понятно.

Потому, что по нормальному не получается.

Что означает «по нормальному»? Что ты ожидаешь?

Да, это эффективно.

Да нифига это не эффективно. Это нормально во время компиляции, но никак не в рантайме. И тем более при КАЖДОМ вызове.

Категоричное безосновательное заявление. Сделай, померяй и тогда принимай решение. Если динамический контекст в рантайме становится объективно слишком дорог - переделай.

Эффективно - это два разыменования.

Прибить гвоздями это эффективно?

Это ты разыменования считаешь самыми эффективными и «нормальными»? Для таких как ты придумали ВЕКТОРНЫЕ ВЫЧИСЛЕНИЯ ( http://www.nncron.ru/book/sf/chapter9.htm ). Играйся - сколько влезет, только причём тут контексты - непонятно. Зачем эмулировать то, что уже есть в чистом виде?

anonymous
()
Ответ на: комментарий от anonymous

>Да нифига это не эффективно. Это нормально во время компиляции, но никак не в рантайме

Так мой древний вариант посмотри. Там в райнтайме потери по сравнению с чистым Фортом минимальны. И не зависят от глубины наследования. Вызов виртуального метода - одно чтение адреса из памяти и вызов по нему. По-моему, в Си++ также.

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

Вот о чём и речь. У каждого фортера есть свой ООП :)

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

> Оп-па! Дамы и господа! Случилось чудо! Теперь можно считать, что ООП легко моделируется!

Чудо не случилось. Я молчал, т.к. мне было прикольно наблюдать, как фортеры пыхтят и реализуют тривиальный (общеизвестный) механизм :-)

Впрочем, от этого была польза — выяснилось, что они понимают его детали существенно по-разному.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>прикольно наблюдать, как фортеры пыхтят и реализуют тривиальный (общеизвестный) механизм :-)

Двадцать лет назад пионэры страдали похожей фигней. Можно ли сделать рекурсию на бейсике (классическом, который с номерами строк и GOSUB)? Пионэры радовались как пионэры, когда им удавалось рекурсивно слепить какую-нибудь «ханойскую башню». На вопрос: «А фигли толку с вашей рекурсии в бейсике?» - вот точно также радостно лыбились: «Но ведь можно же!» и доказывали, что в бейсике рекурсия самая правильная: «ведь реализована средствами языка, и всё-всё подконтрольно программисту».

anonymous
()
Ответ на: комментарий от anonymous

> Двадцать лет назад пионэры страдали похожей фигней. Можно ли сделать рекурсию на бейсике (классическом, который с номерами строк и GOSUB)? Пионэры радовались как пионэры, когда им удавалось рекурсивно слепить какую-нибудь «ханойскую башню». На вопрос: «А фигли толку с вашей рекурсии в бейсике?» - вот точно также радостно лыбились: «Но ведь можно же!» и доказывали, что в бейсике рекурсия самая правильная: «ведь реализована средствами языка, и всё-всё подконтрольно программисту».

Двадцать лет назад выпускали книги, как написать систему управления базами данных на raw-devices (без файловой системы) на Бейсике. Жаль, не помню названия.

Ключевые слова: Бейсик, База данных, raw-device, печатная книга

P.S. «Вы слишком много кушать! В смысле: зажрались.»//

anonymous
()
Ответ на: комментарий от anonymous

>Двадцать лет назад выпускали книги, как написать систему управления базами данных на raw-devices (без файловой системы) на Бейсике.

C рекурсией? Потому как бейсик без рекурсии, всеравно что форт без ООП. :)

anonymous
()
Ответ на: комментарий от anonymous

> Двадцать лет назад пионэры страдали похожей фигней. Можно ли сделать рекурсию на бейсике (классическом, который с номерами строк и GOSUB)? Пионэры радовались как пионэры, когда им удавалось рекурсивно слепить какую-нибудь «ханойскую башню».

самые крутые пионэры жили 30 лет назад.
Билл Джой, например.
Те, кто хакал машинное время, просиживал сутки в машинном зале, вбив char 'K', вместо int, и кому прошло в голову начать писать Shared систему - Юникс, для параллельной работы. А им мужики в пиджаках говорили: пионэры, пионэры. А они таки создали Юникс. И даже воспитали следующих пионэров 20 лет назад (не тех, которые Бейсик мучали, а тех кто решил Линуксы и БСД поднимать за счёт своего времени, свободные, без венчурного капиталла).

siberean
()
Ответ на: комментарий от siberean

Пора бы тебе понять, что Линуксы подняли не пионеры забесплатно, а капиталисты с сугубо коммерческими целями в погоне за наживой и для устранения конкурентов. Если бы они не вложили в Линукс кучу бабла, то про маленькую игрушку Линукс знало бы лишь 5 красноглазых прыщавых извращенцев.

anonymous
()
Ответ на: комментарий от anonymous

капиталисты понабежали значительно позже.
Не было бы базы, стабильной системы, созданной в свободное время - не было бы вообще о чём разговаривать.
Если и забашляли - то универы (я учился в 93-96 годах и преподавание шло на Линуксе с первым ядром).

Наколько помню - с юниксом было то же самое. Делали его дома и в гаражах. Это потом толканули капиталистам.
Да, и все вебовые гуглы, фейсбуки, твиттеры - делались вначале на энтузиазме, для себя, для колледжских и универсистетских забав, а деньги пришли позже.

siberean
()
Ответ на: комментарий от anonymous

Массовые инвестиции в линукс - имхо пошли уже после Большого Голубого, и уже в этом веке, когда ядро 2.4 под конец стало более масштабируемое и смогло конкурировать с коммерческими юниксами (в 2.6 те фичи стали из коробки). В 20 веке максимумы на количество файл-дескрипторов (сокетов например), перформанс, код надо было подкручивать и пр. - были смешными по сравнению с теми же санками.

Но в образовательной среде линукс был популярен уже в середине 90х, как бесплатная альтернатива дорогим юникс станциям.
И в юниксовых фирмах - уже пользовался каким-то авторитетом и многие его уже тогда использовали как десктоп (по крайней мере в тех фирмах где я работал).

siberean
()
Ответ на: комментарий от siberean

справедливости ради, надо сказать - это было уже в конце 90х, не середине (в середине - я ещё учился и не пользовался линуксом на работе, на той работе же был dos5-6 и винда 3.0-3.11. Стыдно даже. Вот жена под новеллевской сетью и OS/2 сидела).

siberean
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.