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

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

WH>>>Как видишь ПМ и ФВП ужали код в 3 раза на ровном месте.
VD>>Ужали, ладно. Глвное, что после переписывания лично я сразу уловил суть алгоритма. А в этих кучах for-ов его угадать еще нужно (и это не просто).
C>Проблема в том, что в компиляторе ты не уловишь суть алгоритма, если к нему не будет поставлен комментарий типа: "в прошлый заход мы пометили ноду как 'пройденую', теперь пытаемся проверить возможность сворачивания выражения".

Ну, как видишь, алгоритм стал очевиден и читается влет, так как сжат он путем фунциональной декомпозиции.

А что до коментариев, то особенность ФП в том и заключается, что он преобразует одно в другое, то есть ничего не меняется. И значит коментировать нечего. На каждом шаге у тебя получаются данный конкретной версии (стадии обработки).

C>Разбирать код без таких комментариев — жутко неудобно. Я уже попытался так компилятор OCaml'а смотреть.

Поясни, что ты имешь в виду.

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

G>любить работу и работать за деньги несколько параллельные сущности.

Скажем так, они могут сочетаться. Но если они сочетаются, то ты уже работаешь не только за деньги, а "и за деньги тоже...". Улавливаешь разницу?

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

G>то про что говорил ты в изначальном утверждении — взаимоисключение этих понятий.
G>короче я за простоту мотивации деньгами, чем копание в психологии "непризнаного гения".

Причем тут гении? Теболее не признанные...

Одни деньги — это полный приплызд, но никто не говорит, что все работники должны быть альтруистами.

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

VD>Скажем так, они могут сочетаться. Но если они сочетаются, то ты уже работаешь не только за деньги, а "и за деньги тоже...". Улавливаешь разницу?

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

это как раз прекрасно мотивируется деньгами и прочими бонусами.

VD>Одни деньги — это полный приплызд, но никто не говорит, что все работники должны быть альтруистами.

ты говорил. бесспорно — и за деньги и за идею идеальный вариант.

Здравствуйте, Anton Batenev, Вы писали:

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

A>>Как иллюстрация возможности erlang-а (то, что слева меленькое и скромненькое — это apache на мейнстрим C, а красное и могучее — это erlang, цифирики снизу — кол-во _одновременно_ обслуживаемых клиентов сервером). Но вот беда, большинство не знает, что такое функциональное программирование и не видит "миллионов" проектов на erlang-е.

AB>А сайт http://yaws.hyber.org лежит как-то Они не на своем же веб-сервере хостятся случайно? А то RSDN-DOS очень опасная штука
А с чего был сделан вывод, что именно сервер лежал?

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

WH>

WH>        def GetDx(_, _)
WH>        {
WH>        | ([ck], [cf]) =>
WH>            (cf.Map(_ * ck), [])
            
WH>        | (ck :: klast, cf :: flast) =>
WH>            def (incDx, cflast) = GetDx(klast, flast);
WH>            (cf.MapI((i, f) => f * ck + incDx[i]), cf :: cflast)
        
WH>        | _ => throw Exception();//Если списки разной длинны.
WH>        }
WH>

(С)

Автор: WolfHound
Дата: 11.06.07

WH>Как видишь ПМ и ФВП ужали код в 3 раза на ровном месте.

MapI — что это? Map с индексом? IMHO неэффективно для списков (см. incDx[i]). Должна быть функция что то вроде ZipWith, склеивающая по функции два списка:

      (cf.ZipWith(((dx, f) => f * ck + dx), incDx), cf :: cflast)

Если что не так записал — Немерл не знаю

Насчёт же ПМ своё мнение уже высказывал неоднократно — его на рсдн превозносят чересчур. Всё равно на верхнем уровне работать с потрохами не будут, а для стандартных типов вроде списка должна быть библиотека комбинаторов, с которыми мысль выражается яснее.

Например (пардон, ещё раз, за незнание Немерля) на Хаскель эта задача будет выглядеть что то вроде

getDx ks fs = (map sum $ transpose $ zipWith (\x -> map (x*)) ks fs, init fs)

Наверняка можно записать понятнее, transpose здесь некрасив, сейчас нет времени. Позже погляжу.
Смысл такой
zipWith (\x -> map (x*)) — переменожаем ks на столбцы матрицы fs
map sum . transpose — суммируем столбцы

Я верно задачу понял?

В общем, для работы ПМ чаще всего нужен только на уровне модулей, в которых определен ПМ-ящийся тип данных.
Дальше работаем в стиле wholemeal programming.

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

