_C_>это следствие C# мышления. для любого программиста, минувшего С# доступ через экземпляр к статике — _C_>и не ошибка и не грех, а вполне заурядная вещь.
возможно более убедительной демонстрацией этого будет склонность писать скобочки, точки с запятой,
хотя этого можно изначально и не делать. а вот мы напишем, нам так привычней. так же и здесь. всем нужно постоянство,
которое ведет к инертности и застою. даже предлагаемые фичи, хотя они никому повредить не могут (установка возвращаемого типа)
вызывают сопротивление.
Re[2]: О возможности обращаться к статическим членам через с
демонстрирующая почему это правильное решение.
_C_>это следствие C# мышления. для любого программиста, минувшего С# доступ через экземпляр к статике — _C_>и не ошибка и не грех, а вполне заурядная вещь.
Это следствие рационального мышления и интуиции. Человек интуитивно предполагает, что раз есть наследование, то оно должно давать эффект. По этому логичнее запретить то, что может быть понято неверно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: О возможности обращаться к статическим членам через с
VD>Это следствие рационального мышления и интуиции. Человек интуитивно предполагает, что раз есть наследование, то оно должно давать эффект. По этому логичнее запретить то, что может быть понято неверно.
Если отвлечься от конкретного момента, то у нас спор-дискуссия о сложностяж-длительностях обряда. и ты готов обсуждать уменьшение сложности,
но не готов усомниться в целесообразности оного вообще. Если мы посмотрим на тенденцию языкостроения, но увидим два отчетливых тренда,
строгие языки стремятся к расслаблению, расслабленные к строгости. это не спроста и вытекает из существования двух плохо сочетаемых потребностей
— быстрого прототипирования и точного описания. в гугло-Dart изначально зашита идея их сращивания и поэтому в будущем это будет реально серьезный конкурент.
что противопоставить взамен? против режима быстрого прототипирования — ничего кроме него самого. поэтому всякие строгости / непонятности,
которые тянутся из .net, c#, ... должны быть отключаемы в режиме, в котором будет работать половина или большинство. это у тебя большинство программ создается для показа /использования программистами, поэтому соблюдение всех канонов вполне обосновано. большинство же создает программы для конкретных нужд, где лишняя писанина и понимание глубоких вещей только мешает и отвлекает. вспомним идеи вирта, которые являются следствием бритвы Оккама, и опционально без необходимости не будем требовать усложнения. в будущем, разумеется.
Re[4]: О возможности обращаться к статическим членам через с
Здравствуйте, _Claus_, Вы писали:
_C_>строгие языки стремятся к расслаблению, расслабленные к строгости. это не спроста и вытекает из существования двух плохо сочетаемых потребностей
Это C# чтоли? Так они dynamic по сути для простого COM-интеропа прикрутили и паритета с фичей VB.NET.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[5]: О возможности обращаться к статическим членам через с
_C_>>строгие языки стремятся к расслаблению, расслабленные к строгости. это не спроста и вытекает из существования двух плохо сочетаемых потребностей
H>Это C# чтоли? Так они dynamic по сути для простого COM-интеропа прикрутили и паритета с фичей VB.NET.
для с# добавили кроме dynamic добавляли автовывод типов и LINQ, а то что внутри оно строго, как мы знаем, это ничего,
снаружи стало менее строго ( = меньше писать).
Re[6]: О возможности обращаться к статическим членам через с
Здравствуйте, _Claus_, Вы писали:
_C_>для с# добавили кроме dynamic добавляли автовывод типов и LINQ, а то что внутри оно строго, как мы знаем, это ничего, _C_>снаружи стало менее строго ( = меньше писать).
Извини, но написан какой-то бред. Я рекомендую изучить простую классификацию "типизации": статическая/динамическая, слабая/строгая. Вывод типов не делает строгую типизацию менее строгой — он просто работает.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[7]: О возможности обращаться к статическим членам через с
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, _Claus_, Вы писали:
_C_>>для с# добавили кроме dynamic добавляли автовывод типов и LINQ, а то что внутри оно строго, как мы знаем, это ничего, _C_>>снаружи стало менее строго ( = меньше писать).
H>Извини, но написан какой-то бред. Я рекомендую изучить простую классификацию "типизации": статическая/динамическая, слабая/строгая. Вывод типов не делает строгую типизацию менее строгой — он просто работает.
Какая разница прикладному программисту Какая типизация если он Просто пишет
def a=1
Re[8]: О возможности обращаться к статическим членам через с
Здравствуйте, Аноним, Вы писали:
А>Какая разница прикладному программисту Какая типизация если он Просто пишет
А>def a=1
Основная — в том, что когда он позже передаст a в метод, который принимает только строки, будет ошибка компиляции.
Почти во всех языках со статической типизацией есть та или иная форма вывода типов. Сколько писать программисту и какая типизация — вещи независимые. То что обычно в языках со статической типизацией чаще приходится писать имена типов скорее следствие двух причин:
1) дизайнеры статических языков люди параноидальные относительно того, чтобы пользователи языков сами понимали что пишут; и
2) вывод и проверка типов для большой программы — дело тормозное, а указание типов в конкретных местах (в Немерле, например, на входе и выходе каждого метода) ее ускоряет.
Re[7]: О возможности обращаться к статическим членам через с
Здравствуйте, hardcase, Вы писали:
H>Извини, но написан какой-то бред. Я рекомендую изучить простую классификацию "типизации": статическая/динамическая, слабая/строгая. Вывод типов не делает строгую типизацию менее строгой — он просто работает.
В случае _Claus_ проблема, видимо, в том, что его понятие о выводе типов ассоциируется с Бу. А в нем вывод типов вещь весьма условная, так как в случае неудачи Бу переходит на динамику.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: О возможности обращаться к статическим членам через с
От:
Аноним
Дата:
11.12.11 12:15
Оценка:
Здравствуйте, catbert, Вы писали:
C>Здравствуйте, Аноним, Вы писали:
А>>Какая разница прикладному программисту Какая типизация если он Просто пишет
А>>def a=1
C>Основная — в том, что когда он позже передаст a в метод, который принимает только строки, будет ошибка компиляции.
C>Почти во всех языках со статической типизацией есть та или иная форма вывода типов. Сколько писать программисту и какая типизация — вещи независимые. То что обычно в языках со статической типизацией чаще приходится писать имена типов скорее следствие двух причин: C>1) дизайнеры статических языков люди параноидальные относительно того, чтобы пользователи языков сами понимали что пишут; и C>2) вывод и проверка типов для большой программы — дело тормозное, а указание типов в конкретных местах (в Немерле, например, на входе и выходе каждого метода) ее ускоряет
круто но для программиста который пишет без ошибок понятный код пофиг. Диномический в принципе эквивалентнен полиморфизму высшего порядка
Re[10]: О возможности обращаться к статическим членам через
Здравствуйте, Аноним, Вы писали:
А>круто но для программиста который пишет без ошибок понятный код пофиг. Диномический в принципе эквивалентнен полиморфизму высшего порядка
Все прекрасно до тех пор пока не потребуется изменить программу на динамически типизированном языке.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[8]: О возможности обращаться к статическим членам через с
H>>Извини, но написан какой-то бред. Я рекомендую изучить простую классификацию "типизации": статическая/динамическая, слабая/строгая. Вывод типов не делает строгую типизацию менее строгой — он просто работает.
Мое утверждения о стремлении строгих языков к расслаблению подразумевает в случае С# и опциональную динамику, и упрощения с типами, и LINQ.
Если это все не упрощения (уменьшение нужного кода для программы, уменьшение требований и знаний к программисту) — тогда я конный полицай. И доказываю я то, что упрощения, опциональные хотя бы, полезны. не надо их бояться. сложные языки рано или поздно вымирают, не оставив потомков, если не находят способа быть проще. если для H2 будет возможно написать систему макросов, эмулирующую CoffeeScript, больше никому ничего не придется доказывать,
что Н- лучший, у вас на руках будет то, чего никто, никогда не сможет ни оспорить, ни замолчать.
VD>В случае _Claus_ проблема, видимо, в том, что его понятие о выводе типов ассоциируется с Бу. А в нем вывод типов вещь весьма условная, так как в случае неудачи Бу переходит на динамику.
это не так. Бу переходит на динамику, если метод или поле в объекте не обнаружено и а) объект имеет динамик-интерфейс или б) глобально установлен флаг,
все объекты трактующий как динамик.
Re[10]: О возможности обращаться к статическим членам через
Здравствуйте, _Claus_, Вы писали:
_C_>Мое утверждения о стремлении строгих языков к расслаблению подразумевает в случае С# и опциональную динамику, и упрощения с типами, и LINQ.
Это следствие использования неверной терминологии.
Все эти "расслаблению", "упрощения" — это все выдуманные тобой термины смысл которых ты и сам не можешь четко сформулировать.
_C_>Если это все не упрощения (уменьшение нужного кода для программы, уменьшение требований и знаний к программисту) — тогда я конный полицай.
С последним спорить не буду, а вот "уменьшение нужного кода" и "уменьшение требований и знаний" противоречащие друг другу вещи. Гибкие конструкции позволяющие сделать код меньше и выразительнее требуют большей квалификации программиста. Ведь программист должен знать расширенный набор фичь и уметь их применять.
_C_>И доказываю я то, что упрощения, опциональные хотя бы, полезны.
Определись с тем что ты понимаешь под упрощением. Думаю, что под этим термином скрывается — повышение гибкости.
_C_> не надо их бояться. сложные языки рано или поздно вымирают, не оставив потомков, если не находят способа быть проще. если для H2 будет возможно написать систему макросов, эмулирующую CoffeeScript, больше никому ничего не придется доказывать, что Н- лучший, у вас на руках будет то, чего никто, никогда не сможет ни оспорить, ни замолчать.
Можно не значит нужно.
У Немерла есть проблемы и мы их знаем. Но это никак не строгость типизации или отсутствие багофич к которым привыкли пользователи хреново спроектированных языков.
VD>>В случае _Claus_ проблема, видимо, в том, что его понятие о выводе типов ассоциируется с Бу. А в нем вывод типов вещь весьма условная, так как в случае неудачи Бу переходит на динамику.
_C_>это не так. Бу переходит на динамику, если метод или поле в объекте не обнаружено
Ну, да. А это любая ошибка в коде. Плюс еще есть "б)", "в)", "г)" и т.п. Вот пример с неявным даункастом очень характерен.
Такого "расслабления" нам не надо.
Вот внятный АПИ для макросов, качественные сообщения компилятора, гибкость синтаксического расширения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: О возможности обращаться к статическим членам через
VD>Такого "расслабления" нам не надо. VD>Вот внятный АПИ для макросов, качественные сообщения компилятора, гибкость синтаксического расширения.
тогда вот об этом нужно забыть —
В качестве внешних DSL-ей смогут выступать не только простейшие HTML/XML, но даже полноценные языки программирования вроде VB, Delphi или C#. При этом
для внешних DSL-ей будет обеспечена автоматическая поддержка IDE (подсветка, подсказки и т.п.).
это цитата с сайта об отличиях Nemerle 1 от 2. заявляете другие языки — имейте ввиду, что идеология в них может сильно отличаться от "правильной".
и это либо закладывается сразу либо никак.
Re[11]: О возможности обращаться к статическим членам через
Здравствуйте, _Claus_, Вы писали:
_C_>тогда вот об этом нужно забыть - _C_>
_C_> В качестве внешних DSL-ей смогут выступать не только простейшие HTML/XML, но даже полноценные языки программирования вроде VB, Delphi или C#. При этом
_C_>для внешних DSL-ей будет обеспечена автоматическая поддержка IDE (подсветка, подсказки и т.п.).
_C_>это цитата с сайта об отличиях Nemerle 1 от 2. заявляете другие языки — имейте ввиду, что идеология в них может сильно отличаться от "правильной". _C_>и это либо закладывается сразу либо никак.
Ну почему же? Просто типизацию нужно будет писать свою. Если Немерле2-тим осилит и сделает DSL для типизации, то это будет даже несложно.
Re[12]: О возможности обращаться к статическим членам через
C>Ну почему же? Просто типизацию нужно будет писать свою. Если Немерле2-тим осилит и сделает DSL для типизации, то это будет даже несложно.
этого мало. нужен встроенный механизм перехвата управления/разрешения ситуаций, где N-логика не подходит.
например
неизвестный метод -> обработка
неизвестная переменная -> ..
передается не тот тип -> ..
...
логики макросов мало, нужен контроль над поведением компилятора. если его не продумать, то
По сути, Nemerle 2.0 будет фрэймворком для разработки новых языков.
хорошо не получится. а если не хорошо, то смысла мало — кода много. мне это нужно для дела, поэтому такой нудный.
