Здравствуйте, VladD2, Вы писали:
VD>Ну, а основные крикуны кричат даже не потому, что им не нравится язык или еще что. Их больше всего раздражает, что об этом говрю я. И у меня не мания величия.
Нет ты совсем ни причем, во всем виновата твоя манера поливать все кроме твоих любимых игрушек грязью. Если бы у тебя не было такой привычки, то у тебя был бы еще один (скорее больше) активный стороник Немерле в моем лице.
Здравствуйте, Mirrorer, Вы писали:
M>Здравствуйте, Mirrorer, Вы писали:
M>>Зы. Директ Х тоже предоставляет небор COM интерфейсов. Без них не было бы так просто подключать различные кодеки к проигрывателю. M>Имелось ввиду без СОМ интерфейсов вообще, а не именно ДиректХ-совых.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Так вот я, что характерно, с этим в корне несогласен. Не в том смысле, что "уж я-то знаю такую технологию", я в принципе. Как и с тезисами вроде "для профессионала все языки программирования одинаковы" и т.п.
ЗХ>Я убежден, что легкий, мощный, "хорошо ложащийся в руку" инструмент (в совмещении, вестимо, со светлой головой) способен давать разницы в основных параметрах разработки (продуктивность, надежность, минималистичность, и т.п.) именно что на порядки.
Кстати, свежая новость из RSS в тему: некая компания Berkeley Data Systems решила провести что-то вроде олимпиады по программированию для того, чтобы нанять затем наиболее удачливых участников. И провела мероприятие "Programmer Deathmatch" с призом в $10000.
Соревнования проходили в три этапа: в первом участвовало 120 человек, во втором 30. Первые два этапа проводились через Internet. Последний этап, в котором приняло участие 8 финалистов, прошел в штаб-квартире Berkeley Data System.
Примечательно, что восемь финалистов (в возрасте от 24-х до 38-ми лет) использовали восемь(!) разных языков: C, C++, C#, Java, Perl, PHP, Python, and Ruby. И в итоге соревнования завершились в ничью.
Если оттакиваться от пропагандируемого здесь мнения, что C++ отстой и глюкодром, то уже удивительно, что кто-то на C++ смог составить конкуренцию C# и Java. А уж результат на C вообще выглядит выдающимся.
Однако для тех, кто поверил ДеМарко и Листеру, проводивших подобные соревнования в далеких 80-х, сюрпризов здесь нет
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, PhantomIvan, Вы писали:
PI> ...но вместе с тем, я весьма удивлён вместе с VladD2 (и думаю, с этим связана эмоциональность его прошлых постов) тем фактом, что лишь немногие увидели в немерле реальную, "на сегодня" замену промышленно используемых языков, сей факт не может не огорчать.
PI>если бы не это неприятие в сущности хай-ендового языка...
Щаз, все бросим, и будем свои сотни тысяч, а кто и миллионы строк кода на ваш Немерле переписывать. А также десятки программеров срочно на Немерле переучивать.
На немерле еще ни одного серьезного проекта не сделано пока. А использовать сырой язык — студенческую поделку, на который даже неформального стандарта нет, как реальную замену промышленным языкам (lol — это ж долно ж было такое в голову прийти) никто, естественно, не хочет. Дураков нет.
VD>4. Функции как первоклассные значения. (ФВП — это просто не верный термин, так как почти во всех современных ЯП есть ФВП). Тут конкурентами Немерле являются: C#, Руби, Питон, Смолток, O'Caml, Хаскель, Скала, Эрэнг. Причем только O'Caml и Хаскель столь же мощьны как Немерле. Отсальные языки как имеют те или иные проблемы в этом вопросе. Ну, да не странно, ведь кроме Эрлэнга остальные языки не принято называть ФЯ.
Объясни пожалуйста, чем более мощны функции в это тройке (Окамл Хаскель и Немерле) чем например в питоне (или руби). Мне кажется что наоборот Окамл и Немерле немного уступают тут динамике (за счет того что в динамике функции более обобщенные).
VD>5. Сопоставление с образцом (pattrn matching) и алгеброические типы. Тут конкуренты: O'Caml, Хаскель, Скала и Эрэнг. Причем сопоставление с образцом это настолько мощьная вещь в плане повышения мощьности языка, что уже одного его отсуствия достаточно, чтобы назвать язык устаревшим. Конечно все тоже самое можно делат на if-ах, но паттерн-матчинг позволяет решать многие задачи куда проще. Он реально повышает уровень программ.
Да на самом деле очень мощная возможность. Но во первых есть вещи частично перекрывающие эти возможности (мультиметоды) и во вторых на очень большем классе задач пользы от паттерн матчинга нет (зато есть класс задач где он на порядок увеличивает мощность языка). По моему ПМ очень мощное, но достаточно узко заточенное оружие.
VD>6. Вывод типов. Спорный вопрос, но все же я считаю, что опускание лишних деталей позволяет делать код несколько более высокоуровневым. К тому же код реально становится более кратким. Это само по себе не приемущество, но без этого просто не мыслемо применение функционального стиля. Современный C# (2.0) отлично демонстрирует, что без вывода типов использование функционального стиля становится не эффективным. Здесь у нас конкуренты: Скала, Хаскель, ОКамл и все скрипты. VD>7. ООП. Тут с одной стороны конкурентов много, но с другой качественная реализация ООП есть далеко не везде. Например, Питон я точно не могу назвать качествнной реалзацией. Руби чуть лушче, но все же тоже не дотягивет. Но в любом случае из этого списка резко исчизают Хаскель и Эрлэнг.
В питоне да есть свои заморочки, (но с другой стороны его ООП мощнее за счет метаклассов чем), но в чем Руби-то слабее?, по моему там ООП мощнее Скалы и Немерле (тоже за счет метаклассов).
VD>8. Автоматическое управление памятью. Тут опять проще говорить о том, кто выбывает. Это конечно же С++. VD>9. Умная IDE, отладка и другие прелести автоматизации программирования и проектирования. Тут пожалуй единственный пункт где пока что в аутсайдерах сам Немерле, а лидерами являются C# и Java (возможно в скором времени дела будут неплзхо обстаять и у Скалы). Однако мы лично работаем над устранением этого недостатка и в ближайшем будущем у Немерла появится IDE не хуже чем у лидеров. Причем я отвественно заявляю, что Риби и Питон вообще никогда не получат IDE такого качества, потому что эти языки не предоставляют нужной метаинформации во время разработки. Ну, разве что для них напишут подсистему вывода типов, но тогда эти языки перейдут в другой класс и сделают нехилый шаг по направлению Немерлетизации .
Выделенное интенсивно делают, в рамках PyPy.
VD>10. Возможности расширения. Тут конкуренты только O'Caml и Lisp. Причем оба языка резко проигрывают Немерле так как не позволяют получать метаинформацию о типах. Это делает их значительно менее мощьными. С другой стороны нельзя не отметить, что возможности по модификации АСТ у Лиспа и даже у O'Caml-а несколько выше. Хотя реально это мало что дает, так как возможности по модификации АСТ у Немерле тоже нехилые. Кстати, это пожалуй единственный пункт где из списка на прочь выбывает скала. По поводу скриптов можно сказать, что с одной стороны те их них что поддерживают метапрограммирование тоже вохоят в эту категорию, но с другой их метапрограммирование не позволяет серьезно менять синтаксис. Хотя тут я могу ошибаться. Так что можно оставить их вписывание сюда на усмотрение читателя.
Ну руби позволяет и частично синтаксис "менять", питон нет, но метапрограммирование у обоих вполне на уровне. К тому же питон предоставляет библиотеки для полного доступа к AST и комиляции, и при желании там очень много можно наворотить.
VD>11. Встроенная поддержка параллелизма. Тут в списке остается только Эрлэнг. Но Немерле, ОКамл и Лисп позволяют добавить подобнрые фрэймворки в виде библиотеки. Так что пункт не столь очевиден.
Питон тоже позволяет в виде библиотеки, есть даже несколько в стиле эрланга.
VD>12. Производительность получаемого кода. Тут у нас резко пролетают все скрипты. Причины даже не хочется обсуждать. Разговоры о компиляции мне тоже тут не интересны. Чудес не бывает. Или это уже будет не скрпт, или он будет фигово компилироваться.
Пока да, посмотрим что из PyPy получится.
VD>Теперь остается пробежать список и понять, что в итоге Немерле остался в одиночистве. Все конкуренты отсеялись на тех или иных этапах.
Легко добавить пару пунктов и он точно также отсеется.
(например компиляция в нативный код)
VD>Конечно можно сказать, что кому-то некоторые пункты могут оказаться не важными, но факт отсается фактом.
Здравствуйте, Programmierer AG, Вы писали:
PA>AndreiF wrote:
>> >> Немерле включает в себя практически все полезные идеи языков, который были до него.
PA>Еще одна поправочка. Ни разу не все.
Ты не понимаешь, все что немерле не включает, автоматически считается абсолютно бесполезной идеей.
Здравствуйте, eao197, Вы писали:
E>Очень похоже, что есть четыре градации лжи: просто ложь, наглая ложь, статистика и сравнение языков программирования от VladD2.
Лучше предметно ответь с чем не согласен, в противном случае лучше промолчать (достаточно -1 поставить).
Здравствуйте, Андрей Хропов, Вы писали:
E>>Очень похоже, что есть четыре градации лжи: просто ложь, наглая ложь, статистика и сравнение языков программирования от VladD2.
АХ>Лучше предметно ответь с чем не согласен, в противном случае лучше промолчать (достаточно -1 поставить).
-1 не достаточно. А оценки "Афигеть", как крайней формы офигевания от прочитанного, здесь нет.
Не знаю, с чем здесь спорить, тем более, что VladD2 сказал, что это его личное мнение, а не повод для спора. Но по некоторым бы пунктам хотелось получить разъяснения:
a) почему в отношении ФВП Scala уступает Nemerle?
b) до чего именно ООП в Ruby не дотягивает?
c) почему в плане встроенной поддержки параллелизма не рассматриваются Actor-ы в Scala?
d) почему расширяемость языка считается неоспоримым достоинством?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Не знаю, с чем здесь спорить, тем более, что VladD2 сказал, что это его личное мнение, а не повод для спора. Но по некоторым бы пунктам хотелось получить разъяснения: E>a) почему в отношении ФВП Scala уступает Nemerle? E>b) до чего именно ООП в Ruby не дотягивает? E>c) почему в плане встроенной поддержки параллелизма не рассматриваются Actor-ы в Scala?
+1 +1 +1 E>d) почему расширяемость языка считается неоспоримым достоинством?
Ну, во всяком случае, отсутствие расширяемости неоспоримым достоинством точно не назовешь
PI>>вот мы плавно подошли к противоречию: PI>>предположим, все 4 у тебя — "светлые головы" PI>>одно из двух: либо задача делится на 4 равные части, либо к примеру, это одна функционально односвязная часть. PI>>если первое, то каждый из твоих программеров — как бы хирург, лишенный помощи своей "операционной бригады" (тестирует сам, документирует сам, утилиты пишет сам) M>Тестеры отдельно, программисты отдельно. M>Юнит тесты пишутся программистами. M>Документация пишется во время разработки благо набрать три слеша и получить заглушку для описания метода не сложно. И кому лучше знать, как описать функцию, если не программисту, который ее реализовывал. + Практика Review, которая проверяет не только код, но и комментарии\документацию к нему. Что мы делаем не так ?
всё так, я только акцентировал внимание, что это не "операционная бригада" по Бруксу, там другой подход
PI>> смещаются на менее "умные" задачи — типа написания юнит-тестов. M>Написать хороший юнит тест сможет только программист, который отвечает за реализацию. А полноценные тесты на развернутой системе, это уже тестер естественно. PI>>(для юнит-тестов нужен менее опытный в программировании тестер). M>-1
я не знаю что такое "хороший" юнит-тест; я читал в от эту книгу:
и не видел там ни одного "хорошего" (в смысле "умного") юнит теста
не писать лишнего кода — да, не тестировать совсем низкий уровень — да, ускорить тесты — да,
разбираться в коде — да, но разобрать код, и написать его — не то же самое,
и чтобы для тестов нужен был тот же программер, который может "поднять" нетривиальную функциональность сверху-донизу (или снизу наверх)... гм...
ну да неважно, возможно я порю чушь, раз Курилка старательно расставляет мне минусы, а тебе плюсы
так шо пака, лучше поработаю чем спорить ради спора
Здравствуйте, PhantomIvan, Вы писали:
PI>это не "операционная бригада" по Бруксу
по этому вопросу консенсус.
Просто у меня сложилось другое представление об операционных бригадах, когда читал Брукса, но это было давно, да и сейчас его под рукой нету, так что в дальнейший спор по этому поводу не будет иметь смысла.
PI>>> смещаются на менее "умные" задачи — типа написания юнит-тестов. M>>Написать хороший юнит тест сможет только программист, который отвечает за реализацию. А полноценные тесты на развернутой системе, это уже тестер естественно. PI>>>(для юнит-тестов нужен менее опытный в программировании тестер). M>>-1
PI>не писать лишнего кода — да, не тестировать совсем низкий уровень — да, ускорить тесты — да,
+1 +1 +1
Имеется ввиду что юнит тесты должны быть осмысленными. Если программист считает, что какой-то вариант развития событий должен быть проверен юнит тестом, он его пишет.
Можно написать 1000 юнит тестов, но они не будут проверять допустим возникающие исключитальные ситуации. А какие исключитлеьные ситуации могут возникать — об этом лучше знать программисту, а не тестеру.
Когда же при тестировании выяснится, что программа вылетает еще в каком-то месте, то это записывается как бага на программиста, а программист пишет юнит тест для этого исключительного случая. При таком раскладе исключительный случай больше не произойдет. Это будет проверяться все время юнит тестом. Такой ЮТ тестер написать не сможет, поскольку он подразумевает понимание внутренней логики работы приложения.
PI>и чтобы для тестов нужен был тот же программер, который может "поднять" нетривиальную функциональность сверху-донизу (или снизу наверх)... гм...
Не для тестов, а для юнит-тестов. Юнит тесты должны писаться программистам. И если там нетривиальная функциональность, то только программист который ее реализовывал, должен писать ЮТ на нее. Потому что может быть много неочевидных моментов, о которых при "чтении кода" можно и не догадаться. Для того, чтобы с первого прочтения понять все неочевидные моменты, необходим программист с опытом не менее, а то и более того, который реализовывает "нетривиальную функциональность".
Собственно вот. Немного сумбурно получилось, но надеюсь понятно.
MS>А ты как раз и строишь свою аргументацию на полной отстойности всего что было. А не на преимуществах нового. Понимаешь в чем
Хэй! развитие средств программирования — постепенное улучшение и переход от менее удобного к более удобному, производительному, эффективному, надежному. и не использование более прогрессивного подхода — всего лишь консерватизм. (который подобен политике Реакции на данном форуме)
VD>>Ну, а основные крикуны кричат даже не потому, что им не нравится язык или еще что. Их больше всего раздражает, что об этом говрю я. И у меня не мания величия.
FR>Нет ты совсем ни причем, во всем виновата твоя манера поливать все кроме твоих любимых игрушек грязью. Если бы у тебя не было такой привычки, то у тебя был бы еще один (скорее больше) активный стороник Немерле в моем лице.
то есть ты не используешь немерле, только из-за того, что тебе не нравится Влад?
PI>> ...но вместе с тем, я весьма удивлён вместе с VladD2 (и думаю, с этим связана эмоциональность его прошлых постов) тем фактом, что лишь немногие увидели в немерле реальную, "на сегодня" замену промышленно используемых языков, сей факт не может не огорчать.
PI>>если бы не это неприятие в сущности хай-ендового языка...
G>Щаз, все бросим, и будем свои сотни тысяч, а кто и миллионы строк кода на ваш Немерле переписывать. А также десятки программеров срочно на Немерле переучивать.
а CLR и интероп никто не отменял (вот уж действительно лол, что такую банальность приходится писать)
если кто-то завяз в каком-то болоте вроде десятилетних проектов, то могу лишь посочуствовать, речь не о них (еще одна банальность )
PI>>и чтобы для тестов нужен был тот же программер, который может "поднять" нетривиальную функциональность сверху-донизу (или снизу наверх)... гм... M>Не для тестов, а для юнит-тестов. Юнит тесты должны писаться программистам. И если там нетривиальная функциональность, то только программист который ее реализовывал, должен писать ЮТ на нее. Потому что может быть много неочевидных моментов, о которых при "чтении кода" можно и не догадаться. Для того, чтобы с первого прочтения понять все неочевидные моменты, необходим программист с опытом не менее, а то и более того, который реализовывает "нетривиальную функциональность".
M>Собственно вот. Немного сумбурно получилось, но надеюсь понятно.
да, понятно
лишь добавлю, что под "тестерами" я имею в виду кодеров, которые пишут 1) юнит-тесты 2) автоматизированные функциональные тесты 3) другие виды нетривиального (стресс- и пр.) тестирования
а бета-тестеры — это обезьяны (извините, девочки из отдела тестинга ), о которых я не говорю т.к. это не интересно (тока разве что, о том насколько эти девочки милы)
плюс я считаю что тест — это нечто, что подходит к некоему блоку, как к блэкбоксу, с этой позиции нужно иметь спеку, а не знать потроха
опять же, Брукс — родом из промышленного программирования, где строятся bullet-proof приложения
исходя из современных реалий, это значит полное покрытие тестами вширь и вглубь
то есть "гибкие" технологии могут вполне работать для небольших мобильных команд, и работают таки, но фактически они плюют на разделение труда...
Здравствуйте, PhantomIvan, Вы писали:
E>>c) почему в плане встроенной поддержки параллелизма не рассматриваются Actor-ы в Scala?
PI> это кто такие?
либа scala.actors — это реализация Erlang-модели паралелизма.. Т.е. на пальцах акторы — это механизм, который позволяет обмениваться сообщениями между потоками. Посмотри здесь и здесь
И у меня не мания величия. 
это кто такие?