Здравствуйте, Quintanar, Вы писали:
Q>Здравствуйте, GlebZ, Вы писали:
GZ>>автоматическое выведение типов — поясните, что вы имеете ввиду.
Q>Что-что. Это и имею ввиду. Не нужно указывать типы явно, компилятор сам их способен вывести из контекста, экономит кучу времени на написание всех этих объявлений да еще нередко в нескольких местах.
Это в другой флейм. Что лучше статические или динамические типы. Я сторонник проверки типов на этапе компиляции.
GZ>>удобная декомпозиция сложных структур - имеет недостаток. Редко используется, и решается еще на этапе дизайна. Q>То, что вы ее не используете, не означает, что она редко используется.
Да используются они не редко, я тут несколько лажанулся. Но вот эти проблемы решаются еще на этапе дизайна. Ну напишешь ты побольше кода. Ну и что. От этого он станет только более понятным.
Q>По правде сказать, в С-подобных языках ее особо и не поиспользуешь ибо встроеные типы данных примитивны, а для пользовательских язык расширить невозможно.
Ну-ну. В С++ и C# вполне достаточно средств конструирования новых типов. Только я ими не пользуюсь. Вопреки многим мнениям, усложняет программу.
GZ>>замыкания — наплевать насколько они классически реализованы в C#. Меня текущая реализация удовлетворяет. Мало того, текущая реализация указателей на функции в C++, для меня достаточна.
Q>Ну да, зачем нужны циклы, когда есть goto, говорили программисты на Фортране.
Тогда расскажите в чем плюсы классического замыкания по сравнению с делегатами.
GZ>>макросы — проясните что вы имели ввиду.
Q>Способ изменить часть программы на этапе компиляции. Позволяют ввести в язык естественным образом операторы и концепции, отсутствующие в языке изначально.
У, дядька. Тебе расказать, что первая версия С++ была просто описана макросами. Темплайты и макросы в С++ мало?
GZ>>continuations — проясните, что вы имели ввиду.
Q>Continuations слишком сложный вопрос, чтобы осветить его в двух словах. Коротко — это обобщение исключений, longjmp и т.п.
Q>>>Как сказал один любитель Лиспа, пока другие ждут добавления новых конструкций в свои любимые языки, мы добавляем их сами. И реализация тех же продолжений средствами самого же Лиспа яркий тому пример. GZ>>И каким образом это будет влиять на качество конечного продукта?
Q>Это будет влиять на скорость разработки продукта. Для крупных фирм это может быть и неинтересно, но для маленьких колективов весьма критично.
Очень критично когда приходит новый человек. На С++ и С# проблемы начинаются когда его начинают знакомить с механизмами дизайна приложений. Вы еще хотите на него навалить синтаксис.
Q>По твоему отношению к моим словам заметно, что ты не знаешь, что дают эти фичи в языках, где они действительно полностью реализованы, так чего тогда спорить?
Уважаемый, не обижайтесь. Но если из этих фич меня бы спросили, что мне не хватает в работе, я бы выбрал другой список.
Метапрограммирование — решает также вопрос декомпозиции сложных структур. И вообще приятная штука.
АОП — только главное чтобы он был более управляемый и не ограничевал меня — что плохо в текущих реализациях АОП языков. Возможно решить с помощью метапрограммирования.
Динамическое изменение инстансов или множественная диспачеризация. В некоторых случаях — может сильно сократить код, хотя и сейчас проблема решаемая с помощью интерфейсов, множественного наследования.
С уважаением, Gleb.
PS: Можно спросить ваш коммерческий опыт, в каких по численности командах вы работали, какие по объему программы, и на каких языках?
Здравствуйте, Dog, Вы писали:
Q>>Это будет влиять на скорость разработки продукта. Для крупных фирм это может быть и неинтересно, Dog>Там что деньги по другому считают ?
Да. Боссу легче набрать N програмистов на Java и с ними долбать пару лет программу. К тому же, у больших фирм другие возможности в плане продвижения своих продуктов. Глючную посредственность им впарить гораздо проще.
Q>> но для маленьких колективов весьма критично. Dog>Время покажет. Dog>Кстати, вы не подскажите сколько таких крутых языков осталось на свалке истории ?
Здравствуйте, GlebZ, Вы писали:
Q>>Что-что. Это и имею ввиду. Не нужно указывать типы явно, компилятор сам их способен вывести из контекста, экономит кучу времени на написание всех этих объявлений да еще нередко в нескольких местах. GZ>Это в другой флейм. Что лучше статические или динамические типы. Я сторонник проверки типов на этапе компиляции.
А причем тут динамические типы? Я же говорю — компилятор сам выводит типы на этапе компиляции.
GZ>Да используются они не редко, я тут несколько лажанулся. Но вот эти проблемы решаются еще на этапе дизайна. Ну напишешь ты побольше кода. Ну и что. От этого он станет только более понятным.
Ха. Что может быть более понятным, чем
(Left Leaf header, Right body) = function_definition;
GZ>У, дядька. Тебе расказать, что первая версия С++ была просто описана макросами. Темплайты и макросы в С++ мало?
Темплейты слишком маломощны. Сойдет для сельской местности (С++), но нормально преобразовывать код они не могут.
>> GZ>>И каким образом это будет влиять на качество конечного продукта? >> Q>Это будет влиять на скорость разработки продукта. Для крупных фирм это >> может быть и неинтересно, >> Там что деньги по другому считают ? ANS>Имхо там больше доля маркетинга, меньше программирования.
Или я чего-то не понял или критерий скорости разработки не важен для крупных фирм
Dog пишет:
>> > GZ>>И каким образом это будет влиять на качество конечного продукта? >> > Q>Это будет влиять на скорость разработки продукта. Для крупных фирм это >> > может быть и неинтересно, >> > Там что деньги по другому считают ? > ANS>Имхо там больше доля маркетинга, меньше программирования. > Или я чего-то не понял или критерий скорости разработки не важен для > крупных фирм
Имхо, скорость разработки и её стоимость играют меньшую роль в крупных
фирмах, так как там большую роль играют процессы планирования, контроля,
маркетинговые.
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Здравствуйте, Quintanar, Вы писали:
Q>Здравствуйте, GlebZ, Вы писали:
GZ>>У, дядька. Тебе расказать, что первая версия С++ была просто описана макросами. Темплайты и макросы в С++ мало?
Q>Темплейты слишком маломощны. Сойдет для сельской местности (С++), но нормально преобразовывать код они не могут.
ИМХО GlebZ путает в очередной раз уродские сишные макросы с лисповскими, что в корне не правильно.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Dog пишет:
>>> > GZ>>И каким образом это будет влиять на качество конечного продукта? >>> > Q>Это будет влиять на скорость разработки продукта. Для крупных фирм это >>> > может быть и неинтересно, >>> > Там что деньги по другому считают ? >> ANS>Имхо там больше доля маркетинга, меньше программирования. >> Или я чего-то не понял или критерий скорости разработки не важен для >> крупных фирм
ANS>Имхо, скорость разработки и её стоимость играют меньшую роль в крупных ANS>фирмах, так как там большую роль играют процессы планирования, контроля, ANS>маркетинговые.
Неверное предположение. Скорость разработки и стоимость важны.
GZ>>>удобная декомпозиция сложных структур - имеет недостаток. Редко используется, и решается еще на этапе дизайна. Q>>То, что вы ее не используете, не означает, что она редко используется. GZ>Да используются они не редко, я тут несколько лажанулся. Но вот эти проблемы решаются еще на этапе дизайна. Ну напишешь ты побольше кода. Ну и что. От этого он станет только более понятным.
Правда? А теперь давай мешки поворочаем, ты не против? Напиши пожалуйста на С++ или С# более понятный код, чем этот. Покажи, как ты решишь проблему "на этапе дизайна".
Ничего сложного — разбор заголовка IP-датаграммы. Dgram — это массив байт. << ... >> — это его разбор на составные части посредством pattern matching. После имени переменной идет ее размер в битах через двоеточее, а тип указан после "/" (по умолчанию — целое).
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Тебе же пример привели. Если по телевизору крутят только росийских ANS>эстрадных исполнителей, то можно ли сделать вывод, что джаза не существует?
А... Это доказывает, что он существует! Я угадал?
Кстити, недолюбливаю джаз. Люблю классику. Моцарта, знаете ли. И что характирно в отличии от джаза кассику по телевизору показывают иногда. Видмо я попсовый мэйнстрим.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Quintanar, Вы писали:
Q>Как сказал один любитель Лиспа, пока другие ждут добавления новых конструкций в свои любимые языки, мы добавляем их сами. И реализация тех же продолжений средствами самого же Лиспа яркий тому пример.
Как в прочем и отупение вызываемое мириадами скобок и отсуствием явных типов.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Quintanar, Вы писали:
Q>Что-что. Это и имею ввиду. Не нужно указывать типы явно, компилятор сам их способен вывести из контекста, экономит кучу времени на написание всех этих объявлений да еще нередко в нескольких местах.
Ну, экономия конечно огромная. Интересно ты пробовал считать сколько ты времени терящь на том, что для твоего любимого языка (Окамл если не ошибаюсь) нет IDE с автодополнением?
Выведение типов дает определенные приемущества, но так же дает и недостатки. Компилятор не замечает многие ошибки принимая их за полиморфное использование. Скорость компиляции может уйти в аут при некоторых стечениях обстоятельств. Человеку читающему код нужно догадываться о вех выкрутасах которые может дать неявный полиморфизм. Так что тут даш, на даш. Это конечно намного лучше чем динамическая типизация, но все равно идея довольно противоречивая.
Q>То, что вы ее не используете, не означает, что она редко используется. По правде сказать, в С-подобных языках ее особо и не поиспользуешь ибо встроеные типы данных примитивны, а для пользовательских язык расширить невозможно.
Ну, язык то расширь можно. Другое дело, что исследовательские языки тут несомненно продвинулись дальше.
Q>Ну да, зачем нужны циклы, когда есть goto, говорили программисты на Фортране.
Ну, это уже не очень верные методы ведения дискусии. Вспомним хотя бы о том, что фортранщики сейчас как раз используют те указатели в С++.
Q>Способ изменить часть программы на этапе компиляции. Позволяют ввести в язык естественным образом операторы и концепции, отсутствующие в языке изначально.
Пожалуй действительно единственная вещь которую я бы хотел иметь в любом языке. Однако макросы тут всех вводят в заблуждение, ассоциируясь с С/С++. Лучше говорить о метапрограммировании. Думаю за ним будущее. Но будут ли они в ИЯ, ФЯ или в гибридах разницы по сути нет.
GZ>>continuations — проясните, что вы имели ввиду.
Q>Continuations слишком сложный вопрос, чтобы осветить его в двух словах. Коротко — это обобщение исключений, longjmp и т.п.
Дык завел бы тему... рассказал бы. Народ спасибо сказал бы.
Q>Это будет влиять на скорость разработки продукта. Для крупных фирм это может быть и неинтересно, но для маленьких колективов весьма критично.
Это интересно для всех. Но надо учитывать что метапрограмирование на порядок сложнее обычного. И не все его потянут. Вот мэйстрим и идет по пути введения плодов, а не средств.
Q>По твоему отношению к моим словам заметно, что ты не знаешь, что дают эти фичи в языках, где они действительно полностью реализованы, так чего тогда спорить?
Интересно, а по моим словам можно сказать тоже самое? Если нет, то значит данное знание не является достаточным для всецелого отвержения мэйстрима и погружения в ресерчь.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Неверное предположение. Скорость разработки и стоимость важны.
Я бы даже сказал они связаны. Чем выше скорость тем дешевле производство. Однако скорость производства не всегда является решающим фатором. Обычно ищется компромис. Вся эта буря эмоций вызвана тем, что раньше компромисом были языки вроде С++ и Дельфи, а теперь их меняют Ява и Шарп. А те кому еще во времена плюсов были ближе исследовательские проекты просто обижаются, что не их любимцы срывают куш.
В общем, опять основным критерием в споре становится банальная привязанность к любимому детящу.
Вот ПК все цепляется за плюсы, Quintanar за Окамл. А меня обвиняют в пропаганде МС, так как я уже променял, и не без удоволствия, С++ на C# и не смог до конца проникнуться идеями Лиспа и Окамла, хотя опять же оценил многие из них как перспективные.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Quintanar, Вы писали:
Q>Да. Боссу легче набрать N програмистов на Java и с ними долбать пару лет программу. К тому же, у больших фирм другие возможности в плане продвижения своих продуктов. Глючную посредственность им впарить гораздо проще.
Не надо скатываться до дешевого пиара базирующегося на наклеивании ярлыков.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 пишет: > ANS>Тебе же пример привели. Если по телевизору крутят только росийских > ANS>эстрадных исполнителей, то можно ли сделать вывод, что джаза не > существует? > > А... Это доказывает, что он существует! Я угадал? > > Кстити, недолюбливаю джаз. Люблю классику. Моцарта, знаете ли. И что > характирно в отличии от джаза кассику по телевизору показывают иногда.
Видимо я всегда не вовремя включаю телевизор
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Здравствуйте, VladD2, Вы писали:
VD>Ну, экономия конечно огромная. Интересно ты пробовал считать сколько ты времени терящь на том, что для твоего любимого языка (Окамл если не ошибаюсь) нет IDE с автодополнением?
Как это нет? Есть пакет для Emacs для OCaml. Хотя понимаю, некоторых при слове Emacs кидает в дрожь. Тем не менее, он практически ничем не уступает VS, если и есть минусы, то только из-за того, что он более универсальный, не ориентирован на один-два языка.
VD>Выведение типов дает определенные приемущества, но так же дает и недостатки. Компилятор не замечает многие ошибки принимая их за полиморфное использование. Скорость компиляции может уйти в аут при некоторых стечениях обстоятельств. Человеку читающему код нужно догадываться о вех выкрутасах которые может дать неявный полиморфизм. Так что тут даш, на даш. Это конечно намного лучше чем динамическая типизация, но все равно идея довольно противоречивая.
1) Про ошибки не надо. Если функция оказывается полиморфной, то это никак не ошибка. Ты попиши сначала на языке с выводом типов, а потом уже говори про ошибки.
2) Стечения обстоятельств лечатся явным указанием типа. И вообще, хороший стиль заключается в явном указании типа для всех ключевых функции (не обязательно сразу при разработке).
VD>Пожалуй действительно единственная вещь которую я бы хотел иметь в любом языке. Однако макросы тут всех вводят в заблуждение, ассоциируясь с С/С++. Лучше говорить о метапрограммировании. Думаю за ним будущее. Но будут ли они в ИЯ, ФЯ или в гибридах разницы по сути нет.
Не совсем верно. ФЯ удобнее тем, что у их AST гораздо меньше типов вершин. Я тут пытаюсь вставить continuations в OCaml с помощью его p4-препроцессора, так такой геморой из-за того, что есть куча разных типов конструкции, что дай боже. Идеал, конечно, Лисп, где типов всего 2.
GZ>>>continuations — проясните, что вы имели ввиду.
Q>>Continuations слишком сложный вопрос, чтобы осветить его в двух словах. Коротко — это обобщение исключений, longjmp и т.п.
VD>Дык завел бы тему... рассказал бы. Народ спасибо сказал бы.
Q>>Это будет влиять на скорость разработки продукта. Для крупных фирм это может быть и неинтересно, но для маленьких колективов весьма критично.
VD>Это интересно для всех. Но надо учитывать что метапрограмирование на порядок сложнее обычного. И не все его потянут. Вот мэйстрим и идет по пути введения плодов, а не средств.
Q>>По твоему отношению к моим словам заметно, что ты не знаешь, что дают эти фичи в языках, где они действительно полностью реализованы, так чего тогда спорить?
VD>Интересно, а по моим словам можно сказать тоже самое? Если нет, то значит данное знание не является достаточным для всецелого отвержения мэйстрима и погружения в ресерчь.
Здравствуйте, VladD2, Вы писали:
VD>Ну, экономия конечно огромная. Интересно ты пробовал считать сколько ты времени терящь на том, что для твоего любимого языка (Окамл если не ошибаюсь) нет IDE с автодополнением?
Как это нет? Есть пакет для Emacs для OCaml. Хотя понимаю, некоторых при слове Emacs кидает в дрожь. Тем не менее, он практически ничем не уступает VS, если и есть минусы, то только из-за того, что он более универсальный, не ориентирован на один-два языка.
VD>Выведение типов дает определенные приемущества, но так же дает и недостатки. Компилятор не замечает многие ошибки принимая их за полиморфное использование. Скорость компиляции может уйти в аут при некоторых стечениях обстоятельств. Человеку читающему код нужно догадываться о вех выкрутасах которые может дать неявный полиморфизм. Так что тут даш, на даш. Это конечно намного лучше чем динамическая типизация, но все равно идея довольно противоречивая.
1) Про ошибки не надо. Если функция оказывается полиморфной, то это никак не ошибка. Ты попиши сначала на языке с выводом типов, а потом уже говори про ошибки.
2) Стечения обстоятельств лечатся явным указанием типа. И вообще, хороший стиль заключается в явном указании типа для всех ключевых функции (не обязательно сразу при разработке).
VD>Пожалуй действительно единственная вещь которую я бы хотел иметь в любом языке. Однако макросы тут всех вводят в заблуждение, ассоциируясь с С/С++. Лучше говорить о метапрограммировании. Думаю за ним будущее. Но будут ли они в ИЯ, ФЯ или в гибридах разницы по сути нет.
Не совсем верно. ФЯ удобнее тем, что у их AST гораздо меньше типов вершин. Я тут пытаюсь вставить continuations в OCaml с помощью его p4-препроцессора, так такой геморой из-за того, что есть куча разных типов конструкции, что дай боже. Идеал, конечно, Лисп, где типов всего 2.
VD>Дык завел бы тему... рассказал бы. Народ спасибо сказал бы.
Ну вот пример continuations на псевдоязыке
val next = identity;
let compute_infinity val =
label:
compute ... compute
(* получили промежуточный результат, но не знаем тот ли *)
if call-with-current-continuation (\lambda cont
next = cont; false ) then goto label else return result
let main =
res = compute_infinity init_val
if (res is not what we want) then (call next true)
call-with-cc принимает на вход функцию от одной переменной (в данном случае я передал анонимную. В этой переменной функции передается текущее продолжение вычислений. Фактически это означает, что если мы вызовем cont val, то это будет эквивалентно тому, что call-with-cc вернула бы в качестве результата val. Сила в том, что этот cont мы можем сохранить в переменной и вызвать позже, причем из совсем другой функции. В данном случае у нас есть функция, где обрабатывается нечто очень большое и получаются промежуточные результаты, эти результаты мы возвращаем, но одновременно запоминаем продолжение, чтобы вернуться к вычислениям в случае, если промежуточный результат не подходит. В главной функции нет цикла, ибо когда мы вызываем продолжение мы возвращаемся, условно говоря, назад во времени. compute_infinity init_val каждый раз будет возвращать разные значения.
Исключения — это по сути частный случай продолжений (в Haskell исключения так и реализованы). Вот как примитивно можно было бы реализовать исключения с помощью продолжений:
define try (expr1) catch (expr2) =
res = call-with-current-cont (\lambda cont ->
expr1)
if (res == Error err) then ((\lambda err -> expr2) err)
else res
define throw err = cont (Error err)
В данном случае продолжения нужны только для того, чтобы вылететь сразу на верхний уровень из глубин expr1.
Здравствуйте, Quintanar, Вы писали:
Q>Здравствуйте, GlebZ, Вы писали:
Q>>>Что-что. Это и имею ввиду. Не нужно указывать типы явно, компилятор сам их способен вывести из контекста, экономит кучу времени на написание всех этих объявлений да еще нередко в нескольких местах. GZ>>Это в другой флейм. Что лучше статические или динамические типы. Я сторонник проверки типов на этапе компиляции.
Q>А причем тут динамические типы? Я же говорю — компилятор сам выводит типы на этапе компиляции.
А я говорю о явной типизации. Тогда и все эти Миллнеры по боку.
Кстати, насколько я знаю (источник по моему был Garperton) они реализованы в JavaScript. А его не mainstreamовым не назовешь.
GZ>>У, дядька. Тебе расказать, что первая версия С++ была просто описана макросами. Темплайты и макросы в С++ мало?
Q>Темплейты слишком маломощны. Сойдет для сельской местности (С++), но нормально преобразовывать код они не могут.
Для императивного языка с ООП, они достаточны.
Здравствуйте, Gaperton, Вы писали:
G>Правда? А теперь давай мешки поворочаем, ты не против? Напиши пожалуйста на С++ или С# более понятный код, чем этот. Покажи, как ты решишь проблему "на этапе дизайна".
G>
G>Ничего сложного — разбор заголовка IP-датаграммы. Dgram — это массив байт. << ... >> — это его разбор на составные части посредством pattern matching. После имени переменной идет ее размер в битах через двоеточее, а тип указан после "/" (по умолчанию — целое).
Спасибо за пример.Еще раз докажем, что императивный язык умеющий управлять ресурсами компьютера может быть эффективным.
Теперь у нас есть структура, которую мы можем подставлять в любое место памяти, для облегчения доступа к заголовку. В случае, если ты определил, что тормозит именно место разбора заголовка датаграммы, то ничего тебе не мешает его просто не разбирать . Это и отличает императивные языки, что в них значительно больше степеней свободы для изменения и управлению ресурсами компьютера.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Quintanar, Вы писали:
Q>>Здравствуйте, GlebZ, Вы писали:
GZ>>>У, дядька. Тебе расказать, что первая версия С++ была просто описана макросами. Темплайты и макросы в С++ мало?
Q>>Темплейты слишком маломощны. Сойдет для сельской местности (С++), но нормально преобразовывать код они не могут.
К>ИМХО GlebZ путает в очередной раз уродские сишные макросы с лисповскими, что в корне не правильно.
Ну не подумал сразу именно о Лиспе. Только тогда уж, и я с удовольствием назову макросы лиспа уродскими (как и сам Лисп, очень он мне не нравится). Оно настолько встроено в него, что нельзя говорить о возможности лиспа без "макросов". Но эта вынужденная игра с рекурсией, мне сильно не нравится. Она сильно усложняет жизнь. Легче и проще (а зачастую и быстрее) решать такие вопросы императивно и адресно.
