Re[7]: Разница есть
От: Silver_s Ниоткуда  
Дата: 28.08.04 09:11
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Продолжить можно тем, что используя чистые функции, легко моделируется объекты с состояниями. Например, почти для любой императивной структуры данных существует аналог на чистых функциях......

G>
G>NewTree = insert( Element, Tree ),
G>do_something( NewTree, Tree );
G>

G>Т. е. любое "изменение" обратимо, по причине того, что это никакое не изменение. В вышеприведенном примере будут существовать два дерева, которые будут физически разделять все узлы, кроме корня и пути от корня до вставленного элемента....

А если суть программы только поддержание состояния этого дерева и передача этого состояния во внешний мир (да хотя бы на экран монитора)? И если еще объекты в дереве привязаны к реальному миру...на одном напрмер висят открытые файлы, на другом ядерный реактор, на третьем сетевое подключение. Это немного меняет суть.

Наверное программу с натяжкой можно считать конечным автоматом. На входы поступают сигналы из внешнего мира, состояние этого автомата считывается извне. Вот для моделирования КА как то плохо себе представляю ФЯ.
Но есть в реализации программы и невидимые куски, они в принципе могут быть и существенными . И относятся они к реализации перехода из одного состояния в другое. Вот если объединить усилия ФЯ и обычных языков, чтобы каждый своим делом занимался — это возможно был бы лучший вариант.

Вот к примеру, посмотрел я Samples для F#. Там один пример такой. Программа симулятор Life (думаю Life всем известна). Т.е. формочка, по менюшке, запускается и останавливается симулятор, и в формочке отображается процесс.
Правильная структура этой программы такая, есть один объект с состоянием — это матрица игрового поля, есть одна функция переводящая этот объект в следующее сотояние. Дерева переходов нету, оно плоское, т.е один сигнал из внешнего мира на переход состояния, получили сигнал перешли в следующее состояние и все. И плюс к этому формочка с менюшками, выводящая на экран состояние игрового поля.
Так вот, там формочка сделана на C#, а функция изменения состояния на F#. (хотя там немного по другому выглядит но суть такая) Эта функция пожалуй основная часть этой программы, для написаня этой функции действительно ФЯ может оказаться полезен. При написании этой функции на других языках, там бы вводили дополнительные вспомогательные костыли-объекты со своими состояниями и переходами, но они в данном случае не нужны.
А другие задачи по структурированию данных, задания логики переходов состояний итд, лучше наверное оставить другим языкам, которые в этом направлении продвинулись.



К ФЯ вроде привинчивают фичи для запоминания состояния, но от этого они скорее получают свойства обычных языков. Назначение ФЯ вроде немного другое.
Re[8]: Разница есть
От: Курилка Россия http://kirya.narod.ru/
Дата: 28.08.04 09:27
Оценка:
Здравствуйте, Silver_s, Вы писали:


S_> А другие задачи по структурированию данных, задания логики переходов состояний итд, лучше наверное оставить другим языкам, которые в этом направлении продвинулись.

Не знаю, но вот как раз с т.зр. структурирования данных имхо ФЯ довольно хорошо выглядят, т.к. всякие списки, деревья и проч. там просто изначально есть и обработка таких типов гораздо проще, причём типы эти полиморфны изначально.
Про логику переходов не знаю, не буду говорить, чего сам очень чётко не представляю
Re[4]: Сильные стороны функционального программирования
От: Xentrax Россия http://www.lanovets.ru
Дата: 28.08.04 19:59
Оценка: 26 (4) +1 -1
Здравствуйте, Glоbus, Вы писали:

G>Товарищ, ответь пожалуйста на такой вот вопрос — если ФЯ так выгодны и мегаудобны — почему же они не используетются?


G>Вот есть например МС — вершина ИТ-сектора, контора с возможно максимальной на сегодняшний день эффективностью — казалось бы, эти товарищи точно должны врубаться что удобно и эффективно, а что нет. Вопрос — почему не пользуют ФЯ, почему не пишут на том же хаскеле.


Удобность и эфффективность инструмента в мире литературы, живописи и разработки программного обеспечения плохо корррелирует с экономическим благостостянием используещего оный инструмент "творца". И уж в MS это понимают.

