Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Ну уж нет. Читай внимательно. Выделено мной.
IT>>>Вот здесь два примера того, как правильные высокоуровневые конструкции могут сделать код в разы проще, понятнее и эффективнее
PD>>Код!
FR>Это
FR>
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, Константин Л., Вы писали:
КЛ>>может быть после того, как поучаствуешь, будешь говорить про мальчиков-архитекторов?
[]
от твоей манеры общения пропадает все желание тебе отвечать
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да. Но не более эффективно, чем собственно ассемблер. В лучшем случае (см. выделенное мной) — не хуже. А ведь обещали на порядок — вот я и смеюсь.
Неочевидно, кто будет смеяться последним. Представления вашего поколения об эффективности программ оказались плохо совместимыми с реальностью.
Помимо abstraction penalty есть еще и abstraction gain.
В реальной жизни вручную оптимизировать мало-мальски сложный алгоритм на ассемблере не получится — слишком мала емкость головы. И это даже если задаться конкретным целевым процессором и параметрами окружения.
Наточить вручную программу, которая будет эффективна на широком классе условий эксплуатации — вообще малореально. В том смысле, что всё-таки придется вводить абстракции высокого уровня. Ну, например, придется делать подменяемый алгоритм сортировки чего-нибудь, чтобы выбирать его в зависимости от количества ядер процессора.
А то и вообще придется точить свой кодогенератор, который будет инлайнить оптимальный для данного RegEx целевой код непосредственно перед вызовом.
В итоге, если потратить достаточное время и усилия, то скорее всего получится та самая управляемая среда, jit, hot-spotting, query plan evaluation, и прочие техники, с успехом применяющиеся там, где некоторые упертые программисты до сих пор думают, что ассемблер лучше.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
VD>Как ни одного? А тогда к чему вся эта пышная демагогия?
Шикарно. Предлогаю переименовать форум в "Демагагия программирования", как более соответствующее духу дискуссий
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Pavel Dvorkin, Вы писали:
FR>>>по твоему не код?
PD>>А он эффективнее в разы ?
FR>В смысле читабельности и писабельности конечно.
В этом смысле — мб, и да, если знать Хаскель, конечно. Но меня вообще-то больше интересует эффективность его выполнения
Здравствуйте, FR, Вы писали:
FR>По моему тут только ты единственный его неправильно понял.
Если бы было сказано — кодирования — я бы еще засомненвался. Но эффективность кода — как еще можно понять ? Ладно, спишем — будем считать, что я проявил плохие телепатические способности, в отличие от вас всех
Здравствуйте, Sinclair, Вы писали:
S>В итоге, если потратить достаточное время и усилия, то скорее всего получится та самая управляемая среда, jit, hot-spotting, query plan evaluation, и прочие техники, с успехом применяющиеся там, где некоторые упертые программисты до сих пор думают, что ассемблер лучше.
Я что-то одно не понял. Я вроде говорил, что сделать лучше, чем на ассемблере , да и то предельно оптимизировав, не получится, а не то, что ассемблер лучше. Разницу чувствуешь или объяснить ?
Конечно, проще спорить , если предварительно приписать оппоненту то, что хотелось бы от него слышать... Впрочем, этот твой стиль мне давно знаком.
Меж тем я уже не раз слышал от Синклера, что "язык ему очень нравится".
AVK>Просто предложил почитать его сообщения, бо с его точкой зрения в тех флеймах я в общем и целом согласен.
Я их читал. Потому и говорю.
VD>>Может быть мне конечно и показалось, но он в некоторый момент как-то резко переменил риторику.
AVK>Ну и кто из нас тут говорит за Синклера?
А я как раз за него и не говорю. Он сам за себя довольно не двусмысленно сказал.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>Ну а что я могу на подобное ответить?
VD>Дать ссылку
Лень
VD> или признать, что внятного объяснения нет.
Я уже признал — для тебя внятного объяснения у меня нет.
AVK>>Учитывая, что "внятное" — характеристика в большей степени субъективная,
VD>А это уже судить тем кто будет смотреть ссылки.
И где я тут сказал за Синклера???
VD>Меж тем я уже не раз слышал от Синклера, что "язык ему очень нравится".
Наздоровье. Это не отменяет того простого факта, что те претензии к Немерле, что он высказывает, вполне соответствуют моим претензиям.
AVK>>Просто предложил почитать его сообщения, бо с его точкой зрения в тех флеймах я в общем и целом согласен.
VD>Я их читал.
Зачем тогда ссылки с меня требуешь?
AVK>>Ну и кто из нас тут говорит за Синклера?
VD>А я как раз за него и не говорю. Он сам за себя довольно не двусмысленно сказал.
Интересно, а ты ссылочку дашь?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, IT, Вы писали:
VD>>1. Неизменяемые структуры данных. VD>>2. Аглебраические типы данных (variant в Nemerle).
IT>Я это не упомянул, т.к. это всё опять же работает на уровне кода. На компоновку кода и архитектуру приложения это никак не влияет.
Достаточно сравнить архитектуру компилятора написанного на ООЯ и на том же Немерле. Сразу видно, что два этих пункта сильно влияют на архитектуру. Так что тут я с тобой не соглашусь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В этом смысле — мб, и да, если знать Хаскель, конечно. Но меня вообще-то больше интересует эффективность его выполнения
Ключевым моментом, которого пока не касались в этой дискуссии, является высокоуровневая оптимизация, про которую никакой ассемблер не знает. Например, в Хаскелле есть дефорестация (list fusion). Вася взял список, применил к его элементам функцию f, получив другой список:
vasja lst = map f lst
Петя взял васин код, и поэлементно применил к возвращаемому этим кодом списку функцию g
petja lst = map g (vasja lst)
Оля взяла петин код, поэлементно применила к возвращаемому этим кодом списку функцию h
olja lst = map h (petja lst)
Компилятор Хаскеля взял эту конструкцию с кучей промежуточных списков и оптимизировал в
Здравствуйте, D. Mon, Вы писали:
DM>А вот тут подробнее, пожалуйста. Как упомянутые фишки изменят дело, кроме более удобного синтаксиса? DM>Вот задачка: есть семейство алгоритмов (та же компенсация, допустим), которые теперь отличаются не одной функцией, а пятью (при этом имеют по 10 общих). В случае ООП и наследования все просто — общие функции в базовый класс, различные — в наследников.
Вот эти "если" — это все выдумки. На практике если для алгоритма требуется передавать более трех функций, то что-то не так в самой функции. Когда код исходно пишется в функциональном стиле, то функция пишется не как монолит с "настройками", а собирается из других более общих функций. При этом происходит нечто вроде IoC (разворот управления). Вместо того чтобы создавать функцию-монстра и потом передавать ей тонну детализирующих функций, нужная функция собирается из кусков. Примером тут может служить LINQ. В нем нет одной супер-функции типа Query, а есть несколько функций: Where, OrderBy, ThenBy, Join, Group, Select и т.п. Каждая из них принимает одну-две лямбды и возвращает некий обект-контекст к которому можно применять другие функции из приведённого списка.
Ну, и если, что то гибридный язык позволяет использовать для обледенения набора функций и интерфейсы с реализациями. На программу (если ее пишут не долболомы) таки случаев должно быть не много, за то случаев где требуется передать одну-две функции море. Это сэкономит массу времени сил и избавит код от не нужных типов (баласта).
DM>А что в этом случае делают в Хаскеле и Лиспе?
Ты бы попробовал на них по программировать, а потом бы уже вопросы задавал. А то тебе ведь ничего объяснить нельзя просто по определнию. Ты думаешь другими категориями.
DM>Первое, приходящее мне на ум решение, — функция-конструктор, которая получает на вход охапку тех функций, что отличают конкретный алгоритм, и выдает в качестве результата одну функцию, его реализующую. Последняя уже вызывается когда надо. Т.е. все детали специализации пошли в замыкание, и по сути, мы получили некий аналог объекта из ООП, но с меньшим числом степеней свободы.
Есть разные пути. В конце концов не трудно функции поместить в кортеж. Но на самом деле сама постановка задачи — это выдумка.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Достаточно сравнить архитектуру компилятора написанного на ООЯ и на том же Немерле. Сразу видно, что два этих пункта сильно влияют на архитектуру. Так что тут я с тобой не соглашусь.
В общем, я бы поправил твое высказывание следующим образом:
ФП с человеческим лицом офигительно улучшает и упрощает реализацию алгоритмов за счет встраивания в язык мощных фич вроде поддержки ФВП, паттерн-матчинга, возможности возвращать значение почти из любой конструкции языка, вывода типов и т.п., а так же позволяет, в некоторых случаях, существенно упростить проектирование отдельных частей приложения заменив классы алгебраическими типами данных и неизменяемыми структурами данных.
В таком описании соглашусь полностью.
Собственно проблема только в том, что тех кто придерживаются такого мнения окружают с двух сторон. С одной стороны те кто не хочет или не может (в силу своих особенностей) воспринять ФП, а с другой те кто кроме ФП ничего больше не видят и не приемлют.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>>Вот здесь два примера того, как правильные высокоуровневые конструкции могут сделать код в разы проще, понятнее и эффективнее.
PD>Полностью абстрагируясь от эффективного вычисления процентов , отмечу лишь, что сделать код с помощью каких-то высокоуровненвых конструкций проще — можно, понятнее — тоже можно, а вот эффективнее — дудки. Потому что предельно эффективная программа — это наилучшим образом оптимизированная программа, написанная на ассемблере. А в этом самом ассемблере есть только презренные присваивания, if, с грехом пополам циклы, и ни одной лямбды
Дворкин, а что ты тогда делаешь в форуме по дотнету, да и здесь? Ты же должен писать софт на асме. И по сему, времени у тебя свободного остаться не должно. Вот у меня и возникает вопрос, ты просто: ты нас обманываешь или заказчиков?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>>Вот если бы я был АВК, то сказал бы "опять С++
AVK>Фи, как грубо и неумело. Не переноси свои фобии на других.
Какие фобии? Как только где-то появляется слово Nemerle, так то час мы видим тебя с громкими воплями "опять этот Nemerle...". Право, реакция совершенно не адекватная. Если в Nemerle ничего нет, то что так на него реагировать то? (вопрос риторический)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, Константин Л., Вы писали:
_FR>>>То есть можно жертвовать надёжностью, модульностью, локализацией ради "читабельности"? Это при том, что мнение "чем локальнее объявление, тем лучше" можно считать верным (или нет?), а "читабельность" — величина субъективная?
КЛ>>где ты увидел что я ими жертвую? private static. ни стейта, ни открытости.
_FR>Ну представь себе такой не очень маленький класс. Кому-то понадобилось дописать в него некий метод, в котором понадобился какой-то хелпер. Он смотрит: ага! кто-то добрый уже такой написал! и берёт его. Вот связанность и получилась. Когда же хелпер объявлен локально, "случайно", поошибке, "не правильно" заиспользовать его невозможно, нужно явно постараться.
Прости, но если это хелпер, который удовлетворяет его потребности, то это значит, что мы написали реюзабельный код, и его уже можно попробовать вынести наружу в common/utils. Чем лучше в данном случае подход "локальная функция на каждый чих"?
КЛ>>>>плюс от к захвату контекста все-же лучше прибегать с осторожностью.
_FR>>>Вынося метод "наружу" ты позваляешь кому-то (а как ты запрещаешь? ага, никак!) к нему обратиться, тем самым увеличивая связаность. К лишней связаности надо относиться с ещё большим подозрением чем "к захвату контекста". Кстати, из за чего требуется осторожность? И, между прочим, мы же говорим о методах, не захватывающих контекст.
КЛ>>связанность и там и там. только в одном случае по параметрам, в другом по локальным переменным. Наружу это куда? Я же написал — private.
_FR>Связанность с параметрами — нормальное дело. Это всё равно что утверждать, что класс связан со своими членами: конечно связан, только это "положительная связь", в том смысле, что не причиняет вреда и которую легко порвать.
Тогда еще раз повторюсь.
КЛ>плюс от к захвату контекста все-же лучше прибегать с осторожностью.
_FRВынося метод "наружу" ты позваляешь кому-то (а как ты запрещаешь? ага, никак!) к нему обратиться, тем самым увеличивая связаность. К лишней связаности надо относиться с ещё большим подозрением чем "к захвату контекста". Кстати, из за чего требуется осторожность? И, между прочим, мы же говорим о методах, не захватывающих контекст.
КЛ>>связанность и там и там. только в одном случае по параметрам, в другом по локальным переменным. Наружу это куда? Я же написал — private.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, Константин Л., Вы писали:
КЛ>>может быть после того, как поучаствуешь, будешь говорить про мальчиков-архитекторов?
MS>У тебя есть разум, надо только научиться им пользоваться. Почему все приходится разжевывать? Понимаешь, нет в этом моем высказывании ничего уничижительного. Я просто хотел сказать, что бывают разные задачи по самой сути. Для меня — это придумать алгоритм и отдать его "мальчикам-архитекторам" и прочим. И меня не интересует размер проекта, это их забота (про разделение труда слышал?) Поэтому, можно сказать, что я и не участвую в этом проекте. При этом архитекторы могут считать меня неким мальчиком-алгоритмистом и в этом тоже нет ничего уничижительного.
Ну что за тон, право?
Понимаешь, обычно уменьшительно-ласкательные приставки это способ выразить насмешку, презрение. Мне вот было интересно, на каком основании ты всех архитекторов того, под общую гребенку, м? Я тебя спросил, я ты мне тут же "не участвовал, стремно; используй моск, приходится разжевывать". Твой тон очень резок и категоричен. Как ты хочешь, чтобы потом тебя нормально понимали?
MS>Бывали и казусы. Однажды архитекторы так запроектировали некий модуль обработки данных, что он требовал квадратичного времени выполнения как ты ни кодируй (а надо и можно было обойтись линейным.) В результате, по самым оптимистичным прогнозам, данная архитектура на реальных объемах данных требовала бы не меньше 500 лет для обработки. Зато все было очень красиво.
Как твоё "используй моск, я никого не хотел обидеть, бывали казусы" сочетается с вот этим высказыванием?
А уж обернуть в классы и иерархии, плюс кодовая оптимизация — это рутина, этим пусть мальчики-архитекторы и мальчики-кодеры занимаются. Я всегда готов их проконсультировать и объяснить сущность алгоритма.
1. Обосрал процесс создания архитектуры
2. Обосрал пару профессий вместе с ихними представителями
Здравствуйте, Константин Л., Вы писали:
КЛ>Ну что за тон, право?
КЛ>Понимаешь, обычно уменьшительно-ласкательные приставки это способ выразить насмешку, презрение.
ИМХО, вполне естественная, хоть и некорректная, реакция на попытку пенисометрии.
КЛ>1. Обосрал процесс создания архитектуры КЛ>2. Обосрал пару профессий вместе с ихними представителями
Это у него такая манера беседовать. Не только у него, кстати. Остается только либо забанить его навечно, либо терпеть, пока он совсем не выйдет за рамки.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
