Здравствуйте, Beam, Вы писали:
B>Что неудобно? Использовать try-finally при работе с ресурсами?
Ага. Ужасно неудобно. Потому в C# и Nemerle это делается очень редко. Вместо этого используется using. Знаком с такой конкцепцией?
B>Странные Вы вещи говорите, однако ...
Только для тебя.
B>И возвращаясь к теме. Так что надо делать в Nemerle, чтобы не натыкаться в макросах на продемонстрированные "грабли"?
Использовать юсинг. Макросы тут правда не причем. Это надо делать влюбом коде в не зависимости от того генерируется он или нет.
Выглядит это так:
using (variable = GetSomeLockableResource())
{
UseSomeLockableResource(variable);
} // Здесь ресурс совободится что бы не случилось.
Реализуется это дело переписыванием кода с использованием try/finally, но выглядит куда как понятнее и кратче.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ну, и не надо забывать про то что Немерле многое взял у C# просто с целью быть более понятным для мэйнстрим-программистов которые как раз в основном работают на C#, С++ или Яве.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, IT, Вы писали:
FR>>>Нет после лиспа уже было много вещей которых в нем нет и вряд ли уже будут. FR>>>И вообще пока мейнстрим будет давится и с отрыжками переваривать функциональщину, новое може появится совсем в другом месте
IT>>Например? Из последнего появивщегося мне известно AOP. Но это не имеет отношения к функциональщине.
FR>В лиспе не было вывода типов, ленивости, паттерн матчинга в общем очень многого из того что появилось в новых функциональных языках. Да и вообще лисп не чистый функциональный язык.
Паттерн-мэтчинг прикручивается туда макросами. Как, впрочем, и AOP. Вывод типов ему без надобности, потому что это не статически типизированный язык. Про ленивость ничего не скажу, дабы не соврать ненароком.
Здравствуйте, Сергей Туленцев, Вы писали:
FR>>В лиспе не было вывода типов, ленивости, паттерн матчинга в общем очень многого из того что появилось в новых функциональных языках. Да и вообще лисп не чистый функциональный язык.
СТ>Паттерн-мэтчинг прикручивается туда макросами. Как, впрочем, и AOP. Вывод типов ему без надобности, потому что это не статически типизированный язык. Про ленивость ничего не скажу, дабы не соврать ненароком.
Туда все руками относительно легко прикручивается в том числе и ленивость в виде задержаных вычислений и потоков, вообще туда и чисто императивное программирование также легко прикручивается. Только это не значит что в лиспе было все и даже уже есть то чего еще нет нигде Это просто значит что лисп очень гибкий язык
Re[27]: Не нужность super return (нелок. возврата) [рассм. п
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, FDSC, Вы писали:
FDS>>И что, это намного хуже и сложнее? И наверняка быстрее работает, чем перехват повторно вызывающихся нелокальных возвратов.
ANS>И первый и второй вариант твоей программы не правильные. У тебя и там и там 2 ошибки в коде и 2 ошибки в дизайне. Что на на таких примерах можно продемонстрировать я не понимаю.
Я думаю, в не такой тупой, как компьютер и можете сообразить, что там имелось ввиду. Что касается ошибок, то если вы заявляете, что они есть (они действительно есть), наверное их стоит описывать и показать, что я неправ.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, FR, Вы писали:
FR>>Если я скажу что весь ООП идет от фортрана это будет по твоему верное утверждение?
IT>В контексте обсуждаемого вопроса меня это не интересует.
Зря это же основопологающий вопрос
IT>>>Т.е. прошло 25-35 лет FR>>Ну и?
IT>Ну и что нового могут найти очкарики в функциональном программировании, чтобы начать опять оправдыавть своё ничтожество?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Beam, Вы писали:
B>>Что неудобно? Использовать try-finally при работе с ресурсами?
VD>Ага. Ужасно неудобно. Потому в C# и Nemerle это делается очень редко. Вместо этого используется using. Знаком с такой конкцепцией?
Знаком. Синтаксический сахар.
B>>И возвращаясь к теме. Так что надо делать в Nemerle, чтобы не натыкаться в макросах на продемонстрированные "грабли"?
VD>Использовать юсинг. Макросы тут правда не причем. Это надо делать влюбом коде в не зависимости от того генерируется он или нет.
Да я же говорю про другие грабли Пока что Вы избегаете давать ответ на мой вопрос. Посмотрите предыдущие посты. Вы пытаетесь уйти в сторону от обсуждения проблемы. Давайте не будем говорить о частностях. Смотрите шире.
Пусть у нас есть макрос, с параметром body (код). И пусть этот параметр используется в середине макроса. Т.е. при развертывании макроса получится код:
// выполняем какой-то код 1
// здесь будет код $body
// выполняем какой-то код 2
Если передать в этот макрос код, внутри которого есть return , то код 2 выполнен не будет.
Разве не эту проблему Вы увидели в блоках Smalltalk? Пока что я не услышал вразумительного ответа — все вокруг да около.
Здравствуйте, Klapaucius, Вы писали:
K>Нас мало — понятно, что мы лучше. Правда, тут главное не ошибиться и не оказаться не в том хвосте нормального распределения.
Вот за это отдельное спасибо. Я плакал.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Beam, Вы писали:
B>Разве не эту проблему Вы увидели в блоках Smalltalk? Пока что я не услышал вразумительного ответа — все вокруг да около.
Тут дело в локальности.
В случае с макросом весь код видно, а в случае со Smalltalk блок кода с нелокальным возвратом может уйти куда угодно в том числе попасть в другой поток... вот будут забавные глюки когда один поток неожиданно прирывает другой...0
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Beam, Вы писали:
B>>Разве не эту проблему Вы увидели в блоках Smalltalk? Пока что я не услышал вразумительного ответа — все вокруг да около. WH>Тут дело в локальности. WH>В случае с макросом весь код видно, а в случае со Smalltalk блок кода с нелокальным возвратом может уйти куда угодно в том числе попасть в другой поток... вот будут забавные глюки когда один поток неожиданно прирывает другой...0
А разве что-то может помешать из макроса прихлопнуть другой поток?, я что-то не слышал про такие ограничения.
Можно не цитировать все сообщение?
VD>>Это я к тому, что главное в языке выразительность для программиста.
К>А читать, значит, написанное мы не будем, так?
А как ты понимаешь понятие "выразительность"? Чем оно по-твоему отличается от краткости?
Выразительность и определяет насколько код понятен для человека.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Beam, Вы писали:
B>>Разве не эту проблему Вы увидели в блоках Smalltalk? Пока что я не услышал вразумительного ответа — все вокруг да около. WH>Тут дело в локальности.
Здесь уже говорилось, что возврат управления из блока осуществляется в тот контекст, в котором он был описан. Это и есть та локальность о которой Вы говорите. Но почему-то упоминание об этом и вызвало бурную дискуссию. В общем, все происходит в точности так же как и в макросах Nemerle.
WH>В случае с макросом весь код видно, а в случае со Smalltalk блок кода с нелокальным возвратом может уйти куда угодно в том числе попасть в другой поток... вот будут забавные глюки когда один поток неожиданно прирывает другой...0
В этом случае будет брошено исключение
blockWithReturn := [^28].
process := [:blockToRun | blockToRun value] newProcessWithArguments: (Array with: blockWithReturn).
process resume.
В этом примере создается новый процесс и в него передается параметр — блок, который надо выполнить. Мы передаем блок с возвратом (blockWithReturn), запускаем процесс и ... никаких забавных глюков не происходит, а появлется исключение CannotReturnError (Context cannot return).
Здравствуйте, FR, Вы писали:
FR>>>Так это и есть по существу, ты по сути предложил человеку неверное
IT>>В чём неверность?
FR>В определении по аналогии.
Блин, какая аналогия? Я лишь показал реализацию
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
FDS>Банально
FDS>public static void ForEach<T>(T root, Action<T> action) FDS> where T: IRecursible<T> FDS>{ FDS> action(root); FDS> CRT Child = root.LoadFromDataBaseChildAndLock(); FDS> foreach(T Child in root) FDS>{
FDS> ForEach(Child, action); FDS>} FDS>Child.Unlock(); FDS>} S>>[/c#]
FDS>и уже ошибка
Ниче не понял. Это ты зачем этот бред написал, прошу прощения? Во-первых, это ошибка компиляции. Во вторых, даже если ты ее поправишь, то за такой код можно сразу на выговор в личное дело нарваться. Поясняю:
ForEach — это библиотечный метод. Он пишется ровно один раз и ровно в том виде, в котором я написал. Никаких LoadFromDatabaseChildAndLock в нем не может быть по определению.
Все обращения к базе делаются в рамках реализации IEnumerable в T, а Unlock — в реализации IDisposable того, что возвращается из T.GetEnumerator(). Тогда все будет правильно, независимо от того, super или обычный return применен.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[26]: Не нужность super return (нелок. возврата) [рассм. п
Здравствуйте, Дарней, Вы писали:
ГВ>> Нельзя делать выводы о качественных сторонах продукта по его распространённости. Д>если ты веришь, что тебя окружают одни идиоты и ты один на коне и весь в белом — то нельзя. Как же можно верить мнению идиотов, когда ты — самый умный и знаешь про это. Д>Если же ты более реалистично относишься к своим умственным способностям, то надо понимать, что просто так ничего не получается. И распространенность — в том числе.
1. мдя, вы не романтик
2. очень странно что в мир проходят не самые лучшие творения. и про картошку и про "элиту" тут уже писалось. осталось вспомнить только новомодную попсу. тоже популяна
зы. да, я знаю... но без пространственных аналогий на кывт-е почему-то не флеймят
Здравствуйте, eao197, Вы писали:
E>Так гребут, что вынуждены делать бесплатную версию своей EiffelStudio чтобы привлечь новых разработчиков. E>Лет десять назад у них, вероятно, особых проблем-то и не было. А сейчас, на фоне распространенности Java (которая бесплатно есть на большем количестве платформ, чем Eiffel), агрессивного маркетинга C#, количества библиотек и фреймворков для Java и C#, количества IDE для Java/C#, количества документации/книг/учебных курсов, количества разработчиков, имеющих опыт разработки на Java/C#, перспективы у Eiffel-я, имхо, очень не важные.
Сам язык от этого не страдает. Страдает его популярность, ну и nil с ним.
E>Не зря же Мейер сейчас статейки пишет, что мол дешевые индусы и воссточные славяне оставят без работы дорогих американских разработчиков. Если только последние не возьмутся за ум и не начнут использовать "правильные" инструменты, резко повышающие их (разработчиков то есть)
А индусы вообще всех порвут своей дешевизной. Что хотят, то и творят. Язык тут не при чем.
E> производительность, то хана им. А правильным инструментом, естественно, является Eiffel Methodology + Eiffel Studio. Хотя чем Eiffel сейчас может конкурировать, например, с Java 5 + IDEA (Eclipse) лично я, например, не понимаю.
Навороченность IDE может говорить о негибкости языка. Если они появились — значит, была потребность. Где их нет, то нет и соответствующей потребности.
Если нам не помогут, то мы тоже никого не пощадим.
Посмотрите предыдущие посты. Вы пытаетесь уйти в сторону от обсуждения проблемы. Давайте не будем говорить о частностях. Смотрите шире.
1.1.4 stable rev. 510
Нельзя делать выводы о качественных сторонах продукта по его распространённости.
