Здравствуйте, IT, Вы писали:
IT>Работоспостобность — это не только баги, но ещё и нефункциональные требования, вроде требований к быстродействию и используемым ресурсам. Реализуются эти требования как правило с помощью разнообразных оптимизаций на всех уровнях. Оптимизации, в свою очередь, могут в разы ухудшить читабельность кода. Взять хотя бы распараллеливание или кеширование.
Правильно! Именно поэтому мы и любим средства, которые позволяют использовать распараллеливание и кэширование не ухудшая читаемость.

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

IT>Работоспостобность — это не только баги, но ещё и нефункциональные требования, вроде требований к быстродействию и используемым ресурсам. Реализуются эти требования как правило с помощью разнообразных оптимизаций на всех уровнях. Оптимизации, в свою очередь, могут в разы ухудшить читабельность кода. Взять хотя бы распараллеливание или кеширование.

Оптимизации ухудшающие читабельность выполняются под конкретные требования и затрагивают от силы 10% кода.

IT>И только последним пунктом у нас идёт maintainability (сопровождабельность), частью которой как раз и являются адекватные требования к читабельности кода.

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

IT>Неправильно фиксировать сопровождаемость на первом месте навсегда и ради неё жертвовать функциональными или нефукнциональными требованиями.

Ежели систематически жертвовать читабельностью ради требований, то проект в скором времени сдохнет.

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

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

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

IT>>И только последним пунктом у нас идёт maintainability (сопровождабельность), частью которой как раз и являются адекватные требования к читабельности кода.

U>Главное — это соответствие приложения требованиям заказчика сегодня, завтра, через полгода, через пять лет. Читабельный код это необходимое условие выполнения этого требования. Нечитабельный код может соответствовать требованиям заказчика сиюминутно (хотя обычно и в этом случае читабельный код обошелся бы дешевле), но любое изменение этих требований в будущем приводит к проблемам и с работоспособностью, и с функциональностью и со сроками.

Если контракт на конкретный объём работ — зачем мне закладываться на двести лет вперёд? Я завершил разработку по ТЗ, внедрил, мы разошлись. Так что главное — это соответствие ТЗ.

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

Если вы не можете, это не значит, что это невозможно. Да, дорого. Да, муторно. Но вполне реально. Это я по своему опыту говорю.

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

AS>Если контракт на конкретный объём работ — зачем мне закладываться на двести лет вперёд? Я завершил разработку по ТЗ, внедрил, мы разошлись. Так что главное — это соответствие ТЗ.

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

AS>Если вы не можете, это не значит, что это невозможно. Да, дорого. Да, муторно. Но вполне реально. Это я по своему опыту говорю.

Все реально, только обычно дешевле заново написать, используя отдельные функциональные куски из старого кода.

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

U>Оптимизации ухудшающие читабельность выполняются под конкретные требования и затрагивают от силы 10% кода.

Да хоть пол процента. Главное, что у оптимизаций приоритет выше, чем у читабельности.

IT>>И только последним пунктом у нас идёт maintainability (сопровождабельность), частью которой как раз и являются адекватные требования к читабельности кода.

U>Главное — это соответствие приложения требованиям заказчика сегодня, завтра, через полгода, через пять лет.

Вот. Правильно.

U>Читабельный код это необходимое условие выполнения этого требования.

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

U>Ежели систематически жертвовать читабельностью ради требований, то проект в скором времени сдохнет.

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

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

ВВ>>> Объективно ведь никто не заставлял в C# делать так
AVK>>ИМХО, на правоверных сишников рассчитано. Существование i++ и ++i из той же оперы.

ВВ>В принципе-то если тебе надо сделать сначала инкремент, потом передать значение в функицию, то чем плохо:
ВВ>MyFunc(++i)
ВВ>Тоже плохо читается? Но ведь все вроде наглядно
ВВ>Кстати, ведь тернарный оператор тоже в общем-то читабельность не улучшает. И даже нововведенный ??

Я те так скажу. В Nemerle операции ++/-- (и инфиксная и префиксная) и = имеют тип void и стало быть не могут использоваться в выражении. По началу я авторам тоже задал вопрос типа твоего. Получил ответ такой. Мы в дизайне языка стремились избавиться даже от малейших возможностей сделать случайную ошибку программистом.

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

По факту использую изменяемые переменные только там где это действительно может дать огромный выигрыш.