C>>Проблема в том, что в компиляторе ты не уловишь суть алгоритма, если к нему не будет поставлен комментарий типа: "в прошлый заход мы пометили ноду как 'пройденую', теперь пытаемся проверить возможность сворачивания выражения".
VD>Ну, как видишь, алгоритм стал очевиден и читается влет, так как сжат он путем фунциональной декомпозиции.
Нет. Я про другое говорю — вот тебе дадут такой код:

    if (VA.isRegLoc()) {
      MVT::ValueType RegVT = VA.getLocVT();
      TargetRegisterClass *RC;
      if (RegVT == MVT::i32)
        RC = X86::GR32RegisterClass;
      else {
        assert(MVT::isVector(RegVT));
        RC = X86::VR128RegisterClass;
      }
      
      unsigned Reg = AddLiveIn(DAG.getMachineFunction(), VA.getLocReg(), RC);
      SDOperand ArgValue = DAG.getCopyFromReg(Root, Reg, RegVT);
      
      if (VA.getLocInfo() == CCValAssign::SExt)
        ArgValue = DAG.getNode(ISD::AssertSext, RegVT, ArgValue,
                               DAG.getValueType(VA.getValVT()));
      else if (VA.getLocInfo() == CCValAssign::ZExt)
        ArgValue = DAG.getNode(ISD::AssertZext, RegVT, ArgValue,
                               DAG.getValueType(VA.getValVT()));
      
      if (VA.getLocInfo() != CCValAssign::Full)
        ArgValue = DAG.getNode(ISD::TRUNCATE, VA.getValVT(), ArgValue);
      
      ArgValues.push_back(ArgValue);
    }

Читается без проблем. Но вот ЧТО он делает — без комментариев понять сложно.

И вот такого кода в компиляторе — почти весь.

VD>А что до коментариев, то особенность ФП в том и заключается, что он преобразует одно в другое, то есть ничего не меняется. И значит коментировать нечего. На каждом шаге у тебя получаются данный конкретной версии (стадии обработки).
ROTFL.

C>>Разбирать код без таких комментариев — жутко неудобно. Я уже попытался так компилятор OCaml'а смотреть.
VD>Поясни, что ты имешь в виду.
В компиляторе OCaml'а код почти без комментариев. Очень часто просто непонятно ЧТО именно делает данная функция (хотя КАК она это что-то делает — прекрасно понятно).

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

WH>>

WH>>        def GetDx(_, _)
WH>>        {
WH>>        | ([ck], [cf]) =>
WH>>            (cf.Map(_ * ck), [])
            
WH>>        | (ck :: klast, cf :: flast) =>
WH>>            def (incDx, cflast) = GetDx(klast, flast);
WH>>            (cf.MapI((i, f) => f * ck + incDx[i]), cf :: cflast)
        
WH>>        | _ => throw Exception();//Если списки разной длинны.
WH>>        }
WH>>

(С)

Автор: WolfHound
Дата: 11.06.07

L>MapI — что это? Map с индексом? IMHO неэффективно для списков (см. incDx[i]).

Для списков неэффективно, но cf — это не список. Это массив.

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

T>Сам никогда под ВМ не писал, за четыре года работы юзал в общем-то только разные ассемблеры (штуки четыре или пять), C, C++ и немножко Delphi. Ну ещё выучил Lisp чтобы на досуге развлекаться. Но какт всегда думал что в общем-то пофиг managed/unmanaged, инструмент и есть инструмент.

T>В последнее же время наблюдаю совершенно ужасную тенденцию — человек переходит (из-за денег или просто по воле начальства) с неуправляемого кода на управляемый и в течении полугода объективно тупеет. Просто становится неспособен думать про управление памятью, перестаёт представлять себе как чтот функционирует внутри реального железа и как следствие больше не может перейти обратно, становится обречён писать под виртуальные машины. Некоторые даж забывают асм и становятся неспособны сломать простейший прот на программке, то есть сделать вещь которую даже шестнадцатилетние дети умеют и которая вообще навыков программирования не требует. Забывает Рихтера и организацию памяти, зато начинает думать о какойт "бизнес-логике" и прочей лабуде. Хуже того, забывает основные алгоритмы, забывает Кнута и Кормена, зато начинает хвастаться знанием каких-то "библиотек" и "платформ".

А внесу-ка я свои три копейки в эту дискуссию.

