Здравствуйте, AndrewVK, Вы писали:
AVK>Без всяких граничных случаев. Вот буквально вчера переписал старый кусок с использованием фич 3 шарпа — вместо нескольких экранов кода получилось 25 строк большей частью декларативного кода. Думаю, не стоит объяснять, что в плане поддержки новый вариант на голову круче, хотя время начальой разработки на общем фоне некритично.
Количество строк кода не является критерием поддерживаемости. Вообще, поддерживаемость — это сложное понятие, которое включает в себя противоречивые критерии. С одной стороны "лаконичность", а с другой "очевидность". Лаконичность часто противоречит "очевидности". В общем, это созвучно древним флеймам из С++, что лучше: написать простенький цикл руками, или использовать алгоритмы из STL. Первый вариант "очевидный", а второй "лаконичный". Какой из них "правильный" — сказать сложно. Короче, это я к тому, что уменьшение количества строк кода еще не означает однозначное улучшение поддерживаемости. Соответствующий пример привести не сложно. Думаю, ты и сам можешь
лэт ми спик фром май харт
Re[6]: Судьба новых идей, или почему прогресс идет так медле
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, prVovik, Вы писали:
V>>Количество строк кода не является критерием поддерживаемости.
AVK>Является. Хотя, конечно, критерий этот далеко не единственный и даже не самый важный.
Ой, я это и имел ввиду, просто некорректно выразился. Там дальше мысль развивается.
лэт ми спик фром май харт
Re[2]: Судьба новых идей, или почему прогресс идет так медле
Здравствуйте, prVovik, Вы писали:
V>я тоже много сокрушался по поводу отсутствия того или иного вида синтаксического сахара. Юзинга нет или еще чего — как люди вообще могут писать программы на яве, я понять не мог. Но вот когда дело дошло до решения конкретных проблем предметной области, проблемы языка сразу стали несущественными. 95% mainstream-программистов сильно начхать на эти "приятные мелочи", ибо они "живут" в своей предметной области и почти все проблемы, с которыми им приходится сталкиваться — это проблемы предметной области для которых возможный выигрыш от "приятные мелочей" ничтожен. Прикладной программист не бьется над проблемой, как вызвать метод: через рефлексию, или динамический сахар? Он бьется скорее над поиском: какой метод вызвать, когда вызвать, с какими параметрами вызвать и что делать с результатом. Как видишь, в решении реальных проблем, с которыми сталкиваются прикладные программисты, синтаксический сахар помогает слабо, ибо он лишь помогает ответить на вопрос "Как сделать?", но он ни на сантиметр не приближает к ответу на "Что делать?". А основополагающий вопрос — это именно второй. Вот лично мне почти плевать на эти новые языковые фичи, так как они помогают лишь в решении мелких тактических задачек, которые и раньше решались совершенно без сколько-нибудь существенных трудозатрат.
Отрадно осознавать, что не перевелись еще на Руси разумные люди!
Надобно твердо осознавать, что к прогрессу и всяким финтифлюшкам новамодным с осторожностью великой относиться положено.
Ибо кто может разуметь разницу между путешествием с помощью самолета реактивнаго и лошади ломовой, когда впереди всего — принять решение, куда двигаться надлежит? Ибо путь в тьму шагов зачинается с однаго шага.
Вдругорядь, кака разница между емелием новамодным и проверенным годами почтовым голубем? Поелику мудрый человек разумеет: главное то, чего в грамоте написано.
Вместо того, чтобы невозбранно напедалить осемь экранов на басике православном, как у нас, программистов индустриальнаго типа междусобойно положено, несерьезные программисты используют бесовские фичи сишарпов третьих, из сотонинского хаскеля (Господи прости) понатянутых. Небывать тому! Ясно же, что инфернальныя функциональныя языки одному только врагу рода человеческого и понятны!
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[3]: Судьба новых идей, или почему прогресс идет так медле
Но только ты не понял, о чем я писал. Наверное, я недостаточно точно сформулировал мысль. Прогресс должен облегчать жизнь людей. Если человек вынужден использовать голубиную почту, а прогресс ему предлагает использовать электронные часы с хайтек кукушкой, чтобы отправлять голубей точно по расписанию, то это не очень хороший прогресс. Потому что проблема не в том, чтобы отправлять голубей точно по расписанию (можно и механическими часами обойтись), проблема в том, что голуби плохо письма доставляют. Nuzhny приводил очень хороший пример с математиком, который использует древний фортран. Очевидно, многие считают, что математик станет много счастливее, если пересядет на Nemerle. Но вот только математику не составляет труда реализовать алгоритм даже на убогом фортране, у него другая трудность: придумать алгоритм.
Тут Майкросовту предъявляют претензии, что он медленно реализует языковые фичи в шарпе. Но зато они сделали WF, WCF, которые решают реальные проблемы прикладных программистов, которые намного важнее, чем отсутствие какого-нибудь паттерн-матчинга.
Языковые фичи, конечно, тоже важны, но по приоритету они находятся далеко за фреймворком. Судя по всему, МС пользуется этим принципом для развития языка, учитывая, что она подтягивает язык именно под потребности фреймворка, а не под потребности программистов-философов.
лэт ми спик фром май харт
Re[6]: Судьба новых идей, или почему прогресс идет так медле
Здравствуйте, prVovik, Вы писали:
V>Количество строк кода не является критерием поддерживаемости. Вообще, поддерживаемость — это сложное понятие, которое включает в себя противоречивые критерии. С одной стороны "лаконичность", а с другой "очевидность". Лаконичность часто противоречит "очевидности". В общем, это созвучно древним флеймам из С++, что лучше: написать простенький цикл руками, или использовать алгоритмы из STL. Первый вариант "очевидный", а второй "лаконичный". Какой из них "правильный" — сказать сложно. Короче, это я к тому, что уменьшение количества строк кода еще не означает однозначное улучшение поддерживаемости. Соответствующий пример привести не сложно. Думаю, ты и сам можешь
Это очень левый пример.
В С++ использование STL ужасно и связано с появлением кучи мусора.
В более правильных языках мусора нет.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Судьба новых идей, или почему прогресс идет так медле
Здравствуйте, prVovik, Вы писали:
V>Количество строк кода не является критерием поддерживаемости. Вообще, поддерживаемость — это сложное понятие, которое включает в себя противоречивые критерии. С одной стороны "лаконичность", а с другой "очевидность". Лаконичность часто противоречит "очевидности". В общем, это созвучно древним флеймам из С++, что лучше: написать простенький цикл руками, или использовать алгоритмы из STL. Первый вариант "очевидный", а второй "лаконичный". Какой из них "правильный" — сказать сложно.
И как решает этот случай наша некая прогрессивная технология? (которую, к примеру, MS обзывает неинтересной).
Здравствуйте, prVovik, Вы писали:
V>Тут Майкросовту предъявляют претензии, что он медленно реализует языковые фичи в шарпе. Но зато они сделали WF, WCF, которые решают реальные проблемы прикладных программистов, которые намного важнее, чем отсутствие какого-нибудь паттерн-матчинга.
V>Языковые фичи, конечно, тоже важны, но по приоритету они находятся далеко за фреймворком. Судя по всему, МС пользуется этим принципом для развития языка, учитывая, что она подтягивает язык именно под потребности фреймворка, а не под потребности программистов-философов.
Фреймворк сам по себе — зависит от языка, от платформы.
Именно платформа определяет — как будет реализован фреймворк/api.
Будет в платформе паттерн-мэтчинг, будут замыкания — и фреймворк будет реализован совершенно иначе.
И эта иная реализация может кардинально улучшить использование фреймворка.
И пока ты будешь учиться решать задачи мышекликанием как в дельфях, или подобным "высокоинтеллектуальным" методом —
тебе будет хватать имеющихся фрейворков. А когда тебе надо будет написать действительно сложный алгоритм,
вот тут тебе и захочется "новомодных" фич.
Здравствуйте, mkizub, Вы писали:
M>А когда тебе надо будет написать действительно сложный алгоритм, вот тут тебе и захочется "новомодных" фич.
А до тех пор, пока большинству программистов не приходится иметь дело с действительно сложными алгоритмами, MS может рубить бабло на инструментах "попроще", увеличивая их мощность по мере готовности "масс" к принятию и использованию этих "новомодных" фич.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: Судьба новых идей, или почему прогресс идет так медле
Здравствуйте, WolfHound, Вы писали:
WH>Это очень левый пример. WH>В С++ использование STL ужасно и связано с появлением кучи мусора. WH>В более правильных языках мусора нет.
Дело не в мусоре. К мусору привыкаешь и перестаешь замечать, как не замечаешь баннеры с рекламой на веб-страницах.
лэт ми спик фром май харт
Re[7]: Судьба новых идей, или почему прогресс идет так медле
Здравствуйте, mkizub, Вы писали:
V>>Количество строк кода не является критерием поддерживаемости. Вообще, поддерживаемость — это сложное понятие, которое включает в себя противоречивые критерии. С одной стороны "лаконичность", а с другой "очевидность". Лаконичность часто противоречит "очевидности". В общем, это созвучно древним флеймам из С++, что лучше: написать простенький цикл руками, или использовать алгоритмы из STL. Первый вариант "очевидный", а второй "лаконичный". Какой из них "правильный" — сказать сложно.
M>И как решает этот случай наша некая прогрессивная технология? (которую, к примеру, MS обзывает неинтересной).
Не понял, какой случай?
лэт ми спик фром май харт
Re[5]: Судьба новых идей, или почему прогресс идет так медле
Здравствуйте, mkizub, Вы писали:
M>И пока ты будешь учиться решать задачи мышекликанием как в дельфях, или подобным "высокоинтеллектуальным" методом - M>тебе будет хватать имеющихся фрейворков. M>А когда тебе надо будет написать действительно сложный алгоритм, M>вот тут тебе и захочется "новомодных" фич.
Гамотное сравнение.
Создания стены и кирпича в этой стене.
СУВ, Aikin
Re[5]: Судьба новых идей, или почему прогресс идет так медле
Здравствуйте, mkizub, Вы писали:
M>Фреймворк сам по себе — зависит от языка, от платформы.
От платформы. Язык не причем. Языков может быть много, а платформа с фреймворком одни.
M>Именно платформа определяет — как будет реализован фреймворк/api. M>Будет в платформе паттерн-мэтчинг, будут замыкания — и фреймворк будет реализован совершенно иначе.
Не важно, как он реализован, важно, что торчит наружу.
M>И эта иная реализация может кардинально улучшить использование фреймворка.
Приведи пример кардинального улучшения. Я вот кроме как стандартных дженерик-коллекций ничего не могу вспомнить. Зато я могу вспомнить, как язык неоднократно подгоняли в угоду фреймворку и средствам разработки.
M>И пока ты будешь учиться решать задачи мышекликанием как в дельфях, или подобным "высокоинтеллектуальным" методом - M>тебе будет хватать имеющихся фрейворков.
А плевать на интеллектуальность метода решения, меня интересует результат.
M>А когда тебе надо будет написать действительно сложный алгоритм, вот тут тебе и захочется "новомодных" фич.
Возможно, только боюсь, что время реализации "высокоинтелектуального" алгоритма будет несопоставимо мало в сравнении с временем реализации остальной системы (если, конечно, мы говорим о серьезных программах). Соответственно, выигрыш в конечном счете будет небольшой.
лэт ми спик фром май харт
Re[8]: Судьба новых идей, или почему прогресс идет так медле
Здравствуйте, prVovik, Вы писали:
V>Дело не в мусоре. К мусору привыкаешь и перестаешь замечать,
Именно в мусоре.
Ибо из тонны мусора приходится выкапывать полезные данные.
V>как не замечаешь баннеры с рекламой на веб-страницах.
Это другое.
Банеры всегда весят в одном месте.
А в данном случае банеры висят черед каждое слово.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Судьба новых идей, или почему прогресс идет так медле
Здравствуйте, prVovik, Вы писали:
M>>И как решает этот случай наша некая прогрессивная технология? (которую, к примеру, MS обзывает неинтересной).
V>Не понял, какой случай?
Какая новая технология позволит решить проблему противоречия между краткостью и понятностью кода?
Скажем, мета-программирование, и Nemerle в частности — решают эту проблему?
А другие средства для решения этой проблемы есть?
Если есть — то какие? Если нет — то какие надо создать? Если мы их создадим — будет ли нам счастье,
в том числе и реализует ли её MS или нет?
Здравствуйте, prVovik, Вы писали:
M>>И эта иная реализация может кардинально улучшить использование фреймворка.
V>Приведи пример кардинального улучшения. Я вот кроме как стандартных дженерик-коллекций ничего не могу вспомнить. Зато я могу вспомнить, как язык неоднократно подгоняли в угоду фреймворку и средствам разработки.
Возможность передать замыкание (closure) в контейнер.
Возможность повесить код (обработчик) на событие в GUI (скажем, на нажатие кнопки).
Возможность определить тип данных в runtime (instanceof и т.п.).
Возможность инкапсуляции, наследования, полиморфизма (ООП).
И многое многое другое.
Скажешь, фреймворк не будет зависить от наличия этих возможностей в языке/платформе?
Здравствуйте, prVovik, Вы писали:
V>В общем, это созвучно древним флеймам из С++, что лучше: написать простенький цикл руками, или использовать алгоритмы из STL. Первый вариант "очевидный", а второй "лаконичный". Какой из них "правильный" — сказать сложно. Короче, это я к тому, что уменьшение количества строк кода еще не означает однозначное улучшение поддерживаемости. Соответствующий пример привести не сложно. Думаю, ты и сам можешь
Чушь это. Это спор с блабами. Код использующий СТЛ не очевиден только тем кто не удостужился изучить СТЛ или даже лежащие в его основах принципы. Конечно сам СТЛ довольно кривое порождение, так как делался в рамках С++ и человеком сознание которого было под большим влиянием С++, но тем неменее базис у него очень даже логичный и стройный — лямбда-исчисления (т.е. математика и ФП).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Судьба новых идей, или почему прогресс идет так медле