Так что на ваши споры я смотрю с усмешкой. Ты ратуешь за фичу думая, что она обеспечит тебе краткость, в то время как она как раз обеспечивает длинный говнокод который тяжело отлаживать. Как показывает практика вычисления вообще без изменения состояния дает куда более краткий код. Так что "x + 1" становится препочтительнее "х++" и "++х" вместе взятых (и даже вопроса не возникает писать "х + 1" или "1 + х" , а использование рекурсии зачастую лучше чем использование изменяемых переменных в циклах.

Так что я бы лучше обсудил другой вопрос — "Почему современные мэйнстрим-языки навязывают императивный стиль". Какого скажем рожна я не могу в C# создать неизменяемую локальную переменную?

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

VD>Я те так скажу. В Nemerle операции ++/-- (и инфиксная и префиксная) и = имеют тип void

А зачем тогда вообще две формы ++?

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

VD>Так что на ваши споры я смотрю с усмешкой. Ты ратуешь за фичу думая, что она обеспечит тебе краткость,

Я не ратую за фичу. А пытаюсь развести маленький флейм
Как раз под влиянием твоего комментария в какой-то ветке, что inline assignment это плохо.

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

Длинный говнокод обеспечивают говнокодеры. На VB.NET, даже при соблюдении всех пассов в целях повышения его, так сказать, "типизированности", говнокод вот выходит даже куда лучше в C#. Ну правда, в том, что приложения плохо написаны виноват язык и его возможности, которыми все пользуют без разрабора?
По-моему как раз напротив — проблема в том, что возможностями языка не пользуются.
А то, что у большинства фичек языка — начиная от самых простеньких вроде того, что оператор возвращает результат операции, и кончая более, так сказать, фундаментальными — есть "побочные" эффекты тут уж ничего не попишешь. Собственно, немалое количество посвящено обсужденями в стиле, полезна ли возможность Х или не полезна.
Да в общем-то и далеко ходить-то не надо. Что пишут в этой ветке, пытаясь доказать, что inline assignment — это плохо? Пишут "говнокод".
Коллеги, ради бога, я вам и без inline assignment такой говнокод напишу, что заснуть всю ночь не сможете

VD>Как показывает практика вычисления вообще без изменения состояния дает куда более краткий код. Так что "x + 1" становится препочтительнее "х++" и "++х" вместе взятых (и даже вопроса не возникает писать "х + 1" или "1 + х" , а использование рекурсии зачастую лучше чем использование изменяемых переменных в циклах.

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

VD>Так что я бы лучше обсудил другой вопрос — "Почему современные мэйнстрим-языки навязывают императивный стиль".

Императивный стиль — это мейнстрим. Практика опять-таки показывает, что у императивного стиля много проблем. Ну а как быть с функциональным стилем? Не появится ли у него даже большее количество проблем, чем у императивного стиля, если он станет мейнстримом?

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

VD>Какого скажем рожна я не могу в C# создать неизменяемую локальную переменную?

Я бы начал даже с неизменяемых in параметров функций.

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

AVK>А зачем тогда вообще две формы ++?

А они автоматом получаются. Описываешь оператор и можешь использовать его как нравится. Особенно хорошо для эстетствующих особ или долболомов считающих что скажем ++i быстрее чем i++.

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

ВВ>Длинный говнокод обеспечивают говнокодеры. На VB.NET, даже при соблюдении всех пассов в целях повышения его, так сказать, "типизированности", говнокод вот выходит даже куда лучше в C#. Ну правда, в том, что приложения плохо написаны виноват язык и его возможности, которыми все пользуют без разрабора?

Конечно появление говнокода без "умелых" рук невозможно (ну или плачевного состояния мозга программиста в момент написания оного, например, из-за аврала). Однако есть четкая зависимость между общим объемом говнокода на еденицу площади проекта и языком программирования. Скажем С++ по этом параметру явный лидер. Это не значит, что на С++ нельзя писать качественный код. Это значит, что С++ не способствует написанию хорошего кода.

По мне так если язык уберегает от граблей, то это несомненный плюс. От того на плюсах я вообще перестал писать.

ВВ>Да в общем-то и далеко ходить-то не надо. Что пишут в этой ветке, пытаясь доказать, что inline assignment — это плохо? Пишут "говнокод".
ВВ>Коллеги, ради бога, я вам и без inline assignment такой говнокод напишу, что заснуть всю ночь не сможете

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

Так что присвоение нужно рассматривать как оптимизацию. А раз это оптимизация, то ее лучше выделить в отдельную строку, а то и функцию. Так оно надежнее будет. И так мест где можно сделать ошибку слишком много.

VD>>Как показывает практика вычисления вообще без изменения состояния дает куда более краткий код. Так что "x + 1" становится препочтительнее "х++" и "++х" вместе взятых (и даже вопроса не возникает писать "х + 1" или "1 + х" , а использование рекурсии зачастую лучше чем использование изменяемых переменных в циклах.

ВВ>У меня возникает такое ощущение, что практика показывает, что человеческий мозг очень хорошо умеет приспасабливать к теории
ВВ>Вот помню были раньше обсуждения — хорошо ли множественное наследование или плохо и почему его нет в C#. Мне вот одно время его не хватало. Теперь я не только о нем не вспоминаю, но, более того, даже готов отстаивать, что множественное наследие — это зло и вообще говоря концептуально неправильно в рамках ООП. А, черт его знает, может так оно и есть. А может, и не так. Но ведь "практика" говорит, извините...

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

VD>>Так что я бы лучше обсудил другой вопрос — "Почему современные мэйнстрим-языки навязывают императивный стиль".

ВВ>Императивный стиль — это мейнстрим.

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

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

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

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

ВВ>Я вот в императивном стиле проблем особых не вижу. Когда приложение правильно спроектировано, пишется с использованием мозга и пр. Проблемы ведь на самом деле не из-за императивности возникают.

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

VD>>Какого скажем рожна я не могу в C# создать неизменяемую локальную переменную?

ВВ>Я бы начал даже с неизменяемых in параметров функций.

Это частности. Скажем в Немерле все переменные по умолчанию не изменяемые. В том числе и параметры. Если надо их сделать изменяемыми, то надо использовать ключевое слово mutable перед ним. И никаких проблем. Только изменение подхода. Так просто, а работает на ура.

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

VD>Конечно появление говнокода без "умелых" рук невозможно (ну или плачевного состояния мозга программиста в момент написания оного, например, из-за аврала). Однако есть четкая зависимость между общим объемом говнокода на еденицу площади проекта и языком программирования. Скажем С++ по этом параметру явный лидер. Это не значит, что на С++ нельзя писать качественный код. Это значит, что С++ не способствует написанию хорошего кода.
VD>По мне так если язык уберегает от граблей, то это несомненный плюс. От того на плюсах я вообще перестал писать.

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

ВВ>>Да в общем-то и далеко ходить-то не надо. Что пишут в этой ветке, пытаясь доказать, что inline assignment — это плохо? Пишут "говнокод".
ВВ>>Коллеги, ради бога, я вам и без inline assignment такой говнокод напишу, что заснуть всю ночь не сможете
VD>Это не аргумент. Я тебе отвечу так. Если код можно написать без изменения состояния, то его лучше написать без него. Иннлайн-присвоение способствует изменению состояния внутри выражения, что легко приводит к появлению трудно уловимых ошибок. Ну, а раз известны пути получения более надежного и при этом более короткого когда, так зачем заниматься извращениями и использовать ненадёжные паттерны?
VD>Так что присвоение нужно рассматривать как оптимизацию. А раз это оптимизация, то ее лучше выделить в отдельную строку, а то и функцию. Так оно надежнее будет. И так мест где можно сделать ошибку слишком много.
VD>Мне кажется не надо переводить стрелки. У множественного наследования есть свои плюсы и минусы. У вычислений без изменения состояния есть только один минус — оно может быть менее шустрым нежели антологичное но с присвоениями. Но если мы и так получаем приемлемую производительность, то возиться с изменением состояния глупо. На этом мы только теряем.

Да дело тут не в сравнении MH и инлайн ассайнмента, конечно. Речь об изменении отношения. Вот года три назад ты бы высказал то же самое мнение об inline assignment?

VD>>>Так что я бы лучше обсудил другой вопрос — "Почему современные мэйнстрим-языки навязывают императивный стиль".
ВВ>>Императивный стиль — это мейнстрим.
VD>Это ошибочное заявление которое отлично опровергается хотя бы тем фактом, что в мэйнстриме прекрасно используется SQL (не имеющих к императиву ни малейшего отношения), а теперь еще и Линк.

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

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

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

И потом, неужели тебе лично не доводилось видеть красиво написанных программ в императивном стиле? Я вот не вижу в нем "корень зла", честно.

VD>>>Какого скажем рожна я не могу в C# создать неизменяемую локальную переменную?
ВВ>>Я бы начал даже с неизменяемых in параметров функций.
VD>Это частности. Скажем в Немерле все переменные по умолчанию не изменяемые. В том числе и параметры. Если надо их сделать изменяемыми, то надо использовать ключевое слово mutable перед ним. И никаких проблем. Только изменение подхода. Так просто, а работает на ура.

Кстати, раз уж речь зашла о Немерле. В Немерле действительно есть optional-параметры? И зачем они там?

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

ВВ>И потом, неужели тебе лично не доводилось видеть красиво написанных программ в императивном стиле? Я вот не вижу в нем "корень зла", честно.

Я тебе говорю о том, что если взять к примеру С или Виртовский Паскаль и сравнить их с Обжект Паскалем и С++, то никто не будет спорить, что наличие в арсенале программиста не только структурного программирования, но и объектно-ориентированного является несомненным плюсом. Но почему-то многие начинают спорить с тем, что поддержка языком СП + ООП + ФП + МП лучше нежели поддержка только СП + ООП.

Ну, а про корень зал я уже сказал. Программу не меняющую переменных отлаживать банально проще. Ее состояние лежит в стеки и она похожа на набор преобразований данных. Ты можешь просто подниматься по стеку вверх и видеть что происходило до момента приведшего к проблеме. Но, конечно, жить в императивном мире и при этом не пользоваться императивом в принципе невозможно. Иногда императив нужен чтобы повысить производительность, иногда чтобы упростить (архитекрурно) решение. По сему я сморю на это как на дизайнерский выбор. Там где я не получаю выгоды от императива или, что еще хуже, получаю проблемы, я постараюсь использовать императив. Там где получаю, я выберу его. Это взвешенный выбор.

ВВ>Кстати, раз уж речь зашла о Немерле. В Немерле действительно есть optional-параметры? И зачем они там?

Причем тут это? Ну, да ладно.
Да, и не только optional, но и именованных. Правда optional-параметры поддерживаются несколько более ограничено. Их нельзя инициализировать экземплярами объектов. Но это тоже можно доработать.

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

IT>Да хоть пол процента. Главное, что у оптимизаций приоритет выше, чем у читабельности.

эт смотря в какой угол эта оптимизация ставиться.
мне вот надо, что-б у меня процесс обслуживания клиента в одном куске системы не превышал 400мс (а лучше и близко к этим 400мс не подкрадывался). вот тут я таки воюю за каждые 10мс.
в другом куске той же системы нет таких жестких требований, ну и на кой мне там оптимизация которая даст +10мс но сделает код нечитабельным?

IT>Если он работает и выполняет свои функции, но плохо читаем, то необходимая цель достигнута. Если же он не работает, но хорошо читабелен, то это провал.

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

короче я к тому, что рулит сбалансированность, а крайности никогда до добра не доводят... а если честно то вообще из чистого графоманства ))

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

ili>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>Ну типа:

ВВ>>

ВВ>>int x;

ВВ>>if ((x = MyFunc()) > 4 && x % 2 == 0)
ВВ>>{

ВВ>>}
ВВ>>

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

А главное, не ясно, от чего не написать так:

int x = MyFunc();
if ( x > 4 && x % 2 == 0)
{
}

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

ili>эт смотря в какой угол эта оптимизация ставиться.

Именно. Как правило оптимизация — это результат реализации нефункциональных требований. Если оптимизация никаких проблем не решает, то она не имеет право на жизнь.

IT>>Если он работает и выполняет свои функции, но плохо читаем, то необходимая цель достигнута. Если же он не работает, но хорошо читабелен, то это провал.

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

Это всё понятно и никто с этим не спорит. Вопрос стоит именно как или-или.

ili>Да и как-то не вяжется первое предложение с тем же BLT и его вылезанностью на предмет читаемости

Тем не менее в BLT полно непонятных на первый взгляд мест, тот же emit или mapping. Без оптимизаций алгоритм мапинга занимал бы 20 строк, но работал бы в разы медленнее.

ili>короче я к тому, что рулит сбалансированность, а крайности никогда до добра не доводят... а если честно то вообще из чистого графоманства ))

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