Мне как раз последние полтора года пришлось иметь дело с Явой и C#. Отупляет ? Да. Но не уверен , что дело именно в управляемости или неуправляемости кода (замечу в скобках , что я здесь известен как активный противник управляемого кода

Дело скорее в задачах. В сущности самих задач. В неуправляемой среде пишут чаще всего программы, в которых требуются более или менее серьезные алгоритмы. Думать надо, одни словом. И не только об управлении памятью (это, в конце концов, мелочи), а о структуре данных в программе, о потоках данных (не stream , о быстродействии и т.д.

В моей практике был случай, когда, получив от заказчика задание, я две недели не написал ни одной строчки. Никак не мог придумать решение, которое меня бы полностью устроило. Бездельничал. Занимался прочими делами. Подсознание работало, и в какой-то момент решение было найдено, оставалось его запрограммировать, что я за пару дней и сделал. Заказчик меня хорошо знал и не торопил.

Смог бы я то же сделать на управляемом языке ? Бесспорно да. С извращениями, правда, так как в решении использовались memory-mapped файлы с плохо типизированными данными, а это то, чего в управляемых средах боятся как черт ладана. Но в том-то и дело, что программу такого рода на нем писать никому в голову и не пришло бы в голову.

А большинство задач, для которых используются управляемые среды — это бизнес-задачи. В них алгоритмы если и не совсем на нуле, то почти. И сложной структуры данных, как правило, тоже нет. Наборы классов с геттерами и сеттерами (они меня порой забавляют, видишь код на 2-3 сотни строчек, вроде серьезно, а по существу — просто структура старого доброго C (даже не С++) + конструктор. А все остальное — геттеры и сеттеры, причем автогенерированные). И суть задачи там не в том, чтобы сложную логику в программе реализовать (ее просто в большинстве бизнес-задач нет), а в том, чтобы аккуратно все сделать. Геттер туда, сеттер сюда, оттуда взять, сюда положить, в базу записать, из нее прочитать, на экран вывести. И не забыть подходящий паттерн обязательно применить, без паттерна тебя просто не поймут И т.п.


Шутки шутками, а когда мне после полугода такой деятельности пришлось-таки написать простенький двойной цикл, я даже удивился и подумал — не ошибся ли, может, не то делаю ? Нет, все же оказалось, что двойной цикл там был на месте. В последующий год мне больше писать вложенных циклов не довелось

Естественно, от такой деятельности тупеешь. Еще один класс, еще десяток геттеров и сеттеров, в конце концов думаешь — будет этому конец или нет ?

И еще один фактор здесь сущетсвенен. Это — любовь к компонентам. Если надо что-то сделать — ищи соответствующий класс, он тебе все и обеспечит (пусть крайне неэффективно, может быть). Нашли — применяй его и весь разговор. Время не терпит, изобретать свои велосипеды некогда. Отсюда и соответсвующая психология, человеку просто не приходится писать что-либо сложное самому, а, следовательно, умение писать сложное атрофируется. Кстати, помните насчет программиста на Delphi — "пишет в соответсвующую эху : Народ, где найти компонет, который ищет льва в пустыне и сажает его в клетку"

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

Ну а вывод ? Он, в общем-то, скорее всего не тот, который прочитавшие это ожидают.

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

Ситуация примерно та же, как если бы Микеланджело или Растрелли предложили бы построить Эмпайр Стейтс Билдинг (я отвлекаюсь от вопроса, сумели бы они это сделать или нет). Скорее всего они бы сказали, что строить подобные параллелепипеды с пчелиными сотами внутри — типичное отупение, и со своей позиции были бы правы. Ну а для архитекторов Эмпайр Стейтс Билдинг это была неплохая работа...

Вот, правда, собор святого Петра или Эрмитаж они бы все же не построили. Технически — никакой проблемы, а не построили бы все же...

Кесарю кесарево, а слесарю — слесарево

Здравствуйте, Pavel Dvorkin, Вы писали:


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

Упрощаешь, областей намного больше чем две и многие из этих областей паралельны (а некторые и перпендекулярны ) противопоставлению управляемый — неуправляемый.

Здравствуйте, Pavel Dvorkin, Вы писали:

Действительно прискорбно, сочувствую.
Но тут есть один нюанс. Ведь в чем вся прелесть простой и монотонной работы? В том, что ее можно автоматизировать.
Попробуй. Очень помогает от отупения.

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

AF>Здравствуйте, Pavel Dvorkin, Вы писали:

AF>Действительно прискорбно, сочувствую.
AF>Но тут есть один нюанс. Ведь в чем вся прелесть простой и монотонной работы?

Ну насчет прелести — это ты явно загнул

>В том, что ее можно автоматизировать.

Эх... Можно, конечно. Беда в том, что на это времени нет.

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

FR>Упрощаешь, областей намного больше чем две

Я же не говорю, что областей две в том смысле, что других вообще нет. Просто задачи можно (порой неточно, порой условно) отнести к одной из этих двух категорий. Бизнес-программирование и все остальное. Остальное весьма обширно, разнооборазно, порой и перпендикулярно, но это не бизнес-программирование.


>и многие из этих областей паралельны (а некторые и перпендекулярны ) противопоставлению управляемый — неуправляемый.

С этим согласен, да и сам я писал, что мог бы при желании написать на управляемом коде, только не нужно это.

Я тут видел примеры JRuby, и там как пример краткости Ruby приводилось:
Ruby:

print "123"

Java:

public class MyClass {
  public static void main(String args[]) {
    System.out.println("123");
  }
}

и у меня такое чувство возникло, типа "Мля, вот учил всю эту хрень, а оно уже не нужно получается" Внутри меня все возмутилось "Как же так, это же слишком легко получается!"
Но создавать тему по поводу того, что Ruby отупляет, я не стал.
Иногда нужно приложения писать с мощным расслоением, с помощью EJB и пр., а иногда это просто пустая трата времени и денег, все зависит от задач.
Так что я рекомендую аффтору темы одуматься пока не поздно
Против прогресса не попрешь! На руби студентов можно нанять и бабки экономить!

забыл добавить, сам я на жабе програмлю

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Эх... Можно, конечно. Беда в том, что на это времени нет.

Прямо как в анекдоте про лесоруба, которому некогда наточить пилу, потому что надо еще кучу деревьев спилить.

Ты же на асме, си и т.д. используешь чужие битблиотеки. И это нормально. В управляемом коде ты можешь использовать только готовые библиотеки. Т.к. у меня уже не болит голова как передаются аргуметы (хотя даже в 1Ске переодически приходится думать, т.к. гоняются ссылки), как выделяется память и т.д. я могу писать больше полезного ПО для заказчика.
Это ИМХО основной плюс.

В плане тупит — в принципе согласен. Цель сделать так, чтобы порог входа был как можно меньше, значит ЗП программиста будет меньше, значит либо цена на ПО упадет, либо шеф больше поимеет

Научится программировать для меня проще всего на
1) 1Ска 7
2) Шарп+Дельфи+ВБ+1Ска 8 (это ИМХО клоны)
3) Паскаль
4) АСМ по х86
5) С++

