Здравствуйте, Вася, Вы писали:
BZ>типы в ООП динамические.
Вась, ты не мог бы дать определение термина "динамический тип", и чем он отличается от "статического типа"? Я всегда, понимаешь, держу руку на пульсе и открыт свежим веяниям в computer science. Есть у меня предположения, что ты говоришь о старых добрых "полиморфных переменных"
BZ> секрет успеха ООп именно в том, что он предложил наьбор операций, который похзволяет работать с динамическими, неизвестными в вомент компиляции типами в надёжной, compile-time checked манере.
Это, видимо, очень, очень большой секрет, знает который лишь узкий круг ограниченных лиц.
BZ>а RTTI — это чистая динамика, предоставляющая доступ к остальным операциям, которые в compile-time не проверишь
Да, RTTI — чистая динамика, не имеющая никакого отношения к ООП.
Re[54]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, IT, Вы писали:
ANS>>Спокойнее. Ты уже мог заметить, что решение ограниченное временем компиляции я считаю ущербным "по умолчанию". Так что мимо такой фразы я просто не смог пройти мимо
IT>Так бы сразу и сказал, что макросы суксь.
Я еще не определился
Кстати, в LISP есть макросы, но "время компиляции" может быть и во время выполнения. Такая система мне нравится. Но о пользе и вреде макросов я не говорю.
Здравствуйте, Cyberax, Вы писали:
C>Мне в макросах не нравится то, что мы отлаживаем не саму программу, а ее язык. Мне кажется, что нужны какие-то более глубокие средства интеграции с IDE.
Мета-программа есть мета-программа. Она манипулирвет кодом как данными. Тут дригого ничего ен придуемешь. Макросы просто упрощают эту манипуляцию и предоставляют инструменты декомпозиции кода.
C>SymADE — это движение в этом направлении.
С чего бы это? Из приводимых, разрозненных, примеров лично я вижу, что в SymADE вообще конь не валялся. Мета-программирование (МП) там используется во всю, но таких вещей как квази-цитирование и паттернм матчинг нет и в памине. В итоге приходится манипулировать галимым АСТ средствами Явы. В общем, мрак.
Ты явно не можешь поянть в чем фишка у автора SymADE.
Он во что бы то ни стало хочет отказаться от текста. Думает, что не будеть текста как базового формата хранения, как все стразу в жизни станет просто и красиво. А никаких идей по упрощению МП или заменяющих его в SymADE нет.
C>Еще вспоминается Smalltalk'овские IDE.
Давай. Начинай. Что же там такого чудестного?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[45]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Andrei F., Вы писали:
VD>>"Мы" это кто? Я имею в виду, что ХМЛ для ползователя удобнее, так как он сможет манипулировать с документом во первых как с обычным текстом (хранить его в системах контроля версий, мерджить и т.п.), а во вторых стандартное структурирование поможет выуживать из документов нужную информацию не прибегая к пропроитарным АПИ, а так же писать собственные редакторы для данных документов (например, резко упрощается создание генераторов отчетов выдающих на выходе воровские файлы).
AF>и опять все сводится к legacy
Где ты увидил это свое "legacy"? А? Тебе же говорят "удбнее для пользователей". Точка.
VD>>Что до скорости загрузки, то на современных компьютерах оверхэд от текстового формата будет небольшой (при качественной реализации), а зипование (применяемое в офисных пакетах) способно даже дать выигрышь по сравнению с бинарными форматами.
AF>не способно, если проектированием бинарного формата занимался не полный дебил.
Значит занимались полные дебилы, потому как это факт. В прочем, у меня другая точка зрения. Просто кто-то говорит не разобравшись и это точно не я.
AF> Хотел бы я посмотреть, как ты будешь сравнивать скорость работы зазипованного XML с database-in-file.
А зачем мне БД если я хочу передать текстовый документ?
AF>То есть главная и единственная проблема — в том, что MS не помогал разрабатывать 3d-party реализации либ для работы со своим форматом?
Нет главная проблема в непрозрачности не текстовых форматов. И нужно иметь очень веские основания, чтобы предпочесть их текствым. В случае с СУБД — это основание есть. В случае с текстовым документом аля Вордовский — нет. В случае с исходниками такого основания нет и подавно. Ну, разве что сложность создания прасера. Но это проблемы разработчика. Пользовтель же выберет самое удобное для себя. И текстовый формат будет одним из приемуществ для него.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[48]: Являются ли макросы свидетельством недостаточной выр
Это некорректный запрос с точки зрения SQL92.
VD>>2. Если в рантайме их задают, значит они есть.
AVK>Выяснение типов в рантайме как раз и есть динамическая типизиция.
Вот только в SQL типы известны еще до выполнения запроса. А это и есть рантайм для SQL.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
VD>>Это прописные истины. Я с ними не спорю. Вот только они не отменяют того факта, что на Хаскеле получаетя другое решение. С другими характеристиками и с другими последствиями.
BZ>а причём тут ваша частная задача? про неё ты можешь говорить что угодно — это твоё право. в целом же generic программирование, как и программирование вообще, требует оптимизации не более чем в 20% случаев
А я не абстрактные задачи решаю, а исключительно частные.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>так вот, в то время как макросы обеспечивают доступ к AST генерируемого кода плюс обычные средства ЯП для манипуляции с ним — templates/generics предоставляют свой собственный набор операций, нацеленный именно на generic программирование,
Не скажу за Хаскель, но для С++ — это не правда. Там "язык" получился соврешенно случайно. Ни на что он не нацелен и решает задачи МП с горем пополам.
BZ> и в этой области они позволяют достигать того же эффекта затратой куда меньших усилий.
Это уже полнейшая лож. Если бы это было так, то никто бы и не стал возиться с макросами. На практике МП на шаблонах С++ выливается в кривейшие решения, изобилующие ужимками и хаками, то и дело преводящие к дичайшему оверхэду и геморою. По сравнению с ними добротная макросистема выглядит просто верхом совершенства и позволяет куда больше.
BZ> сишные темплейты вероятно не позволяют реализовать то, что тебе нужно, но в хаскеле это одна из поппулярных областей исследований и среди хаскеловских систем generic программирования есть достаточно мощные
Ага. Только вот обобщенное программирование по любому будет меньше чем МП. Обобщенное программирование не подразумевает генерацию нового кода. Хаскель конечно преуспел в этой области. Его классы типов несомненно красивое решение, новыше головы не прыгнешь и именно поэтому есть Темплэйт Хаскель.
BZ>подытоживая — речь идёт о том, что задачи generic программирования, которые в C* языках имеют решение только черехз макросы, здесь могут быть рещшены другими средствами, непосредственно отражающими специфику области. вот и всё. макросы, как всегда — универсальный инструмент для реализации всего того, чего ещё нет в языке
Тут не счем спорить. Если впихнуть в язык средства для чего-то то реализовывать это что-то вручную будет не надо (при условии достаточной универсальности и производительности встроенного решения). Но надеюсь никто в здравом уме не будет спорить с тем, что все в язык не впихнуть, с тем, что впихвание усложняет язык и с тем, что не все впихнутые решения оказываются приемлемыми на практике. Так вот макросы и есть средство гибко впихивать в язык то что нужно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[49]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
VD>Где ты увидил это свое "legacy"? А? Тебе же говорят "удбнее для пользователей". Точка.
Там, где ты сказал про системы контроля версий и мерджилки.
AF>> Хотел бы я посмотреть, как ты будешь сравнивать скорость работы зазипованного XML с database-in-file.
VD>А зачем мне БД если я хочу передать текстовый документ?
А какая тебе разница, как пользователю, что там внутри? Берешь файл и передаешь.
VD>Нет главная проблема в непрозрачности не текстовых форматов. И нужно иметь очень веские основания, чтобы предпочесть их текствым. В случае с СУБД — это основание есть. В случае с текстовым документом аля Вордовский — нет. В случае с исходниками такого основания нет и подавно. Ну, разве что сложность создания прасера. Но это проблемы разработчика. Пользовтель же выберет самое удобное для себя. И текстовый формат будет одним из приемуществ для него.
Непрозрачность — это политика МС, а не особенность использованной ими технологии. Разработчиками PNG ничто не помешало сделать формат прозрачным.
Но мы же здесь не о политике говорим?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>так вот, в то время как макросы обеспечивают доступ к AST генерируемого кода плюс обычные средства ЯП для манипуляции с ним — templates/generics предоставляют свой собственный набор операций, нацеленный именно на generic программирование,
VD>Не скажу за Хаскель, но для С++ — это не правда. Там "язык" получился соврешенно случайно. Ни на что он не нацелен и решает задачи МП с горем пополам.
язык там менее мощный, но в пределах своих возможностей он задачи решает. скажем, на нём нетрудно запрограммировать сериализацию, есдли задаться ограниченным набором типов и конструкторов типов
BZ>> и в этой области они позволяют достигать того же эффекта затратой куда меньших усилий.
VD>Это уже полнейшая лож. Если бы это было так, то никто бы и не стал возиться с макросами.
в хаскеле макросами и не пользуются — считается, дурной тон
BZ>> сишные темплейты вероятно не позволяют реализовать то, что тебе нужно, но в хаскеле это одна из поппулярных областей исследований и среди хаскеловских систем generic программирования есть достаточно мощные
VD>Ага. Только вот обобщенное программирование по любому будет меньше чем МП. Обобщенное программирование не подразумевает генерацию нового кода. Хаскель конечно преуспел в этой области. Его классы типов несомненно красивое решение, новыше головы не прыгнешь и именно поэтому есть Темплэйт Хаскель.
type classes — это не generic, а polymorhic programming. я уже многоркатно говорил, что здесь ижёт терминологическая путаница. generic programming — это операции типа gmap или gfold, позволяющие сгенерить операции отображения или скажем сериализации для сколь угодно сложного типа
Люди, я люблю вас! Будьте бдительны!!!
Re[45]: Являются ли макросы свидетельством недостаточной выр
VladD2 wrote: > C>Мне в макросах не нравится то, что мы отлаживаем не саму программу, а > ее язык. Мне кажется, что нужны какие-то более глубокие средства > интеграции с IDE. > Мета-программа есть мета-программа. Она манипулирвет кодом как данными.
Именно это мне и не нравится.
> Тут дригого ничего ен придуемешь. Макросы просто упрощают эту > манипуляцию и предоставляют инструменты декомпозиции кода.
Мне почему-то кажется, что манипуляции с кодом должна делать IDE.
Проще всего на примере показать. В Java для организации событий
используется вот такой жуткий паттерн:
public class Something
{
int anything;
Set<PropertyChangeListener> listeners=new
HashSet<PropertyChangeListener>();
int getAnything()
{
return anything;
}
void setAnything(int anything)
{
if (this.anything!=anything)
{
fireEvents(listeners,new PropertyChangeEvent(...));
this.anything=anything;
}
}
};
Класс с кучей таких свойств — это жуткое, душераздирающее зрелище. Можно
банально решить эту проблему с помощью макроса, который будет
разворачиваться в нужный код.
А можно решить эту проблему с помощью IDE, которая вместо этого жуткого
кода будет показывать что-нибудь типа "[+] PropertyWithEvents int
anything;" (при нажатии [+] — разворачиваем тело).
Еще один пример — regexp'ы в языке. Можно сделать кучу сложных макросов,
похожих по синтаксису на regexp'ы (причем полностью повторить синтаксис
скорее всего не получится), а можно просто научить IDE определять
литералы, в которых есть regexp'ы.
Такой подход, несомненно, менее мощный, чем полноценные макросы. Однако,
он намного более индус-friendly. Кроме того, нам для него не требуется
[большого] изменения языка (Java или C#), а достаточно изменения IDE.
Причем возможно эволюционное развитие.
Мне еще этот подход кажется более естественным, что ли. Но это мое
субъективное мнение.
> C>SymADE — это движение в этом направлении. > С чего бы это? Из приводимых, разрозненных, примеров лично я вижу, что в > SymADE вообще конь не валялся.
Так поэтому это даже не "шаг", а просто "движение"
Надо как-то заставить IDE понимать больше в семантике кода.
> Ты явно не можешь поянть в чем фишка у автора SymADE. > Он во что бы то ни стало хочет отказаться от текста.
Да это понятно тупиковая идея — лучше текста ничего не придумали для
работы с кодом (т.е. для написания кода).
> C>Еще вспоминается Smalltalk'овские IDE. > Давай. Начинай. Что же там такого чудестного?
Программа по сути может представлять из себя "слепок" состояния
программы + IDE. Интерсный подход.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[48]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, AndrewVK, Вы писали:
Вкратце: тип результата case однозначно определяется по типу операндов, приоритет у строки, дальше идут числа и даты. AVK>Выяснение типов в рантайме как раз и есть динамическая типизиция.
Никакой динамики там нет. К моменту выполнения запроса все типы, включая тип результата case, известны.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[46]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Cyberax, Вы писали: C>Класс с кучей таких свойств — это жуткое, душераздирающее зрелище. Можно C>банально решить эту проблему с помощью макроса, который будет C>разворачиваться в нужный код.
Здравствуйте, Cyberax, Вы писали:
C>Мне еще этот подход кажется более естественным, что ли. Но это мое субъективное мнение.
Именно что индус-friendly. В чистом виде копипейст со всеми вытекающими. Что если выяснится, что код твоего паттерна, к примеру, не multithreaded? Выискивать и выправлять все места? А если индусы там уже своих козявок понадобавляли?
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[47]: Являются ли макросы свидетельством недостаточной выр
IT wrote: > C>Мне еще этот подход кажется более естественным, что ли. Но это мое > субъективное мнение. > Именно что индус-friendly. В чистом виде копипейст со всеми вытекающими. > Что если выяснится, что код твоего паттерна, к примеру, не > multithreaded?
Использовать средства рефакторинга IDE, с массовой заменой кода паттерна.
> Выискивать и выправлять все места? А если индусы там уже > своих козявок понадобавляли?
А если выяснится, что твой макрос вынуждает клиента быть unthreadsafe?
Здравствуйте, BulatZiganshin, Вы писали:
BZ>type classes — это не generic, а polymorhic programming. я уже многоркатно говорил, что здесь ижёт терминологическая путаница. generic programming — это операции типа gmap или gfold, позволяющие сгенерить операции отображения или скажем сериализации для сколь угодно сложного типа
Только (пока) эти операции в Хаскелле целиком и полностью реализуются на классах типов, которые и обеспечивают "обход" типа.
Здравствуйте, awson, Вы писали:
A>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>type classes — это не generic, а polymorhic programming. я уже многоркатно говорил, что здесь ижёт терминологическая путаница. generic programming — это операции типа gmap или gfold, позволяющие сгенерить операции отображения или скажем сериализации для сколь угодно сложного типа A>Только (пока) эти операции в Хаскелле целиком и полностью реализуются на классах типов, которые и обеспечивают "обход" типа.
откуда у вас столь глубокие познания предмета? из моих же постов, где я объясняю как это можно сделать через type classes. однако это только одна из групп подходов, также используются макросистемы, спец. надстройки над хаскел, RTTI. читайте
Здравствуйте, Cyberax, Вы писали:
C>Использовать средства рефакторинга IDE, с массовой заменой кода паттерна.
Простой заменой дело не обойдётся. Самое плохое в копи-пейсте, что он с каждой копией имеет тенденцию слегка мутировать.
C>А если выяснится, что твой макрос вынуждает клиента быть unthreadsafe?
Значит макрос будет заточен под конкретные нужды без переписывания остального кода.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[49]: Являются ли макросы свидетельством недостаточной выр
IT wrote: > C>Использовать средства рефакторинга IDE, с массовой заменой кода паттерна. > Простой заменой дело не обойдётся. Самое плохое в копи-пейсте, что он с > каждой копией имеет тенденцию слегка мутировать.
В том-то и дело, что ты НЕ делаешь copy-paste. В простейшем варианте ты
пишешь: "[клавиша-модификатор]WithEvents[/клавиша-модификатор]int
anything;". IDE тебе сама все сгенерирует, зафолдит и вообще уберет с
глаз долой.
> C>А если выяснится, что твой макрос вынуждает клиента быть unthreadsafe? > Значит макрос будет заточен под конкретные нужды без переписывания > остального кода.
Что мешает заточить темплейт под нужды кода?
Я всегда, понимаешь, держу руку на пульсе и открыт свежим веяниям в computer science. 
Если нам не помогут, то мы тоже никого не пощадим.
из моих же постов, где я объясняю как это можно сделать через type classes. однако это только одна из групп подходов, также используются макросистемы, спец. надстройки над хаскел, RTTI. читайте