В последние годы массовую популярность завоевывали только те языки, которые накачивали бооольшими деньгами. А у С++ такая хорошая жизнь наступила из-за того, что компилятор С++ без проблем компилировал код на C (с некоторыми малозночительными "особенностями").


MS обычным людям добра НЕ желает, а желает добра себе и побольше, поэтому придумала C# — Delphi/Java/VBasic/C++/С-подобный язык не для того, чтобы вбухать денег в перестройку фундамента индустрии, а чтобы как можно больше программистов узнали в этом языке знакомые конструкции и знакомые кнопочки. У них даже понятие такое есть — learning curve.

В разработке софта главное — заключить соглашение с OEM партнерами, и хорошо отрекламировать продукт, а не качественно и быстро его написать. Для тех, кто не может содержать программистов в Амеркие, есть Индия, Китай и даже Россия. Только совсем недавно, по мере роста зависимости от софта, и роста потребности в софте, и проникновении софта во все сферы жизни, включая унитаз, американские идеологи индустрии серьезно задумались, что же они будут делать когда программировать будет все население США, включая умалишенных и дошкольников.

Как бы вращение Земли вокруг Солнца тоже долго не признавалось (значительно дольше, чем прошло времени с тех пор, чем у ФЯ появились аппаратные и программные возможноси показать себя в реальном деле). Кроме того, в индустрии ПО постоянно наращивается уровень абстрагирования от железа и алгоритмов — благодарая насыщенным средам, полноценным библиотекам и компонентам, а также паттернам проектирования.

А вот кончится ли постепенное повышение уровня абстракции в разработке ПО переходом на более Ф. языки, неизвестно, так как меня ИЯ удовлетворяют полностью.
Re[7]: Сильные стороны функционального программирования
От: bleed  
Дата: 28.08.04 20:55
Оценка:
VD>>> 2. Создать инициативную группу.
G>>Пусть желающие в нее войти ответят на твой пост, для начала, а там подумаем, что с пунктом 3.

VD>Дык для этого лучше открыть новую тему. Сформулировать все по человечески. А то многие могли просто пропустить эту сообщение.


Я бы хотел поучаствовать и помочь чем смогу. Правда, опыт у меня не очень большой, но интерес есть приличный.
Re[8]: Разница есть
От: Gaperton http://gaperton.livejournal.com
Дата: 29.08.04 09:41
Оценка:
Здравствуйте, Silver_s, Вы писали:

S_>А если суть программы только поддержание состояния этого дерева и передача этого состояния во внешний мир (да хотя бы на экран монитора)? И если еще объекты в дереве привязаны к реальному миру...на одном напрмер висят открытые файлы, на другом ядерный реактор, на третьем сетевое подключение. Это немного меняет суть.


S_> Наверное программу с натяжкой можно считать конечным автоматом. На входы поступают сигналы из внешнего мира, состояние этого автомата считывается извне. Вот для моделирования КА как то плохо себе представляю ФЯ.


Erlang. Функция процесса, реализующая простой конечный автомат. Получает сообщения от других процессов — соответственно, это код с побочными эффектами.
state_machine( state_A ) ->
   receive
      switch_to_state_C -> state_machine( state_C );
      switch_to_state_B -> state_machine( state_B )
   end;

state_machine( state_B ) ->
   receive
      switch_to_state_A -> state_machine( state_A );
      switch_to_state_C -> state_machine( state_C )
   end;

state_machine( state_C ) ->
   receive
      exit -> nil;
      switch_to_state_A -> state_machine( state_A )
   end.


Erlang. То же самое, на чистых функциях. Используем так: NewState = switch_state( OldState, Message ).
switch_state( state_A, Message ) ->
   case Message of
      switch_to_state_C -> state_C;
      switch_to_state_B -> state_B
   end;

switch_state( state_B, Message ) ->
   case Message of
      switch_to_state_A -> state_A;
      switch_to_state_C -> state_C
   end;

switch_state( state_C, Message ) ->
   case Message of
      exit -> terminal_state;
      switch_to_state_A -> state_A
   end.


Сомневаюсь, что на С++ получится проще.
Re[8]: Сильные стороны функционального программирования
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.08.04 11:55
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Э-э-э... То есть что-то вроде основополагающей стати в духе "ФП: что, зачем и почему" в стиле FAQ к comp.lang.functional?


