Здравствуйте, cl-user, Вы писали:
CU>Я бы скорее поговорил о возможности разделения кода (блин, чтобы не говорили — "их есть у нас" — в _пределах одного файла_!) на "для компиляцци" и/или "для компилятора". Тогда часть инструкций (в т.ч. и описание классов) можно было бы определить как "и для одного, и для второго" — и не бфло бы никаких ограничений ни для макр, ни для классов.
Низнаю. Я использую макрос постоянно и иногда пишу свои... и ни разу у меня не вызвало проблем то что макросы это сущьнсти верхнего уровня.
Вообще макросы как довольно мощьное средство не надо пихать всюду. Это как бы последний аргумент. И когда он нужен, то его как бы проблема уже серьезная и решать ее гду-то в закутке просто не приходит на ум.
CU>Авторы ведь знакомились с подобной технологией
Авторы много с чем знакомились. И обосновали свой выбор. Потому я и говорю, что согласен с ним.
CU>Я не вижу/не понимаю, почему прекомпилированность макр налогает ограничение невозможности в одном файле/блоке кода сначала откомпилировать макры, а потом остальной код при следующем проходе?
Хотя бы потому что это не разумно (хотя технически реализуемо). Неразумно по причине усложнения поддержки. Я применял подобную технику в R# и иришел к выоду, что она черезмерна в данном случае. Удобнее иметь макросы как бибилотеку. Это повзволяет удбоно их отлиживать, контролировать и поддерживать.
CU>Спасибо, но я не об этом. Если объявление def... and... позволяет обойти огрничение видимости, то почему не сделать такое поведение "по умолчанию" для любого def...?
Потому что and подразумевает, что между предыдущей функций и этой нет никакого кода на который можно замкнуться.
Хотя потенциально конечно можно было бы разрешить использвать идующую дальше фукнцию если она идет срауз (не отделена другими объявлениями). Но это пришлось бы отдельно объяснять. В прочем можшь предложить это разраотчикам языка (в конференци). Посмотрим что они скажут.
CU>P.S. К чему я это всё? Да я всё пытаюсь добится от "апологетов" согласия с тем, что один язык не то что не идеален, но таки совершенно не смог вобрать в себя все известные достижения из области языкостроения, причём совершенно не из-за заботы о "мэйнстримовом программисте" (типа ему это не нужно), а из-за банальной нехватки ресурсов. И нынешнее положение дел в лучшем случае позволяет надеятся, что вторая версия языка избавится от многих/некоторых ограничений.
Пока что ты демонсррируешь докапывание к неваждым мелочам. Я могу таких еще с десяток привести. Темоблее если речь идет о прирципиальном выборе альтернативы.
Однакто качество языка определяется не этим. Оно скорее определяется колечеством полезных свойств, их сбалансированностью и интуитивностью.
CU>P.P.S. К чему был этот "P.S."? Я всё пытаюсь ответить на первое сообщение : ребята, смелее признавайте имеющиеся недостатки в языке (а отсутсвие той или иной возможности — именно недостаток, недостаток этой самой возможности),
Это совсем не так. Избыток ненужных "достоинств" — это недостатко. Одно из достоинств языка — это простота использования. По этому лепить в язык все что приходит на ум просто нельзя.
Есть приципиашьные фичи. Ну, там поддеркжа функций как первокасных сущностей, ООП, паттернм-матчинг и т.п. Они важны и конечно их наличие определяет возможность использовать тот или иной стиль прогарммирования. А вот детали реализации уже более тонкая субстанция. Тут уже нельзя сказать вот так вот хорошо, а вот так плохо. Детали уже надо рассматривать в общей картике. Важно не их количество, а их сбаланстированность и не противоричивость.
По-моему, вопрос должен ставиться так. Фича полезна если она интуитивно понятана и полезна на практике. Отсюда следствия:
1. Лучше не добалвять в язык что-то что пийдется долго объяснять.
2. Если что-то приходится объяснять, то это что-то лучше поправить.
3. Если фича не используется основным количеством народа, то ее лучше удалить.
CU>причём я именно о языке, а не о его реализации (т.е. проблемы релиза, документации, багов и прочего не в счёт) — "и люди к вам потянутся" Да, ряд недостатков может быть принципиальным и непреодолимым. Так просто признайте, что этот ряд есть, по возможности максимально точно его описав, а не уговаривайте окружающих, что эти возможности нафиг никому не нужны.
Дык так и есть. Просто почему-то большинство как раз говорит о том, что никому не нужно, а не о том, что явлется проблемой.
Лично я вижу некоторые проблемы, но они скрее являются слествием реалазации на базе дотнета и по сути являются данью бесшевной поддержки компонетной технологии (и в принципе обходятся макросами).
CU> Ведите себя как технические специалисты, а не как "полутехнические маркетологи". Не знаю как кого, а меня обилие рекламы может отвернуть даже от неплохой вещи (ибо обилие реклами как минимум не может быть бесплатным).
Да не надо нас уговаривать. Мы с этим согласны.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Т.е. только для N пришлось применять такой слоган, за который раньше высмеяли бы прилюдно, не приняли бы всерьёз, а авторы бы с горя запили по чёрному?.. Ну-ну.
Если язык настолько хорош, то смысл ваших мантр совершенно неясен.
Если же без таких мантр язык не так уж и хорош, то на сколько же он хорош на самом деле?...
P.S. Прошу извинения за сваливание в ХВ, но у одного хорошего языка ещё очень много проблем и слишком неопределённое будущее, чтобы на подобные высказывания была хоть какая-то реакция, кроме токсического отторжения
Здравствуйте, Mckey, Вы писали:
CU>>>P.P.S. К чему был этот "P.S."? Я всё пытаюсь ответить на первое сообщение : ребята, смелее признавайте имеющиеся недостатки в языке (а отсутсвие той или иной возможности — именно недостаток, недостаток этой самой возможности), причём я именно о языке, а не о его реализации (т.е. проблемы релиза, документации, багов и прочего не в счёт) — "и люди к вам потянутся"
N>>Да, у Nemerle есть недостатки. И он — не идеальный язык.
M>Но он лучший язык из того что я видел и пробовал...
Но это не повод не пытаться его совершенствовать (в том числе — избавлять от недостатков).
Здравствуйте, cl-user, Вы писали:
CU>P.S. Прошу извинения за сваливание в ХВ, но у одного хорошего языка ещё очень много проблем
У языка то как раз проблем нет. Есть определённые проблемы у реализации компилятора.
CU>и слишком неопределённое будущее,
Так у нас, в отличии от других языков, есть все шансы на определение этого будущего.
CU>чтобы на подобные высказывания была хоть какая-то реакция, кроме токсического отторжения
Это как? Насколько мне известно таксикоз обычно бывает не из-за языков, а из-за беременности
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, cl-user, Вы писали:
CU>>P.S. Прошу извинения за сваливание в ХВ, но у одного хорошего языка ещё очень много проблем
IT>У языка то как раз проблем нет. Есть определённые проблемы у реализации компилятора.
По мне так именно в языке не хватает нескольких вещей. И пока _единственная_ его реализация продолжает развиваться в том числе и авторами _языка_ вместе с самим языком — есть надежда...
CU>>и слишком неопределённое будущее,
IT>Так у нас, в отличии от других языков, есть все шансы на определение этого будущего.
Возможно, у вас есть шансы на определение данной _реализации_ языка. Тех, кто мог бы определять будущее самого языка я здесь не наблюдаю...
CU>>чтобы на подобные высказывания была хоть какая-то реакция, кроме токсического отторжения
IT>Это как? Насколько мне известно таксикоз обычно бывает не из-за языков, а из-за беременности
Ну, можно сказать что меня затрахали подобные восторженно-истеричные мантры
Здравствуйте, cl-user, Вы писали:
CU>Т.е. только для N пришлось применять такой слоган, за который раньше высмеяли бы прилюдно, не приняли бы всерьёз, а авторы бы с горя запили по чёрному?.. Ну-ну.
Мужик, с таним чувством юмора, вернее его отсусвием, на свете жить нельзя.
Чесно-слово прийтется тебе застрелиться.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Мужик, с таним чувством юмора, вернее его отсусвием, на свете жить нельзя.
VD>Чесно-слово прийтется тебе застрелиться.
Разрешите выполнять приказание?!
Нет, лучше я тебе зеркальце подарю
Здравствуйте, cl-user, Вы писали:
IT>>У языка то как раз проблем нет. Есть определённые проблемы у реализации компилятора. CU>По мне так именно в языке не хватает нескольких вещей. И пока _единственная_ его реализация продолжает развиваться в том числе и авторами _языка_ вместе с самим языком — есть надежда...
Так в чём проблема? Если то, что по тебе, действительно стоящая вещь, то я ни секунды не сомневаюсь, что она будет добавлена в язык.
IT>>Так у нас, в отличии от других языков, есть все шансы на определение этого будущего. CU>Возможно, у вас есть шансы на определение данной _реализации_ языка. Тех, кто мог бы определять будущее самого языка я здесь не наблюдаю...
Надо будет что-то добавить в язык, добавим, в независимости от тогго наблюдаешь ты это или нет. Даже не сомневайся. Но, само собой, бред и чушь в язык добавлять никто не позволит.
IT>>Это как? Насколько мне известно таксикоз обычно бывает не из-за языков, а из-за беременности CU>Ну, можно сказать что меня затрахали подобные восторженно-истеричные мантры
Я тебе сочувствую. Нельзя так слишком близко принимать всё к сердцу. Большому мальчику уже пора бы научиться отделять зёрна от плевел.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Так в чём проблема? Если то, что по тебе, действительно стоящая вещь, то я ни секунды не сомневаюсь, что она будет добавлена в язык.
По мне стоящая вещь — локальные макро и, как их частная разновидность, локальное переопределение синтаксиса. Вот только осталось определиться — для кого это "бред и чушь", а для кого — нет
IT>Надо будет что-то добавить в язык, добавим, в независимости от тогго наблюдаешь ты это или нет. Даже не сомневайся. Но, само собой, бред и чушь в язык добавлять никто не позволит.
Ок, я подожду — это проще всего
IT>Я тебе сочувствую. Нельзя так слишком близко принимать всё к сердцу. Большому мальчику уже пора бы научиться отделять зёрна от плевел.
Ы, если первоначальное "положение" было совершенно несерьёзным, то почему вы иначе относитесь к отзывам на него? "Нельзя так слишком близко принимать всё к сердцу." (c) You.
Здравствуйте, nikov, Вы писали:
IT>>Но, само собой, бред и чушь в язык добавлять никто не позволит.
N>Ерунда. Лицензия никому не запрещает ветку сделать.
И что?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, cl-user, Вы писали:
CU>По мне стоящая вещь — локальные макро и, как их частная разновидность, локальное переопределение синтаксиса. Вот только осталось определиться — для кого это "бред и чушь", а для кого — нет
Да, было бы не плохо. Вноси предложение
IT>>Я тебе сочувствую. Нельзя так слишком близко принимать всё к сердцу. Большому мальчику уже пора бы научиться отделять зёрна от плевел.
CU>Ы, если первоначальное "положение" было совершенно несерьёзным, то почему вы иначе относитесь к отзывам на него? "Нельзя так слишком близко принимать всё к сердцу." (c) You.
Потому что было заметно, что ты принимаешь это слишком близко к сердцу. Не стоит.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Потому что было заметно, что ты принимаешь это слишком близко к сердцу. Не стоит.
Хм. Я бы сказал, что это было очень плхоже на то, что я принимаю... (далее по тексту). Ведь на самом деле не важно, что именно я чувствовал, когда что-то говорил, а важно — чего я хотел добиться... Хотя "у любой палки два конца"... А с другой стороны — ты уверен, что не стоит "принимать/реагировать"? Почему бы не попытаться, если попытка почти ничего не стоит, а результат _может_ быть? (это как улыбаться / не улыбаться) Особенно, когда событие уже "нанесло положенный урон"? Ладно, завязываем. Ведб в любом случае — это дело сугубо личное?
Здравствуйте, cl-user, Вы писали:
N>>Очевидно. Если ему надо, то он добавит, никого не спрашивая. CU>Совсем не очевидно. _Он_ ( ) хочет "пропихнуть" свой _feature request_, который ему одному явно не "по зубам"
Я имел в виду: некий безличный "он"
Здравствуйте, IT, Вы писали:
CU>>По мне стоящая вещь — локальные макро и, как их частная разновидность, локальное переопределение синтаксиса. Вот только осталось определиться — для кого это "бред и чушь", а для кого — нет
IT>Да, было бы не плохо. Вноси предложение
Здравствуйте, cl-user, Вы писали:
VD>>Чесно-слово прийтется тебе застрелиться.
CU>Разрешите выполнять приказание?! CU>Нет, лучше я тебе зеркальце подарю
Без зеркальца переживу... выполняй.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
IT>>И что?
N>Очевидно. Если ему надо, то он добавит, никого не спрашивая.
Если это будет по делу, то нет проблем. Если без дела и без согласования, то боюсь, что в таком случае уровень доверия между теми, кто занимается проектом может существенно снизиться. Это в свою очередь приведёт к ограничению доступа к коду. Оно тебе надо? Проще согласовать или хотя бы поставить в известность.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, cl-user, Вы писали:
CU>По мне стоящая вещь — локальные макро и, как их частная разновидность, локальное переопределение синтаксиса. Вот только осталось определиться — для кого это "бред и чушь", а для кого — нет
Это прежде чем обсуждать еще нужно детерминировать. Что значит "локальные"?
Синтаксис и так переопеределяется для пространства имен в котором объявляетсся using другого пространства имен в котором объявлен макрос переопределяющий снитаксис. Так что в некотором смысле он лкален.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Если это будет по делу, то нет проблем. Если без дела и без согласования, то боюсь, что в таком случае уровень доверия между теми, кто занимается проектом может существенно снизиться. Это в свою очередь приведёт к ограничению доступа к коду. Оно тебе надо?
Мне — не надо. Я говорю о том, что при такой лицензии, нельзя говорить о каком либо запрете. Исходники свободно распостраняемы как в исходном, так и в измененном виде. Любой, кому это понадобится, может сделать контролируемую им копию репозитория и вносить туда любые изменения, которые ему забагорассудится. И продвигать свою версию в дальнейшем.
Здравствуйте, nikov, Вы писали:
N>Мне — не надо. Я говорю о том, что при такой лицензии, нельзя говорить о каком либо запрете. Исходники свободно распостраняемы как в исходном, так и в измененном виде. Любой, кому это понадобится, может сделать контролируемую им копию репозитория и вносить туда любые изменения, которые ему забагорассудится. И продвигать свою версию в дальнейшем.
Это не будет изменением языка. Это будет созданием клона. Причем почти гаратнированно провального.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
IT>>Если это будет по делу, то нет проблем. Если без дела и без согласования, то боюсь, что в таком случае уровень доверия между теми, кто занимается проектом может существенно снизиться. Это в свою очередь приведёт к ограничению доступа к коду. Оно тебе надо?
N>Мне — не надо. Я говорю о том, что при такой лицензии, нельзя говорить о каком либо запрете. Исходники свободно распостраняемы как в исходном, так и в измененном виде. Любой, кому это понадобится, может сделать контролируемую им копию репозитория и вносить туда любые изменения, которые ему забагорассудится. И продвигать свою версию в дальнейшем.
Это сколько угодно. Не вижу в этом ничего плохого и не удивлюсь, если такие попытки будут предприниматься.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>>>Чесно-слово прийтется тебе застрелиться.
CU>>Разрешите выполнять приказание?! CU>>Нет, лучше я тебе зеркальце подарю
VD>Без зеркальца переживу... выполняй.
Какой все же доброжелательный и приятный народ на РСДНе..Это что-то
Здравствуйте, VladD2, Вы писали:
CU>>По мне стоящая вещь — локальные макро и, как их частная разновидность, локальное переопределение синтаксиса. Вот только осталось определиться — для кого это "бред и чушь", а для кого — нет
VD>Это прежде чем обсуждать еще нужно детерминировать. Что значит "локальные"?
VD>Синтаксис и так переопеределяется для пространства имен в котором объявляетсся using другого пространства имен в котором объявлен макрос переопределяющий снитаксис. Так что в некотором смысле он лкален.
Согласен. Имел в виду "локальные" по отношению к файлу/модулю/классу/методу/функции/блоку кода/да хоть выражения в конце концов..
Здравствуйте, cl-user, Вы писали:
CU>Согласен. Имел в виду "локальные" по отношению к файлу/модулю/классу/методу/функции/блоку кода/да хоть выражения в конце концов..
А какой смысл вводить каую-то повышенную гранулярность?
Мне кажется ты говоришь не о локальности, а о возможности объявлять и испольовать макросы в одном проекте (без предварительной компиляции). Иначе твои желания выглядят по меньшей мере странно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
CU>>Согласен. Имел в виду "локальные" по отношению к файлу/модулю/классу/методу/функции/блоку кода/да хоть выражения в конце концов..
VD>А какой смысл вводить каую-то повышенную гранулярность?
Это не введение "повышенной гранулярности" — это снятие ограничений.
VD>Мне кажется ты говоришь не о локальности, а о возможности объявлять и испольовать макросы в одном проекте (без предварительной компиляции). Иначе твои желания выглядят по меньшей мере странно.
И об этом тоже. Просто я попытался "объять необъятное" — захотел добиться максимальной свободы работы с макрами по аналогии работы с функциями (я понимаю, что точно такой-же свободы не добиться без рантайм компиляции макр, но на этом я и не настаиваю).
И попутный вопрос: объявление функций через def... and... — это "умышленное" или "временное" ограничение? Ведь внутри модуля "взаимно-рекурсивные" методы объявляются стандартным способом.
Здравствуйте, Mirrorer, Вы писали:
VD>>Без зеркальца переживу... выполняй. M>Какой все же доброжелательный и приятный народ на РСДНе..Это что-то
Ты на всех-то не обобщай. Он у нас один такой.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Идеальный язык программирования
От:
Аноним
Дата:
27.02.07 12:51
Оценка:
Здравствуйте, cl-user, Вы писали:
CU>И попутный вопрос: объявление функций через def... and... — это "умышленное" или "временное" ограничение? Ведь внутри модуля "взаимно-рекурсивные" методы объявляются стандартным способом.
А какие неудобства возникают? Вроде как если локальные функции "взаимно-рекурсивны", то и располагать их логичнее подряд.
Здравствуйте, Аноним, Вы писали:
CU>>И попутный вопрос: объявление функций через def... and... — это "умышленное" или "временное" ограничение? Ведь внутри модуля "взаимно-рекурсивные" методы объявляются стандартным способом.
А>А какие неудобства возникают? Вроде как если локальные функции "взаимно-рекурсивны", то и располагать их логичнее подряд.
Да просто интересует — откуда ноги у ограничения, если всёравно "свободный" код оформляется модулем (классом) /* и где я это читал? */. Или я неправ?
Здравствуйте, Lloyd, Вы писали:
VD>>>Без зеркальца переживу... выполняй. M>>Какой все же доброжелательный и приятный народ на РСДНе..Это что-то
L>Ты на всех-то не обобщай. Он у нас один такой.
Здравствуйте, cl-user, Вы писали:
А>>А какие неудобства возникают? Вроде как если локальные функции "взаимно-рекурсивны", то и располагать их логичнее подряд. CU>Да просто интересует — откуда ноги у ограничения, если всёравно "свободный" код оформляется модулем (классом) /* и где я это читал? */. Или я неправ?
Здравствуйте, ie, Вы писали:
А>>>А какие неудобства возникают? Вроде как если локальные функции "взаимно-рекурсивны", то и располагать их логичнее подряд. CU>>Да просто интересует — откуда ноги у ограничения, если всёравно "свободный" код оформляется модулем (классом) /* и где я это читал? */. Или я неправ?
ie>Методом
Да я уже понял своё заблуждение, но, мне кажется, могли бы и обойти сие ограничение.
Здравствуйте, cl-user, Вы писали:
VD>>А какой смысл вводить каую-то повышенную гранулярность?
CU>Это не введение "повышенной гранулярности" — это снятие ограничений.
Нет там никаких ограничений. Или тогда надо говорить о снятии ограничений на описание классов унутри объявлений параметров методов и т.п.
VD>>Мне кажется ты говоришь не о локальности, а о возможности объявлять и испольовать макросы в одном проекте (без предварительной компиляции). Иначе твои желания выглядят по меньшей мере странно.
CU>И об этом тоже. Просто я попытался "объять необъятное" — захотел добиться максимальной свободы работы с макрами по аналогии работы с функциями (я понимаю, что точно такой-же свободы не добиться без рантайм компиляции макр, но на этом я и не настаиваю).
Это не свобода. Это всего лишь выбор ограничений. Говоря умными словами — дизайнерский выбор.
В Немерле сделан осознанный выбор. Макросы являются прекомпилируемыми и статически типизированными. Естественно, это решение налагает ограничения и дает свои приемущества. Как показывает практика ограничение вполне разумное и дающее вполне полезные приемущества. Возможно в каком-нибудь Руби это было бы неверным выбором. Но это ведь не Руби.
CU>И попутный вопрос: объявление функций через def... and... — это "умышленное" или "временное" ограничение? Ведь внутри модуля "взаимно-рекурсивные" методы объявляются стандартным способом.
Намеренное. Локальные фукнции это не просто скрытые от глаз методы. Они замыкаются на контекст в котором они объявляются. Таким образом их область видимости это область видимости внешней фукнции/метода вполь до начала этой самой вложенной фукнции. Вызвать что-то объявленное ниже локальня фукнция просто так не может, так как у объявленны ниже фукнций еще не сформирован их конектс.
Чтобы было явснее вот пример:
Test() : void// некоторый метод
{
def a = 1;
def f1()
{
WriteLine(a); // ОК - используем объявленную выше переменную "a".
f2() // Неврено! f2() не может быть вызвана так как она замкнута на b которая еще не определена!
}
def b = 2;
def f2()
{
WriteLine(b);
}
}
Ну, а если локальные функции не замыкаются, то их можно вынести в отдельный скрытый метод. Все что при этом надо сделать — описать типы парамтеров и убрать "def".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>А какой смысл вводить каую-то повышенную гранулярность?
CU>>Это не введение "повышенной гранулярности" — это снятие ограничений.
VD>Нет там никаких ограничений. Или тогда надо говорить о снятии ограничений на описание классов унутри объявлений параметров методов и т.п.
Я бы скорее поговорил о возможности разделения кода (блин, чтобы не говорили — "их есть у нас" — в _пределах одного файла_!) на "для компиляцци" и/или "для компилятора". Тогда часть инструкций (в т.ч. и описание классов) можно было бы определить как "и для одного, и для второго" — и не бфло бы никаких ограничений ни для макр, ни для классов.
Авторы ведь знакомились с подобной технологией
VD>>>Мне кажется ты говоришь не о локальности, а о возможности объявлять и испольовать макросы в одном проекте (без предварительной компиляции). Иначе твои желания выглядят по меньшей мере странно.
CU>>И об этом тоже. Просто я попытался "объять необъятное" — захотел добиться максимальной свободы работы с макрами по аналогии работы с функциями (я понимаю, что точно такой-же свободы не добиться без рантайм компиляции макр, но на этом я и не настаиваю).
VD>Это не свобода. Это всего лишь выбор ограничений. Говоря умными словами — дизайнерский выбор.
VD>В Немерле сделан осознанный выбор. Макросы являются прекомпилируемыми и статически типизированными. Естественно, это решение налагает ограничения и дает свои приемущества. Как показывает практика ограничение вполне разумное и дающее вполне полезные приемущества. Возможно в каком-нибудь Руби это было бы неверным выбором. Но это ведь не Руби.
Я не вижу/не понимаю, почему прекомпилированность макр налогает ограничение невозможности в одном файле/блоке кода сначала откомпилировать макры, а потом остальной код при следующем проходе?
CU>>И попутный вопрос: объявление функций через def... and... — это "умышленное" или "временное" ограничение? Ведь внутри модуля "взаимно-рекурсивные" методы объявляются стандартным способом.
VD>Намеренное. Локальные фукнции это не просто скрытые от глаз методы. Они замыкаются на контекст в котором они объявляются. Таким образом их область видимости это область видимости внешней фукнции/метода вполь до начала этой самой вложенной фукнции. Вызвать что-то объявленное ниже локальня фукнция просто так не может, так как у объявленны ниже фукнций еще не сформирован их конектс.
<skip лекцию>
Спасибо, но я не об этом. Если объявление def... and... позволяет обойти огрничение видимости, то почему не сделать такое поведение "по умолчанию" для любого def...?
P.S. К чему я это всё? Да я всё пытаюсь добится от "апологетов" согласия с тем, что один язык не то что не идеален, но таки совершенно не смог вобрать в себя все известные достижения из области языкостроения, причём совершенно не из-за заботы о "мэйнстримовом программисте" (типа ему это не нужно), а из-за банальной нехватки ресурсов. И нынешнее положение дел в лучшем случае позволяет надеятся, что вторая версия языка избавится от многих/некоторых ограничений.
P.P.S. К чему был этот "P.S."? Я всё пытаюсь ответить на первое сообщение : ребята, смелее признавайте имеющиеся недостатки в языке (а отсутсвие той или иной возможности — именно недостаток, недостаток этой самой возможности), причём я именно о языке, а не о его реализации (т.е. проблемы релиза, документации, багов и прочего не в счёт) — "и люди к вам потянутся" Да, ряд недостатков может быть принципиальным и непреодолимым. Так просто признайте, что этот ряд есть, по возможности максимально точно его описав, а не уговаривайте окружающих, что эти возможности нафиг никому не нужны. Ведите себя как технические специалисты, а не как "полутехнические маркетологи". Не знаю как кого, а меня обилие рекламы может отвернуть даже от неплохой вещи (ибо обилие реклами как минимум не может быть бесплатным).
P.P.P.S. "Ничего личного". Всем, принимающим участие в развитии языка, а также тем, кто отвечает на местами идиотские вопросы — большое спасибо.
Здравствуйте, cl-user, Вы писали:
CU>Я бы скорее поговорил о возможности разделения кода (блин, чтобы не говорили — "их есть у нас" — в _пределах одного файла_!) на "для компиляцци" и/или "для компилятора". Тогда часть инструкций (в т.ч. и описание классов) можно было бы определить как "и для одного, и для второго" — и не бфло бы никаких ограничений ни для макр, ни для классов.
CU>Авторы ведь знакомились с подобной технологией
Ну, насколько я помню, возможность делать макры в той же сборке осуждалась, и контраргумент был — типа, прийдется считать транзитивное замыкание макросов и всех классов, которые они используют; из-за этого могли бы появиться странные ошибки — например, добавил свойство в класс — а программа не компилируется, т.к. в замыкание макр попало их же использование.
Но можно ввести специальную конструкцию, например — macro namespace X { ... } — и всё, что используют макры, объявлять там. Может, это улучшит ситуацию.
А принципиальных проблем вроде бы нет.
Здравствуйте, Алексей П, Вы писали:
АП>Но можно ввести специальную конструкцию, например — macro namespace X { ... } — и всё, что используют макры, объявлять там. Может, это улучшит ситуацию. АП>А принципиальных проблем вроде бы нет.
Дык и чем это будет отличаться от хранения макросов в отдельном проекте? Все тоже самео. Только пропадает возможность котролировать наличие макросов в коде.
Так все ясно. Нет ссылок на макро-библиотеки, нет макросов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Дык и чем это будет отличаться от хранения макросов в отдельном проекте? Все тоже самео. Только пропадает возможность котролировать наличие макросов в коде.
Только тем, что нет этой самой библиотеки. Это иногда было бы действительно удобно.
Кстати, заодно можно ввести конструкцию using macros X; — вместо импорта их по обычному using X; — реально повысит контролируемость.
VD>Так все ясно. Нет ссылок на макро-библиотеки, нет макросов.
Но факт того, что в библиотеке макросы, выясняется либо заглядыванием в код, либо по названию. То же самое.
[..skip..]
На скипнутое уже ответили
CU>P.S. К чему я это всё? Да я всё пытаюсь добится от "апологетов" согласия с тем, что один язык не то что не идеален, но таки совершенно не смог вобрать в себя все известные достижения из области языкостроения, причём совершенно не из-за заботы о "мэйнстримовом программисте" (типа ему это не нужно), а из-за банальной нехватки ресурсов. И нынешнее положение дел в лучшем случае позволяет надеятся, что вторая версия языка избавится от многих/некоторых ограничений.
Да брось ты! Разве ты еще не понял, никто не утверждает что язык идеален, это юмор такой был
Что до качества языка, то это определенно на данный момет лучший язык для .NET и один из лучших, что я вообще в своей жизни видел.
Здравствуйте, Алексей П, Вы писали:
АП>Только тем, что нет этой самой библиотеки. Это иногда было бы действительно удобно.
Библиотека все равно будет, только не явная. И это вызвает определенный геморой. Лучше когда все явно и очевидно. Тогда в случае возникновения проблем хотя бы ясно что делать.
Я сейчас как раз работаю над поддежкой автоматического обновления информации о типах при перекомпиляции макросов. Надеюсь получится сделать это максимально прозрачно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ie, Вы писали:
CU>>P.S. К чему я это всё? Да я всё пытаюсь добится от "апологетов" согласия с тем, что один язык не то что не идеален, но таки совершенно не смог вобрать в себя все известные достижения из области языкостроения, причём совершенно не из-за заботы о "мэйнстримовом программисте" (типа ему это не нужно), а из-за банальной нехватки ресурсов. И нынешнее положение дел в лучшем случае позволяет надеятся, что вторая версия языка избавится от многих/некоторых ограничений.
ie>Да брось ты! Разве ты еще не понял, никто не утверждает что язык идеален, это юмор такой был
Да и я уже не о первом сообщении, а вот как-раз о следующем:
ie>Что до качества языка, то это определенно на данный момет лучший язык для .NET и один из лучших, что я вообще в своей жизни видел.
вот если бы ты к своей фразе добавил "один из лучших языков общего назначения" — я бы согласился
"Оказывается, с вами иногда даже очень приятно и полезно побеседовать." Шутка!
Здравствуйте, VladD2, Вы писали:
CU>>Авторы ведь знакомились с подобной технологией
VD>Авторы много с чем знакомились. И обосновали свой выбор. Потому я и говорю, что согласен с ним.
Вот именно такие слова меня и настораживают — авторы сознательно ввели такие ограничения, потому что _решили_, что что писать программы лучше именно так, или авторы сознательно пошли на такие ограничения учитывая ограниченность своих ресурсов для реализации данных возможностей? В ваших словах я слышу второе, и это меня "озадачивает". В чём же вы видите тогда перспективу развития языка (не реализации)? Или он сформирован окончательно и бесповоротно? Но тогда он мёртв...
CU>>Я не вижу/не понимаю, почему прекомпилированность макр налогает ограничение невозможности в одном файле/блоке кода сначала откомпилировать макры, а потом остальной код при следующем проходе?
VD>Хотя бы потому что это не разумно (хотя технически реализуемо). Неразумно по причине усложнения поддержки.
Т.е. таки _только_ ограниченность ресурсов (и на поддержку и сопровождение в т.ч.)?
CU>>Спасибо, но я не об этом. Если объявление def... and... позволяет обойти огрничение видимости, то почему не сделать такое поведение "по умолчанию" для любого def...?
VD>Потому что and подразумевает, что между предыдущей функций и этой нет никакого кода на который можно замкнуться. VD>Хотя потенциально конечно можно было бы разрешить использвать идующую дальше фукнцию если она идет срауз (не отделена другими объявлениями).
А если таких функций несколько (аналог def... and... and... and...) с непростым порядком взаимовызовов? И чем могут помешать другие объявления?
VD>Но это пришлось бы отдельно объяснять.
один фиг надо объяснять порядок объявления и использования функций — что так, что этак.
VD>В прочем можшь предложить это разраотчикам языка (в конференци). Посмотрим что они скажут.
Мой интерес к языку ещё не дорос до такой степени
CU>>P.S. К чему я это всё? Да я всё пытаюсь добится от "апологетов" согласия с тем, что один язык не то что не идеален, но таки совершенно не смог вобрать в себя все известные достижения из области языкостроения, причём совершенно не из-за заботы о "мэйнстримовом программисте" (типа ему это не нужно), а из-за банальной нехватки ресурсов. И нынешнее положение дел в лучшем случае позволяет надеятся, что вторая версия языка избавится от многих/некоторых ограничений.
VD>Пока что ты демонсррируешь докапывание к неваждым мелочам.
Хм, это ваша оценка моих слов. Надеюсь, вы не претендуете на абсолютную истину? Мне это не кажется такими уж мелочами.
VD>Я могу таких еще с десяток привести. Темоблее если речь идет о прирципиальном выборе альтернативы.
Альтернативы чего? Языков? Так "совершенство" языка — не повод не совершенствовать его дальше. Альтернативы возможностей? Так здесь просто — возможность или есть, или её нет
VD>Однакто качество языка определяется не этим. Оно скорее определяется колечеством полезных свойств, их сбалансированностью и интуитивностью.
— "определяется колечеством полезных свойств"
— " их сбалансированностью" — всегда есть свобода выбора: использовать возможность или нет (конечно если возможность есть)
— " интуитивностью" — это при наличии определённого багажа знаний, который и будет определять "интуитивно/нет" — т.е. критерий весьма субъективный. Если обучение происходит "с чистого листа", то проблема практически отсутствует.
CU>>P.P.S. К чему был этот "P.S."? Я всё пытаюсь ответить на первое сообщение : ребята, смелее признавайте имеющиеся недостатки в языке (а отсутсвие той или иной возможности — именно недостаток, недостаток этой самой возможности),
VD>Это совсем не так. Избыток ненужных "достоинств" — это недостатко. Одно из достоинств языка — это простота использования. По этому лепить в язык все что приходит на ум просто нельзя.
Это смотря с какой т.з. смотреть: ты видишь "упрощение" в _отсутствии_ возможности, я вижу "усложнение" в _присутсвии_ ограничения. С моей т.з. добавление некоторых возможностей сделало бы язык проще.
VD>Есть приципиашьные фичи. Ну, там поддеркжа функций как первокасных сущностей, ООП, паттернм-матчинг и т.п. Они важны и конечно их наличие определяет возможность использовать тот или иной стиль прогарммирования. А вот детали реализации уже более тонкая субстанция. Тут уже нельзя сказать вот так вот хорошо, а вот так плохо. Детали уже надо рассматривать в общей картике.
Согласен, но:
VD>Важно не их количество, а их сбаланстированность и не противоричивость.
к такому выводу совсем не могу придти, ибо "интуитивно" не понимаю (в отношении высказанных мною "фич") как оценить эти самые "их сбаланстированность и не противоричивость"
VD>По-моему, вопрос должен ставиться так. Фича полезна если она интуитивно понятана и полезна на практике.
Опять-же, я бы опустил интуицию. Скорее можно говорить о "форме" реализации фичи — более/менее удобной для того или другого.
VD>Отсюда следствия: VD>1. Лучше не добалвять в язык что-то что пийдется долго объяснять. Это слишком субъективно. И таки цена фичи может оправдывать её сложность VD>2. Если что-то приходится объяснять, то это что-то лучше поправить. ну да, если _форму_ фичи можно упростить — лучше упростить (упростить для _человека_, для компилятора — лучше не надо ) VD>3. Если фича не используется основным количеством народа, то ее лучше удалить. Очень спорный момент. А если возможность по другому не реализовать никак/очень сложно, но она действительно редко используется?
По мне, единственное ограничение на включение фичи, дающей некоторую выгоду, не противоречящей общей концепции языка, — это затраты на её реализацию.
CU>>причём я именно о языке, а не о его реализации (т.е. проблемы релиза, документации, багов и прочего не в счёт) — "и люди к вам потянутся" Да, ряд недостатков может быть принципиальным и непреодолимым. Так просто признайте, что этот ряд есть, по возможности максимально точно его описав, а не уговаривайте окружающих, что эти возможности нафиг никому не нужны.
VD>Дык так и есть. Просто почему-то большинство как раз говорит о том, что никому не нужно, а не о том, что явлется проблемой.
"большинство как раз говорит о том, что никому не нужно" — это 5!
У каждого свё виденье проблем и своя оценка их важности.
VD>Лично я вижу некоторые проблемы, но они скрее являются слествием реалазации на базе дотнета и по сути являются данью бесшевной поддержки компонетной технологии (и в принципе обходятся макросами).
И никаких других фич тебе не надо, более того — ты ничего более и не желаешь видеть в языке?
Здравствуйте, cl-user, Вы писали:
CU>P.P.S. К чему был этот "P.S."? Я всё пытаюсь ответить на первое сообщение : ребята, смелее признавайте имеющиеся недостатки в языке (а отсутсвие той или иной возможности — именно недостаток, недостаток этой самой возможности), причём я именно о языке, а не о его реализации (т.е. проблемы релиза, документации, багов и прочего не в счёт) — "и люди к вам потянутся"
Да, у Nemerle есть недостатки. И он — не идеальный язык.
Здравствуйте, cl-user, Вы писали:
VD>>Авторы много с чем знакомились. И обосновали свой выбор. Потому я и говорю, что согласен с ним.
CU>Вот именно такие слова меня и настораживают — авторы сознательно ввели такие ограничения, потому что _решили_, что что писать программы лучше именно так, или авторы сознательно пошли на такие ограничения учитывая ограниченность своих ресурсов для реализации данных возможностей?
Скажи, ты занимался дизайном ЯП?
А вообще дизайном софта?
В курсе, что в большинстве случаев ты обязан выбирать между противоречащими решениями.
Скажем, если ты предпочел динамическую типизацию, то ты не можшь выбрать статическую. Или если ты предпочел поддеркжу перегрузки и привдеений типов, то уже не можешь использовать систему типов Хиндли-Миллера (и наоборот).
CU>В ваших словах я слышу второе, и это меня "озадачивает".
В моих словах ты слышишь звон (с). Ты их просто не хочешь понять.
VD>>Хотя бы потому что это не разумно (хотя технически реализуемо). Неразумно по причине усложнения поддержки.
CU>Т.е. таки _только_ ограниченность ресурсов (и на поддержку и сопровождение в т.ч.)?
Ага. Реусрсов. Но не разработчиков языка, а его пользователя.
CU>А если таких функций несколько (аналог def... and... and... and...) с непростым порядком взаимовызовов?
Какая разница сколько их?
CU> И чем могут помешать другие объявления?
Еще раз прочитай, что я написал. Ключевое слово "замынания".
VD>>Но это пришлось бы отдельно объяснять.
CU>один фиг надо объяснять порядок объявления и использования функций — что так, что этак.
Ты первый кому это понадобилось объяснять. И то скорее докапался нежели реально не понял.
VD>>В прочем можшь предложить это разраотчикам языка (в конференци). Посмотрим что они скажут.
CU>Мой интерес к языку ещё не дорос до такой степени
Здачи подожди пока вырастет.
CU>Хм, это ваша оценка моих слов. Надеюсь, вы не претендуете на абсолютную истину? Мне это не кажется такими уж мелочами.
Кстати, а нельзя ли на "ты" или уж тогда писать "Ваши" с большой боквы. А то я тут вроде один.
VD>>Я могу таких еще с десяток привести. Темоблее если речь идет о прирципиальном выборе альтернативы.
CU>Альтернативы чего? Языков?
Альтернативы дизайна тех или инх фич.
VD>>Однакто качество языка определяется не этим. Оно скорее определяется колечеством полезных свойств, их сбалансированностью и интуитивностью.
CU>- "определяется колечеством полезных свойств" CU>- " их сбалансированностью" — всегда есть свобода выбора: использовать возможность или нет (конечно если возможность есть) CU>- " интуитивностью" — это при наличии определённого багажа знаний, который и будет определять "интуитивно/нет" — т.е. критерий весьма субъективный. Если обучение происходит "с чистого листа", то проблема практически отсутствует.
Что я могу сказать. Это твое мение. Я свое уже сказал. Могу только добавить, что интуитивностья я ценю превыше всего. Если в зяыке нужно много заучивать наизусть, то — это плохой язык. Все должно казаться логичным и непротиворечивым.
CU>Это смотря с какой т.з. смотреть: ты видишь "упрощение" в _отсутствии_ возможности, я вижу "усложнение" в _присутсвии_ ограничения. С моей т.з. добавление некоторых возможностей сделало бы язык проще.
Ну, что я могу сказть. Создай свой язык. Предъяви его на суд общественности и поглядим что получится. Пока что я могу сказать, что или ты ударился в абстрактные измышления и потому мы не можем прийти к общей точке зрения, или твои приципы дизайна являются крайне порочными. Это конечно на мой взгляд и я могу ошибаться. Но вот такое у меня ощущение.
CU>к такому выводу совсем не могу придти, ибо "интуитивно" не понимаю (в отношении высказанных мною "фич") как оценить эти самые "их сбаланстированность и не противоричивость"
Ну, что я могу поделать. Миллионы людей чего-то не понимают и живут с этим.
CU>Опять-же, я бы опустил интуицию.
Твои проблемы. А я бы опустил все остальное, а ее оставил бы.
CU> Скорее можно говорить о "форме" реализации фичи — более/менее удобной для того или другого.
Чего "того"? Чего "иного"? Важно чтобы люди (в массе своей) смотря на участок кода понимали его. И чтобы они не ошибались только потмоу, что интуиция им подсказала одно, а реально все оказалось совсем не так.
CU>По мне, единственное ограничение на включение фичи, дающей некоторую выгоду, не противоречящей общей концепции языка, — это затраты на её реализацию.
Вот затраты на реализацию должно быть последним аргументом. А полезность и понятность первыми.
Ладно. Мне это уже надоело. Ну, не согласен ты со мной и ладно. О чем спорить то?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, cl-user, Вы писали:
ie>>Что до качества языка, то это определенно на данный момет лучший язык для .NET и один из лучших, что я вообще в своей жизни видел. CU>вот если бы ты к своей фразе добавил "один из лучших языков общего назначения" — я бы согласился
Здравствуйте, VladD2, Вы писали:
VD>>>Авторы много с чем знакомились. И обосновали свой выбор. Потому я и говорю, что согласен с ним.
VD>В курсе, что в большинстве случаев ты обязан выбирать между противоречащими решениями. VD>Скажем, если ты предпочел динамическую типизацию, то ты не можшь выбрать статическую. Или если ты предпочел поддеркжу перегрузки и привдеений типов, то уже не можешь использовать систему типов Хиндли-Миллера (и наоборот).
Так ведь нет "непреодолимых противоречий" для реализации оговренных фич?
VD>В моих словах ты слышишь звон (с). Ты их просто не хочешь понять.
Да слова то как раз понятны — далше некуда.
VD>>>Хотя бы потому что это не разумно (хотя технически реализуемо). Неразумно по причине усложнения поддержки.
Упрощение поддержки может вернуть нас в каменный век. Ладно, не хотите реализовывать — не надо. Но только не говорите тогда, что этих фич нет "по причине их ненужности". Сказали бы сразу: это трудно реализовать, ещё труднее поддерживать — я бы сразу успоколися. Или пошёл бы искать ресурся для реализации
CU>>Т.е. таки _только_ ограниченность ресурсов (и на поддержку и сопровождение в т.ч.)?
VD>Ага. Реусрсов. Но не разработчиков языка, а его пользователя.
Извини, здесь не понял.
VD>Еще раз прочитай, что я написал. Ключевое слово "замынания".
Тем более! Ладно, если это действительно анахронизм из окамла — так и запишем.
CU>>один фиг надо объяснять порядок объявления и использования функций — что так, что этак.
VD>Ты первый кому это понадобилось объяснять. И то скорее докапался нежели реально не понял.
Не перескакивай! Язык незнающему его всё равно объяснять надо. Так какая разница что объяснять?
VD>Кстати, а нельзя ли на "ты" или уж тогда писать "Ваши" с большой боквы. А то я тут вроде один.
Можно и на "ты" — проблем нет. Мои "вы" — не более чем игра слов.
VD>Альтернативы дизайна тех или инх фич.
Дык нету некоторых фич — какой к собакам дизайн?
VD>Что я могу сказать. Это твое мение. Я свое уже сказал. Могу только добавить, что интуитивностья я ценю превыше всего. Если в зяыке нужно много заучивать наизусть, то — это плохой язык. Все должно казаться логичным и непротиворечивым.
Ещё раз: интуиция — это следствие "багажа имеющихся знаний". У тебя это багаж большой. У меня он просто совсем другой. У кого-то его вовсе нет. Почему все должны равнятся под твой жизненный опыт?
VD>Ну, что я могу сказть. Создай свой язык. Предъяви его на суд общественности и поглядим что получится.
Да мне и этот очень нравится. Но я хочу ,чтобы он стал ещё лучше.
VD>Пока что я могу сказать, что или ты ударился в абстрактные измышления и потому мы не можем прийти к общей точке зрения, или твои приципы дизайна являются крайне порочными. Это конечно на мой взгляд и я могу ошибаться. Но вот такое у меня ощущение.
"Абстрактные измышления" — это уже следствие попытки доказать, что пара фич очень даже не помешала бы. Но меня не слышат — говорят, что очень даже помешает...
VD>Твои проблемы. А я бы опустил все остальное, а ее оставил бы.
Я уже сказал — это слишком субъективно.
VD>Чего "того"? Чего "иного"? Важно чтобы люди (в массе своей) смотря на участок кода понимали его. И чтобы они не ошибались только потмоу, что интуиция им подсказала одно, а реально все оказалось совсем не так.
Если люди никогда не видили с++, С# — интуиция им ничем не поможет! Язык таки надо учить и знать!
VD>Вот затраты на реализацию должно быть последним аргументом. А полезность и понятность первыми.
Так по мне и полехность и понятность очевидны пары фич
VD>Ладно. Мне это уже надоело. Ну, не согласен ты со мной и ладно. О чем спорить то?
Да я не спорю. Я лишь сказал — мне бы ещё вот того и вот этого... Мне же не сказали — не, нам влом делать, делай сам если хочешь, ну или найми кого... Меня стали убеждать, что я хочу полную х%&ню и нормальный человек такого хотеть не может. Вот с этим я стал спорить...
Здравствуйте, ie, Вы писали:
ie>>>Что до качества языка, то это определенно на данный момет лучший язык для .NET и один из лучших, что я вообще в своей жизни видел. CU>>вот если бы ты к своей фразе добавил "один из лучших языков общего назначения" — я бы согласился
ie>Это по дефолту
Хм, так по такому "дефолту" получится "нет ОS кроме MS, нет браузера кроме IE" и т.д., вплоть до "нет языка кроме N". Нет, конечно, люди имеют право даже на такую т.з. Только она с моей... не совпадает, что-ли
Здравствуйте, cl-user, Вы писали:
ie>>Это по дефолту CU>Хм, так по такому "дефолту" получится "нет ОS кроме MS, нет браузера кроме IE" и т.д., вплоть до "нет языка кроме N".
Если все утрировать и гиперболизировать, то естсетвенно. А вообще я не понял, что ты хотел этим сказать
CU>Нет, конечно, люди имеют право даже на такую т.з. Только она с моей... не совпадает, что-ли
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, cl-user, Вы писали:
CU>>P.P.S. К чему был этот "P.S."? Я всё пытаюсь ответить на первое сообщение : ребята, смелее признавайте имеющиеся недостатки в языке (а отсутсвие той или иной возможности — именно недостаток, недостаток этой самой возможности), причём я именно о языке, а не о его реализации (т.е. проблемы релиза, документации, багов и прочего не в счёт) — "и люди к вам потянутся"
N>Да, у Nemerle есть недостатки. И он — не идеальный язык.
Но он лучший язык из того что я видел и пробовал...
Здравствуйте, ie, Вы писали:
ie>>>Это по дефолту CU>>Хм, так по такому "дефолту" получится "нет ОS кроме MS, нет браузера кроме IE" и т.д., вплоть до "нет языка кроме N".
ie>Если все утрировать и гиперболизировать, то естсетвенно. А вообще я не понял, что ты хотел этим сказать
Я хотел сказать, что _неописанные_ "дефолты" — это скорее баги (нитерфейса) У каждого свои "дефолты". И многие местные споры сводятся к вопросу "Чьи дефолты правильнее"
Если нам не помогут, то мы тоже никого не пощадим.
— всегда есть свобода выбора: использовать возможность или нет (конечно если возможность есть)
— это при наличии определённого багажа знаний, который и будет определять "интуитивно/нет" — т.е. критерий весьма субъективный. Если обучение происходит "с чистого листа", то проблема практически отсутствует. 