На другом не кодил.

T>P.P.S. Кроме программирования, преподаю сейчас на кафедре и вижу почти те же тенденции у своих студентов, прям с детства стремление меньше думать больше получать.

Рабство: давать рабам столько, чтобы они работали и не дохли. Принцип олплаты поменялся не сильно. Вот студенты и хотят больше получать. Ну и пусть ХОТЯТ

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

AF>Прямо как в анекдоте про лесоруба, которому некогда наточить пилу, потому что надо еще кучу деревьев спилить.

Именно

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


WH>Нужно учесть то что подавлюяющая масса "программистов" в принципе не могут подняться выше уровня быдлокодера. Вне зависимости от того на чем они пишут. Те если человек не способено то ему хоть 1C хоть ASM всеравно толку не будет.
WH>А вот те кто в состоянии подняться на высокий уровень могут работать на любых языках.
+1

WH>Ибо одни задачи проще писать на одном языке, а другие на другом.
Точно. Для управления КОМ-портом юзаю дельфу, а для моих клиентов (магазины и небольшие фирмы) 1С, т.к. изобретать свою буху на дельфи или шарпе влом и никто не оценит (денег не дадут лишних).

ДВ>

ДВ>public class MyClass {
ДВ>  public static void main(String args[]) {
ДВ>    System.out.println("123");
ДВ>  }
ДВ>}
ДВ>

Помнится, когда я это впервые увидел, подумал: "Блин, а нахрена оно все это нужно, если можно WriteLn() написать?" (я тогда только-только Паскаль выучил )

Много лет спустя я прозрел, но недоумение осталось

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

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

L>>MapI — что это? Map с индексом? IMHO неэффективно для списков (см. incDx[i]).

K>Для списков неэффективно, но cf — это не список. Это массив.

А зачем там массив? Алгоритмически нужен сильный random access по индексам?