От части. Не мловажную роль тут должен играть призыв объедениться всех заинтересованных людей. Но призывать конечно лучше предварительно объяснив перспективу. Причем нельзя перегибать палку и излишне идиалезировать ФЯ.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Сильные стороны функционального программирования
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.08.04 11:55
Оценка:
Здравствуйте, bleed, Вы писали:

B>Я бы хотел поучаствовать и помочь чем смогу. Правда, опыт у меня не очень большой, но интерес есть приличный.


Прекрасно! Значит ждем новой темы и вообще открытия раздела.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Ну ладно... Реальная вычислительная задача.
От: Silver_s Ниоткуда  
Дата: 29.08.04 16:39
Оценка:
Ну хорошо, возьмем конкретную вычислительную задачу, если ФЯ в них сильны.
Нужно написать функцию. На вход ей подается:
1) координаты прямой на плоскости в виде двух точек (X,Y)
2) флажок указывающий на то что прямую рассматривать как бесконечную, или как отрезок по этим точкам.
3) Координаты прямоугольника.
Нужно подрезать эту прямую (или отрезок если флажок стоит) по границам прямоугольника(все что снаружи него обрезается), и вернуть координаты нового отрезка.

Несмотря на кажущуюся простоту, довольно муторная задача. На ИЯ напишется около 150 строк не очень читабельного кода. Уйдет на это несколько часов.

Даст ли что применение ФЯ для такой задачи? Легчие ли на нем это сделать? Получится ли код читабельным?
И если для такой задачи ФЯ плохо подходит, то для чего вобще тогда он подходит?
Re[2]: Ну ладно... Реальная вычислительная задача.
От: Quintanar Россия  
Дата: 29.08.04 20:54
Оценка: 33 (4)
Вот примерный код. Алгоритм работы простой. Сначала мы находим точки пересечения линии со сторонами прямоугольника, после чего полученный отрезок, если он есть, обрезаем по первоначальному отрезку.
Функции:
intersect_line ((x1,y1),(x2,y2)) ((a1,b1),(a2,b2)) flag
x,y — координаты точек прямой, a,b — координаты прямоугольника. Я предполагаю, что a1,b1 — нижний левый угол, а a2,b2 — верхний правый. flag = 1 если задан отрезок, иначе прямая.
В этой функции создаются функции для прямой по координатам x и y, затем находятся точки пересечения и потом, если
такие точки есть, вызывается функция обрезания по отрезку.

adjust_result p1 p2 (x1,y1) (x2,y2) flag
p — точки найденного отрезка, x,y — точки первоначального отрезка.
Если flag = 1 то находим пересечение этих двух отрезков. Для этого упорядочиваем их точки по возрастанию координаты x (если они равны, то по y). Создаем функцию для сравнения двух точек (приходится это делать из-за особого случая равенства координат x). А дальше рассматриваем 5 возможных случаев взаимного расположения отрезков.

Остальные функции простые и комментариев особых не требуют.
// специальный тип: либо какое-то значение либо ничего. Удобно применять подобный тип в случаях, когда
// функция может вернуть или значение или ошибку (или отказаться возвращать значение).
type 'a my_type = SOME of 'a | NONE;

// для создания функций для прямой
let create_line_func x (x1,y1) (x2,y2) =
    if (x1 = x2) then NONE else SOME (y1-y2)*(x-x1)/(x1-x2)+y1;

// Пересечение со стороной прямоугольника, y1 < y2
let check_intersect line_f (x, (y1, y2))
    match line_f x with
        SOME y => if ((y >= y1) and (y <= y2)) then (x,y) else nill
    |   NONE => nill;

let swap_points (x1,y1) (x2,y2) =
    if (x1 == x2)
        if (y1 > y2) then ((x2,y2),(x1,y1)) else ((x1,y1),(x2,y2))
    else if (x1 > x2) then ((x2,y2),(x1,y1) else ((x1,y1),(x2,y2));

// обрезаем отрезок p1 p2 по отрезку  x y 
adjust_result p1 p2 (x1,y1) (x2,y2) flag
    if (flag = 0) then SOME (p1,p2) else
    let (np1, np2) = swap_points p1 p2 in // упорядочиваем точки по возрастанию
    let (q1, q2) = swap_points (x1,y1) (x2,y2) in // ниже функция > для сравнения 2-х точек
    let greater = if (x1 = x2) then (function (x1,y1) (x2,y2) -> if (y1 > y2) then true else false)
                   else (function (x1,y1) (x2,y2) -> if (x1 > x2) then true else false) in
    // 5 случаев взимного расположения отрезков
    if (greater q1 np2) then NONE
    else if (greater np1 q1) then NONE
    else if ((greater q1 np1) and (greater np2 q2) then SOME (q1,q2)
    else SOME ((if (greater np1 q1) then np1 else q1), (if (greater (q2 np2) then np2 else q2));

// пересечение линии или отрезка с прямоугольником
let intersect_line ((x1,y1),(x2,y2)) ((a1,b1),(a2,b2)) flag =
    let line_f_h x = create_line_func x (x1,y1) (x2,y2) in //уравнение прямой относительно оси X
    let line_f_v y = create_line_func y (y1,x1) (y2,x2) in //уравнение прямой относительно оси Y
    let result = (check_intersect line_f_h (a1, (b1,b2))) :: (check_intersect line_f_h (a2, (b1,b2))) ::
                 (check_intersect line_f_v (b1, (a1,a2))) :: (check_intersect line_f_v (b2, (a1,a2))) :: 
                 nill in // здесь мы создали список точек пересечения прямой с прямоугольником
    match result with
        p1::p2::nill => SOME (adjust_result p1 p2 (x1,y1) (x2,y2) flag) // отрезок
    |   p1::nill => SOME (adjust_result p1 p1 (x1,y1) (x2,y2) flag)   // точка
    |   _ => NONE;                 // пустое множество
Re[9]: Сильные стороны функционального программирования
От: faulx  
Дата: 30.08.04 06:11
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Кстати, что могут дать линивые вычисления в рельных приложения кроме "залатывания концептуальных дыр" ФЯ я так и не осознал.


В статье был простейший пример. Если сформулировать в общих чертах: ленивые вычисления являются средством повышения модульности. В схеме вроде "producer — consumer" модуль-producer становится более изолированным от модуля-consumer'а, соотвественно, повышается возможность его повторного использования.
Re[10]: Сильные стороны функционального программирования
От: INTP_mihoshi Россия  
Дата: 30.08.04 06:39
Оценка:
Здравствуйте, faulx, Вы писали:

VD>>Кстати, что могут дать линивые вычисления в рельных приложения кроме "залатывания концептуальных дыр" ФЯ я так и не осознал.


F>В статье был простейший пример. Если сформулировать в общих чертах: ленивые вычисления являются средством повышения модульности. В схеме вроде "producer — consumer" модуль-producer становится более изолированным от модуля-consumer'а, соотвественно, повышается возможность его повторного использования.


Кхм... А при чем тут ленивые вычисления? ЛВ просто соттветствуют принципу "я не знаю, чему это равно, но знаю, как посчитать, еси меня спросят"
Re[11]: Сильные стороны функционального программирования
От: faulx  
Дата: 30.08.04 08:30
Оценка: 3 (1)
Здравствуйте, INTP_mihoshi, Вы писали:

INT>Здравствуйте, faulx, Вы писали:


VD>>>Кстати, что могут дать линивые вычисления в рельных приложения кроме "залатывания концептуальных дыр" ФЯ я так и не осознал.


F>>В статье был простейший пример. Если сформулировать в общих чертах: ленивые вычисления являются средством повышения модульности. В схеме вроде "producer — consumer" модуль-producer становится более изолированным от модуля-consumer'а, соотвественно, повышается возможность его повторного использования.


INT>Кхм... А при чем тут ленивые вычисления? ЛВ просто соттветствуют принципу "я не знаю, чему это равно, но знаю, как посчитать, еси меня спросят"


Я же говорю, в статье есть пример, очень простой, правда. Producer-у не нужно знать, когда прекращать producing данных. Соотвественну, consumer-у не нужно ничего знать о producer-е. В качестве средства коммуникации между ними служит (потенциально) бесконечный список (иногда его называют stream). Откуда он взялся, consumer-у все равно, он возьмет из него только то, что нужно. Producer-у это списка тоже неинтересно, сколько данных генерировать и когда останавливаться.

Если я не ошибаюсь, в Unix подобным образом работает кострукция program1 | program2.
Re[12]: Сильные стороны функционального программирования
От: Курилка Россия http://kirya.narod.ru/
Дата: 30.08.04 08:42
Оценка:
Здравствуйте, faulx, Вы писали:

F>Здравствуйте, INTP_mihoshi, Вы писали:


F>Я же говорю, в статье есть пример, очень простой, правда. Producer-у не нужно знать, когда прекращать producing данных. Соотвественну, consumer-у не нужно ничего знать о producer-е. В качестве средства коммуникации между ними служит (потенциально) бесконечный список (иногда его называют stream). Откуда он взялся, consumer-у все равно, он возьмет из него только то, что нужно. Producer-у это списка тоже неинтересно, сколько данных генерировать и когда останавливаться.


F>Если я не ошибаюсь, в Unix подобным образом работает кострукция program1 | program2.


Глянь сюда
Автор: Курилка
Дата: 30.08.04
Re[3]: Ну ладно... Реальная вычислительная задача.
От: INTP_mihoshi Россия  
Дата: 30.08.04 13:38
Оценка: 21 (1)
Вот код того же самого для OCaml.

Представляем отрезок параметрическим уравнением a + k*b
По каждому измерению смотрим, какой отрезок значений k лежит в прямоугольнике.
Потом все эти отрезки пересекаем.
Работает для любого числа измерений.

let order (a,b) = 
if (a +. b == nan) 
    then (neg_infinity, infinity) (* Это случай, когда прямая проходит точно по краю прямоугольника *)
    else (if (a<b) then (a,b) else (b,a))

let cut_1d vec1d cut = (cut -. fst vec1d) /. snd vec1d

let dual_cut_1d vec1d (cut1, cut2) = order ((cut_1d vec1d cut1), (cut_1d vec1d cut2))

let add_cuts (min1, max1) (min2, max2) = (max min1 min2, min max1 max2)

let cut_vec_rect vec rect part = List.fold_left add_cuts part (List.map2 dual_cut_1d vec rect) 

let actual_cut_points vec rect part = 
    let (cut1, cut2) = cut_vec_rect vec rect part in
    if (cut1 <= cut2) 
        then List.map (fun (p, d) -> ((p +. cut1 *. d), (p +. cut2 *. d))) vec
        else []


Пустой список в ответе соответствует случаю "нет пересечений".

Это собственно код алгоритма. Далее несколько функций для приведения векторов и прямоугольников в нужный вид и пример использования.

let linia = (neg_infinity, infinity)
let otrezok = (0., 1.)

let bypoints2bydimensions vec = List.fold_left2 (fun l c1 c2 -> (c1,c2)::l) [] (fst vec) (snd vec)
let bydimensions2bypoints vec = List.fold_left (fun (l1, l2) (c1, c2) -> (c1::l1, c2::l2)) ([], []) vec

let makevec vec = List.map (fun (c1, c2) -> (c1, c2 -. c1)) (bypoints2bydimensions vec)
let makerect = bypoints2bydimensions
let showvec = bydimensions2bypoints

let testvec = makevec ([0.; 0.] , [2.; 0.])  (* ([x1; y1] , [x2; y2]) *) 
let testrect = makerect ([0.; 0.] , [3.; 2.]) (* ([x1; y1] , [x2; y2]) *)

let r = showvec (actual_cut_points testvec testrect linia)
Re[5]: Сильные стороны функционального программирования
От: Glоbus Украина  
Дата: 30.08.04 13:47
Оценка: +2 -2
Здравствуйте, Xentrax, Вы писали:

Какая-то патетика про мировой заговор мс. Если уж мы перешли к этому вопрос, то давай, уважаемый, не будем забывать, что мс это наверное контора которая на сегодняшний день из всех что есть больше всех "желает добра людям" как ты выразился. Тема перетиралась тыщу раз поэтому не будем на ней останавливаться — аргумент тут один — где МС и где все остальные
Так вот возвращаясь к вопросу — если мс такие киты капитализма — то чеж ОНИ такие ЛОХИ не юзают ФЯ? Повторяю — не обычные юзеры, которым как ты говоришь промыли мозги шарпами а именно сами МС?
Удачи тебе, браток!
Re[6]: Сильные стороны функционального программирования
От: INTP_mihoshi Россия  
Дата: 30.08.04 13:52
Оценка: +1 -1
Здравствуйте, Glоbus, Вы писали:

G>Так вот возвращаясь к вопросу — если мс такие киты капитализма — то чеж ОНИ такие ЛОХИ не юзают ФЯ? Повторяю — не обычные юзеры, которым как ты говоришь промыли мозги шарпами а именно сами МС?


А зачем? У них и так все хорошо Ну, не выходит WinFS — и хрен с ним. Выпустим без него, все равно купят. Ну, нету генериков на шарпе. Но все равно ж писать на нем будут.
Re[7]: Сильные стороны функционального программирования
От: INTP_mihoshi Россия  
Дата: 30.08.04 14:00
Оценка:
G>>Так вот возвращаясь к вопросу — если мс такие киты капитализма — то чеж ОНИ такие ЛОХИ не юзают ФЯ? Повторяю — не обычные юзеры, которым как ты говоришь промыли мозги шарпами а именно сами МС?

ах да, забыл главную причину. Фя придумали не они Вот доделают F#...
Re[6]: Сильные стороны функционального программирования
От: Gaperton http://gaperton.livejournal.com
Дата: 30.08.04 15:01
Оценка: -2
Здравствуйте, Glоbus, Вы писали:

G>Какая-то патетика про мировой заговор мс. Если уж мы перешли к этому вопрос, то давай, уважаемый, не будем забывать, что мс это наверное контора которая на сегодняшний день из всех что есть больше всех "желает добра людям" как ты выразился. Тема перетиралась тыщу раз поэтому не будем на ней останавливаться — аргумент тут один — где МС и где все остальные

G>Так вот возвращаясь к вопросу — если мс такие киты капитализма — то чеж ОНИ такие ЛОХИ не юзают ФЯ? Повторяю — не обычные юзеры, которым как ты говоришь промыли мозги шарпами а именно сами МС?

Ага. "Если бы это была вещь стоящая, она за границей давно уже распространена была бы. Значит ты, дружок, ерунду придумал". Я понял принцип. Что удобно, думать не надо. Совсем. Вот, например, что я придумал, и хочу своей гениальной мыслью поделиться:

А почему МС не использует CVS? А почему МС не юзает Java? А почему у МС серваки не под Линухом, раз ваш линух такой крутой?? А??? Ацтой ваш линух патамучта. А что это МС не испозьзует ИБМ-овские мэйнфреймы? Сейчас, соберусь с мыслями, и пойду в форумы Java и Unix.

И что прикольно, стоит МС (гипотетически) перевести разработку на ФЯ, и вообще, изменить курс как Биллу за обедом по приколу в голову взбредет, так придется говорить то же самое, но с противоположным знаком. Придется, эта, быть в курсе!

Удивительно, а вы правда считаете, что успех продуктов микрософта как-нибудь связан с языками программирования, на которых они созданы?
Re[6]: Сильные стороны функционального программирования
От: Gaperton http://gaperton.livejournal.com
Дата: 30.08.04 15:19
Оценка:
Здравствуйте, Glоbus, Вы писали:

G>Здравствуйте, Xentrax, Вы писали:


G>Какая-то патетика про мировой заговор мс. Если уж мы перешли к этому вопрос, то давай, уважаемый, не будем забывать, что мс это наверное контора которая на сегодняшний день из всех что есть больше всех "желает добра людям" как ты выразился. Тема перетиралась тыщу раз поэтому не будем на ней останавливаться — аргумент тут один — где МС и где все остальные

G>Так вот возвращаясь к вопросу — если мс такие киты капитализма — то чеж ОНИ такие ЛОХИ не юзают ФЯ? Повторяю — не обычные юзеры, которым как ты говоришь промыли мозги шарпами а именно сами МС?
Так что возвращаясь к этому вопросу, вспомним, что в мире существует очень много вещей, которые не использует МС. Просто ну огромное количество. И факт, что МС не испольует нечто, будь МС хоть слоны капитализма — все равно не делает эти самые вещи ни лучше, ни хуже.

А слоны идут, известно куда. На север. Кстати, если кит на слона налезет — кто победит? ?
Re[4]: Ну ладно... Реальная вычислительная задача.
От: Gaperton http://gaperton.livejournal.com
Дата: 30.08.04 17:10
Оценка:
Здравствуйте, INTP_mihoshi, Вы писали:

Великолепно!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.