NC>Странный подход, написано free, в фиг скачаешь без этого вашего тунца. Как они собираются привлекать разработчиков, не имевших до этого дела с эппл?
Здравствуйте, kleng, Вы писали:
K>Смущает разработчик. Намордник и анальный зонд в комплекте?
Вот не неадо вываливать свои сексуальные фантазии на форум для программистов, их лучше постить на соответствующих ресурсах.
Если же говорить о разработках Apple, то компания является одним из основных (или даже основным) спонсором LLVM и Clang. А эти компиляторы, в отличие от VS бесплатны, а в отличие от GCC идут под куда более гуманной лицензией.
Так что если язык был разработан Apple – это скорее даже плюс. Разве что меня берут сомнения, что он где-либо за пределами Darwin + FreeBSD работать будет
M>>ЗЫ. Помнится, тут многие слбни пускали по поводу какого-то концепта IDE, где выполнение показывалось на ходу. А Apple взяли и реализовали не концепт
A>Мамут, очнись. Для Скалы это сделано в Scala IDE года 3 назад, а год (или чуть меньше) сделано и в ИДЕЕ. A>Вот ИДЕЙное видео A>http://blog.jetbrains.com/scala/2014/05/23/meet-the-new-scala-worksheets-in-intellij-idea/
Прикольно, не знал
M>>
A>Ага, ага. Эппл снова что-то изобрёл на -3 года первее всех.
Здравствуйте, NeoCode, Вы писали:
NC>Странный подход, написано free, в фиг скачаешь без этого вашего тунца. Как они собираются привлекать разработчиков, не имевших до этого дела с эппл?
M>ЗЫ. Помнится, тут многие слбни пускали по поводу какого-то концепта IDE, где выполнение показывалось на ходу.
На самом деле, это скорее ВАУ фича, чем что-либо полезное. Те примеры что есть, скорее всего масксимум возможностей и показывают, а именно простые однопоточные приложения с простой моделью данных.
Здравствуйте, Qbit86, Вы писали:
Q>Это не сексуальные фантазии, а вполне оправданные опасения.
В каком месте они оправданны, если большинство низкоуровневого кода ядра и компиляторы у Apple выпущены под BSD лиензией? Оправданны в сексуальных фантазиях?
M>>ЗЫ. Помнится, тут многие слбни пускали по поводу какого-то концепта IDE, где выполнение показывалось на ходу.
A>На самом деле, это скорее ВАУ фича, чем что-либо полезное. Те примеры что есть, скорее всего масксимум возможностей и показывают, а именно простые однопоточные приложения с простой моделью данных.
Ну, на самом деле я на это дело смотрю, как на приятный расширенный REPL
Здравствуйте, Qbit86, Вы писали:
I>>И самое главное — Сишный синтаксис !
Q>Где ты там увидел сишный синтаксис? В официальном заявлении сказано: «Objective-C without C».
Здравствуйте, Mamut, Вы писали:
A>>На самом деле, это скорее ВАУ фича, чем что-либо полезное. Те примеры что есть, скорее всего масксимум возможностей и показывают, а именно простые однопоточные приложения с простой моделью данных. M>Ну, на самом деле я на это дело смотрю, как на приятный расширенный REPL
Мне вот всегда было интересно зачем REPL нужен...
Здравствуйте, Ikemefula, Вы писали:
I>Apple родила язык.
Спасибо, Эппл, что не iGO.
I>Вывод типов
Это скорее реконструкция типов.
I>паттерн-матчинг,
Насколько я понял, он "плоский", Т.е. [Just a,_] не сматчит. Привет 60-е, короче говоря.
Да и синтаксис у него, конечно, тот еще:
enum ServerResponse {
case Result(String, String)
case Error(String)
}
let success = ServerResponse.Result("6:00 am", "8:09 pm")
let failure = ServerResponse.Error("Out of cheese.")
switch success {
case let .Result(sunrise, sunset):
let serverResponse = "Sunrise is at \(sunrise) and sunset is at \(sunset)."case let .Error(error):
let serverResponse = "Failure... \(error)"
}
I>замыкания,
Это без ГЦ на одном подсчете ссылок? Ну ну.
I>дженерики,
Только вот от конструктора абстрагироваться-то как обычно нельзя.
I>'монадический' optional
Который, как я понял, автораспаковывается.
I>Если будет внятный GC,
А его хотя-бы обещают?
I>то это лучше C#, Джавы и С++ вместе взятых.
Тоже мне бином Ньютона. Чтоб хуже сделать — это специально постараться нужно, как Гуглу.
I>Но судя по набору фич язык сильно близко подобрался к Scala и F#
Он объединяет в себе недостатки этих языков: убогую систему типов F#-а c убогим Scala-синтаксисом.
I>И самое главное — Сишный синтаксис !
Как будто это что-то хорошее! Синтаксис не сишный, немного получше, но не сильно.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
A>>>На самом деле, это скорее ВАУ фича, чем что-либо полезное. Те примеры что есть, скорее всего масксимум возможностей и показывают, а именно простые однопоточные приложения с простой моделью данных. M>>Ну, на самом деле я на это дело смотрю, как на приятный расширенный REPL C>Мне вот всегда было интересно зачем REPL нужен...
Это очень удобный инструмент. Как для быстрого прототипирования и проверки некоторых идей, так и для быстрого тестирования некоторых вещей
Здравствуйте, Mamut, Вы писали:
M>>>Ну, на самом деле я на это дело смотрю, как на приятный расширенный REPL C>>Мне вот всегда было интересно зачем REPL нужен... M>Это очень удобный инструмент. Как для быстрого прототипирования и проверки некоторых идей, так и для быстрого тестирования некоторых вещей
Ну так берёшь, создаёшь файлик и туда записываешь (с автокомплитом и всеми прочими плюшками) нужный код. Потом с отладчиком выполняешь, они нынче умные и позволяют удобно инспектировать код.
Здравствуйте, Cyberax, Вы писали:
C>Мне вот всегда было интересно зачем REPL нужен...
Нужен для экспериментирования с кодом. Просто это подходит только для языков где небольшой снипет кода что-то нетривиальное делает без трудновоспроизводимого окружения, вроде функциональных языков, либо в тех, где это самое окружение легко сохранять, вроде лиспов и смолтоков.
Во всяких C/Java он в основном бесполезен. также очень легко сделать неюзабельный REPL "для галочки", как в F#.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
M>>>>Ну, на самом деле я на это дело смотрю, как на приятный расширенный REPL C>>>Мне вот всегда было интересно зачем REPL нужен... M>>Это очень удобный инструмент. Как для быстрого прототипирования и проверки некоторых идей, так и для быстрого тестирования некоторых вещей C>Ну так берёшь, создаёшь файлик и туда записываешь (с автокомплитом и всеми прочими плюшками) нужный код. Потом с отладчиком выполняешь, они нынче умные и позволяют удобно инспектировать код.
1. Зачем, если ты имеешь тот же автокомплит (и часто отладчик) прямо из REPL'а?
2. Для большинства языков, чтобы что-то выполнить, нужно написать толпу обвязки вокруг (все эти main'ы, вызовы и прочее), когда надо быстро проверить пару идей?
Здравствуйте, Klapaucius, Вы писали:
K>Насколько я понял, он "плоский", Т.е. [Just a,_] не сматчит. Привет 60-е, короче говоря.
90е и 2000 это Java и C#, в которых еще более примитивный switch
K>Да и синтаксис у него, конечно, тот еще:
Да, не такой, как в Хаскеле
I>>И самое главное — Сишный синтаксис !
K>Как будто это что-то хорошее! Синтаксис не сишный, немного получше, но не сильно.
Именно. Для 90% разрабов, которые только и имеют дело с сишным синтаксисом, это очень круто.
Здравствуйте, Mamut, Вы писали:
C>>Ну так берёшь, создаёшь файлик и туда записываешь (с автокомплитом и всеми прочими плюшками) нужный код. Потом с отладчиком выполняешь, они нынче умные и позволяют удобно инспектировать код. M>1. Зачем, если ты имеешь тот же автокомплит (и часто отладчик) прямо из REPL'а?
Не везде они есть.
M>2. Для большинства языков, чтобы что-то выполнить, нужно написать толпу обвязки вокруг (все эти main'ы, вызовы и прочее), когда надо быстро проверить пару идей?
А идеи без обвязки будут работать?
Здравствуйте, Klapaucius, Вы писали:
C>>Мне вот всегда было интересно зачем REPL нужен... K>Нужен для экспериментирования с кодом. Просто это подходит только для языков где небольшой снипет кода что-то нетривиальное делает без трудновоспроизводимого окружения, вроде функциональных языков, либо в тех, где это самое окружение легко сохранять, вроде лиспов и смолтоков.
Ну то есть, как замена удобному отладчику.
M>>2. Для большинства языков, чтобы что-то выполнить, нужно написать толпу обвязки вокруг (все эти main'ы, вызовы и прочее), когда надо быстро проверить пару идей? C>А идеи без обвязки будут работать?
Зависит от идеи
В C/C++/Java/C# ты даже строчку кода не можешь запустить без main'а
А мне надо сейчас баг решать, с разными вводными данными (небольшим количеством). Прямо в шелле:
Все, во втором окне запускаю curl для проверки резульатов (проверяем выхлоп REST API на некотором наборе данных, не можем воспроизвести ситуацию из бага).
При этом я тут же могу сделать стопятьсот других полезных вещей
Убило использование подсчета ссылок без автоматического разруливания за зацикливаний. В 21 веке это выглядит дико. Такому языку нужен GC или хотя бы автоматический поиск зацикливаний, как в Руби.
С экстернал-параметрами какой-то овердизайн. Плюс, похоже, перегрузки возможны только для функций с этими самыми экстернал-параметрами.
Чисто стилистически не понравилась утащенная из GO идея не писать круглые скобки, но всегда писать фигурные.
Плохо, что не поддерживается концепция "все является выражением".
Странно выглядит отсутствие приватных членов в классах (можно я чего-то не заметил?).
В остальном язык ничего. Во многом похож на Немерл.
Из присутствующего в нем и отсутствующего в Немерле можно выделить именованные кортежи в качестве возвращаемых значений функций и диапазоны в паттернах. Хотя не ясно можно ли задавать границы диапазонов переменными.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mamut, Вы писали:
M>многие слбни пускали по поводу какого-то концепта IDE, где выполнение показывалось на ходу. А Apple взяли и реализовали не концепт
О чем речь? Можно по подробнее?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mamut, Вы писали:
M>Ну, на самом деле я на это дело смотрю, как на приятный расширенный REPL
Только на практике репл годится только для поиграться. В больших приложениях нужны более серьёзные средства отладки и управления проектами. В Немерле репл сдох за ненадобностью.
Правильным подходом было бы встроить репл в отладчик. Остановился по точке останова и поигрался с данными с помощью локального репла. Ну, а еще правильнее чтобы можно было код править на лету, как в скриптах. У МС есть Edit & Continue, но слишком много ограничений.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kaa.python, Вы писали:
KP>Если же говорить о разработках Apple, то компания является одним из основных (или даже основным) спонсором LLVM и Clang.
Ключевые слова — спонсор, и "один из". Не владельцы проекта.
Здравствуйте, VladD2, Вы писали:
VD>Убило использование подсчета ссылок без автоматического разруливания за зацикливаний. В 21 веке это выглядит дико. Такому языку нужен GC или хотя бы автоматический поиск зацикливаний, как в Руби.
Как в Питоне, наверное. В Руби испокон веков был честный mark & sweep, никакого RC.
В свифте они целились на рантайм-совместимость с Obj-C, а там тот же самый ARC. Трудно было бы добавить честный GC в один язык, не добавив в другой. Ну и скорее всего это дело принципа: обеспечить иллюзию детерминированности и какбы отсутствие тормозов GC, шоб андроид не получился.
M>>Ну, на самом деле я на это дело смотрю, как на приятный расширенный REPL
VD>Только на практике репл годится только для поиграться. В больших приложениях нужны более серьёзные средства отладки и управления проектами. В Немерле репл сдох за ненадобностью.
Правильно. Что надо сделать? Придумать за оппонента тезис, мол, REPL заменяет какие-то там средства отладки и т.п. И давай — шашку наголо и бороться с этим тезисом. Про Немерле смешно, да.
Здравствуйте, Mamut, Вы писали:
M>Правильно. Что надо сделать? Придумать за оппонента тезис, мол, REPL заменяет какие-то там средства отладки и т.п. И давай — шашку наголо и бороться с этим тезисом. Про Немерле смешно, да.
Я ничего не придумывал. Просто сказал, что он особо не нужен на практике.
M>Вот у нас большое приложение. Общее количество кода около миллиона строчек. Ничего, в разработке и REPL применяется, и «более серьёзные средства отладки».
Да, сдох. И единственная причина — не нужен никому на практике. Был бы нужен давно реанимировали. За все время вопрос о нем поднимался ровно один раз и успешно заглох.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
M>>Правильно. Что надо сделать? Придумать за оппонента тезис, мол, REPL заменяет какие-то там средства отладки и т.п. И давай — шашку наголо и бороться с этим тезисом. Про Немерле смешно, да.
VD>Я ничего не придумывал. Просто сказал, что он особо не нужен на практике.
Извини, но вот это:
Только на практике репл годится только для поиграться. В больших приложениях нужны более серьёзные средства отладки и управления проектами.
это именно придумывание.
M>>Вот у нас большое приложение. Общее количество кода около миллиона строчек. Ничего, в разработке и REPL применяется, и «более серьёзные средства отладки».
VD>Ну, расскажи как вы там репл в большом приложении применяете.
Здравствуйте, VladD2, Вы писали:
M>>Правильно. Что надо сделать? Придумать за оппонента тезис, мол, REPL заменяет какие-то там средства отладки и т.п. И давай — шашку наголо и бороться с этим тезисом. Про Немерле смешно, да.
VD>Я ничего не придумывал. Просто сказал, что он особо не нужен на практике.
M>>Вот у нас большое приложение. Общее количество кода около миллиона строчек. Ничего, в разработке и REPL применяется, и «более серьёзные средства отладки».
VD>Ну, расскажи как вы там репл в большом приложении применяете.
ставишь бряк куда надо, а там тупо вызываешь функции как хочешь. вместо перезапуска всего приложения ты можешь попробовать на лету пару вариантов и готовый результат перенести в код.
Вероятно оттого, что всё кругом на макросах а ни серверных приложений, ни мобильных не пишется.
Прикинь, как круто — на каждый мелкий бажок создаешь инсталяционный пекадж, инсталируешь, запускаешь, ждёшь, прогоняешь всю цепочку и все это для того, что бы выяснить ,что в путях потерялся один из компонетов.
Здравствуйте, Mamut, Вы писали:
M>2. Для большинства языков, чтобы что-то выполнить, нужно написать толпу обвязки вокруг (все эти main'ы, вызовы и прочее)
Большинство языков давно обзавелись фреймворками для юнит-тестирования и тест-раннерами в составе IDE.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
M>>2. Для большинства языков, чтобы что-то выполнить, нужно написать толпу обвязки вокруг (все эти main'ы, вызовы и прочее) AVK>Большинство языков давно обзавелись фреймворками для юнит-тестирования и тест-раннерами в составе IDE.
M>>В C/C++/Java/C# ты даже строчку кода не можешь запустить без main'а AVK>Конечно конечно. Я вот проект уже несколько месяцев пишу, а в нем, прикинь, ни одного мейна.
M>>>2. Для большинства языков, чтобы что-то выполнить, нужно написать толпу обвязки вокруг (все эти main'ы, вызовы и прочее) AVK>>Большинство языков давно обзавелись фреймворками для юнит-тестирования и тест-раннерами в составе IDE.
M>Еще один.
Вы с Владом придумали себе два тезиса:
1. REPL не нужен, вместо него нужны более серьёзные средства отладки и управления проектами.
2. REPL не нужен, большинство языков давно обзавелись фреймворками для юнит-тестирования и тест-раннерами в составе IDE.
Самое смешное, никто нигде не говорит, что REPL заменяет средства отладки или средства для удобного юнит-тестирования. Но вы эти два тезиса придумали и пытаетесь с ними бороться
Здравствуйте, Mamut, Вы писали:
M>Немерл. И на практике. И «большие приложения». Извини, но количество взаимоисключений тут слишком велико.
А ты думаешь что если ты попышешь злостью, то реальность вдруг превратится в угодную тебе картинку.
Мы пишем довольно большой проект на Немерле. И не один. Репл у нас был еще 6 лет назад. По мере развития компилятора его поломали. Но так как на практике от него нет толку, его никто не восстанавливает.
Это реальность. А то что ты там себе придумал — это твоя виртуальная реальность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
I>ставишь бряк куда надо, а там тупо вызываешь функции как хочешь.
Это и функциями отладчика делается прекрасно. Репл тут не нужен.
I>вместо перезапуска всего приложения ты можешь попробовать на лету пару вариантов и готовый результат перенести в код.
В студии даже можно исправить код в C# и продолжить выполнение. Причем тут репл?
I>скажем, рестарт сервера занимает несколько минут. проверить вырианты одной функции, это на пару секунд на каждый. Без репл это превращается в часы отладки.
Это домыслы.
Я вот не видел еще репла с отладчиком связанного. Обычно это отдельная утилита. А функцию вызвать — это сколько угодно и без него.
I>Вероятно оттого, что всё кругом на макросах а ни серверных приложений, ни мобильных не пишется.
Очевидно ты мало понимаешь в предмете обсуждения. Вот погляди что народ делает в области того же веба http://nemerleweb.com
Как и очевидно, что сотф не сходится к серверному или мобильному.
I>Прикинь, как круто — на каждый мелкий бажок создаешь инсталяционный пекадж, инсталируешь, запускаешь, ждёшь, прогоняешь всю цепочку и все это для того, что бы выяснить ,что в путях потерялся один из компонетов.
Это все вещи не связанные с наличием или отсутствием репла.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
I>>вместо перезапуска всего приложения ты можешь попробовать на лету пару вариантов и готовый результат перенести в код.
VD>В студии даже можно исправить код в C# и продолжить выполнение. Причем тут репл?
Исправление кода на многих системах недоступно, ты не знал про это ?
I>>скажем, рестарт сервера занимает несколько минут. проверить вырианты одной функции, это на пару секунд на каждый. Без репл это превращается в часы отладки.
VD>Это домыслы.
Это факты.
VD>Я вот не видел еще репла с отладчиком связанного. Обычно это отдельная утилита. А функцию вызвать — это сколько угодно и без него.
I>>Вероятно оттого, что всё кругом на макросах а ни серверных приложений, ни мобильных не пишется.
VD>Очевидно ты мало понимаешь в предмете обсуждения. Вот погляди что народ делает в области того же веба http://nemerleweb.com
Cудя по тому, что ты не видел репла связаного с отладчиком, ты про веб знаешь чуть больше, чем ничего
Сколько лет этим примерам ? Чем они лучше N+1 других фремворков ? Похоже, ничем, только требуют намного больше кода.
Серверные это не всегда веб, кстати говоря.
VD>Как и очевидно, что сотф не сходится к серверному или мобильному.
это самый большие ниши на сегодняшний день.
I>>Прикинь, как круто — на каждый мелкий бажок создаешь инсталяционный пекадж, инсталируешь, запускаешь, ждёшь, прогоняешь всю цепочку и все это для того, что бы выяснить ,что в путях потерялся один из компонетов.
VD>Это все вещи не связанные с наличием или отсутствием репла.
VD>Мы пишем довольно большой проект на Немерле. И не один. Репл у нас был еще 6 лет назад. По мере развития компилятора его поломали. Но так как на практике от него нет толку, его никто не восстанавливает.
VD>Это реальность. А то что ты там себе придумал — это твоя виртуальная реальность.
Виртуальная реальность — это называть полтора проекта, которые пишут пять людей, реальностью и истиной, которая распространяется на всех.
Здравствуйте, Mamut, Вы писали:
M>Самое смешное, никто нигде не говорит, что REPL заменяет средства отладки или средства для удобного юнит-тестирования.
Самое смешное что ты не умеешь читать. Я отвечал исключительно на твою реплику о том, что нужно написать кучу обвязки. Так вот, это не так — достаточно написать один единственный метод и пометить его атрибутом [Test].
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
M>>Самое смешное, никто нигде не говорит, что REPL заменяет средства отладки или средства для удобного юнит-тестирования.
AVK>Самое смешное что ты не умеешь читать. Я отвечал исключительно на твою реплику о том, что нужно написать кучу обвязки. Так вот, это не так — достаточно написать один единственный метод и пометить его атрибутом [Test].
Действительно, ведь все абсолютно упирается в юнит тесты, и все можно решить юнит-тестами
Здравствуйте, Ikemefula, Вы писали:
I>90е и 2000 это Java и C#, в которых еще более примитивный switch
Я имел в виду, что в 70-е уже "неплоский" изобрели. А на Java и C# чего равняться — в них (языках, не реализациях) фич, изобретенных после 1968-го раз два и обчелся.
I>Да, не такой, как в Хаскеле
Да, и не такой как в остальных языках с паттерн матчингом. Вообще, тяжело навскидку вспомнить, где бы он был такой же страшный. Даже в скале получше, а там заявка на самый страшный ПМ серьезная.
I>Для 90% разрабов, которые только и имеют дело с сишным синтаксисом, это очень круто.
Тут неявное предположение, что если кто-то с чем-то имеет дело постоянно — он и дальше хотел бы продолжать иметь.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Cyberax, Вы писали:
C>Ну то есть, как замена удобному отладчику.
Нет, это не замена отладчику, это скорее замена всяким приседаниям с "созданием файликов".
РЕПЛ можно использовать совместно с отладчиком — и тогда окружение на брейкпойнте можно "инспектировать" и обрабатывать результат прямо определенной на месте функцией на этом же самом языке.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, VladD2, Вы писали:
VD>В Немерле репл сдох за ненадобностью.
Nemerlish, насколько я помню, был с самыми зачаточным функционалом, так что пользы от него было немного и не удивительно, что он оказался никому не нужен. Нормальный доделанный РЕПЛ инструмент более серьезный, в нем доступен язык полностью, т.е. можно любые декларации делать, автокомплит есть, интеграция с отладчиком и т.д.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
I>>90е и 2000 это Java и C#, в которых еще более примитивный switch
K>Я имел в виду, что в 70-е уже "неплоский" изобрели. А на Java и C# чего равняться — в них (языках, не реализациях) фич, изобретенных после 1968-го раз два и обчелся.
Тебя не смущает, что самые популярные и востребованые языки, это те, в которых никаких особенных фич то и нет ?
K>Да, и не такой как в остальных языках с паттерн матчингом. Вообще, тяжело навскидку вспомнить, где бы он был такой же страшный. Даже в скале получше, а там заявка на самый страшный ПМ серьезная.
Нет задачи дать внятный ПМ тем, у кого он и так есть.
Есть другая задача — дать хоть какой то ПМ тем, у кого ничего нет.
I>>Для 90% разрабов, которые только и имеют дело с сишным синтаксисом, это очень круто.
K>Тут неявное предположение, что если кто-то с чем-то имеет дело постоянно — он и дальше хотел бы продолжать иметь.
Тут неявно указание на популярность сишного синтаксиса за последние 40 лет.
Есть факт — от императивного программирования отказа быть в принципе не может, в силу ряда причин, в частности слишком низком перформансе функциональных языков в низкоуровневых алгоритмах
И вот пока что для императивного программирования сишный синтаксис самый сбалансированый. Скажем, идейка выравнивать код отступами интересная, но её массы как то не принимают.
Здравствуйте, Ikemefula, Вы писали:
I>Тебя не смущает, что самые популярные и востребованые языки, это те, в которых никаких особенных фич то и нет ?
Нет, не смущает. Эти языки востребованы не из-за фич языков, а фич инфраструктуры вообще и реализаций в частности, этих языков, которых как раз достаточно и вложить столько труда в инфраструктуру какого-то другого, более продвинутого языка просто никто не может себе позволить.
Там где требования к качеству реализации низкие (в случае всяких питонов-рубей) языки выглядят совсем иначе и с перечисленными "самыми востребованными" имеют мало общего. Короче говоря, был бы для JVM только интеркол — писали бы на интерколе, просто текучка кадров и заполняемость психлечебниц слегка подскочила бы.
I>Нет задачи дать внятный ПМ тем, у кого он и так есть. I>Есть другая задача — дать хоть какой то ПМ тем, у кого ничего нет.
Непонятно только, зачем давать "хоть какой-то", если можно нормальный дать?
I>Есть факт — от императивного программирования отказа быть в принципе не может, в силу ряда причин, в частности слишком низком перформансе функциональных языков в низкоуровневых алгоритмах
Да нет, парформанс лапшевого низкоуровневого кода обычно нормальный (если компилировать LLVM/JVM/CLR, а не какими-нибудь студенческими кодогенераторами), проблема в том, что идиоматический код тормозит и многие даже проблемой это не считают, а значит в этом направлении не работают.
Это по другому нужно сформулировать: синтаксис в ФЯ лекгковесен для (и, следовательно, поощряет использование) лямбд, карринга и полиморфизма, все это связано с издержками в смысле перформанса. В сишном синтаксисе за все это обычно дают по рукам на ранних подступах, средствами карательного синтаксиса.
Поэтому вполне можно обосновать громоздкий синтаксис для лямбд, f(a,b,c) синтаксис и страшные аннотации параметрического полиморфизма. Но какая польза от убогого паттерн-матчинга? Компилятор паттерн-матчинга, как правило, дает код лучше того, который бы средний программист написал разбирая какую-то сложную структуру. Зачем за него наказывать?
I>И вот пока что для императивного программирования сишный синтаксис самый сбалансированый. Скажем, идейка выравнивать код отступами интересная, но её массы как то не принимают.
Для меня ужасы сишного синтаксиса — это, в первую очередь, адские типы ссылок на функции/массивов, префиксные аннотации типов и параметры типов с елочками и монструозные свитчи, которые как раз совсем не в духе общей тенденции сишного синтаксиса не злоупотреблять большим кол-вом ключевых слов на строку кода. Ничего этого для императивного программирования не нужно.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
I>>Тебя не смущает, что самые популярные и востребованые языки, это те, в которых никаких особенных фич то и нет ?
K>Нет, не смущает. Эти языки востребованы не из-за фич языков, а фич инфраструктуры вообще и реализаций в частности, этих языков, которых как раз достаточно и вложить столько труда в инфраструктуру какого-то другого, более продвинутого языка просто никто не может себе позволить.
Ты плохо прочёл — в этих языках фич практически нет. Отсюда следствие — отсутствие фич не является препятствием, ни разу.
K>Там где требования к качеству реализации низкие (в случае всяких питонов-рубей) языки выглядят совсем иначе и с перечисленными "самыми востребованными" имеют мало общего. Короче говоря, был бы для JVM только интеркол — писали бы на интерколе, просто текучка кадров и заполняемость психлечебниц слегка подскочила бы.
Это голословно. Хорошо бы увидеть какие то жосткие данные на тему "в областях где цена ошибки высока (== цене бизнеса, цене жизни и тд) используется XXX"
Итого, от тебя требуется раскрыть XXX. Лично я сомневаюсь, что там будет доминировать пейтоны-руби-хаскели. Там даже эрланг не будет доминировать, хотя он там точно есть.
I>>Есть другая задача — дать хоть какой то ПМ тем, у кого ничего нет.
K>Непонятно только, зачем давать "хоть какой-то", если можно нормальный дать?
Уже наверное 50 лет дают и никак дать не могут. Функциональщина хронически не лезет в мейнстрим, ну никак.
K>Да нет, парформанс лапшевого низкоуровневого кода обычно нормальный (если компилировать LLVM/JVM/CLR, а не какими-нибудь студенческими кодогенераторами), проблема в том, что идиоматический код тормозит и многие даже проблемой это не считают, а значит в этом направлении не работают.
1 низкоуровневые алгоритмы, если они не на си или не на оптимизированых шаблонах С++ сосут не нагибаясь. Разница в перформансе-потреблении памяти минимум в разы. отсюда ясно, почему обработку изображений никто в своём уме не пишет на функциональных языках.
2 идиоматический код еще сильнее усугубляет проблемы
K>Это по другому нужно сформулировать: синтаксис в ФЯ лекгковесен для (и, следовательно, поощряет использование) лямбд, карринга и полиморфизма, все это связано с издержками в смысле перформанса. В сишном синтаксисе за все это обычно дают по рукам на ранних подступах, средствами карательного синтаксиса.
Сишный синтаксис очень хорош для структур данных, ООП и подобных вещей. Скажем, для описания данных лучше чем JSON не придумаешь.
K>Поэтому вполне можно обосновать громоздкий синтаксис для лямбд, f(a,b,c) синтаксис и страшные аннотации параметрического полиморфизма. Но какая польза от убогого паттерн-матчинга? Компилятор паттерн-матчинга, как правило, дает код лучше того, который бы средний программист написал разбирая какую-то сложную структуру. Зачем за него наказывать?
Убогий паттерн матчинг на порядок лучше его отсутствия.
I>>И вот пока что для императивного программирования сишный синтаксис самый сбалансированый. Скажем, идейка выравнивать код отступами интересная, но её массы как то не принимают.
K>Для меня ужасы сишного синтаксиса — это, в первую очередь, адские типы ссылок на функции/массивов, префиксные аннотации типов и параметры типов с елочками и монструозные свитчи, которые как раз совсем не в духе общей тенденции сишного синтаксиса не злоупотреблять большим кол-вом ключевых слов на строку кода. Ничего этого для императивного программирования не нужно.
"монструозные свитчи" это из за отстутствия даже убогого ПМ. Адские типы ссылок на функции-массивы из за слабого полиморфизма.
Здравствуйте, Klapaucius, Вы писали:
K>Нет, это не замена отладчику, это скорее замена всяким приседаниям с "созданием файликов".
А какие приседания? С REPL'ом меня ещё додалбывало то, что его потом сложно снова воспроизвести.
K>РЕПЛ можно использовать совместно с отладчиком — и тогда окружение на брейкпойнте можно "инспектировать" и обрабатывать результат прямо определенной на месте функцией на этом же самом языке.
Ну как бы, новые debugger'ы позволяют запускать код в контексте остановленного потока.
Здравствуйте, Klapaucius, Вы писали:
K>Nemerlish, насколько я помню, был с самыми зачаточным функционалом, так что пользы от него было немного и не удивительно, что он оказался никому не нужен. Нормальный доделанный РЕПЛ инструмент более серьезный, в нем доступен язык полностью, т.е. можно любые декларации делать, автокомплит есть, интеграция с отладчиком и т.д.
Что с этого всего толку в статически типизированном ООЯ?
Менять типы невозможно, так как куча всего зависит на раскладку памяти.
Ну, а если репл интегрирован с отладчиком, то это уже и не репл как бы.
Развивать нужно средства отладки, а не какие-то игрушки.
Оптимальный вариант когда, как в скриптовых языках, программу можно остановить, поправить и продолжить дальше. По объективным причинам для компилируемых статически-типизируемых ООЯ — это сделать крайне сложно. Но сложно не значит невозможно. Так что надо копать в эту сторону.
От репловских же функций нужно иметь возможность выполнить некий код в режиме интерпретатора. Этого более чем достаточно. Писать код в репле — это не лучшая идея. Хорошая IDE все равно будет в разы удобнее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
I>Если будет внятный GC, то это лучше C#, Джавы и С++ вместе взятых. Но судя по набору фич язык сильно близко подобрался к Scala и F#
I>И самое главное — Сишный синтаксис !
По первым описаниям — смесь бейсика с Ruby, местами вдохновлённый Питоном и Go. На C никак не похож.
Здравствуйте, D. Mon, Вы писали:
VD>>Убило использование подсчета ссылок без автоматического разруливания за зацикливаний. В 21 веке это выглядит дико. Такому языку нужен GC или хотя бы автоматический поиск зацикливаний, как в Руби. DM>Как в Питоне, наверное. В Руби испокон веков был честный mark & sweep, никакого RC.
В Питоне, если речь про CPython, generational GC в дополнение к подсчёту ссылок. GC можно отключать (я этим пользовался, заказывая его в разрешённые моменты), подсчёт ссылок — нет. В других движках может быть только GC.
DM>В свифте они целились на рантайм-совместимость с Obj-C, а там тот же самый ARC. Трудно было бы добавить честный GC в один язык, не добавив в другой. Ну и скорее всего это дело принципа: обеспечить иллюзию детерминированности и какбы отсутствие тормозов GC, шоб андроид не получился.
Отсутствие концентрированных тормозов можно обеспечить множеством способов, но если их этот устраивает — почему бы и нет...
Здравствуйте, Mamut, Вы писали:
M>Виртуальная реальность — это называть полтора проекта, которые пишут пять людей, реальностью и истиной, которая распространяется на всех.
Я не хочу спорить с твоим бредом. Мне на это жалко время тратить. Верь во что хочешь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, NeoCode, Вы писали:
NC>Странный подход, написано free, в фиг скачаешь без этого вашего тунца. Как они собираются привлекать разработчиков, не имевших до этого дела с эппл?
Здравствуйте, Klapaucius, Вы писали:
I>>90е и 2000 это Java и C#, в которых еще более примитивный switch
K>Я имел в виду, что в 70-е уже "неплоский" изобрели. А на Java и C# чего равняться — в них (языках, не реализациях) фич, изобретенных после 1968-го раз два и обчелся.
Для первой версии рабочего промышленного языка, а не экспериментального и это неплохо.
На редкость удачная первая версия такого, предназначенного для массового использования, языка.
Здравствуйте, netch80, Вы писали:
DM>>В свифте они целились на рантайм-совместимость с Obj-C, а там тот же самый ARC. Трудно было бы добавить честный GC в один язык, не добавив в другой. Ну и скорее всего это дело принципа: обеспечить иллюзию детерминированности и какбы отсутствие тормозов GC, шоб андроид не получился.
N>Отсутствие концентрированных тормозов можно обеспечить множеством способов, но если их этот устраивает — почему бы и нет...
Это дело реализации/компилятора, ИМХО.
Для системных вещей — конечно только подсчет ссылок (да и тот редкость).
А для всяких нетребовательных околоскриптовых — можно будет и ГЦ потом дать.
Здравствуйте, netch80, Вы писали:
I>>Если будет внятный GC, то это лучше C#, Джавы и С++ вместе взятых. Но судя по набору фич язык сильно близко подобрался к Scala и F# I>>И самое главное — Сишный синтаксис ! N>По первым описаниям — смесь бейсика с Ruby, местами вдохновлённый Питоном и Go. На C никак не похож.
Точно! Эдакий современный продвинутый вариант Бейсика. Безопасный и провоцирующий на эксперименты.
Веселенький, кста. ))
Изучение Rust, к примеру, навевает скуку. А описание Swift хочется читать и читать. Оч положительные эмоции. Особенно, если помнить, что это лишь первая версия языка. Первый промышленный язык, который будет заведомо распространён, и который сходу утер нос C#. ))
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Ikemefula, Вы писали:
I>>Если будет внятный GC, то это лучше C#, Джавы и С++ вместе взятых. Но судя по набору фич язык сильно близко подобрался к Scala и F#
I>>И самое главное — Сишный синтаксис !
N>По первым описаниям — смесь бейсика с Ruby, местами вдохновлённый Питоном и Go. На C никак не похож.
Ну давай посмотрим, а то не ясно, откуда мог взяться питон если все надо скобочками отделять
Типы указываются постфиксно, щас это модно, например тот же подход в TypeScript
struct FixedLengthRange {
var firstValue: Int
let length: Int
}
Наследование
class SomeClass: SomeSuperclass {
// class definition goes here
}
Не ясно, что здесь от бейсика и руби
Или вот
struct Fahrenheit {
var temperature: Double
init() {
temperature = 32.0
}
}
var f = Fahrenheit()
println("The default temperature is \(f.temperature)° Fahrenheit")
Здравствуйте, vdimas, Вы писали:
V>Первый промышленный язык, который будет заведомо распространён, и который сходу утер нос C#. ))
Смишно. Распространенный язык, недоступный на линуксе и винде.
Что до носа C#, то вот простейший вопрос: напиши на свифте генерик-функцию, работающую с разными линейными контейнерами (массив, два вида списков, deque). Скажем, на входе контейнер с интами, найти минимум из первых 10 положительных чисел. Второй вопрос: добавить свой контейнер и чтобы эта функция без изменений с ним заработала.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, netch80, Вы писали:
V>Первый промышленный язык, который будет заведомо распространён, и который сходу утер нос C#. ))
Здравствуйте, D. Mon, Вы писали:
V>>Первый промышленный язык, который будет заведомо распространён, и который сходу утер нос C#. )) DM>Смишно. Распространенный язык, недоступный на линуксе и винде.
А какая разница разработчикам под семейство макосей на этот довод?
Он всё-равно сходу будет более распространён как инструмент написания коробочных продуктов, чем тот же C#.
DM>Что до носа C#, то вот простейший вопрос: напиши на свифте генерик-функцию, работающую с разными линейными контейнерами (массив, два вида списков, deque). Скажем, на входе контейнер с интами, найти минимум из первых 10 положительных чисел. Второй вопрос: добавить свой контейнер и чтобы эта функция без изменений с ним заработала.
Это намек на IEnumerable<IComparable>?
Самому не смишно?
Здравствуйте, D. Mon, Вы писали:
DM>Что до носа C#, то вот простейший вопрос: напиши на свифте генерик-функцию, работающую с разными линейными контейнерами (массив, два вида списков, deque). Скажем, на входе контейнер с интами, найти минимум из первых 10 положительных чисел. Второй вопрос: добавить свой контейнер и чтобы эта функция без изменений с ним заработала.
Кароч, облом ждать очередной итерации пинг-понга в сообщениях.
Ты привел сценарий, когда дотнет генерит в рантайм код под value-type как аргументы генериков.
Теперь, если включить мозг (просто понять целевую платформу и её философию) — самому не смешно?
Ничего подобного в промышленном инструментарии под коробочные продукты под эту ось и под приложения для самой оси (и даже для написания запчастей этой оси) никогда не будет, ес-но.
Тут можно ожидать только подвижки в ту же сторону, в которую идет обобщенное программирование в С++.
Здравствуйте, Cyberax, Вы писали:
K>>Нет, это не замена отладчику, это скорее замена всяким приседаниям с "созданием файликов". C>А какие приседания? С REPL'ом меня ещё додалбывало то, что его потом сложно снова воспроизвести.
Repl сложно воспроизвести, если ты намодифицировал всего подряд и функции у тебя кругом модифицирующие.
Здравствуйте, vdimas, Вы писали:
V>Точно! Эдакий современный продвинутый вариант Бейсика. Безопасный и провоцирующий на эксперименты.
V>Веселенький, кста. )) V>Изучение Rust, к примеру, навевает скуку. А описание Swift хочется читать и читать. Оч положительные эмоции. Особенно, если помнить, что это лишь первая версия языка. Первый промышленный язык, который будет заведомо распространён, и который сходу утер нос C#. ))
Ого, у тебя, оказывается, есть информация из будущего.
Свифт предлагает очень много фич разом. Есть большой шанс, что сообщество обжективных разрабов, которое консервативное донельзя, просто не примет. Так что вполне можно ожидать сценарий "с места и в лужу".
Здравствуйте, vdimas, Вы писали:
V>А какая разница разработчикам под семейство макосей на этот довод? V>Он всё-равно сходу будет более распространён как инструмент написания коробочных продуктов, чем тот же C#.
DM>>Что до носа C#, то вот простейший вопрос: напиши на свифте генерик-функцию, работающую с разными линейными контейнерами (массив, два вида списков, deque). Скажем, на входе контейнер с интами, найти минимум из первых 10 положительных чисел. Второй вопрос: добавить свой контейнер и чтобы эта функция без изменений с ним заработала.
V>Это намек на IEnumerable<IComparable>? V>Самому не смишно?
Это намёк на экстеншны, предсказуемый полиморфизм, обобщенное программирование и особенности дизайна базовых классов. Вот скажем если в свифте контейнеры никто не задизайнит внятно, то от экстеншнов толку будет крайне мало.
Здравствуйте, vdimas, Вы писали:
V>Кароч, облом ждать очередной итерации пинг-понга в сообщениях. V>Ты привел сценарий, когда дотнет генерит в рантайм код под value-type как аргументы генериков.
А в огороде бузина.
V>Теперь, если включить мозг (просто понять целевую платформу и её философию) — самому не смешно? V>Ничего подобного в промышленном инструментарии под коробочные продукты под эту ось и под приложения для самой оси (и даже для написания запчастей этой оси) никогда не будет, ес-но.
Забудь про то, что и как делается в рантайме. Главное, что в компайл-тайм в C# у тебя есть определенные инструменты — полиморфизм, обобщенное программирование, внятный дизайн контейнеров и экстеншны. Как они работают в рантайме — никому не интересно. Вопрос не про это.
Здравствуйте, Ikemefula, Вы писали:
I>Типы указываются постфиксно, щас это модно, например тот же подход в TypeScript
Это сто лет как модно, и используется в большом количестве не Си-подобных языков: F#, OCaml, Scala, Nemerle, ActionScript, etc. Не говоря уже о теории типов и языков программирования.
Здравствуйте, Mamut, Вы писали:
A>>>>На самом деле, это скорее ВАУ фича, чем что-либо полезное. Те примеры что есть, скорее всего масксимум возможностей и показывают, а именно простые однопоточные приложения с простой моделью данных. M>>>Ну, на самом деле я на это дело смотрю, как на приятный расширенный REPL C>>Мне вот всегда было интересно зачем REPL нужен...
M>Это очень удобный инструмент. Как для быстрого прототипирования и проверки некоторых идей, так и для быстрого тестирования некоторых вещей
"Для быстрого тестирования некоторых вещей" достаточно не бояться писать тесты в любых их вариациях: юнит тесты, интеграционные тесты, учебные тесты, воспроизводилки интересных сценариев. Ключевое слово — воспроизводимость.
Насчёт прототипирования вообще мысль не понял. ИМХО, единственное удачное применение REPL — это когда к запущенному приложению можно подключиться через какой-нибудь SSH и пощупать как у него дела дёргая всякие методы всяких объектов.
Я ненавижу Swift уже за то, что он у меня вчера в ньюсфиде встретился не менее 8 раз.
Ещё один язык, который работает на сильно ограниченном наборе платформ. Ещё один язык со своим уникальным и самым лучшим синтаксисом. Ещё один язык, который теперь в вакансиях сначала будет "крайне приветствуется", а потом "необходимо знать: Objective C, Objective C++, Swift". Ещё один язык, который будет иметь ненулевую популярность, просто потому что хипстеры.
1. Уродливый Objective C всё равно не запретят. Потому что это нереализуемо. Их будет два.
2. Прекрасный новый Swift идеологически не отличается от Objective C: это ЭКЗОТИКА. Прошлая экзотика была из глубоких 80-х, новая — из 2010ых.
3. Этот НОВЫЙ язык будет работать на очень старой платформе "с большой историей" — со странноватыми API и отсутствием клёвых штук типа рефлексии.
Здравствуйте, andyag, Вы писали:
A>1. Уродливый Objective C всё равно не запретят. Потому что это нереализуемо. Их будет два.
Это Apple. Они могут — Carbon API они таки запретили, хотя им пользовались такие гиганты как Photoshop.
A>2. Прекрасный новый Swift идеологически не отличается от Objective C: это ЭКЗОТИКА. Прошлая экзотика была из глубоких 80-х, новая — из 2010ых. A>3. Этот НОВЫЙ язык будет работать на очень старой платформе "с большой историей" — со странноватыми API и отсутствием клёвых штук типа рефлексии.
То есть? Рефлексию несложно добавить — это же LLVM. Аналогично, поддержка остальных платформ (в том числе Windows) скорее зависит от того, чтобы кто-то не поленился сделать сборку для них.
Здравствуйте, Cyberax, Вы писали:
C>Аналогично, поддержка остальных платформ (в том числе Windows) скорее зависит от того, чтобы кто-то не поленился сделать сборку для них.
Сомневаюсь. Сборку не то, чтобы поленятся сделать, просто побоятся судебных преследований со стороны Apple. Вспомнят неприятную историю про преследование Гугла Ораклом.
Здравствуйте, Qbit86, Вы писали:
C>>Аналогично, поддержка остальных платформ (в том числе Windows) скорее зависит от того, чтобы кто-то не поленился сделать сборку для них. Q>Сомневаюсь. Сборку не то, чтобы поленятся сделать, просто побоятся судебных преследований со стороны Apple. Вспомнят неприятную историю про преследование Гугла Ораклом.
Ну вообще-то, в том судебном процессе победил Гугл. И всё зависит от лицензии, под которой Apple сделает доступным компилятор.
Здравствуйте, Cyberax, Вы писали:
C>Ну вообще-то, в том судебном процессе победил Гугл.
В последнем на данный момент раунде (насколько мне известно) побеждает Оракл: «Аппеляционный суд США постановил: Oracle обладает авторским правом на части языка программирования Java, использованные Google при разработке ОС Android».
Здравствуйте, Qbit86, Вы писали:
C>>Ну вообще-то, в том судебном процессе победил Гугл. Q>В последнем на данный момент раунде (насколько мне известно) побеждает Оракл: «Аппеляционный суд США постановил: Oracle обладает авторским правом на части языка программирования Java, использованные Google при разработке ОС Android».
Нет, аппеляционный суд не согласился с некоторыми интерпретациями закона в решении. Теперь дело пойдёт по второму кругу, об окончательной победе Оракла пока речи нет.
Здравствуйте, Cyberax, Вы писали:
C>Аналогично, поддержка остальных платформ (в том числе Windows) скорее зависит от того, чтобы кто-то не поленился сделать сборку для них. C>Нет, аппеляционный суд не согласился с некоторыми интерпретациями закона в решении.
А, ну тогда ок; «кто не поленился» может спокойно брать и реализовывать компилятор языка на Windows.
Здравствуйте, andyag, Вы писали:
A>"Для быстрого тестирования некоторых вещей" достаточно не бояться писать тесты в любых их вариациях: юнит тесты, интеграционные тесты, учебные тесты, воспроизводилки интересных сценариев. Ключевое слово — воспроизводимость.
И запускать эти тесты надо полагать, придется на боевой системе ?
A>Насчёт прототипирования вообще мысль не понял. ИМХО, единственное удачное применение REPL — это когда к запущенному приложению можно подключиться через какой-нибудь SSH и пощупать как у него дела дёргая всякие методы всяких объектов.
Эта хрень дает возможности сократить на прядок другой количество перезапусков приложения. Если для каждого перезапуска надо собирать пекадж или делать деплоймент, то разница просто сумасшедшая.
Здравствуйте, andyag, Вы писали:
A>Ещё один язык, который работает на сильно ограниченном наборе платформ. Ещё один язык со своим уникальным и самым лучшим синтаксисом. Ещё один язык, который теперь в вакансиях сначала будет "крайне приветствуется", а потом "необходимо знать: Objective C, Objective C++, Swift". Ещё один язык, который будет иметь ненулевую популярность, просто потому что хипстеры.
И что с того ?
A>1. Уродливый Objective C всё равно не запретят. Потому что это нереализуемо. Их будет два. A>2. Прекрасный новый Swift идеологически не отличается от Objective C: это ЭКЗОТИКА. Прошлая экзотика была из глубоких 80-х, новая — из 2010ых. A>3. Этот НОВЫЙ язык будет работать на очень старой платформе "с большой историей" — со странноватыми API и отсутствием клёвых штук типа рефлексии.
Если будет внятный перформанс и легкость интеграции с обжективси, то этот Обжектив си умрем сам собой, ибо переписать модуль заново будет много быстрее, чем фиксить старый. А где совсем туго, так и оставить обжектив.
Рефлексию легко добавить, и лучше если это будет чуть попозжа. Как вариант, всунуть компайл-тайм рефлексию, шоб сильнее отличиться от дотнета и джавы
Здравствуйте, Ikemefula, Вы писали:
I>Это намёк на экстеншны, предсказуемый полиморфизм, обобщенное программирование и особенности дизайна базовых классов.
Если речь о принципиальной возможности запрошенного, то это всё не важно.
Система типов в дотнете нифига не предсказуемая. Все эти эффекты от "неожиданного" боксирования или наоборот, от бесполезности изменения полей составных value-объектов, возвращаемых как св-ва, т.е. разница в поведении полей и св-в, разница в поведении оператора [] у встроенных массивов и объектов/интерфейсов, это всё просто россыпь граблей на ровном месте. Причем, даже у С++ есть ср-ва этих граблей избегать, т.е. есть ср-ва приводить семантику обращения с элементами встроенных массивов и юзверских типов-коллекций к чему-то более-менее идентичному, то у дотнета — нет никаких. Нужно тупо помнить о граблях. По-настоящему смешно в либах дотнета становится внутри кода генериков, когда первой строчкой идет попытка динамического приведения аргумента-коллекции к массиву и затем ветвление алгоритма в зависимости от успешности приведения. Криво это всё до невозможности.
Здравствуйте, Ikemefula, Вы писали:
V>>Кароч, облом ждать очередной итерации пинг-понга в сообщениях. V>>Ты привел сценарий, когда дотнет генерит в рантайм код под value-type как аргументы генериков. I>А в огороде бузина.
ы?
V>>Теперь, если включить мозг (просто понять целевую платформу и её философию) — самому не смешно? V>>Ничего подобного в промышленном инструментарии под коробочные продукты под эту ось и под приложения для самой оси (и даже для написания запчастей этой оси) никогда не будет, ес-но.
I>Забудь про то, что и как делается в рантайме. Главное, что в компайл-тайм в C# у тебя есть определенные инструменты — полиморфизм, обобщенное программирование, внятный дизайн контейнеров и экстеншны. Как они работают в рантайме — никому не интересно. Вопрос не про это.
Так ты не понял прикола с исходным вопросом? А чего тогда влез? ))
Здравствуйте, Ikemefula, Вы писали:
V>>Веселенький, кста. )) V>>Изучение Rust, к примеру, навевает скуку. А описание Swift хочется читать и читать. Оч положительные эмоции. Особенно, если помнить, что это лишь первая версия языка. Первый промышленный язык, который будет заведомо распространён, и который сходу утер нос C#. ))
I>Ого, у тебя, оказывается, есть информация из будущего.
Конечно. Бывает такое будущее, которое результат прошлого и настоящего. Например, дав нам вменяемый интероп с нейтивом, COM и ActiveX дотнет когда-то предрек своё будущее уже в первой же бете. Вашему покорному слуге стало всё понятно еще тогда, кароч, поэтому взялся за него активно с первых же бет. До сих пор популярный для меня тул, не взирая на столь медленное выполнение других, более ожидаемых обещаний от технологии. Скажем так, я еще не списал насовсем дотнет со своих счетов, но у него уже нет той форы, что 12 лет назад... время упущено, нейтив по своим фишкам и выразительности начинает ощутимо поджимать, увы и ах. ))
I>Свифт предлагает очень много фич разом. Есть большой шанс, что сообщество обжективных разрабов, которое консервативное донельзя, просто не примет. Так что вполне можно ожидать сценарий "с места и в лужу".
А твоё "будущее" Swift выглядит так, буд-то у него не было ни прошлого, ни настоящего. Или есть большой шанс, что с объектным-С ты сталкивался не ближе, чем издалека. Кароч, всё там будет хорошо, просто поверь. Слишком долго расписывать "почему" для того, кто далек от темы. Представь, что это как дотнет для старого COM и OLE-автоматизации. Причем, в лучшем его виде, как это было в VB.Net изначально или в C# только после прикручивания dynamic. Только еще удобнее, бо никакого dynamic и совместимость по типам на порядки более гладкая, чем дотнетные типы и OLE (вернее, совместимость фактически бесшовная, в отличие от ограничений дотнетного маршаллинга). Да и сам язык на порядок мощнее, чем первый C#, который был калькой с тупейшей джавы. В некоторых местах удобнее даже, чем нынешний пятый C#. Некоторые фишки языка откровенно улыбнули. Всё-таки в яблоках работают романтики... налицо эдакие реализованные "мечты детства" в промышленном языке. Игрища вокруг for и swit/case доставляют. Но вышло всё-таки симпатично. Посмотрим на развитие языка, кароч. Повторюсь, для первой версии настоящего промышленного языка, который сходу начнут использовать сотни тыщ разрабов — это мега-круто, что бы тут кто ни говорил и не пытался замечать недостатки или тем более сравнивать с некими "чистыми"/маргинальными языками.
По-сути, на сегодня Swift должно сравнивать только с последней джавой, последним C# и последними С/С++, с натяжкой еще можно попробовать сравнить с семейством JavaScript (всё-таки там еще серьезнейшие бока даже в статически-компилируемых расширениях). Все остальные языки идут в сад не задерживаясь, бо не дотягивают до мейнстрима, т.е. сравнение с любым другим языком будет чистой воды спекуляцией ни о чем.
Здравствуйте, Mamut, Вы писали:
M>Действительно, ведь все абсолютно упирается в юнит тесты, и все можно решить юнит-тестами
Включай уже голову наконец вместо флеймогенератора. Тест-раннеры могут быть использованы и используются в том числе "как для быстрого прототипирования и проверки некоторых идей, так и для быстрого тестирования некоторых вещей".
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, vdimas, Вы писали:
V>Это намек на IEnumerable<IComparable>?
Да.
V>Самому не смишно?
Очень, потому что в свифте этого нет! Нет общего протокола у контейнеров, у массива только map/reduce/filter и все. Посему до C# уже не дотягивает, а если вспомнить уникальное(?) умение C# превращать внутренние итераторы во внешние, то свифт и вовсе рядом не валялся. Ни о чем похожем на LINQ iРазработчики могут и не мечтать. Так что расскажи еще раз, чем же он утер нос C#.
Здравствуйте, vdimas, Вы писали:
V>Кароч, облом ждать очередной итерации пинг-понга в сообщениях. V>Ты привел сценарий, когда дотнет генерит в рантайм код под value-type как аргументы генериков. V>Теперь, если включить мозг (просто понять целевую платформу и её философию) — самому не смешно? V>Ничего подобного в промышленном инструментарии под коробочные продукты под эту ось и под приложения для самой оси (и даже для написания запчастей этой оси) никогда не будет, ес-но.
Ээ. Что, банально работающего полиморфизма и генериков нельзя ждать в "в промышленном инструментарии под коробочные продукты"? Почему?
V>Тут можно ожидать только подвижки в ту же сторону, в которую идет обобщенное программирование в С++.
То, что я спросил, не имеет отношения к value типам и С++. Элементарно решается на куче языков же.
Здравствуйте, vdimas, Вы писали:
V>Ничего подобного в промышленном инструментарии под коробочные продукты под эту ось и под приложения для самой оси (и даже для написания запчастей этой оси) никогда не будет, ес-но.
Хе, да свифт даже "for x in .." для произвольных контейнеров не умеет, лишь для парочки встроенных. Супер язык, чо. Промышленный. Утер. Да.
Здравствуйте, D. Mon, Вы писали:
DM>Ээ. Что, банально работающего полиморфизма и генериков нельзя ждать в "в промышленном инструментарии под коробочные продукты"? Почему?
Можно, конечно. Но не в том виде, как в C#. У дотнета серьезные ограничения насчет семантики value-type (из-за невозможности обойтись без пина при получении адреса структуры в памяти), куча граблей вокруг всего этого. Вот даже для value-type надо генерить УНИКАЛЬНУЮ реализацию генерика в РАНТАЙМ.... брррр... Это всё далеко за пределами "банально работающего полиморфизма".
Развитие генериков будет идти, конечно, но лишь по пути максимально-эффективного рантайм решения. Думаю, будет помощнее на этапе компиляции. Собсно, повторяюсь.
V>>Тут можно ожидать только подвижки в ту же сторону, в которую идет обобщенное программирование в С++. DM>То, что я спросил, не имеет отношения к value типам и С++. Элементарно решается на куче языков же.
Еще как имеет. Бо для ссылочных типов этот сценарий покрывается свифтом достаточно хорошо.
Здравствуйте, D. Mon, Вы писали:
DM>Очень, потому что в свифте этого нет! Нет общего протокола у контейнеров, у массива только map/reduce/filter и все.
Ну тогда мне теперь смешно. Потому что для любой коллекции достаточно некоего foreach c ф-ным типом-аргументом.
DM>Посему до C# уже не дотягивает
У многих языков никаких итераторов в базовой либе нет и даже не требуется: map/fold и усё. ))
DM>а если вспомнить уникальное(?) умение C# превращать внутренние итераторы во внешние, то свифт и вовсе рядом не валялся. Ни о чем похожем на LINQ iРазработчики могут и не мечтать.
Так говоришь, будто с первой версии дотнета могли мечтать.
DM>Так что расскажи еще раз, чем же он утер нос C#.
Фактически всем тем, что есть в нем и нет в C#. Каждая из таких конструкций языка — сугубо утилитарная, сугубо для удобства.
Здравствуйте, D. Mon, Вы писали:
DM>Хе, да свифт даже "for x in .." для произвольных контейнеров не умеет, лишь для парочки встроенных. Супер язык, чо. Промышленный. Утер. Да.
Это весьма странно, но ваще в свифте много всяких прикольных фич, он явно принадлежит к новой волне гибридных языков типа Rust, Ceylon, Kotlin, Xtend, а не к уже "старым" C#/Java/etc.
Думаю, с контейнерами все добавят, это же самая первая версия. В дотнете первой версии тоже много чего не было.
Здравствуйте, D. Mon, Вы писали:
DM>Хе, да свифт даже "for x in .." для произвольных контейнеров не умеет, лишь для парочки встроенных. Супер язык, чо. Промышленный. Утер. Да.
Ты третий раз говоришь одно и то же. Мне трижды отвечать?
Здравствуйте, gandjustas, Вы писали:
V>>Первый промышленный язык, который будет заведомо распространён, и который сходу утер нос C#. )) G>У вас, сударь, на лицо apple головного мозга.
Здравствуйте, Ikemefula, Вы писали:
I>Ты плохо прочёл — в этих языках фич практически нет. Отсюда следствие — отсутствие фич не является препятствием, ни разу.
Нет, вывести такое следствие не из чего. Вот если бы были языки с равными инфраструктурами и сильно различающиеся по фичам — тогда можно было бы какие-то выводы делать.
I>Хорошо бы увидеть какие то жосткие данные на тему "в областях где цена ошибки высока (== цене бизнеса, цене жизни и тд) используется XXX" I>Итого, от тебя требуется раскрыть XXX. Лично я сомневаюсь, что там будет доминировать пейтоны-руби-хаскели. Там даже эрланг не будет доминировать, хотя он там точно есть.
Не понял, как мы вдруг перешли к "областям, где цена ошибки высока"?
I>Уже наверное 50 лет дают и никак дать не могут. Функциональщина хронически не лезет в мейнстрим, ну никак.
В том и дело, что дорогие/сложные фичи из функциональщины вроде лямбд, дженериков и иммутабельных строк вполне в мейнстрим пролезли. Отсюда и вопрос: что такого с ПМ, что он не пролезает? Я на него ответа не знаю, а вы?
K>>Да нет, парформанс лапшевого низкоуровневого кода обычно нормальный (если компилировать LLVM/JVM/CLR, а не какими-нибудь студенческими кодогенераторами), проблема в том, что идиоматический код тормозит и многие даже проблемой это не считают, а значит в этом направлении не работают.
I>1 низкоуровневые алгоритмы, если они не на си или не на оптимизированых шаблонах С++ сосут не нагибаясь. Разница в перформансе-потреблении памяти минимум в разы. отсюда ясно, почему обработку изображений никто в своём уме не пишет на функциональных языках.
Ну вот, вы же сами написали, что все, кроме C и C++. Остальные это ведь не только пара-тройка ФЯ но и бразиллион языков никакого отношения к ФП в основном не имеющих. Как видите, страшный синтаксис им никак не помог. При этом сабж явно не окажется в категории С/C++, а наоборот — в категории "остальные", в которой ФЯ часто смотрятся в смысле производительности очень хорошо.
I>2 идиоматический код еще сильнее усугубляет проблемы
Да, все верно.
I>Сишный синтаксис очень хорош для структур данных, ООП и подобных вещей. Скажем, для описания данных лучше чем JSON не придумаешь.
Довольно странное утвеждение. Описание структур данных в С-подобных языках как раз часто очень многословное и навороченное.
Вообще, я считаю, что где нет сумм — там и нормальных возможностей описания структур данных нет.
I>Убогий паттерн матчинг на порядок лучше его отсутствия.
Вопрос был в том, зачем делать убогим, если можно не убогим? Что мешает-то?
I>"монструозные свитчи" это из за отстутствия даже убогого ПМ. Адские типы ссылок на функции-массивы из за слабого полиморфизма.
Нет, я не про убогие возможности, а именно про навороченность синтаксиса.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, vdimas, Вы писали:
DM>>Хе, да свифт даже "for x in .." для произвольных контейнеров не умеет, лишь для парочки встроенных. Супер язык, чо. Промышленный. Утер. Да.
V>Ты третий раз говоришь одно и то же.
Это просто дополнение было.
V> Мне трижды отвечать?
Не надо, садись уже, твой ответ услышан. Оказалось, что не сегодняшний свифт утер нос сегодняшнему шарпу, а "свифт через пять лет" вероятно утрет "шарпу 10 лет назад". Ну да, прогресс.
Здравствуйте, Cyberax, Вы писали:
C>А какие приседания?
Представьте, что у вас интерактивной оболочки нет, всякий раз нужно создавать файл со скриптокодом и запускать его? Вот примерно так же чувствует себя пользователь репла, когда ему предлагают для экспериментирования с кодом "файлики создавать".
C>С REPL'ом меня ещё додалбывало то, что его потом сложно снова воспроизвести.
Да, такие сложности бывают.
C>Ну как бы, новые debugger'ы позволяют запускать код в контексте остановленного потока.
С этого места поподробнее, а то мало ли что кто-то может подразумевать под словами "новый дебаггер".
Возьмем, к примеру, отладчик VS 2013. Это, кстати, пример отладчика интегрированного с REPL-ом, только вот репл там крайне убогий.
В студийном репле есть с некоторых пор автокомплит, что хорошо, вот только пользователя ожидает нешуточный сюрприз.
Остановились на брейкпойнте, начинаем инспектировать код:
items.Last() // пока все хорошо. Кстати, а где приглашение?
5.0
items.Take(2)
{System.Linq.Enumerable.TakeIterator<double>}
count: 0
source: null
items.Take(2).ToArray()
{double[2]}
[0]: 5.0
[1]: 5.0
items.OrderByDescending(x => x).Take(5).ToArray() // без ToArray выдаст не то, что нужно в 99% случаев.
Expression cannot contain lambda expressions
// все, приехали
Invalid expression term ''
0 // все, приехали
0
"Expression cannot contain lambda expressions", серьезно? Мы в каменном веке что ли?
Как видите, целый букет проблем, как делающая этот репл совершенно неюзабельным, так и просто набор милых штришков.
И это коммерческий продукт, индус триальный флагман, не какая-то студенческая поделка.
Правда, не понятно, если вы вполне одобряете "запускание кода в контексте остановленного потока", то какие вопросы по нужности REPL? Что-то не сходится.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, VladD2, Вы писали:
VD>Что с этого всего толку в статически типизированном ООЯ?
Толк есть, хотя я не стал бы, например, рекомендовать делать нормальный репл для Немерле, принимая во внимание дефицит ресурсов и целевую аудиторию дотнет-программистов, в которой репл мало известен и не востребован.
Это время можно с большей пользой на что-то другое потратить.
Просто не нужно из невостребованности nemerlish-а делать какие-то космические выводы: то, чего обычно ожидают от репл он все равно не делал.
VD>Ну, а если репл интегрирован с отладчиком, то это уже и не репл как бы.
Довольно странное заявление.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, vdimas, Вы писали:
V>Для первой версии
Такого рода вещи нужно делать сразу, а перепрыгивание пропасти в три версии дает в итоге похожие на палеонтологический музей языки вроде C# в котором есть и лямбды и какое-нибудь недочудо типа анонимного метода.
V>рабочего промышленного языка, а не экспериментального и это неплохо.
Вот только результаты экспериментов в экспериментальных языках он никак не учитывает, т.е. готовит "эксперимент" по очередному ознакомлению лбов индустриальных разработчиков с граблями, обнаруженными десятилетия назад.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, vdimas, Вы писали:
I>>Это намёк на экстеншны, предсказуемый полиморфизм, обобщенное программирование и особенности дизайна базовых классов.
V>Если речь о принципиальной возможности запрошенного, то это всё не важно.
Именно это определяет, какой профит будет от языковых фич.
V>Система типов в дотнете нифига не предсказуемая.
Здравствуйте, Klapaucius, Вы писали:
I>>Ты плохо прочёл — в этих языках фич практически нет. Отсюда следствие — отсутствие фич не является препятствием, ни разу.
K>Нет, вывести такое следствие не из чего. Вот если бы были языки с равными инфраструктурами и сильно различающиеся по фичам — тогда можно было бы какие-то выводы делать.
Хорошая инфраструктура почему то появляется только для самых убогих языков с твоей точки зреня. Тебе самому не смешно ?
I>>Хорошо бы увидеть какие то жосткие данные на тему "в областях где цена ошибки высока (== цене бизнеса, цене жизни и тд) используется XXX" I>>Итого, от тебя требуется раскрыть XXX. Лично я сомневаюсь, что там будет доминировать пейтоны-руби-хаскели. Там даже эрланг не будет доминировать, хотя он там точно есть.
K>Не понял, как мы вдруг перешли к "областям, где цена ошибки высока"?
А что ты имел ввиду под требованием к качеству реализации ? Эти требования определяются исключительно ценой ошибки, а не применяемым языком.
Скажем, если ты начнешь писать для системы жизнеобеспечения, но это совершенно не значит, что "требования к качеству реализации низкие (в случае всяких питонов-рубей)" @ Klapaucius.
I>>Уже наверное 50 лет дают и никак дать не могут. Функциональщина хронически не лезет в мейнстрим, ну никак.
K>В том и дело, что дорогие/сложные фичи из функциональщины вроде лямбд, дженериков и иммутабельных строк вполне в мейнстрим пролезли. Отсюда и вопрос: что такого с ПМ, что он не пролезает? Я на него ответа не знаю, а вы?
А что тут знать. Компилируешь и смотришь, во что это выливается в итоге. Отсюда ясно, что ни перформанса, ни внятного расхода памяти нет и быть не может, при том, что нужно дизайнить внутреннее АПИ специальным образом.
I>>1 низкоуровневые алгоритмы, если они не на си или не на оптимизированых шаблонах С++ сосут не нагибаясь. Разница в перформансе-потреблении памяти минимум в разы. отсюда ясно, почему обработку изображений никто в своём уме не пишет на функциональных языках.
K>Ну вот, вы же сами написали, что все, кроме C и C++. Остальные это ведь не только пара-тройка ФЯ но и бразиллион языков никакого отношения к ФП в основном не имеющих. Как видите, страшный синтаксис им никак не помог. При этом сабж явно не окажется в категории С/C++, а наоборот — в категории "остальные", в которой ФЯ часто смотрятся в смысле производительности очень хорошо.
ФЯ смотрятся хорошо только в высокоуровневых алгоритмах, если их тяжело перевести в императивный вид. В низковровневых вещах разница любого ФЯ с простецким Си минимум в несколько раз.
I>>Сишный синтаксис очень хорош для структур данных, ООП и подобных вещей. Скажем, для описания данных лучше чем JSON не придумаешь.
K>Довольно странное утвеждение. Описание структур данных в С-подобных языках как раз часто очень многословное и навороченное.
JSON вот как раз из Си-подобного языка вырос.
I>>Убогий паттерн матчинг на порядок лучше его отсутствия.
K>Вопрос был в том, зачем делать убогим, если можно не убогим? Что мешает-то?
Полноценный ПМ можно всунуть только в полноценный ФЯ, со всеми его проблемами — перформансом и потреблением памяти. Это очень дорогая фича.
I>>"монструозные свитчи" это из за отстутствия даже убогого ПМ. Адские типы ссылок на функции-массивы из за слабого полиморфизма.
K>Нет, я не про убогие возможности, а именно про навороченность синтаксиса.
В мейнстриме в код лазят самые разные люди, с разными скилами. Сишный синтаксис это своего рода костыль для таких вот людей, снижает уровень вхождения.
Здравствуйте, vdimas, Вы писали:
V>По-сути, на сегодня Swift должно сравнивать только с последней джавой, последним C# и последними С/С++, с натяжкой еще можно попробовать сравнить с семейством JavaScript (всё-таки там еще серьезнейшие бока даже в статически-компилируемых расширениях). Все остальные языки идут в сад не задерживаясь, бо не дотягивают до мейнстрима, т.е. сравнение с любым другим языком будет чистой воды спекуляцией ни о чем.
Так давай сравним с C# последним. Задачу тебе дали. Какие проблемы ? Ты же намекаешь, что знаком с платформой неиздалека. Какие проблемы написать одну функцию, которая выдаст среднее арифметической для первых 10 элементов и будет универсальна для всех контейнеров.
Это чисто языковая задача + особенности дизайна базовой либы.
Здравствуйте, Ikemefula, Вы писали:
I>Так давай сравним с C# последним. Задачу тебе дали. Какие проблемы ? Ты же намекаешь, что знаком с платформой неиздалека. Какие проблемы написать одну функцию, которая выдаст среднее арифметической для первых 10 элементов и будет универсальна для всех контейнеров.
Покажешь как на генериках C# посчитать среднее арифметическое для первых 10 элементов типа System.Numerics.Complex?
Здравствуйте, Ikemefula, Вы писали:
V>>Если речь о принципиальной возможности запрошенного, то это всё не важно. I>Именно это определяет, какой профит будет от языковых фич.
Профит в меньшем кол-ве граблей.
V>>Система типов в дотнете нифига не предсказуемая. I>Я скипнул, потому что к вопросу не относится.
Наоборот. Я увидел язык без встроенных болезней дотнета. А эти болезни тоже не из космоса взялись, а получились как некий компромисс м/у наличием ГЦ и желанием сделать легковестные value-типы.
Здравствуйте, Klapaucius, Вы писали:
K>Вот только результаты экспериментов в экспериментальных языках он никак не учитывает, т.е. готовит "эксперимент" по очередному ознакомлению лбов индустриальных разработчиков с граблями, обнаруженными десятилетия назад.
Прям юношеский максимализм какой-то сорри. ))
Конструкции Swift очевидны и легки для понимания. Средний уровень разработчиков современных аппликух — невысок. Разработчики аппликух редко пишут что-то фундаментальное. 90% работы — это завязать воедино библиотеки ГУИ, низлежащие сетевые и графические фреймворки, плюс 10% целевой логики.
В кач-ве подобного "клея" для ОО-фреймворков язык выглядит очень даже подходящим и недвусмысленным по своему синтаксису.
Здравствуйте, Klapaucius, Вы писали:
K>Это такая деталь реализации, которая делает многие фичи языка мало либо вовсе неприменимыми из-за проблемности и костыльности.
Ну так в дотнете ограничения на семантику value-type и вся сопутствующая россыпь граблей и непоследовательность семантики встроенных массивов и пользовательских контейнеров взялись, наоборот, от присутствия GC.
Простой пример: object.part1.Bounds.Left = 10;
Семантика зависит от типов part1 и Bounds, в зависимости от того, ссылочные типы или нет.
Характерно, что оптимизирующий компилятор, умеющий смотреть вглубь, такую конструкцию разрулил бы даже на value-типах, бо здесь можно обложить локальными пинами всю операцию присваивания. Но вот сохранить ссылку на структуру без сопутствующего пина объекта-владельца уже нельзя (в некоем другом сценарии, например даже в теле св-ва part1.Bounds при возврате значения). И это тянет за собой целую прорву ограничений семантики и популярных для начинающих разработчиков дотнета граблей вокруг value-типов.
Насколько я вижу, подобной кривизны в Swift избежали с самого начала. А это уже интересно.
========
Справделивости ради — кривизна в семантике не от присутствия только GC, ес-но, а в сочетании с мутабельностью, но это уже совсем другой разговор, не об ООП уж точно.
Здравствуйте, D. Mon, Вы писали:
V>> Мне трижды отвечать? DM>Не надо, садись уже, твой ответ услышан.
Ты бы лучше ответил предметно там, где о подробностях речь. Я тебе предложил минимум пару вариантов, а ты испарился.
DM>Оказалось, что не сегодняшний свифт утер нос сегодняшнему шарпу, а "свифт через пять лет" вероятно утрет "шарпу 10 лет назад". Ну да, прогресс.
Хм, итераторы GoF vs map/fold, или подача функтора в некий foreach для произвольного контейнера... не факт что тебе вообще следует так сильно настаивать на своём. Реально, в 2014-м сие смешно, попахивает 90-ми годами. Это минус 20 лет в карму C#, если ты будешь настаивать именно на своём способе решения. Хорошо, что в C# уже доступны и другие способы, например, реактивные либы набирают популярность.
Здравствуйте, vdimas, Вы писали:
V>Бывает так, что запуск программы требует время (на всю установку некоего тяжеловесного окружения). Скажем, запуск вижуал-студии.
V>В этом смысле REPL банально удобнее, т.к. уже при установленном некоем окружении позволяет "играть" с ним.
В отладчике можно вызвать функцию, поменять значения и даже изменить код программы. Этого более чем достаточно для отладки. А вот писать большую программу из репла — это утопия.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
I>>Так давай сравним с C# последним. Задачу тебе дали. Какие проблемы ? Ты же намекаешь, что знаком с платформой неиздалека. Какие проблемы написать одну функцию, которая выдаст среднее арифметической для первых 10 элементов и будет универсальна для всех контейнеров.
V>Покажешь как на генериках C# посчитать среднее арифметическое для первых 10 элементов типа System.Numerics.Complex?
Complex это число, в ём всего две компоненты, действительная и мнимая часть. А речь шла про контейнеры.
если тебя смущает Complex, то для него перегружены операторы, ничего военнго в этом нет.
Здравствуйте, vdimas, Вы писали:
V>>>Если речь о принципиальной возможности запрошенного, то это всё не важно. I>>Именно это определяет, какой профит будет от языковых фич.
V>Профит в меньшем кол-ве граблей.
Показать это ты не можешь, правильно ? Ну, на задаче про 10 первых чисел в разных контейнерах
V>Наоборот. Я увидел язык без встроенных болезней дотнета. А эти болезни тоже не из космоса взялись, а получились как некий компромисс м/у наличием ГЦ и желанием сделать легковестные value-типы.
Здравствуйте, VladD2, Вы писали:
V>>В этом смысле REPL банально удобнее, т.к. уже при установленном некоем окружении позволяет "играть" с ним.
VD>В отладчике можно вызвать функцию, поменять значения и даже изменить код программы. Этого более чем достаточно для отладки. А вот писать большую программу из репла — это утопия.
Отладчик сможет скомпилировать лямбду или макрос ? Крутой, значит, отладчик у Немерле.
Здравствуйте, vdimas, Вы писали:
V>Хм, итераторы GoF vs map/fold, или подача функтора в некий foreach для произвольного контейнера... не факт что тебе вообще следует так сильно настаивать на своём. Реально, в 2014-м сие смешно, попахивает 90-ми годами. Это минус 20 лет в карму C#, если ты будешь настаивать именно на своём способе решения. Хорошо, что в C# уже доступны и другие способы, например, реактивные либы набирают популярность.
Внезапно, в C# foreach может работать и с реактивной коллекцией.
Здравствуйте, vdimas, Вы писали:
V>Ты бы лучше ответил предметно там, где о подробностях речь. Я тебе предложил минимум пару вариантов, а ты испарился.
Я код просил, а не руками махание. Пока ни строчки не получил.
Здравствуйте, vdimas, Вы писали:
V>Покажешь как на генериках C# посчитать среднее арифметическое для первых 10 элементов типа System.Numerics.Complex?
using System;
using System.Collections.Generic;
using System.Numerics;
using System.Linq;
namespace DictionaryPassing
{
public interface CNum<T>
{
T Add(T a, T b);
T FromInt(int a);
}
public interface CReal<T> : CNum<T>
{
T Div(T a, T b);
}
public struct ComplexReal : CReal<Complex>
{
public Complex Div(Complex a, Complex b) { return a/b; }
public Complex Add(Complex a, Complex b) { return a+b; }
public Complex FromInt(int a) { return new Complex(a,0); }
}
static class Utils
{
public static T Avg<T, C>(this IEnumerable<T> xs) where C : CReal<T>, new()
{
var real = new C();
var sum = real.FromInt(0);
var i = 0;
foreach (var x in xs)
{
sum = real.Add(sum, x);
i++;
}
return real.Div(sum, real.FromInt(i));
}
}
class Program
{
static void Main(string[] args)
{
Console.WriteLine(Enumerable.Repeat(new Complex(1, 1), 100).Take(10).Avg<Complex,ComplexReal>());
}
}
}
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Ikemefula, Вы писали:
I>>>Так давай сравним с C# последним. Задачу тебе дали. Какие проблемы ? Ты же намекаешь, что знаком с платформой неиздалека. Какие проблемы написать одну функцию, которая выдаст среднее арифметической для первых 10 элементов и будет универсальна для всех контейнеров.
V>>Покажешь как на генериках C# посчитать среднее арифметическое для первых 10 элементов типа System.Numerics.Complex?
I>Complex это число, в ём всего две компоненты, действительная и мнимая часть. А речь шла про контейнеры. I>если тебя смущает Complex, то для него перегружены операторы, ничего военнго в этом нет.
Ты поставил условие задачи? ОК. Я попросил сначала с тебя обобщенное её решение на генериках для произвольного контейнера. Заодно попросил проверить на аргументе-типе System.Numerics.Complex.
Здравствуйте, Klapaucius, Вы писали:
V>>Покажешь как на генериках C# посчитать среднее арифметическое для первых 10 элементов типа System.Numerics.Complex?
[известное еще в 2005-м году "решение" скипнуто]
Т.е. ни для типа int, ни для float, double, Complex твоё решение не работает, так?
Тут все заранее знали о чем речь, можно было не плодить YA ICalculator<T> или YA IArithmetic<T>, которым уже по 10 лет в обсуждениях на формах. ))
Я лишь демонстрирую оппонентам их демагогию. Тем более, в первоначальном условии попросили показать работоспособность на встроенном int.
Сразу было известно, что на генериках сие нерешаемо в общем виде для произвольных типов, имеющих переопределенные арифметические операторы.
Зато такая задача решается на шаблонах С++. Я лишь заметил оппонентам, что обобщенное программирование в Swift должно быть ближе к C++, чем к генерикам дотнета. Но они не поняли, похоже. Еще заметил, что для прохода по коллекции не нужны итераторы, если у нас имеется функциональный тип и некий метод коллекции foreach, принимающий функтор/делега в кач-ве аргумента. Этого они тоже не поняли. ))
Здравствуйте, vdimas, Вы писали:
V>Т.е. ни для типа int, ни для float, double, Complex твоё решение не работает, так?
Для Complex работает, для int, float, double пишете имплементации CReal и тоже работать будет.
V>Я лишь демонстрирую оппонентам их демагогию. Тем более, в первоначальном условии попросили показать работоспособность на встроенном int.
В чем демогогия? Какая проблема со "встроенным" int?
V>Сразу было известно, что на генериках сие нерешаемо в общем виде для произвольных типов, имеющих переопределенные арифметические операторы.
Наоборот, решаемо и обычно именно так как я показал и решается, в GHC-хаскеле, например.
V>Зато такая задача решается на шаблонах С++. Я лишь заметил оппонентам, что обобщенное программирование в Swift должно быть ближе к C++, чем к генерикам дотнета. Но они не поняли, похоже.
Как что-то хорошее.
V>Еще заметил, что для прохода по коллекции не нужны итераторы, если у нас имеется функциональный тип и некий метод коллекции foreach, принимающий функтор/делега в кач-ве аргумента. Этого они тоже не поняли. ))
В ленивом языке foldr == итератор, все возможности покрываются. В строгом это не так.
Вы давайте, не увиливайте, а решайте задачу D.Mon — я вашу решил.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, vdimas, Вы писали:
DM>>Я код просил, а не руками махание. Пока ни строчки не получил. V>Ты пока попросил решение, такое же как где-то. Известная демагогия. Давай задачу целиком.
Здравствуйте, vdimas, Вы писали:
V>Я лишь демонстрирую оппонентам их демагогию. Тем более, в первоначальном условии попросили показать работоспособность на встроенном int. V>Сразу было известно, что на генериках сие нерешаемо в общем виде для произвольных типов, имеющих переопределенные арифметические операторы.
Ты сам развел демагогию. Вопрос был простейший, с интами. Приплетать комплексные числа и обобщать обобщуемое никто не просил.
Кроме того, мне эта задача интересна не в сравнении с C#, а в сравнении с другими современными языками. Если попросить Клапауция решить ее на хаскеле, он тоже скажет "на генериках сие нерешаемо"? Смешно же.
V>Зато такая задача решается на шаблонах С++. Я лишь заметил оппонентам, что обобщенное программирование в Swift должно быть ближе к C++, чем к генерикам дотнета. Но они не поняли, похоже. Еще заметил, что для прохода по коллекции не нужны итераторы, если у нас имеется функциональный тип и некий метод коллекции foreach, принимающий функтор/делега в кач-ве аргумента. Этого они тоже не поняли. ))
Да все мы поняли. Только того метода у свифтовых коллекций нет(?), поэтому это не решение, а словоблудие.
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, vdimas, Вы писали:
V>>Покажешь как на генериках C# посчитать среднее арифметическое для первых 10 элементов типа System.Numerics.Complex?
K>
K>
Ну ты и дал. А больше кода не мог нагнать ?
var items = new [] { new Complex(12, 6), дописать сколько надо, по желанию};
Console.Write(items.Take(10).Aggregate(new Complex(0,0), (acc,item) => acc + item));
Здравствуйте, Klapaucius, Вы писали:
I>>Ну ты и дал. А больше кода не мог нагнать ?
I>>
I>>var items = new [] { new Complex(12, 6), дописать сколько надо, по желанию};
I>>Console.Write(items.Take(10).Aggregate(new Complex(0,0), (acc,item) => acc + item));
I>>
K>Я понял его задачу (и, судя по всему, правильно) как написание обобщенного кода для вычисления среднего. У вас же код — не обобщенный.
Мы говорили про контейнеры. Так что смотрия где код не обобщенный. Ты можешь взять любой контейнер, даже реактивный, и пускануть этот же код. Более того, даже если ты напишешь свой контейнер, он сам собой заработает, что очевидно.
Здравствуйте, vdimas, Вы писали:
V>Тут все заранее знали о чем речь, можно было не плодить YA ICalculator<T> или YA IArithmetic<T>, которым уже по 10 лет в обсуждениях на формах. )) V>Я лишь демонстрирую оппонентам их демагогию. Тем более, в первоначальном условии попросили показать работоспособность на встроенном int.
В первоначальном условии было про контейнеры.
V>Зато такая задача решается на шаблонах С++. Я лишь заметил оппонентам, что обобщенное программирование в Swift должно быть ближе к C++, чем к генерикам дотнета. Но они не поняли, похоже. Еще заметил, что для прохода по коллекции не нужны итераторы, если у нас имеется функциональный тип и некий метод коллекции foreach, принимающий функтор/делега в кач-ве аргумента. Этого они тоже не поняли. ))
Все что надо знали и без тебя. Главное, что поняли, так это твою неспособность приводить код.
Здравствуйте, vdimas, Вы писали:
V>Ты поставил условие задачи? ОК. Я попросил сначала с тебя обобщенное её решение на генериках для произвольного контейнера. Заодно попросил проверить на аргументе-типе System.Numerics.Complex.
V>Думаю, ты этого не покажешь. Даже для int.
Я уже показал. Ты не забы, что речь про контейнеры ?
Либу в которой нет внятного дизайна контейнеров, не спасет даже самый лучший язык.
Здравствуйте, Ikemefula, Вы писали:
I>Мы говорили про контейнеры. Так что смотрия где код не обобщенный. Ты можешь взять любой контейнер, даже реактивный, и пускануть этот же код. Более того, даже если ты напишешь свой контейнер, он сам собой заработает, что очевидно.
Ну да, любой контейнер с Complex, а не любой контейнер с числами.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
I>>Мы говорили про контейнеры. Так что смотрия где код не обобщенный. Ты можешь взять любой контейнер, даже реактивный, и пускануть этот же код. Более того, даже если ты напишешь свой контейнер, он сам собой заработает, что очевидно.
K>Ну да, любой контейнер с Complex, а не любой контейнер с числами.
В том то и дело, что речь шла про контейнеры, т.е. IEnumerable и тд. Товарищ просто не знал, как это сделано в Swift и решил перепрыгнуть на проблемы рантайма и другие, которые только ухитрился углядеть.
Здравствуйте, Ikemefula, Вы писали:
I>В том то и дело, что речь шла про контейнеры, т.е. IEnumerable и тд. Товарищ просто не знал, как это сделано в Swift и решил перепрыгнуть на проблемы рантайма и другие, которые только ухитрился углядеть.
Да я сразу понял, что он контратаковал на другом направлении. Какая разница, если все равно можно решение дать?
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Ikemefula, Вы писали:
V>>Ты поставил условие задачи? ОК. Я попросил сначала с тебя обобщенное её решение на генериках для произвольного контейнера. Заодно попросил проверить на аргументе-типе System.Numerics.Complex.
V>>Думаю, ты этого не покажешь. Даже для int.
I>Я уже показал.
Где?
I>Ты не забы, что речь про контейнеры ?
Речь о чьей-то упертости, а не о контейнерах.
Вы настаиваете на итераторах GoF, а я настаиваю на принятом в функциональном виде способа обхода контейнера. С т.з. подхода итераторов — классика IoC.
Следуя нынешней моде вы в пролете. ))
I>Либу в которой нет внятного дизайна контейнеров, не спасет даже самый лучший язык.
А что первично, либа или язык? ))
Да и вообще, дизайн там достаточный, просто ты не понимаешь как им пользоваться. Шаблонное мышление-с.
Кароч. Мне надоела ваша упертость. Мне прям сейчас некогда ставить виртуалку с новой макосью и разворачивать там среду (на досуге поиграюсь с этим).
Вот тебе аналог контейнера из С++. Использованы только те ср-ва языка, аналоги которых есть в Swift, из описания языка и примеров.
template<T>
class MyContainer {
vector<T> items_;
public:
typedef function<bool(T&)> ForEachDelegate; // returns true to continue enumerationvoid foreach(ForEachDelegate d) {
for(auto i = items_.begin(); i != items_.end(); ++i)
if(!d(*i))
break;
}
};
Заметь, никакого дизайна контейнера нет. Есть лишь публичный foreach.
Мне расписывать далее решение исходного примера или уже стыдно? ))
Здравствуйте, D. Mon, Вы писали:
DM>Кроме того, мне эта задача интересна не в сравнении с C#, а в сравнении с другими современными языками.
Откровенно говоря, не вижу особого смысла сравнивать Swift с "современными языками". Всякие Go-Swiftы — это подзадержавшиеся Явы-Шарпы, с ними и имеет смысл сравнивать. Языки вроде окамлов-хаскелей-идрисов — это другие поколения и эпохи, сравнивая с ними можно получить только один ответ: в госвифтах все плохо, ничего нет.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, vdimas, Вы писали: V>>Т.е. ни для типа int, ни для float, double, Complex твоё решение не работает, так? K>Для Complex работает, для int, float, double пишете имплементации CReal и тоже работать будет.
Не работает обобщенное решение для Complex, как и для остальных типов. К каждому типу нужно сделать копипасту необобщенного аналога твоего ComplexReal. В итоге, сама обобщенность решения теряет смысл — точно такой же копипастой можно решать исходную задачу без всяких генериков.
V>>Я лишь демонстрирую оппонентам их демагогию. Тем более, в первоначальном условии попросили показать работоспособность на встроенном int. K>В чем демогогия? Какая проблема со "встроенным" int?
Такая же, как с Complex или любым другим типом, имеющим переопределенные операторы (не обязательно арифметические). Не работает "изкаробки". Признаюсь, я удивился, увидев твоё "решение". Т.е. до какой степени надо держать тут всех за дураков, чтобы не понять утверждение о том, почему в C# этого нельзя сделать. Сию тему подробно разжевали еще в первые дни после анонса генериков 10 лет назад. Предлагались разные способы, поболее универсальные, чем твой. Например, многие целевые алгоритмы будут быстрее при явной диспетчеризации по типу аргумента-генерика, например, встроенные типы поддерживают IConvertible, поэтому можно довольно быстро отсечь семейство нужных типов. Для остальных можно попытаться через рефлексию найти переопределенные операторы.
V>>Сразу было известно, что на генериках сие нерешаемо в общем виде для произвольных типов, имеющих переопределенные арифметические операторы. K>Наоборот, решаемо и обычно именно так как я показал и решается, в GHC-хаскеле, например.
В случае C# это НЕ обобщенное решение. Ведь для каждого типа, помимо переопределения операторов, надо определить явную специализацию класса-хелпера. Более того, тип класса-хелпера надо затем всегда указывать явно. В твоём Хаскеле ничего этого делать не надо, как и в С++ — всё подхватывается "само".
V>>Зато такая задача решается на шаблонах С++. Я лишь заметил оппонентам, что обобщенное программирование в Swift должно быть ближе к C++, чем к генерикам дотнета. Но они не поняли, похоже.
K>Как что-то хорошее.
??
V>>Еще заметил, что для прохода по коллекции не нужны итераторы, если у нас имеется функциональный тип и некий метод коллекции foreach, принимающий функтор/делега в кач-ве аргумента. Этого они тоже не поняли. ))
K>В ленивом языке foldr == итератор, все возможности покрываются. В строгом это не так.
Какая из возможностей не покрывается?
K>Вы давайте, не увиливайте, а решайте задачу D.Mon — я вашу решил.
1. Ты ничего не решил, готового к использованию изкаробки обобщенного решения так и не было. В дотнете автоматическое решение возможно только на рефлексии, увы.
По ссылке объявление типа-контейнера, на котором исходная задача решаема в обобщенном виде и будет работать изкаробки, в отличие от твоего решения.
Опущенную часть решения оставляю для самостоятельной работы, там несложно. ))
Здравствуйте, D. Mon, Вы писали:
DM>>>Я код просил, а не руками махание. Пока ни строчки не получил. V>>Ты пока попросил решение, такое же как где-то. Известная демагогия. Давай задачу целиком.
DM>Не просил я "такое же как где-то", очнись. Задача уже сформулирована.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, vdimas, Вы писали:
V>>Я лишь демонстрирую оппонентам их демагогию. Тем более, в первоначальном условии попросили показать работоспособность на встроенном int. V>>Сразу было известно, что на генериках сие нерешаемо в общем виде для произвольных типов, имеющих переопределенные арифметические операторы.
DM>Ты сам развел демагогию. Вопрос был простейший, с интами. Приплетать комплексные числа и обобщать обобщуемое никто не просил.
Я просил. Тебя. А твой коллега показал, что твой пример — фикция, достаточно было сменить условие с поиска минимального на поиск среднего. И тут ты сел в разгона в лужу. ))) А на Swift решаемы в общем виде оба примера, в отличие от C#.
DM>Кроме того, мне эта задача интересна не в сравнении с C#,
Некрасиво так юлить. )))
Твои же слова были о "сравнении с C# десятилетней давности". Столько пафоса и так громко в лужу.
Че ты такой нервный вообще с этим Swift? Расслабься уже. Не хочешь писать на нём — не пиши. Не понимаешь описания языка — не читай. Не умеешь решать свою же задачу БЕЗ итераторов — не решай... используй только те языки, на которых сможешь решить... какие проблемы?
DM>а в сравнении с другими современными языками. Если попросить Клапауция решить ее на хаскеле, он тоже скажет "на генериках сие нерешаемо"? Смешно же.
На Хаскеле как раз решаемо даже более сложное условие (с арифметическими вычислениями которое). Причем, решаемо и работает изкаробки, в отличие от порнографии на C#.
V>>Зато такая задача решается на шаблонах С++. Я лишь заметил оппонентам, что обобщенное программирование в Swift должно быть ближе к C++, чем к генерикам дотнета. Но они не поняли, похоже. Еще заметил, что для прохода по коллекции не нужны итераторы, если у нас имеется функциональный тип и некий метод коллекции foreach, принимающий функтор/делега в кач-ве аргумента. Этого они тоже не поняли. ))
DM>Да все мы поняли. Только того метода у свифтовых коллекций нет(?), поэтому это не решение, а словоблудие.
В твоём условии речь была о именно о пользовательской коллекции. Ты по ссылке ходил или как? Не надоело в лужу падать-то?
Здравствуйте, vdimas, Вы писали:
V>Очнись сам. Я словесное решение ответил сразу же. Твои проблемы, что ты не понимаешь простых вещей. V>Вот тут код: http://www.rsdn.ru/forum/philosophy/5637904.1
Здравствуйте, Klapaucius, Вы писали:
I>>В том то и дело, что речь шла про контейнеры, т.е. IEnumerable и тд. Товарищ просто не знал, как это сделано в Swift и решил перепрыгнуть на проблемы рантайма и другие, которые только ухитрился углядеть.
K>Да я сразу понял, что он контратаковал на другом направлении. Какая разница, если все равно можно решение дать?
Представь себе, ты продавил банан на Химмельсдорфе и остаётся захватить базу. Противник пытается контратаковать на железной дороге. Ты предлагаешь бросить захват ?
Здравствуйте, vdimas, Вы писали:
I>>Ты не забы, что речь про контейнеры ?
V>Речь о чьей-то упертости, а не о контейнерах. V>Вы настаиваете на итераторах GoF, а я настаиваю на принятом в функциональном виде способа обхода контейнера. С т.з. подхода итераторов — классика IoC. V>Следуя нынешней моде вы в пролете. ))
Ты предлагаешь игнорировать встроеные операторы ? А что еще ты предлагаешь игнорироват в таком классном языке ?
I>>Либу в которой нет внятного дизайна контейнеров, не спасет даже самый лучший язык.
V>Кароч. Мне надоела ваша упертость. Мне прям сейчас некогда ставить виртуалку с новой макосью и разворачивать там среду (на досуге поиграюсь с этим).
Вот как поиграешь, так с кодом и приходи. За тобой, кстати , должок — два примера кода для демонстрации асинхронщины с прошлой осени, тех самых "студенту на пару часов".
Здравствуйте, vdimas, Вы написали серию искрометных разоблачений.
V>Не работает обобщенное решение для Complex, как и для остальных типов. К каждому типу нужно сделать копипасту необобщенного аналога твоего ComplexReal. В итоге, сама обобщенность решения теряет смысл — точно такой же копипастой можно решать исходную задачу без всяких генериков.
Все пропало: ad-hoc полиморфизм не имеет смысла: оказывается, что зависимый от типа код — это просто копипаста и вместо написания всяких имплементаций тайпклассов можно просто копипастить — то на то и получится!
V>Такая же, как с Complex или любым другим типом, имеющим переопределенные операторы (не обязательно арифметические). Не работает "изкаробки". Признаюсь, я удивился, увидев твоё "решение". Т.е. до какой степени надо держать тут всех за дураков, чтобы не понять утверждение о том, почему в C# этого нельзя сделать. Сию тему подробно разжевали еще в первые дни после анонса генериков 10 лет назад.
Все пропало: параметрический полиморфизм не нужен — это разжевали еще 10 лет назад!
V>Предлагались разные способы, поболее универсальные, чем твой. Например, многие целевые алгоритмы будут быстрее при явной диспетчеризации по типу аргумента-генерика,
Что, разумеется невозможно при параметрическом полиморфизме, и не совместимо с параметричностью. т.е. либо динамическая безтипизация, либо недозавтипы (хотя-бы GADTы или "язык модулей"), либо шаблонизатор для кода с "текстовой" подстановкой.
Единственный способ "диспетчеризации" по типу при обычном параметрическом полиморфизме в моем примере и продемонстрирован.
V>В случае C# это НЕ обобщенное решение. Ведь для каждого типа, помимо переопределения операторов, надо определить явную специализацию класса-хелпера.
Решение обобщенное, что очевидно следует из типа Avg:
T Avg<T, C>(this IEnumerable<T> xs) where C : CReal<T>, new()
"Явную специализацию класса хелпера" написать конечно надо. Она и в том же хаскеле написана.
V>Более того, тип класса-хелпера надо затем всегда указывать явно.
Это точно, но автоподстановка словарей далеко не везде есть, шарп не один такой инвалид.
V>В твоём Хаскеле ничего этого делать не надо,
Подставлять словари самому не надо, а писать их конечно надо (если они сами не выводятся, но и дотнете можно словари генерировать всякими костыльными способами)
V>как и в С++ — всё подхватывается "само".
В С++ подхватываться нечему, там ни параметрического полиморфизма, ни передачи словаря нет.
K>>Как что-то хорошее. V>??
Как будто то, "что обобщенное программирование в Swift должно быть ближе к C++" — это что-то хорошее.
V>Какая из возможностей не покрывается?
"Продуктивность" свертки, например. Ей нельзя управлять, просто потребляя результат (для чего итератор и нужен). Впрочем, с помощью континьюейшенов можно некий воркараунд накостылить.
V>1. Ты ничего не решил, готового к использованию изкаробки обобщенного решения так и не было. В дотнете автоматическое решение возможно только на рефлексии, увы.
Потому, что дотнетные разработчики (а точнее, принимающие решения) не читатели и не моргнув глазом пустили в свободное плаванье дизайнерское решение, которое целый фрактал проблем порождает. При этом то, что решение проблемное на тот момент было известно лет 30 и лет 25 как проблемы были решены. Разумеется, этого никто не заметил, пока ручка грабель не ознакомила с ними индустриального разработчика.
Проблема тут не в параметрическом полиморфизме, а в ограничении квантификации с помощью интерфейсов.
Причем в этих пресловутых спорах "10 лет назад" им противостояли сторонники аналогичного костыльного носолюшена, что могло бы быть даже смешным, если бы не было грустным.
Но нормальное решение можно закодировать таким вот костыльным образом. Собственно, всякие костыльные воркараунды — единственные способы писать обобщенный код в индус триальных языках, их разработчики же думают не о том, как обобщенный код писать, а о том, как притянуть за уши какой-нибудь треш-угар вроде "знакомого практикам" наследования или шаблонизирования/подстановки туда, где без них только лучше будет.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
V>>Покажешь как на генериках C# посчитать среднее арифметическое для первых 10 элементов типа System.Numerics.Complex?
Кода-то сколько!
private static T Average<T>(IEnumerable<T> items, Func<T, T, T> add, Func<T, int, T> divide)
{
var count = 0;
var sum = items.Aggregate(default(T), (i, j) => { count++; return add(i, j); });
return divide(sum, count);
}
[Test]
public void Test()
{
var items = new [] { new Complex(1, 2), new Complex(2, 3) };
var average = Average(items, (i, j) => i + j, (v, n) => v / n);
}
HgLab: Mercurial Server and Repository Management for Windows
Н>private static T Average<T>(IEnumerable<T> items, Func<T, T, T> add, Func<T, int, T> divide)
Н>{
Н> var count = 0;
Н> var sum = items.Aggregate(default(T), (i, j) => { count++; return add(i, j); });
Н> return divide(sum, count);
Н>}
Н>[Test]
Н>public void Test()
Н>{
Н> var items = new [] { new Complex(1, 2), new Complex(2, 3) };
Н> var average = Average(items, (i, j) => i + j, (v, n) => v / n);
Н>}
Н>
Самое главное — словарь не используется повторно (по замыслу, это просто часть реализации Complex), а пишется по месту.
Кроме того: замучаетесь всю арифметику по одной функции передавать, да и лямбды не инлайнятся.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Самое главное — словарь не используется повторно (по замыслу, это просто часть реализации Complex), а пишется по месту.
Какой словарь?
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Ikemefula, Вы писали:
I>Вот как поиграешь, так с кодом и приходи.
Использованы только те ср-ва языка, аналоги которых есть в Swift, из описания языка и примеров.
I>За тобой, кстати , должок — два примера кода для демонстрации асинхронщины с прошлой осени, тех самых "студенту на пару часов".
Чего-чего? Там были все демонстрации.
Просто ты так и не смог поставить условие задачи. А которое поставил — тебе показали минимум дважды. Тебе не понравилось? — твои проблемы.
Более того, так и не понял принципы работы разных диспетчеров аснхронщины и вообще как она работает. ))
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, andyag, Вы писали:
A>>"Для быстрого тестирования некоторых вещей" достаточно не бояться писать тесты в любых их вариациях: юнит тесты, интеграционные тесты, учебные тесты, воспроизводилки интересных сценариев. Ключевое слово — воспроизводимость.
I>И запускать эти тесты надо полагать, придется на боевой системе ?
Там чуть выше по треду описан контекст. Ни про какие боевые системы и самоотверженных девопсов речи не было: "для быстрого тестирования некоторых вещей".
A>>Насчёт прототипирования вообще мысль не понял. ИМХО, единственное удачное применение REPL — это когда к запущенному приложению можно подключиться через какой-нибудь SSH и пощупать как у него дела дёргая всякие методы всяких объектов.
I>Эта хрень дает возможности сократить на прядок другой количество перезапусков приложения. Если для каждого перезапуска надо собирать пекадж или делать деплоймент, то разница просто сумасшедшая.
Расскажите пожалуйста какой-то юзкейз, отдалённо похожий на реальный мир.
Здравствуйте, vdimas, Вы писали:
I>>За тобой, кстати , должок — два примера кода для демонстрации асинхронщины с прошлой осени, тех самых "студенту на пару часов".
V>Чего-чего? Там были все демонстрации.
Не было. Последняя твоя отписка была вот такой: "нициализируешь локальную переменную и вперед далее вниз по правилам процедурной/функциональной декомпозиции"
Здравствуйте, D. Mon, Вы писали:
DM>Смишно. Распространенный язык, недоступный на линуксе и винде.
Ну т.к. там llvm и есть возможность подключать библиотеки на C, то не вижу никаких проблем для кроссплатформенности, даже если Apple не захочет. Другое дело, что если они не захотят, то скорее всего не будет мощного развития инструментов на других платформах (т.е. будет расклад как у D на всех платформах), а наличие такой поддержки является одним из важных бонусов Swift'a...
DM>Что до носа C#, то вот простейший вопрос: напиши на свифте генерик-функцию, работающую с разными линейными контейнерами (массив, два вида списков, deque). Скажем, на входе контейнер с интами, найти минимум из первых 10 положительных чисел. Второй вопрос: добавить свой контейнер и чтобы эта функция без изменений с ним заработала.
Хгм, не ожидал от тебя такого вопроса. Ты же знаешь, что в том же D (да и в C++ и ещё много где) вопросы подобных контейнеров решаются в стандартной библиотеке (описание которой для Swift'a никто из нас тут ещё не видел), а не в конструкциях самого языка. От языка то собственно вообще практически ничего не требуется, максимум какой-то инструмент для поддержки foreach от произвольных коллекций (и такое есть — ты сам показал по ссылке ниже). Так что не вижу вообще никакого смысла обсуждать подобные вопросы, не держа перед глазами описание стандартной библиотеки Swift'a.
P.S. Eсли бы в Swift'е было мощное метапрограммирование (кстати, его ещё не поздно добавить с помощью макросов) и Apple дала бы обещание поддерживать его не только под свои платформы, то на мой вкус такой язык стал бы даже поинтереснее D... Ну а пока что D мне всё же нравится больше. Но это мой специфичный вкус (не боюсь сложного кода, бывающего в МП), а для очень многих Swift может выглядеть идеалом уже даже и такой.
Здравствуйте, andyag, Вы писали:
A>>>"Для быстрого тестирования некоторых вещей" достаточно не бояться писать тесты в любых их вариациях: юнит тесты, интеграционные тесты, учебные тесты, воспроизводилки интересных сценариев. Ключевое слово — воспроизводимость.
I>>И запускать эти тесты надо полагать, придется на боевой системе ?
A>Там чуть выше по треду описан контекст. Ни про какие боевые системы и самоотверженных девопсов речи не было: "для быстрого тестирования некоторых вещей".
Как тестировать мой код, все понятно. А вот как тестировать интеграцию с системой, т.е. нативными решения, вот это поинтереснее.
I>>Эта хрень дает возможности сократить на прядок другой количество перезапусков приложения. Если для каждого перезапуска надо собирать пекадж или делать деплоймент, то разница просто сумасшедшая.
A>Расскажите пожалуйста какой-то юзкейз, отдалённо похожий на реальный мир.
Например меня есть мобильное приложение. Есть баг, который воспроизводится в релизной версии, но не воспроизводится в девелоперской. Я подключаю отладчик и если в нём внятный репл, собираю нужную мне информацию
Например : "А что вернет вон та функция, если перед этим я вызову то и это"
И здесь нужна возможность писать полноценный код. Например если я проверяю результаты запросов, в которых есть лямбды, я хочу что бы отладчик позволял эти лямбды.
Здравствуйте, Klapaucius, Вы писали:
V>>Не работает обобщенное решение для Complex, как и для остальных типов. К каждому типу нужно сделать копипасту необобщенного аналога твоего ComplexReal. В итоге, сама обобщенность решения теряет смысл — точно такой же копипастой можно решать исходную задачу без всяких генериков.
K>Все пропало: ad-hoc полиморфизм не имеет смысла: оказывается, что зависимый от типа код — это просто копипаста и вместо написания всяких имплементаций тайпклассов можно просто копипастить — то на то и получится!
Да нет. Оказывается, что ad-hoc полиморфизм не поддерживается в полной мере генериками дотнета, только и всего. Иначе бы он сам подхватывал переопределённые операторы. А тебя просто несет на ровном месте. Знаешь же прекрасно о чем речь, но "баба Яга против" )) Остаётся только язвить. ))
V>>Такая же, как с Complex или любым другим типом, имеющим переопределенные операторы (не обязательно арифметические). Не работает "изкаробки". Признаюсь, я удивился, увидев твоё "решение". Т.е. до какой степени надо держать тут всех за дураков, чтобы не понять утверждение о том, почему в C# этого нельзя сделать. Сию тему подробно разжевали еще в первые дни после анонса генериков 10 лет назад.
K>Все пропало: параметрический полиморфизм не нужен — это разжевали еще 10 лет назад!
Если в полноценной реализации, то нужен, ес-но. Но для привычного ООП он почти всегда "недо-", бо идет только по первому аргументу this.
V>>Предлагались разные способы, поболее универсальные, чем твой. Например, многие целевые алгоритмы будут быстрее при явной диспетчеризации по типу аргумента-генерика,
K>Что, разумеется невозможно при параметрическом полиморфизме, и не совместимо с параметричностью. т.е. либо динамическая безтипизация, либо недозавтипы (хотя-бы GADTы или "язык модулей"), либо шаблонизатор для кода с "текстовой" подстановкой.
Ну а что делать, если всё кривое? )))
K>Единственный способ "диспетчеризации" по типу при обычном параметрическом полиморфизме в моем примере и продемонстрирован.
Ты продемонстрировал костыль в условиях "недо-". Но это нахальство какое-то считать всех дураками... бо именно эти костыли обсуждали еще лет 10 назад. Предлагая нарисовать пример на C# я предполагал, что все прекрасно в курсе, о чем речь. Получается, ты один был не в курсе или считаешь всех дураками, "изобретя" сотый вариант одного и того же.
V>>В случае C# это НЕ обобщенное решение. Ведь для каждого типа, помимо переопределения операторов, надо определить явную специализацию класса-хелпера.
K>Решение обобщенное, что очевидно следует из типа Avg: K>
K>T Avg<T, C>(this IEnumerable<T> xs) where C : CReal<T>, new()
K>
Нет. Зависимость конкретных типов T->C должна быть неявной. Явное её указание — избыточность, делает решение недо-обобщенным.
Можно так:
T Avg<T>(this IEnumerable<T> xs) where T : INumber<T>, new()
Как и в Хаскель, собсно. (только с той разницей, что в дотнете INumber<T>, сцуко, описывает контракт только по одному аргументу this... но и этого могло бы хватить для арифметики)
K>"Явную специализацию класса хелпера" написать конечно надо. Она и в том же хаскеле написана.
Я тебе уже показал абзацем выше аналог на C# того, как это есть в Хаскеле. Заканчивай уже спекулировать. Словами я сиё тоже сказал еще несколько постов назад. Не верю, что ты не понял, о чем речь.
Ес-но, реализация арифметических операторов для Complex должна быть где-то описана. Но не дважды же! В Хасклеле бери любую либу с каким-нить MegaComplex, да пользуйся. А в твоём решении на C# надо еще раз по операторам пройтись да продублировать их. Что-то не так в консерватории, не правда ли? ))
V>>Более того, тип класса-хелпера надо затем всегда указывать явно. K>Это точно, но автоподстановка словарей далеко не везде есть, шарп не один такой инвалид.
V>>В твоём Хаскеле ничего этого делать не надо, K>Подставлять словари самому не надо, а писать их конечно надо (если они сами не выводятся, но и дотнете можно словари генерировать всякими костыльными способами)
Ммм... ты действительно не понял пару постов выше намек на то, как это надо было сделать в C#? ))
Блин, ты же сам всё правильно говорил про Хаскель! Модель типов дотнета позволяет делать так же. Просто не сделано для встроенных типов. Но даже при этом можно было бы арифметические операторы подхватывать автоматом и на этапе генерации бинарников подставлять в тела генериков нужный код. Даже можно обойтись существующим стандартом на метаинформацию и байт-код, достаточно компилятором генерить фиктивный IOperators<> в байт-коде, а во время JIT-а просто знать этот интерфейс "в лицо" и при его фиктивной реализации просто подставлять статически-переопределенные операторы, тогда тебе не надо было бы ручками описывать свой ComplexReal.
V>>как и в С++ — всё подхватывается "само". K>В С++ подхватываться нечему, там ни параметрического полиморфизма, ни передачи словаря нет.
А зачем параметрический полиморфизм в сценариях, где уточненные типы выводятся еще на этапе компиляции?
Эдак тебя несет. Мы обсуждали конкретный пример, где параметрический полиморфизм времени исполнения не нужен ни разу.
K>>>Как что-то хорошее. V>>??
K>Как будто то, "что обобщенное программирование в Swift должно быть ближе к C++" — это что-то хорошее.
Насмешил. В Хаскеле не всегда параметрический полиморфизм нужен в рантайм. 99% сценариев разруливаются на этапе компиляции, т.е. обобщенное программирование в этих сценариях не далеко ушло от С++ — обычная "текстовая подстановка" в итоге. Собсно, даже формат библиотек Хаскеля — это упакованный и размеченный результат парсинга текста (считай тупо AST исходников либы), а не объектный код.
V>>Какая из возможностей не покрывается?
K>"Продуктивность" свертки, например. Ей нельзя управлять, просто потребляя результат (для чего итератор и нужен). Впрочем, с помощью континьюейшенов можно некий воркараунд накостылить.
Конечно, можно на продложениях или автоматах.
Есть еще способ: IoC, потреблять результат реактивным способом, управляя потреблением "где-то" в конце цепочки обработки (вызова). Непривычный для функциональщика подход, не? ))
V>>1. Ты ничего не решил, готового к использованию изкаробки обобщенного решения так и не было. В дотнете автоматическое решение возможно только на рефлексии, увы.
K>Потому, что дотнетные разработчики (а точнее, принимающие решения) не читатели и не моргнув глазом пустили в свободное плаванье дизайнерское решение, которое целый фрактал проблем порождает.
Воооот. Именно.
А конкретно в этой ветке мне постарались надавать по щщам именно из-за попытки сравнения со "священной коровой". Я лишь заметил, что многих проблем C# в Swift нет.
Я не спорю, что до "чистых" языков ему далеко. Это гибрид и как любой гибрид состоит из компромиссов. Но в C# есть даже такие компромиссы, увы, которые вовсе не требовались. И ты наглядно их показал в своей собственной реализации yet another IArithmetic<T>.
K>При этом то, что решение проблемное на тот момент было известно лет 30 и лет 25 как проблемы были решены. Разумеется, этого никто не заметил, пока ручка грабель не ознакомила с ними индустриального разработчика.
Ну дело еще в том, что это выдавалось на-гора бесплатно.
И всё-таки в джаве и дотнете не в языке гвоздь, а в миллионах строк библиотек со сложным, но достаточно надежно оттестированным функционалом. Всё вместе это "платформа" для современных сложных приложений. Сиё накладывает определенный отпечаток и на "порог вхождения" и на стоимость разработки инструментария (попробуй-ка прикрути полноценный рефакторинг в Хаскель? ) и т.д. и т.п.
Поэтому тут всё как раз понятно, если не становится в позу эдакого борца-пуриста. Ей богу облом просто сыпать тонной известных до банальности аргументов, ты их и сам прекрасно знаешь. Просто поза такая, походу.
K>Проблема тут не в параметрическом полиморфизме, а в ограничении квантификации с помощью интерфейсов.
Да!
Хотя для value-типов для тех же генереков JIT генерит код, который нигде по-факту методы интерфейсов не вызывает!
Т.е. сие ограничение интерфейсов только на экземплярные методы можно было бы обойти, добавив возможность задавать некий "интерфейс для статических методов", как раз арифметика туда попала бы, а связь T->C в твоём примере была однозначной и не требовала бы явного задания. (Это был бы, конечно не интерфейс в ООП-смысле, а чистый "контракт", бо интерфейс описывает лишь контракт на экземплярные методы).
K>Но нормальное решение можно закодировать таким вот костыльным образом.
Ну да. Иначе бы я не предлагал его показать. При всей демонстрируемой тобой годами грамотности мне с трудом удаётся убедить себя, что конкретно в этой ветке ты выступил простаком. Но, похоже, именно так и есть. Без обид. ))
Что касается по-делу. Параметрический полиформизм генериков C# показывает свою силу только в рекурсивных, относительно типов, сценариях, например:
struct Test<T> where T : struct
{
public void Func<T1>() where T1 : struct
{
Func<Test<T1>>();
}
}
Что как бы на практике появляется с фактически нулевой вероятностью. Во всех остальных случаях, хоть JIT разворачивает генерики только в рантайм, но в обычном же коде мы вызываем генерики таким образом, что компилятор может ресолвить все типы + проверяет ограничения. Т.е. коль в обычном использовании мы имеем дело только с compile-time сценарием, то те же шаблоны С++ покрывают эти сценарии... ну и покрывают дополнительно еще статические методы, операторы, "видит" внутренние типы (сколь угодно рекурсивно), т.е. много еще чего, за счет чего чуток помощнее будут.
K>Собственно, всякие костыльные воркараунды — единственные способы писать обобщенный код в индус триальных языках, их разработчики же думают не о том, как обобщенный код писать, а о том, как притянуть за уши какой-нибудь треш-угар вроде "знакомого практикам" наследования или шаблонизирования/подстановки туда, где без них только лучше будет.
Ну вот мне сходу показалось, что в Swift таких воркараундов должно быть поменьше.
Здравствуйте, Ikemefula, Вы писали:
K>>Ну да, любой контейнер с Complex, а не любой контейнер с числами.
I>В том то и дело, что речь шла про контейнеры, т.е. IEnumerable и тд. Товарищ просто не знал, как это сделано в Swift и решил перепрыгнуть на проблемы рантайма и другие, которые только ухитрился углядеть.
Я же тебе сразу сказал, что ты не понял всей прелести собственной задачи.
Тебе лучше внимательно читать, что именно обсуждается. ))
В твоём стиле это прекрасно делается и в Swift, аналог контейнера на С++ я уже показал. Написать тело нужного функтора оставил для самостоятельной работы. Использовались только конструкции, которые имеют полный аналог в Swift, поэтому со своими спекуляциями идешь сразу лесом.
Здравствуйте, alex_public, Вы писали:
_>Ну т.к. там llvm и есть возможность подключать библиотеки на C, то не вижу никаких проблем для кроссплатформенности, даже если Apple не захочет.
А сам компилятор кто будет писать и портировать? Он разве открытый? License: proprietary
_>Хгм, не ожидал от тебя такого вопроса. Ты же знаешь, что в том же D (да и в C++ и ещё много где) вопросы подобных контейнеров решаются в стандартной библиотеке (описание которой для Swift'a никто из нас тут ещё не видел), а не в конструкциях самого языка.
Я просто увидел вот это: http://www.weheartswift.com/higher-order-functions-map-filter-reduce-and-more/
Там говорилось, что у массивов есть map, filter, reduce и все.
_>P.S. Eсли бы в Swift'е было мощное метапрограммирование (кстати, его ещё не поздно добавить с помощью макросов) и Apple дала бы обещание поддерживать его не только под свои платформы, то на мой вкус такой язык стал бы даже поинтереснее D...
Здравствуйте, vdimas, Вы писали:
V>В твоём стиле это прекрасно делается и в Swift, аналог контейнера на С++ я уже показал. Написать тело нужного функтора оставил для самостоятельной работы. Использовались только конструкции, которые имеют полный аналог в Swift, поэтому со своими спекуляциями идешь сразу лесом.
У тебя только один вариант сохранить лицо — показать код.
Здравствуйте, AlexRK, Вы писали:
ARK>На рынке доля Haskell, Scala и Clojure примерно в районе нуля, а автор с умным видом рассуждает на примере этой маргинальщины.
Здравствуйте, D. Mon, Вы писали:
ARK>>На рынке доля Haskell, Scala и Clojure примерно в районе нуля, а автор с умным видом рассуждает на примере этой маргинальщины. DM>Ну так человек в будущее смотрит, а не в прошлое.
Дык тут бабуля надвое сказала, за кем будущее.
Несколько десятков лет назад поклоннники Lisp, Forth и APL тоже, вероятно, смотрели в будущее.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, andyag, Вы писали:
I>>>И запускать эти тесты надо полагать, придется на боевой системе ?
A>>Там чуть выше по треду описан контекст. Ни про какие боевые системы и самоотверженных девопсов речи не было: "для быстрого тестирования некоторых вещей".
I>Как тестировать мой код, все понятно. А вот как тестировать интеграцию с системой, т.е. нативными решения, вот это поинтереснее.
Давайте разделять "тестировать" и "быстро протестировать". Первое — это бесконечный проектный процесс, который должен быть педантичным и воспроизводимым. Второе — это костыль для "я уже не помню как оно работает", либо "у стороннего сервиса плохая документация". Если вы про второй случай, то, ИМХО, все средства хороши. Не REPL нас спасёт, а именно абсолютно любое решение, в том числе и REPL.
I>>>Эта хрень дает возможности сократить на прядок другой количество перезапусков приложения. Если для каждого перезапуска надо собирать пекадж или делать деплоймент, то разница просто сумасшедшая.
A>>Расскажите пожалуйста какой-то юзкейз, отдалённо похожий на реальный мир.
I>Например меня есть мобильное приложение. Есть баг, который воспроизводится в релизной версии, но не воспроизводится в девелоперской. Я подключаю отладчик и если в нём внятный репл, собираю нужную мне информацию I>Например : "А что вернет вон та функция, если перед этим я вызову то и это"
Это как раз второй сценарий из тех двух, что я описал сверху. Субъективно ящитаю, не должно быть ситуаций, когда возникает мотивация "дёрнуть вот это и это, прежде чем дёргать то". Это полное отчаяние, когда уже совсем не стыдно, лишь бы заработало. В мобильных приложениях (по опыту с Андроид) есть 2 основных категории проблем:
1. Неправильное понимание жизненного цикла приложения и его компонентов. Здесь достаточно тупо отладчика — просто чтобы увидеть, что какой-нибудь onDestroy() вызвался раньше, чем вы реально закончили транзакцию. Здесь просто нечего дёргать REPL'ом — есть ссылка на мёртвый ресурс и всё.
2. Синхронизация, многопоточность и всякое прочее. Конечно это не специфика чисто мобильных приложений. Есть у вас дедлок и REPL. Как оно поможет?
Обе группы невозможно нормально протестировать автотестами. Как тут поможет REPL — тоже не вижу.
I>И здесь нужна возможность писать полноценный код. Например если я проверяю результаты запросов, в которых есть лямбды, я хочу что бы отладчик позволял эти лямбды.
А что за запросы с лямбдами? Звучит как код, который легко покрывается тестами вдоль и поперёк. Чем меньше мобильной специфики, тем очевиднее покрывается тестами.
Здравствуйте, D. Mon, Вы писали:
DM>А сам компилятор кто будет писать и портировать? Он разве открытый? License: proprietary
Ну так можно запускать его как front-end на билд сервере маковском (или виртуалке ). А потом уже у себя делать нормальные бинарники. Но опять же это в случае, если Apple будет против кроссплатформенности, а в этом случае не будет ещё и разработанных удобных библиотек (в смысле уже на Swift'e, даже если там внутри и обращение к C или OS API) под соответствующие платформы и надо будет обращаться напрямую к разным C библиотекам или OS API. А это практически убивает один из главных плюсов.
DM>Я просто увидел вот это: DM>http://www.weheartswift.com/higher-order-functions-map-filter-reduce-and-more/ DM>Там говорилось, что у массивов есть map, filter, reduce и все.
Видимо имелось в виду "всё что есть из функциональщины". )
DM>Мне он тоже в целом понравился, особенно null-safety, но на фоне Dивной интроспекции и МП — слабовато.
О, да, точно, про интроспекцию времени компиляции я забыл. Кстати, очень странно что её нет в Swift'e. Тем более, что там есть атрибуты и т.п. Может снова где-то в документации потерялось? Но без неё реально печально будет со многими моментами. Уже даже в C++ планируют добавить её, а тут...
DM>Вот тут правильно сказал человек: http://justy-tylor.livejournal.com/221988.html
Не воспринимаю подобные высказывания, если автор не указывает предлагаемую им лучшую альтернативу. В данном случае ничего конкретного не указано...
Здравствуйте, andyag, Вы писали:
I>>Как тестировать мой код, все понятно. А вот как тестировать интеграцию с системой, т.е. нативными решения, вот это поинтереснее.
A>Давайте разделять "тестировать" и "быстро протестировать". Первое — это бесконечный проектный процесс, который должен быть педантичным и воспроизводимым. Второе — это костыль для "я уже не помню как оно работает", либо "у стороннего сервиса плохая документация". Если вы про второй случай, то, ИМХО, все средства хороши. Не REPL нас спасёт, а именно абсолютно любое решение, в том числе и REPL.
Абсолютно любое не подойдет. Тесты из IDE в большинстве случаев ничего не дадут.
Вместо тестов проще держать под рукой вещи навроде LINQPad
I>>Например меня есть мобильное приложение. Есть баг, который воспроизводится в релизной версии, но не воспроизводится в девелоперской. Я подключаю отладчик и если в нём внятный репл, собираю нужную мне информацию I>>Например : "А что вернет вон та функция, если перед этим я вызову то и это"
A>Это как раз второй сценарий из тех двух, что я описал сверху. Субъективно ящитаю, не должно быть ситуаций, когда возникает мотивация "дёрнуть вот это и это, прежде чем дёргать то". Это полное отчаяние, когда уже совсем не стыдно, лишь бы заработало. В мобильных приложениях (по опыту с Андроид) есть 2 основных категории проблем: A>1. Неправильное понимание жизненного цикла приложения и его компонентов. Здесь достаточно тупо отладчика — просто чтобы увидеть, что какой-нибудь onDestroy() вызвался раньше, чем вы реально закончили транзакцию. Здесь просто нечего дёргать REPL'ом — есть ссылка на мёртвый ресурс и всё.
Как будто отладчик вот так вот просто даст ссылку на мертвый ресурс. Я, для начала, даже не знаю где проблема. Мне нужно из отладчика локализовать.
A>2. Синхронизация, многопоточность и всякое прочее. Конечно это не специфика чисто мобильных приложений. Есть у вас дедлок и REPL. Как оно поможет? A>Обе группы невозможно нормально протестировать автотестами. Как тут поможет REPL — тоже не вижу.
Репл помогает собирать информацию о текущем состоянии процесса.
I>>И здесь нужна возможность писать полноценный код. Например если я проверяю результаты запросов, в которых есть лямбды, я хочу что бы отладчик позволял эти лямбды.
A>А что за запросы с лямбдами? Звучит как код, который легко покрывается тестами вдоль и поперёк. Чем меньше мобильной специфики, тем очевиднее покрывается тестами.
Любой запрос. Например у меня есть несколько агентов. Я хочу посмотреть состояние только нужных мне агентов. Решение
Это одноразовый код. Или, другой вариант, мне понадобится только 5 первых воркеров. Или, например, сумма объемов промежуточных результатов по некоторым воркерам.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, andyag, Вы писали:
A>>1. Уродливый Objective C всё равно не запретят. Потому что это нереализуемо. Их будет два. C>Это Apple. Они могут — Carbon API они таки запретили, хотя им пользовались такие гиганты как Photoshop.
А давайте попробуем дать оценку количества кода, который зависел от Carbon API и количества кода, написанного на Objective C. Я плохо даю оценки, но наверное "в 10 раз" — это сильное занижение.
A>>2. Прекрасный новый Swift идеологически не отличается от Objective C: это ЭКЗОТИКА. Прошлая экзотика была из глубоких 80-х, новая — из 2010ых. A>>3. Этот НОВЫЙ язык будет работать на очень старой платформе "с большой историей" — со странноватыми API и отсутствием клёвых штук типа рефлексии. C>То есть? Рефлексию несложно добавить — это же LLVM. Аналогично, поддержка остальных платформ (в том числе Windows) скорее зависит от того, чтобы кто-то не поленился сделать сборку для них.
Да какая разница-то? На дворе 2014ый год, а появляется новый "альтернативно одарённый" язык, которому глубоко плевать на этот самый 2014ый год. Просто потому что.
Здравствуйте, Ikemefula, Вы писали:
I>У тебя только один вариант сохранить лицо — показать код.
Эммм, очень странно добиваться от vdimas этого кода после того, как D. Mon кинул ту ссылку на определение интерфейса (к которoму кстати умеет цепляться foreach) для последовательностей в Swift'e. Имея подобное, эту вашу задачку решит любой начинающий. ))) Просто это дело находится (видимо) в стандартной библиотеке языка, а описания к ней в текущей документации на язык нет, так что не обладая установленной средой (и не полазив по исходникам) vdimas'у довольно проблематично было дать красивый ответ. Но теперь то, что вы продолжаете цепляться? Или всё ждёте этот пример школьного кода? )
Кстати, документация вообще кривая. Облазил всё описание языка и не увидел ничего про указатели вообще. Естественно подумал что и нет их. А в другом, совершенно "левом" месте (типа про доступ к Cocoa и т.п.) вижу работу с указателеми (представленными соответствующими классами), причём в коде видна инициализация такого указателя адресом разных структур языка (кстати, вот оно преимущество отсутствия GC типа jvm/.net!). Т.е. в языке есть операция взятия указателя "&", но нигде в описание языка про неё не сказано...
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, andyag, Вы писали:
A>>Ещё один язык, который работает на сильно ограниченном наборе платформ. Ещё один язык со своим уникальным и самым лучшим синтаксисом. Ещё один язык, который теперь в вакансиях сначала будет "крайне приветствуется", а потом "необходимо знать: Objective C, Objective C++, Swift". Ещё один язык, который будет иметь ненулевую популярность, просто потому что хипстеры.
I>И что с того ?
У любого программиста, прочитавшего больше десятка книжек и написавшего больше несколько сотен килострок кода есть свои ценности, переживания и убеждения по поводу "что такое хорошо и что такое плохо". Ценности эти далеко не всегда относятся к любимому языку или любимой библиотеке, часто ценности находятся на более высоком уровне и описывают уже не любовь к инструментам, подходома и знаниям, а любовь к множествам инструментов, подходов и знаний. Все эти множества определяются через "что такое хорошо". А есть ещё "что такое плохо". Через этот критерий определяются всякие штуки, к которым не то что любви нет, а прямо порвать на куски хочется. Эти "хорошо" и "плохо" ни разу не объективны.
Теперь, отвечая на ваш вопрос: "сильно тошнит".
A>>1. Уродливый Objective C всё равно не запретят. Потому что это нереализуемо. Их будет два. A>>2. Прекрасный новый Swift идеологически не отличается от Objective C: это ЭКЗОТИКА. Прошлая экзотика была из глубоких 80-х, новая — из 2010ых. A>>3. Этот НОВЫЙ язык будет работать на очень старой платформе "с большой историей" — со странноватыми API и отсутствием клёвых штук типа рефлексии.
I>Если будет внятный перформанс и легкость интеграции с обжективси, то этот Обжектив си умрем сам собой, ибо переписать модуль заново будет много быстрее, чем фиксить старый. А где совсем туго, так и оставить обжектив.
А смысл? Для под-сообщества не-быдло-айфонщиков внутри сообщества всех айфонщиков он может и есть. Но вот для под-сообщества айфонщиков внутри сообщества всех программистов — это как была бестолковая хрень, так и осталась. Из-за отсуствия должных инструментов на уровне языка культура так и не будет расти. Так и будут продолжаться все эти глобальные синглтоно-сервис-локаторы и сериализация руками в NSDictionary — вместо IoC-контейнеров и сериализации из коробки. Так и будут эти люди писать костыли, чтобы проинициализировать ленивые синглтоны в правильном порядке, потому что язык (и рантайм, и сторонние решения) не дают ему вообще никакого намёка, что возможно что-то не так, и можно сделать как-то иначе. Это только абстрактные программисты знают ООП, признают штуки "dependency injection — это по умолчанию" и понимают, что вообще прочитать объект из JSON — это не 2 дня работы, а что-то нечаянно написанное между двумя глотками кофе. А неабстрактные программисты — это молодые коллеги, которые начали свой путь с Objective C. И существование этих самых ребят — это то самое, что мне не нравится в том, что делает Apple.
I>Рефлексию легко добавить, и лучше если это будет чуть попозжа. Как вариант, всунуть компайл-тайм рефлексию, шоб сильнее отличиться от дотнета и джавы
Не, это куда-то не туда ИМХО. Такими темпами будет ещё одно чудо с вычислением факториалов на этапе компиляции.
Здравствуйте, Ikemefula, Вы писали:
A>>Давайте разделять "тестировать" и "быстро протестировать". Первое — это бесконечный проектный процесс, который должен быть педантичным и воспроизводимым. Второе — это костыль для "я уже не помню как оно работает", либо "у стороннего сервиса плохая документация". Если вы про второй случай, то, ИМХО, все средства хороши. Не REPL нас спасёт, а именно абсолютно любое решение, в том числе и REPL.
I>Абсолютно любое не подойдет. Тесты из IDE в большинстве случаев ничего не дадут. I>Вместо тестов проще держать под рукой вещи навроде LINQPad
Как так — ничего? Если контекст проблемы более-менее понятен, намного проще этот самый контекст накидать в виде теста и несколько раз прокрутить в разных вариациях, чем методом тыка сначала этот контекст ловить во время выполнения кода в продакшне, а потом судорожно писать в реальном времени какие-то команды с вероятностью написать не то, или тупо забыть что ж вы там такое написали в итоге, когда вроде всё уже понятно.
I>>>Например меня есть мобильное приложение. Есть баг, который воспроизводится в релизной версии, но не воспроизводится в девелоперской. Я подключаю отладчик и если в нём внятный репл, собираю нужную мне информацию I>>>Например : "А что вернет вон та функция, если перед этим я вызову то и это"
A>>Это как раз второй сценарий из тех двух, что я описал сверху. Субъективно ящитаю, не должно быть ситуаций, когда возникает мотивация "дёрнуть вот это и это, прежде чем дёргать то". Это полное отчаяние, когда уже совсем не стыдно, лишь бы заработало. В мобильных приложениях (по опыту с Андроид) есть 2 основных категории проблем: A>>1. Неправильное понимание жизненного цикла приложения и его компонентов. Здесь достаточно тупо отладчика — просто чтобы увидеть, что какой-нибудь onDestroy() вызвался раньше, чем вы реально закончили транзакцию. Здесь просто нечего дёргать REPL'ом — есть ссылка на мёртвый ресурс и всё.
I>Как будто отладчик вот так вот просто даст ссылку на мертвый ресурс. Я, для начала, даже не знаю где проблема. Мне нужно из отладчика локализовать.
А почему нет? В том же Андроиде оно падает с явными ошибками типа "эй! тут мёртвый ресурс".
A>>2. Синхронизация, многопоточность и всякое прочее. Конечно это не специфика чисто мобильных приложений. Есть у вас дедлок и REPL. Как оно поможет? A>>Обе группы невозможно нормально протестировать автотестами. Как тут поможет REPL — тоже не вижу.
I>Репл помогает собирать информацию о текущем состоянии процесса.
Текущее состояния — всё хреново. Целостность нарушена. Часть ресурсов нормальные, часть уже разрушены. Предположения, сделанные в коде не сходятся с реальностью. При следующем прогоне ситуация может быть несколько иной. У вас есть REPL. Он подтверждает, что всё хреново. Как это помогает?
I>>>И здесь нужна возможность писать полноценный код. Например если я проверяю результаты запросов, в которых есть лямбды, я хочу что бы отладчик позволял эти лямбды.
A>>А что за запросы с лямбдами? Звучит как код, который легко покрывается тестами вдоль и поперёк. Чем меньше мобильной специфики, тем очевиднее покрывается тестами.
I>Любой запрос. Например у меня есть несколько агентов. Я хочу посмотреть состояние только нужных мне агентов. Решение
I>workers.Where(w => w.Task.Id.Contains('push-pull')).Select(w => w.Task.State).ToArray()
I>Это одноразовый код. Или, другой вариант, мне понадобится только 5 первых воркеров. Или, например, сумма объемов промежуточных результатов по некоторым воркерам.
Если их там "несколько", почему просто на всех не посмотреть? Если это критичная часть системы, почему не добавить какую-то мониторилку, которая периодически будет в лог писать их состояние? Важность таких компонентов сопоставима с важностью адекватной обработки исключений. Для мобильных приложений может и не популярно, но вон всякие серверные штуки поступают именно так: упало — присылай логи.
Здравствуйте, andyag, Вы писали:
A>Теперь, отвечая на ваш вопрос: "сильно тошнит".
Хы, вы кажется первый, кого я вижу с такой реакцией на Swift. А можно тогда развернуть поподробнее? )))
Просто лично у меня были исключительно положительные эмоции при прочтение описания языка. И это при том, что я довольно привередливый в этом смысле, знаю много разных современных языков и являюсь нелюбителем продукции компании Apple.
A>Не, это куда-то не туда ИМХО. Такими темпами будет ещё одно чудо с вычислением факториалов на этапе компиляции.
Вообще то как раз только интроспекция времени компиляции (как в том же D) и имеет смысл для статически типизированных компилируемых языков. А убогие интроспекции времени исполнения, как в Java/C# — это только от недостатка умения. Ну и я вообще то очень удивлён, что в Swift'e нет нормальной интроспекции (а может всё же есть, просто снова не разглядели в документации?). Это серьёзный минус.
Да, и насчёт факториалов во время компиляции... Я бы сказал, что полное отсутствие метапрограммирования — это для меня как раз основной минус Swift'a, который не позволяет представить его основным языком для меня.
Здравствуйте, andyag, Вы писали:
I>>Абсолютно любое не подойдет. Тесты из IDE в большинстве случаев ничего не дадут. I>>Вместо тестов проще держать под рукой вещи навроде LINQPad
A>Как так — ничего? Если контекст проблемы более-менее понятен,
Часто он даже неизвестен. Во когда через репл локализуется, будет понятным, тогда результатом становятся тесты
> намного проще этот самый контекст накидать в виде теста и несколько раз прокрутить в разных вариациях, чем методом тыка сначала этот контекст ловить во время выполнения кода в продакшне, а потом судорожно писать в реальном времени какие-то команды с вероятностью написать не то, или тупо забыть что ж вы там такое написали в итоге, когда вроде всё уже понятно.
Ну вот проблема, покажи как ты будешь решать тестом. Вызываешь нативную функцию файловой системы, она асинхронная, создает фолдер. Отваливается по ошибке 12, это значит что объект уже существует. На всех остальных девайсах такого пока не заметно.
Нужно установить, что за проблема и как ее пофиксить. Задавай вопросы, Говори, какие будешь писать тесты, а я скажу тебе результаты. Т.е. Я показал тебе ровно то, что увидел в отладчике — место откуда летит исключение.
I>>Как будто отладчик вот так вот просто даст ссылку на мертвый ресурс. Я, для начала, даже не знаю где проблема. Мне нужно из отладчика локализовать.
A>А почему нет? В том же Андроиде оно падает с явными ошибками типа "эй! тут мёртвый ресурс".
См проблему выше, никаких падений с мертвым ресурсом там нет.
Вот еще вещь — вызываешь функцию, асинхронную, три раза с разными праметрами, не дожидаясь завершения. Функция нативная. Далее надо дождаться пока все колбеки завершатся и продолжить кое какие действия. Время от времени эта часть зависает.
I>>Репл помогает собирать информацию о текущем состоянии процесса.
A>Текущее состояния — всё хреново. Целостность нарушена. Часть ресурсов нормальные, часть уже разрушены. Предположения, сделанные в коде не сходятся с реальностью. При следующем прогоне ситуация может быть несколько иной. У вас есть REPL. Он подтверждает, что всё хреново. Как это помогает?
Я про ресурсы ничего не говорил. Смотри мои примеры
I>>workers.Where(w => w.Task.Id.Contains('push-pull')).Select(w => w.Task.State).ToArray()
I>>Это одноразовый код. Или, другой вариант, мне понадобится только 5 первых воркеров. Или, например, сумма объемов промежуточных результатов по некоторым воркерам.
A>Если их там "несколько", почему просто на всех не посмотреть? Если это критичная часть системы, почему не добавить какую-то мониторилку, которая периодически будет в лог писать их состояние? Важность таких компонентов сопоставима с важностью адекватной обработки исключений. Для мобильных приложений может и не популярно, но вон всякие серверные штуки поступают именно так: упало — присылай логи.
Я не знаю заранее, какаяя информация мне нужна. Может это наборы данных по воркерам, их тоже в логи пихать?
Я боюсь девайс не выдержит такой мониторинг
Здравствуйте, andyag, Вы писали:
I>>Если будет внятный перформанс и легкость интеграции с обжективси, то этот Обжектив си умрем сам собой, ибо переписать модуль заново будет много быстрее, чем фиксить старый. А где совсем туго, так и оставить обжектив.
A>А смысл? Для под-сообщества не-быдло-айфонщиков внутри сообщества всех айфонщиков он может и есть. Но вот для под-сообщества айфонщиков внутри сообщества всех программистов — это как была бестолковая хрень, так и осталась. Из-за отсуствия должных инструментов на уровне языка культура так и не будет расти.
Культура растет не из за языка, а из за решаемых задач. Платформа все таки набирает вес и сообщество разработчиков пополняется, что очевидно. И так же очевидно, что пополняется не только студентами.
Здравствуйте, andyag, Вы писали:
A>1. Уродливый Objective C всё равно не запретят. Потому что это нереализуемо. Их будет два. A>2. Прекрасный новый Swift идеологически не отличается от Objective C: это ЭКЗОТИКА. Прошлая экзотика была из глубоких 80-х, новая — из 2010ых. A>3. Этот НОВЫЙ язык будет работать на очень старой платформе "с большой историей" — со странноватыми API и отсутствием клёвых штук типа рефлексии.
А вы что предлагаете взамен?
Конечно, не ошибается тот кто ничего не делает. Можно не изобретать ничего нового, юзать старые уродливые языки еще сотни лет и не пытаться ничего улучшить.
Здравствуйте, NeoCode, Вы писали:
NC>Здравствуйте, andyag, Вы писали:
A>>1. Уродливый Objective C всё равно не запретят. Потому что это нереализуемо. Их будет два. A>>2. Прекрасный новый Swift идеологически не отличается от Objective C: это ЭКЗОТИКА. Прошлая экзотика была из глубоких 80-х, новая — из 2010ых. A>>3. Этот НОВЫЙ язык будет работать на очень старой платформе "с большой историей" — со странноватыми API и отсутствием клёвых штук типа рефлексии.
NC>А вы что предлагаете взамен? NC>Конечно, не ошибается тот кто ничего не делает. Можно не изобретать ничего нового, юзать старые уродливые языки еще сотни лет и не пытаться ничего улучшить.
У вас любимая кошка сходила в туалет по-большому прямо в центре кухни. Предлагаются варианты:
1. Организовать на кухне музей альтернативного искусства
2. Убрать
3. Посыпать сахаром и оставить на потом
Здравствуйте, andyag, Вы писали:
A>На дворе 2014ый год, а появляется новый "альтернативно одарённый" язык, которому глубоко плевать на этот самый 2014ый год.
Здравствуйте, andyag, Вы писали:
A>У вас любимая кошка сходила в туалет по-большому прямо в центре кухни. Предлагаются варианты:
A>1. Организовать на кухне музей альтернативного искусства A>2. Убрать A>3. Посыпать сахаром и оставить на потом
A>Ваши действия?
Указать оппоненту на то, что сравнение нового языка программирования с продуктом жизнедеятельности кошки как минимум нужно еще обосновать, и весьма серьезно обосновать.
Re: А вот и сравнения скорости Swift с Objective-C подоспели
В лучшем случае Swift в 7.9x раз медленнее чем Objective-C. Результат, конечно, не ахти, но то что язык находится на стадии бета-тестирования, оставляет надежды а оптимизацию по скорости.
Здравствуйте, Klapaucius, Вы писали:
K>Откровенно говоря, не вижу особого смысла сравнивать Swift с "современными языками". Всякие Go-Swiftы — это подзадержавшиеся Явы-Шарпы, с ними и имеет смысл сравнивать. Языки вроде окамлов-хаскелей-идрисов — это другие поколения и эпохи, сравнивая с ними можно получить только один ответ: в госвифтах все плохо, ничего нет.
Ну да... Ничего нет, кроме детерминированных требований к памяти и хорошей производительности бинарника.
Зачем опять и снова игнорить реальность? Ну не может на сегодня взлететь "настоящее ФП", типа Хаскеля, без самой настоящей суперкомпиляции. Дай этим технологиям еще лет 20 (и это еще оптимистично).
Да и не самый лучший этот Хаскель даже для ФП. Одни лишь name conventions, вшитые в язык, с разбегу делают его не более, чем исследовательским. Конечно, когда мощщи компов и соответствующие компиляторы созреют, то сразу появятся более вменяемые ФП-языки и займут своё вполне заслуженное место.
Re[2]: А вот и сравнения скорости Swift с Objective-C подоспели
Здравствуйте, kaa.python, Вы писали:
KP>В лучшем случае Swift в 7.9x раз медленнее чем Objective-C. Результат, конечно, не ахти, но то что язык находится на стадии бета-тестирования, оставляет надежды а оптимизацию по скорости.
KP>http://www.splasmata.com/?p=2798
KP>P.S. тесты ну ооочень синтетические.
Очень любопытно) Похоже, что этот их Sequence интерфейс почему-то абсолютно не инлайнится...
Здравствуйте, vdimas, Вы писали:
K>>Откровенно говоря, не вижу особого смысла сравнивать Swift с "современными языками". Всякие Go-Swiftы — это подзадержавшиеся Явы-Шарпы, с ними и имеет смысл сравнивать. Языки вроде окамлов-хаскелей-идрисов — это другие поколения и эпохи, сравнивая с ними можно получить только один ответ: в госвифтах все плохо, ничего нет.
V>Ну да... Ничего нет, кроме детерминированных требований к памяти и хорошей производительности бинарника.
А где эта хорошая производительность бинарника ? По тестам на одном уровне с динамическими, до джавы как до небес, не говоря про c#
Здравствуйте, Ikemefula, Вы писали:
V>>Ну да... Ничего нет, кроме детерминированных требований к памяти и хорошей производительности бинарника. I>А где эта хорошая производительность бинарника ? По тестам на одном уровне с динамическими, до джавы как до небес, не говоря про c#
Здравствуйте, Klapaucius, Вы писали:
I>>В том то и дело, что речь шла про контейнеры, т.е. IEnumerable и тд. Товарищ просто не знал, как это сделано в Swift и решил перепрыгнуть на проблемы рантайма и другие, которые только ухитрился углядеть.
K>Да я сразу понял, что он контратаковал на другом направлении. Какая разница, если все равно можно решение дать?
Ниче я не контратаковал. Сам же Ikemefula по-невнимательности "допилил" исходное условие до, фактически, тупикового в версии C#.
Поймать я хотел именно его, он же сам напросился. )))
Но, видать, зря старался, судя по: http://www.rsdn.ru/forum/philosophy/5637841.1
===========
И да. Сравнивать языки можно, действительно, по разным прикладным сценариям, а не только по тем, которые тщательно выбирает лишь одна сторона. Но они уже пытаются и это оспорить. Давно я в этом дурдоме не участвовал. )))
Здравствуйте, Ikemefula, Вы писали:
V>>Чего-чего? Там были все демонстрации. I>Не было. Последняя твоя отписка была вот такой: "нициализируешь локальную переменную и вперед далее вниз по правилам процедурной/функциональной декомпозиции"
Ты меня с кем-то путаешь. Я тебе даже код давал, демонстрирующий работу двух разных диспетчеров и показывающих, что кооперативная многозадачность не имеет проблем с конкурентным доступом к ресурсам. И что модель асинхронщины меньше всего зависит от твоего кода и больше всего от диспетчера, который дергает за нитки автоматы-продолжения.
I>Здесь, судя по всему, такая же история
Здесь ты случайно изменил условие задачи так, что оно резко стало не в пользу C#. Медвежью услугу оказал своей священной корове, кароч. ))
Ну и всерьез воспринимать сие обсуждение после такого: http://www.rsdn.ru/forum/philosophy/5637841.1
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Ikemefula, Вы писали:
V>>>Чего-чего? Там были все демонстрации. I>>Не было. Последняя твоя отписка была вот такой: "нициализируешь локальную переменную и вперед далее вниз по правилам процедурной/функциональной декомпозиции"
V>Ты меня с кем-то путаешь. Я тебе даже код давал, демонстрирующий работу двух разных диспетчеров и показывающих, что кооперативная многозадачность не имеет проблем с конкурентным доступом к ресурсам. И что модель асинхронщины меньше всего зависит от твоего кода и больше всего от диспетчера, который дергает за нитки автоматы-продолжения.
Ничего не путаю, ты показал код который использует очередь для синхронизации.
Про кооперативную многозадачность — ты снова настаиваешь на той же ошибке. Скажем, все буквари по многозадачности утверждают, что гонки это особенность любой многозадачности
I>>Здесь, судя по всему, такая же история
V>Ты не в состоянии отличить обобщенное решение от частного.
Ты всего лишь нашел способ увильнуть от ответа, вместо обсуждения контейнеров перескочил на другие вопросы
Если подробно — нужно написать две функции (или что-то в таком роде): scalarProduct и, скажем, main. Функция scalarProduct должна принимать две последовательности (это могут быть массивы, связные списки, или ещё что-то — не важно) целых чисел и вычислять их скалярное произведение. При этом она должна падать, если длины этих последовательностей различны. Важное (критически) уточнение: это должно происходить НА СТАДИИ КОМПИЛЯЦИИ!!!
Сию задачу разбирали здесь минимум дважды. Она про тот самый параметрический полиморфизм времени исполнения, который ни разу не нужен в ваших примерах.
Так в чем твои-то трудности?
Ну и вообще парень там нагнал пурги:
Дальше ещё веселее. Вы запускаете XCode заново, он восстанавливает тот же файл, снова прогоняет его через компилятор, тот снова сегфолтится, и XCode снова вылетает.
Я не смог запилить такой код, который проверял бы мой тест и при этом не сегфолтился.
А в блокноте не судьба была? ))
Скорее всего компилятор в режиме максимально-глубокого вывода типов для интелисенса пытается рекурсивно выводить типы, но конца этому процессу для конкретно этой задачи НЕТ. ))
Поэтому там падает только интелиссенс среды разработки, насколько я понял из ссылки.
А ты льешь воду на мельницу клинических идиотов, помогая им гнать пургу. Ну бета еще среды разработки, фиг с ней. Ты разве не видел, как регулярно падали не только беты, но и сами MSVS до 2003-й включительно? И даже с сервис паками?
У меня и 10-я студия нет, нет, да упадёт иногда как раз во время парсинга изменений файла при пошаговой отладке.
А по-существу той задачи, там же по ссылке правильно заметили (и здесь когда-то говорили аналогичное):
чтобы поддерживать одинаковость типов, тебе приходится везде обрабатывать вектора вместе. А в этом случае разница между парой векторов и вектором пар исчезает.
Т.е. исходную задачу можно отрефакторить в эквивалентную, не требующую параметрического полиморфизма времени исполнения. В любом случае, в том же Хаскеле, компилятор способен пропустить через тайп-чек эту задачу только тогда, когда он формирует эти вектора ОДНОВРЕМЕННО. Если же попытаться сформировать их раздельно, то тайпчек навернется даже в Хаскеле, бо нет возможности сформировать эти вектора раздельно и проверить одинаковость их типов.
Кароч, по-настоящему эту задачу способны решить только языки с полной поддержкой зависимых типов, а к ним ни C#, ни Swift, ни Хаскель не относятся.
Но что характерно, что текущая система шаблонов С++ ПОЗВОЛЯЕТ в будущем добавить поддержку зависимых типов без какой-либо переделки синтаксиса (правда, с текущим ограничением на целочисленный аргумент зависимого значения). Т.е. система типов Swift тоже в будущем сможет быть развита до аналогичного. А вот в C# — никогда и ни при каких обстоятельствах. Принципиально невозможно. Вот так по-дебильному (C) дизайн генериков сделан. Так шта, накося выкуси. )))
========
Более того, при полноценной поддержке зависимых типов в этой задаче исчезает надобность рекурсивного определения типов, за "глубину" будет отвечать целочисленное значение, определяющее точный тип. Так шта, XCode падать не будет. ))
Здравствуйте, vdimas, Вы писали:
K>>Да я сразу понял, что он контратаковал на другом направлении. Какая разница, если все равно можно решение дать?
V>Ниче я не контратаковал. Сам же Ikemefula по-невнимательности "допилил" исходное условие до, фактически, тупикового в версии C#. V>Поймать я хотел именно его, он же сам напросился. ))) V>Но, видать, зря старался, судя по: http://www.rsdn.ru/forum/philosophy/5637841.1
Ты, вероятно, не понял, но тебя просили показать аналог IEnumerable. Смотри внимательно — автор вопроса дважды явно тебе сообщил и дал решение ВМЕСТО тебя
Вместо того, чтобы хотя бы намекнуть на протоколы, ты понес какую то галиматью про функции, подкрепив это кодом на сиплюсе
Здравствуйте, alex_public, Вы писали:
_>Эммм, очень странно добиваться от vdimas этого кода после того, как D. Mon кинул ту ссылку на определение интерфейса (к которoму кстати умеет цепляться foreach) для последовательностей в Swift'e. Имея подобное, эту вашу задачку решит любой начинающий. ))) Просто это дело находится (видимо) в стандартной библиотеке языка, а описания к ней в текущей документации на язык нет, так что не обладая установленной средой (и не полазив по исходникам) vdimas'у довольно проблематично было дать красивый ответ. Но теперь то, что вы продолжаете цепляться? Или всё ждёте этот пример школьного кода? )
Красиво ответить можно было и без этих базовых интерфейсов на основе того решения, которое я уже описал словесно раз пять — через подачу делегата в стиле IoC...
Всё намного проще. Я пока тупо тянул время, бо в эти выходные ни с какой виртуалкой макоси возиться не собирался.
ЮБК, море, солнце, местное вино... и пускай злопыхатели подождут.
Здравствуйте, vdimas, Вы писали:
V>>>Ну да... Ничего нет, кроме детерминированных требований к памяти и хорошей производительности бинарника. I>>А где эта хорошая производительность бинарника ? По тестам на одном уровне с динамическими, до джавы как до небес, не говоря про c#
V>Ты тестировал?
Если ты не заметил, то результаты тестирования уже выложили прямо в этом треде. Про них и речь, а именно, про отставание от 7 до 49 раз относительно сиплюса
Здравствуйте, vdimas, Вы писали:
_>>Эммм, очень странно добиваться от vdimas этого кода после того, как D. Mon кинул ту ссылку на определение интерфейса (к которoму кстати умеет цепляться foreach) для последовательностей в Swift'e. Имея подобное, эту вашу задачку решит любой начинающий. ))) Просто это дело находится (видимо) в стандартной библиотеке языка, а описания к ней в текущей документации на язык нет, так что не обладая установленной средой (и не полазив по исходникам) vdimas'у довольно проблематично было дать красивый ответ. Но теперь то, что вы продолжаете цепляться? Или всё ждёте этот пример школьного кода? )
V>Красиво ответить можно было и без этих базовых интерфейсов на основе того решения, которое я уже описал словесно раз пять — через подачу делегата в стиле IoC...
V>Всё намного проще. Я пока тупо тянул время, бо в эти выходные ни с какой виртуалкой макоси возиться не собирался.
Все почти верно, кроме одной детали — тянуть время ты можешь годами, или выдать "пфф любой студент за два часа, мы не в детсаде"
Вспомнишь сам или ссылкой дать ?
Re[2]: А вот и сравнения скорости Swift с Objective-C подоспели
Здравствуйте, kaa.python, Вы писали:
KP>В лучшем случае Swift в 7.9x раз медленнее чем Objective-C. Результат, конечно, не ахти, но то что язык находится на стадии бета-тестирования, оставляет надежды а оптимизацию по скорости.
KP>P.S. тесты ну ооочень синтетические.
Даже по этим синтетическим тестам видно, что язык пока что конкурирует с динамическими языками. С учетом того, что objective c отстаёт от модных компилеров С++, то разница между свифтом и objective от 7 до 49 раз это мягко говоря отстой. Шота выглядит как "с места и в лужу"
Здравствуйте, vdimas, Вы писали:
V>Скорее всего компилятор в режиме максимально-глубокого вывода типов для интелисенса пытается рекурсивно выводить типы, но конца этому процессу для конкретно этой задачи НЕТ. ))
Т.е. ты предполагаешь, что при работе с IDE компилятор Swift'a работает в особом режиме, а из консоли его примеры компилировались бы?
V>Кароч, по-настоящему эту задачу способны решить только языки с полной поддержкой зависимых типов, а к ним ни C#, ни Swift, ни Хаскель не относятся.
V>Но что характерно, что текущая система шаблонов С++ ПОЗВОЛЯЕТ в будущем добавить поддержку зависимых типов без какой-либо переделки синтаксиса (правда, с текущим ограничением на целочисленный аргумент зависимого значения). Т.е. система типов Swift тоже в будущем сможет быть развита до аналогичного. А вот в C# — никогда и ни при каких обстоятельствах. Принципиально невозможно. Вот так по-дебильному (C) дизайн генериков сделан. Так шта, накося выкуси. )))
.
V>Более того, при полноценной поддержке зависимых типов в этой задаче исчезает надобность рекурсивного определения типов, за "глубину" будет отвечать целочисленное значение, определяющее точный тип. Так шта, XCode падать не будет. ))
При чем тут сама задача? Ты совсем не умеешь отвлекаться от деталей и видеть смысл?
Смысл простой: компилятор очень падучий, и XCode вместе с ним. Потому тестировать сложно. Про задачу забудь, не о ней речь.
Даже проще примеры были: при попытке описать рекурсивный алгебраик компилятор сегфолтится.
Re[3]: А вот и сравнения скорости Swift с Objective-C подоспели
Здравствуйте, Ikemefula, Вы писали:
I>Даже по этим синтетическим тестам видно, что язык пока что конкурирует с динамическими языками. С учетом того, что objective c отстаёт от модных компилеров С++, то разница между свифтом и objective от 7 до 49 раз это мягко говоря отстой. Шота выглядит как "с места и в лужу"
КОгда говоришь о Бета-версии какого-либо языка, стоит обсуждать предлагаемую им концепцию, но никак не производительность или стабильность сгенерированного кода. Это я не к тому, что Swift – это круто, я его еще даже не смотрел, а к тому, что другие составляющие куда как важнее
Re[2]: А вот и сравнения скорости Swift с Objective-C подоспели
Здравствуйте, kaa.python, Вы писали:
KP>Да, интересно. Если почитать ответы, то получается что скорость Swift не уступает скорости Си, что приколько, я считаю
Он же вроде не уступает, если там отключить рантайм проверки. Это.. гм.. как бы не safe, что декларируется, как фича. Кстати, тебя не смущает, что язык проприетарный, да еще и заточенный под одну платформу?
Здравствуйте, MxMsk, Вы писали:
MM>Кстати, тебя не смущает, что язык проприетарный, да еще и заточенный под одну платформу?
Я пока не смотрел по нему доки, но если это именно что "замена Objective-C", т.е. язык для работы с Cocoa которой ни на каких платформах кроме как от Apple не существует, то нет, не смущает. Если же говорить о проприетарности, то исходя из политики Apple по отношению к другим низкоуровневым разработкам (LLVM, Clang, Darwin) я думаю что его откроют вскоре после релиза.
P.S. но я с UI дела практически не имею, так что у меня к языку разве что чисто академический интерес может проснуться (пока мне на него пофигу).
Re[4]: А вот и сравнения скорости Swift с Objective-C подоспели
Здравствуйте, kaa.python, Вы писали:
KP>КОгда говоришь о Бета-версии какого-либо языка, стоит обсуждать предлагаемую им концепцию, но никак не производительность или стабильность сгенерированного кода. Это я не к тому, что Swift – это круто, я его еще даже не смотрел, а к тому, что другие составляющие куда как важнее
Судя по SO все еще хуже, чем по твоей ссылке — разница на порядок даже если сравнивать с питоном. Не понимаю как можно было прикрутить проверки тиа выход за границу массива и тд, что бы это работало хуже чем питоне
Здравствуйте, vdimas, Вы писали:
V>Да нет. Оказывается, что ad-hoc полиморфизм не поддерживается в полной мере генериками дотнета, только и всего. Иначе бы он сам подхватывал переопределённые операторы.
Дженерики — это параметрический полиморфизм. Никакой ad-hoc полиморфизм они поддерживать и не должны. И никакого "подхватывания операторов" не нужно. Нужно делать как в моем примере реализовано, только с автоподстановкой словарей и подправленным синтаксисом, чтоб ограничения квантификации нормально выглядели, можно было операторы использовать и т.д.
Ну и классы типов/имплементации должны в стандартной библиотеке быть.
V>Если в полноценной реализации, то нужен, ес-но. Но для привычного ООП он почти всегда "недо-", бо идет только по первому аргументу this.
Продемонстрированная мной техника это ограничение обходит.
V>Ну а что делать, если всё кривое? )))
Делать прямым там, где возможно. Обсуждаемое сделать прямым можно одними средствами компилятора, все что для этого нужно (более-менее нормальный полиморфизм, инлайн методов структур и т.д.) CLR уже поддерживает.
V>Ты продемонстрировал костыль в условиях "недо-".
Это менее костыльно чем всякие "подхватывания". Недоделанность дотнетных дженериков совсем не в этом, а в том, что от конструктора типа нельзя абстрагироваться, нету higher-kinded полиморфизма. Ну так с этим и в сабже проблемы.
V>Нет. Зависимость конкретных типов T->C должна быть неявной. Явное её указание — избыточность, делает решение недо-обобщенным.
Явное указание — это, конечно, избыточность, но "недообобщенным" оно решение не делает.
V>Можно так: V>
V>T Avg<T>(this IEnumerable<T> xs) where T : INumber<T>, new()
V>
V>Как и в Хаскель, собсно. (только с той разницей, что в дотнете INumber<T>, сцуко, описывает контракт только по одному аргументу this... но и этого могло бы хватить для арифметики)
Нет, ключевое отличие тут в том, что ":" задает отношение подтипирования, которого в хаскеле нет. В моем решении его (между T и C) также нет и не должно быть.
V>Я тебе уже показал абзацем выше аналог на C# того, как это есть в Хаскеле. Заканчивай уже спекулировать.
Нет, это не аналог того, что есть в хаскеле. Аналог того, что есть в хаскеле показал я.
V>Ес-но, реализация арифметических операторов для Complex должна быть где-то описана. Но не дважды же!
Ну так она и не описана дважды:
public struct ComplexReal : CReal<Complex>
{
public Complex Div(Complex a, Complex b) { return a/b; }
public Complex Add(Complex a, Complex b) { return a+b; }
public Complex FromInt(int a) { return new Complex(a,0); }
}
вызываются библиотечные реализации сложения и деления. Если бы мы сами определеяли Complex — могли бы не описывать операции только для Complex, а определить их прямо в имплементации класса. И тот и другой подход используются в хаскеле.
V>В Хасклеле бери любую либу с каким-нить MegaComplex, да пользуйся. А в твоём решении на C# надо еще раз по операторам пройтись да продублировать их. Что-то не так в консерватории, не правда ли? ))
Очевидно, что надо просто положить инстансы в библиотеку и все, как в хаскеле обычно и делается.
Но нередко бывает и так, когда библиотека нужных инстансов не содержит. Тогда пользователь сам описывает инстансы-"сироты". Что собственно я и зделал в своем примере на C#.
V>Ммм... ты действительно не понял пару постов выше намек на то, как это надо было сделать в C#? ))
Понял, но я не согласен с тем, что в C# надо так делать. Надо было делать именно как я показал.
V>Блин, ты же сам всё правильно говорил про Хаскель! Модель типов дотнета позволяет делать так же. Просто не сделано для встроенных типов.
Продемонстрированная мной техника позволяет определять инстансы для любых типов.
В хаскеле, кстати, для "встроенных" типов полиморфизм вообще не поддерживается.
V>Но даже при этом можно было бы арифметические операторы подхватывать автоматом и на этапе генерации бинарников подставлять в тела генериков нужный код. Даже можно обойтись существующим стандартом на метаинформацию и байт-код, достаточно компилятором генерить фиктивный IOperators<> в байт-коде, а во время JIT-а просто знать этот интерфейс "в лицо" и при его фиктивной реализации просто подставлять статически-переопределенные операторы, тогда тебе не надо было бы ручками описывать свой ComplexReal.
Нет уж, лучше написать инстанс руками и положить в библиотеку, а в компилятор универсальный солвер для подстановки любых инстансов, чем встраивать в реализацию компилятора и рантайма какие-то подхватывания избранных операторов.
Да даже и без автоподстановки инстансов — все равно лучше.
V>А зачем параметрический полиморфизм в сценариях, где уточненные типы выводятся еще на этапе компиляции? V>Эдак тебя несет. Мы обсуждали конкретный пример, где параметрический полиморфизм времени исполнения не нужен ни разу.
Параметрического полиморфизма времени исполнения не существует, он бывает только времени компиляции. Этим он от завтипов отличается, для которых полное стирание типов осуществить нельзя.
V>Насмешил. В Хаскеле не всегда параметрический полиморфизм нужен в рантайм. 99% сценариев разруливаются на этапе компиляции, т.е. обобщенное программирование в этих сценариях не далеко ушло от С++ — обычная "текстовая подстановка" в итоге. Собсно, даже формат библиотек Хаскеля — это упакованный и размеченный результат парсинга текста (считай тупо AST исходников либы), а не объектный код.
Нет, это код, с которым могут поставляются, а могут и не поставляться "развертки", т.е. результат парсинга части кода. Развертки могут использоваться для оптимизации, но все работает и без них — просто медленнее. Это техническая деталь реализации межмодульной оптимизации, реализация параметрического полиморфизма от этого не зависит.
Упомянутый 1% сценариев — это экзистенциальные типы, там словарь действительно не может быть подставлен в комайл-тайм и ссылка на него хранится в объекте, как в ООП.
V>>>1. Ты ничего не решил, готового к использованию изкаробки обобщенного решения так и не было. В дотнете автоматическое решение возможно только на рефлексии, увы.
K>>Потому, что дотнетные разработчики (а точнее, принимающие решения) не читатели и не моргнув глазом пустили в свободное плаванье дизайнерское решение, которое целый фрактал проблем порождает.
V>А конкретно в этой ветке мне постарались надавать по щщам именно из-за попытки сравнения со "священной коровой". Я лишь заметил, что многих проблем C# в Swift нет.
Я сильно сомневаюсь, что обсуждаемая проблема в сабже решена нормально, а не в стиле C++.
V>Я не спорю, что до "чистых" языков ему далеко. Это гибрид и как любой гибрид состоит из компромиссов. Но в C# есть даже такие компромиссы, увы, которые вовсе не требовались. И ты наглядно их показал в своей собственной реализации yet another IArithmetic<T>.
Похоже на то, что и в сабже таких "компромиссов", которые не требовались, хватает.
V>И всё-таки в джаве и дотнете не в языке гвоздь, а в миллионах строк библиотек со сложным, но достаточно надежно оттестированным функционалом.
Ну да, правильно.
V>Хотя для value-типов для тех же генереков JIT генерит код, который нигде по-факту методы интерфейсов не вызывает!
Ну, на этом техника и основывается. если бы не это — реализовывать арифметику таким способом не было бы смысла.
V>Т.е. сие ограничение интерфейсов только на экземплярные методы можно было бы обойти, добавив возможность задавать некий "интерфейс для статических методов", как раз арифметика туда попала бы, а связь T->C в твоём примере была однозначной и не требовала бы явного задания. (Это был бы, конечно не интерфейс в ООП-смысле, а чистый "контракт", бо интерфейс описывает лишь контракт на экземплярные методы).
Зачем какие-то загадочные "интерфейсы для стат.методов" придумывать, если можно просто красиво оформить передачу словаря, т.е. описанную мной технику?
V>Что касается по-делу. Параметрический полиформизм генериков C# показывает свою силу только в рекурсивных, относительно типов, сценариях
Да, совершенно верно, полиморфная рекурсия например. И да, чтоб это использовать нужны более развитые возможности тайплевел-программирования, которых в шарпе нет.
Но вообще параметрический полиморфизм, а не шаблоны в дотнете ради раздельной компиляции сделаны. Передача словаря вполне с раздельной компиляцией совместима.
K>>Собственно, всякие костыльные воркараунды — единственные способы писать обобщенный код в индус триальных языках V>Ну вот мне сходу показалось, что в Swift таких воркараундов должно быть поменьше.
Здравствуйте, vdimas, Вы писали:
V>Ну да... Ничего нет, кроме детерминированных требований к памяти и хорошей производительности бинарника.
"Детерминированные требования к памяти" — это красиво звучит, но на практике означает только, что менеджер памяти там выигрывает по латентности у нормального ГЦ ценой проигрывания throughput и чуть менее чем всех языковых фич. ничего интересного в этом аспекте сабж не предлагает.
Хорошей производительности бинарника в сабже, я думаю, не будет, никто не станет ее до уровня плюсов доводить, останется на уровне "языков, использующих LLVM".
Т.е. код а ля лапшефортран будет работать со скоростью не сильно больше той, которую аналогичный код в лапшефортранном стиле на хаскеле показывает, а в случае сколько-нибудь высокоуровневого кода он хаскелю вообще проиграет.
По поводу суперкомпиляций и настоящего ФП.
1) На производительность низкоуровневого кода "настоящего ФП" она никак не повлияет, а проблема производительности высокоуровневого кода нигде не решена.
2) Я не особо верю в перспективы суперкомпиляции для языков без проверки завершимости, хотя я особо не разбираюсь в суперкомпиляии, я интересуюсь больше более простыми и практичными техниками, которые под это определение не подпадают.
3) Проблемы с производительностью низкоуровневого кода в "настоящем ФП" худо-бедно решаются использованием готовых бэкендов, на которые тратятся значительные (по сравнению с теми, что на ФП тратятся) человекочасы вроде LLVM. Остаются проблемы, которые рантаймом обусловлены, вроде дороговизны изменяемых массивов ссылок и т.д., в случае которых компилятор ничем не поможет.
4) Производительность вообще не главная проблема "настоящего ФП", многие популярные языки никаких успехов по части производительности кода никогда не показывали и не покажут.
Да и от сабжа я их не жду.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Ikemefula, Вы писали:
K>>Нет, вывести такое следствие не из чего. Вот если бы были языки с равными инфраструктурами и сильно различающиеся по фичам — тогда можно было бы какие-то выводы делать. I>Хорошая инфраструктура почему то появляется только для самых убогих языков с твоей точки зреня. Тебе самому не смешно ?
Ну конечно не самых убогих. Но не далеко от этого. Посмотрите на список ваших "наиболее востребованных". Много ли языков более убогих чем они? Вот то-то и оно.
I>А что ты имел ввиду под требованием к качеству реализации ? Эти требования определяются исключительно ценой ошибки, а не применяемым языком.
Под требованием к качеству реализации я имел в виду хороший оптимизирующий компилятор или, например, продвинутый рантайм с нормальным сборщиком мусора (точным, перемещающим, с поколениями, параллельным и т.д.), поддержкой SMP. У 90% языков какой-нибудь Боэм, или треш-угар с подсчетом ссылок, если язык "академиеский" — может еще быть Чейни на страницу кода, написанный студентом за вечер. Никакого SMP, конечно.
I>А что тут знать. Компилируешь и смотришь, во что это выливается в итоге. Отсюда ясно, что ни перформанса, ни внятного расхода памяти нет и быть не может, при том, что нужно дизайнить внутреннее АПИ специальным образом.
Для паттерн-матчинга?
I>ФЯ смотрятся хорошо только в высокоуровневых алгоритмах, если их тяжело перевести в императивный вид. В низковровневых вещах разница любого ФЯ с простецким Си минимум в несколько раз.
ну так а я о чем? "Ну вот, вы же сами написали, что все, кроме C и C++. Остальные это ведь не только пара-тройка ФЯ но и бразиллион языков никакого отношения к ФП в основном не имеющих. Как видите, страшный синтаксис им никак не помог. При этом сабж явно не окажется в категории С/C++, а наоборот — в категории "остальные", в которой ФЯ часто смотрятся в смысле производительности очень хорошо. "
K>>Вопрос был в том, зачем делать убогим, если можно не убогим? Что мешает-то?
I>Полноценный ПМ можно всунуть только в полноценный ФЯ, со всеми его проблемами — перформансом и потреблением памяти. Это очень дорогая фича.
Не согласен, в отличие от комбинирования комбинаторов, которое если попытаться сделать нормально — целый "полноценный ФЯ" за собой притянут, паттерн-матчинг — фича достаточно консервативная.
K>>Нет, я не про убогие возможности, а именно про навороченность синтаксиса. I>В мейнстриме в код лазят самые разные люди, с разными скилами. Сишный синтаксис это своего рода костыль для таких вот людей, снижает уровень вхождения.
Вообще-то речь про всякие ужасы, которые читаются "по спирали" и т.д. Это уровень вхождения снижает? Серьезно?
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
I>>А что тут знать. Компилируешь и смотришь, во что это выливается в итоге. Отсюда ясно, что ни перформанса, ни внятного расхода памяти нет и быть не может, при том, что нужно дизайнить внутреннее АПИ специальным образом.
K>Для паттерн-матчинга?
Именно.
I>>Полноценный ПМ можно всунуть только в полноценный ФЯ, со всеми его проблемами — перформансом и потреблением памяти. Это очень дорогая фича.
K>Не согласен, в отличие от комбинирования комбинаторов, которое если попытаться сделать нормально — целый "полноценный ФЯ" за собой притянут, паттерн-матчинг — фича достаточно консервативная.
Тем не менее фича очень дорогая в использовании. Скажем в менеджед языках после декомпиляции получается какой то тихий ужас. В том же F# небольшая программа на страницу текста даёт восемь страниц генеренного кода.
I>>В мейнстриме в код лазят самые разные люди, с разными скилами. Сишный синтаксис это своего рода костыль для таких вот людей, снижает уровень вхождения.
K>Вообще-то речь про всякие ужасы, которые читаются "по спирали" и т.д. Это уровень вхождения снижает? Серьезно?
Здравствуйте, Ikemefula, Вы писали:
I>Тем не менее фича очень дорогая в использовании. Скажем в менеджед языках после декомпиляции получается какой то тихий ужас. В том же F# небольшая программа на страницу текста даёт восемь страниц генеренного кода.
Да, я видел, что F# плохо компилирует ПМ, но это проблема конкретной реализации, ПМ можно и хорошо компилировать. Там проблема не в объемах кода — написание разбора вручную тоже даст существенно больше кода, там проблема в том, что проверки, которые уже сделаны делаются снова и снова.
I>Что значит 'читаются "по спирали"' ?
Вторая картинка в гугле по запросу "clockwise spiral rule"
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Не согласен, в отличие от комбинирования комбинаторов, которое если попытаться сделать нормально — целый "полноценный ФЯ" за собой притянут
Ради интереса: можно в двух словах, зачем нужно комбинирование комбинаторов и что это вообще такое?
Нечто типа порождения функций из неких примитивов? Если да, то в чем преимущество перед простым вызовом одной функции из другой?
Re[3]: А вот и сравнения скорости Swift с Objective-C подоспели
Ого, при соответствующей опции компилятора получаем быстродействие как у C++? Похоже я был прав в предположение об отличном дизайне (в стиле D) языка.
Ну а тем, кому нужны все эти сомнительные проверки, видимо придётся ждать более стабильной версии компилятора, в которой их попытаются оптимизировать...
P.S. И откуда ты постоянно такие полезные достаёшь? )))
Re[4]: А вот и сравнения скорости Swift с Objective-C подоспели
Здравствуйте, Klapaucius, Вы писали:
K>Да, я видел, что F# плохо компилирует ПМ, но это проблема конкретной реализации, ПМ можно и хорошо компилировать. Там проблема не в объемах кода — написание разбора вручную тоже даст существенно больше кода, там проблема в том, что проверки, которые уже сделаны делаются снова и снова.
I>>Что значит 'читаются "по спирали"' ?
K>Вторая картинка в гугле по запросу "clockwise spiral rule" K>http://cskill.files.wordpress.com/2010/06/ex21.png
Я бы не сказал, что это типичный код для Си
Re[4]: А вот и сравнения скорости Swift с Objective-C подоспели
Здравствуйте, alex_public, Вы писали:
_>Ого, при соответствующей опции компилятора получаем быстродействие как у C++? Похоже я был прав в предположение об отличном дизайне (в стиле D) языка.
И внагрузку получаем отсутствие заявленых фич.
Re[5]: А вот и сравнения скорости Swift с Objective-C подоспели
Здравствуйте, Ikemefula, Вы писали:
I>И внагрузку получаем отсутствие заявленых фич.
Ну конкретно фича с проверками меня вообще не впечатлила. Не понял зачем её вообще ввели в язык такого уровня (в котором есть доступ к голым указателям и т.п.)...
Re[6]: А вот и сравнения скорости Swift с Objective-C подоспели
Здравствуйте, alex_public, Вы писали:
I>>И внагрузку получаем отсутствие заявленых фич.
_>Ну конкретно фича с проверками меня вообще не впечатлила. Не понял зачем её вообще ввели в язык такого уровня (в котором есть доступ к голым указателям и т.п.)...
Указатели это специальный случай, например для хитрого маршалинга.
Здравствуйте, Ikemefula, Вы писали:
I>Ничего не путаю, ты показал код который использует очередь для синхронизации.
Я показал много чего там, уточняй ссылками.
В одном случае я показал как в дотнете использовать два разных механизма асинхронности, на одном из которых гонки есть, а на другом — нет, хотя в обоих случаях вызывается один и тот же асинхронный код.
Еще я показал упрощенную реализацию мануальной кооперативной многозадачности, чтобы продемонстрировать, как легко и непринужденно в случае кооперативной многозадачности можно избежать гонок. Всё что я увидел, это что ты не понимаешь определения "кооперативной многозадачности". Поэтому дальнейшие споры с тобой были бесполезны. Мне нечего добавить к уже сказанному там. Возражений по-существу так и не последовало.
I>Про кооперативную многозадачность — ты снова настаиваешь на той же ошибке. Скажем, все буквари по многозадачности утверждают, что гонки это особенность любой многозадачности
Ну значит ты так и не понял, даже спустя годы, различия в моделях организации многозадачности. И сам же в этом опять расписался. Я помню твою жесть про "прерывания". Ы-Ы-Ы, как грится...
Никакие мьютексы/критические_секции в случае кооперативной многозадачности не нужны, бо в коде и без них легко можно выделить/организовать защищенные от гонок области без дополнительных ср-в, бо передача управления в другой поток/продолжения всегда ЯВНЫЕ. В твоём асинхронном коде на дотнете ты всегда явно пинаешь механизм диспетчеризации асинхронных зачад. Кароч, оба асинхронных диспетчера в дотнете являются ПАССИВНЫМИ. Просто один из них однопоточный (тот, который на GUI-loop и на оповещениях Completion Routines, на которые умеет просыпаться WaitMessageEx и SleepEx), а второй — на пуле потоков. Так вот, во втором случае происходят гонки ни в коем случае не из-за диспетчера (ведь он по-прежнему ППАССИВНЫЙ), а из-за АКТИВНОГО диспетчера низлежащей ОС. Отсюда, кстате, напрашивается любопытное наблюдение, что если некоторые задачи в этом пуле потоков попадают на обслуживание к одному и тому же потоку ОС, то м/у собой у этих задач тоже НЕ МОЖЕТ БЫТЬ ГОНОК. Пока ты эти вещи не вкуришь, даже не пытайся спорить на эти темы.
V>>Ты не в состоянии отличить обобщенное решение от частного. I>Ты всего лишь нашел способ увильнуть от ответа, вместо обсуждения контейнеров перескочил на другие вопросы
Если ты не в состоянии дать обобщенное решение для собственной задачи, то разговаривать сразу не о чем.
Здравствуйте, alex_public, Вы писали:
_>Т.е. ты предполагаешь, что при работе с IDE компилятор Swift'a работает в особом режиме, а из консоли его примеры компилировались бы?
До MSVC от 2005-й студии я мог накатать пример на шаблонах, которые валили компилятор.
Просто исправляешь кусок кода и компилируешь дальше. В любом случае эти конструкции не поддерживались тем компилятором. При том, что свой компилятор С++ они разрабатывали аж с начала 90-х.
V>>Более того, при полноценной поддержке зависимых типов в этой задаче исчезает надобность рекурсивного определения типов, за "глубину" будет отвечать целочисленное значение, определяющее точный тип. Так шта, XCode падать не будет. )) _>Да, да, у меня именно так и вышло. )
Только вместо динамического vector<int> data в случае зависимых типов будет точный int data[N].
Правильное замечание здесь: http://rsdn.ru/forum/philosophy/5525758.1
Здравствуйте, Ikemefula, Вы писали:
V>>Всё намного проще. Я пока тупо тянул время, бо в эти выходные ни с какой виртуалкой макоси возиться не собирался.
I>Все почти верно, кроме одной детали — тянуть время ты можешь годами, или выдать "пфф любой студент за два часа, мы не в детсаде" I>Вспомнишь сам или ссылкой дать ?
Да пофиг. На руках было только описание языка. Согласно его описанию вашу задачку можно решить как тем способом, что настаивал D.Mon, так и тем, что настаивал я. Просто, коль уважаемый мной коллега УТВЕРЖДАЛ, что во встроенных массивах нет итераторов (!!! и я ему ПОВЕРИЛ, т.к. еще не прошелся по базовой либе) я предложил ему решение БЕЗ итераторов вообще.
Уверен, он понял, что я предложил, а ты — нет. И не поймешь. Но после того, как он же прилюдно исправился — показывать ЕГО решение отпало смысл. Но можно еще показать моё решение, в стиле ФП, было бы кому интересно... оно ведь и так известно.
В любом случае, даже в отсутствии в базовой либе итераторов, можно было как в С++ — отлучить операторы от языка, описать их в пользовательских типах, а для встроенных массивов или коллекций, итераторы которых по каким-либо причинам не соответствуют итераторам из стандартной либы, можно однократно написать обобщенный миниатюрный хелпер, выдающий наружу требуемые по фасаду итераторы, примерно как это сделано в концепции boost::range: http://www.boost.org/doc/libs/1_54_0/libs/range/doc/html/index.html
Я понимаю, что для тебя это всё неподъемно, ну уж извини. Я вижу язык, который позволяет делать ТАК ЖЕ, как по ссылке, поэтому не вижу проблему. Ты же знаком только с генериками дотнета, поэтому шаг вправо-влево для тебя "бессмыслица". Ну ОК, знач говорить не о чем, я вижу только бессмысленную рефлексию и топанье ножками. Как же, покусились на священную корову. )))
Что касается ссылки — дай, мне любопытно. Но за 2 часа можно сделать что угодно при уже установленном и настроенном окружении, ес-но. Именно поэтому я дал код на С++ — он просто был под рукой. Я дал часть решения, чтобы показать идею, хоть и не верил, что кто-то кроме тебя не её понял. В любом случае у меня была возможность быстро дать вторую часть решения, если бы кто-то из коллег её попросил. Хотя, я и это считаю откровенным перебором на профессиональном форуме. Идеи решений вообще можно давать на некоем всевдо-языке, какая хрен разница? А кто не вкуривает — пусть идет лесом или на 1C. С ними всё-равно неинтересно — сплошное потреблядство без обмена идеями.
Здравствуйте, Klapaucius, Вы писали:
V>>Если в полноценной реализации, то нужен, ес-но. Но для привычного ООП он почти всегда "недо-", бо идет только по первому аргументу this. K>Продемонстрированная мной техника это ограничение обходит.
Продемонстрированное тобой решение работает даже в С++, где нет полноценного параметрического полиморфизма. Ууупс?
V>>Ну а что делать, если всё кривое? )))
K>Делать прямым там, где возможно. Обсуждаемое сделать прямым можно одними средствами компилятора, все что для этого нужно (более-менее нормальный полиморфизм, инлайн методов структур и т.д.) CLR уже поддерживает.
Не получится, если компилятор не видит конечный вызываемый тип для генерика. Т.е. "подхватывать" операторы только компилятором не выйдет. ИМХО, JIT должен "знать в лицо" некий IOperators<> и делать всю эту работу сам.
V>>Ты продемонстрировал костыль в условиях "недо-".
K>Это менее костыльно чем всякие "подхватывания". Недоделанность дотнетных дженериков совсем не в этом, а в том, что от конструктора типа нельзя абстрагироваться, нету higher-kinded полиморфизма. Ну так с этим и в сабже проблемы.
Для абстрагирования от конструкторов можно использовать точно такой же трюк как ты показал для операторов. И там и там это статические вызываемые ф-ии. (Надеюсь, ты не станешь попрекать меня тем, что пользовательское тело конструктора является экземплярным методом?)
V>>Нет. Зависимость конкретных типов T->C должна быть неявной. Явное её указание — избыточность, делает решение недо-обобщенным. K>Явное указание — это, конечно, избыточность, но "недообобщенным" оно решение не делает.
Ну понятно. Дал необобщенное решение и хвалишь.
По мне обобщенное решение — это которое можно использовать изкаробки. Твоё — нельзя. Оно требует дополнительного явного определения под конкретные типы. менно поэтому в базовых либах дотнета показанный тобой трюк не используется, ведь любое решение на нём не будет готово для непосредственного использования.
V>>Можно так: V>>
V>>T Avg<T>(this IEnumerable<T> xs) where T : INumber<T>, new()
V>>
V>>Как и в Хаскель, собсно. (только с той разницей, что в дотнете INumber<T>, сцуко, описывает контракт только по одному аргументу this... но и этого могло бы хватить для арифметики)
K>Нет, ключевое отличие тут в том, что ":" задает отношение подтипирования, которого в хаскеле нет.
Я бы не говорил так громко, что нет. Классы типов — это и есть аналог подтипирования в ООП, когда речь об абстрактной базе/интерфейсах. И даже можно через механику классов типов накрутить аналог иерархий интерфейсов. Просто оно несколько ортогонально самим типам, которые в хаскеле являются лишь структурами или сигнатурами ф-ий. Но это вопрос терминологии скорее, чем механики происходящего. Фактически идентично в Хаскеле компилятором формируются таблицы для рантайм-полиморфизма, как для виртуальных методов в мейнстримовом ООП.
K>В моем решении его (между T и C) также нет и не должно быть.
Ох, блин... ну и аргументы пошли...
Да какая фиг разница, какой механизм мы использовали для задания отношения двух типов???
Какой механизм был в дотнете, такой я и использовал. Был бы другой механизм — использовал бы другой.
Твой аргумент выглядит как утверждение, что необходимо избежать связи м/у неким типом и набором операций над ним. Почему?
V>>Я тебе уже показал абзацем выше аналог на C# того, как это есть в Хаскеле. Заканчивай уже спекулировать. K>Нет, это не аналог того, что есть в хаскеле. Аналог того, что есть в хаскеле показал я.
Если бы ты показал аналог, тебе не надо было бы явно указывать ComplexReal.
V>>Ес-но, реализация арифметических операторов для Complex должна быть где-то описана. Но не дважды же!
K>Ну так она и не описана дважды:
Дважды, потому что operator+ УЖЕ был однажды описан до этого, а не дан свыше.
K>вызываются библиотечные реализации сложения и деления.
Ну да. Ты пришпилил к готовому публичному интерфейсу ООП-класса еще один фасад. Поздравляю, чо!
K>Если бы мы сами определеяли Complex — могли бы не описывать операции только для Complex, а определить их прямо в имплементации класса. И тот и другой подход используются в хаскеле.
Ну так тогда были бы проблемы с синтаксисом на C#. Ты бы не смог писать привычные a+b. И что мы тогда сравниваем языки. Давай откажемся от операторов вообще, будем описывать формулы через AST и мильон скобок. )))
V>>В Хасклеле бери любую либу с каким-нить MegaComplex, да пользуйся. А в твоём решении на C# надо еще раз по операторам пройтись да продублировать их. Что-то не так в консерватории, не правда ли? )) K>Очевидно, что надо просто положить инстансы в библиотеку и все, как в хаскеле обычно и делается.
В С++ тоже именно так и делается. Потому что любой оператор в С++ — это ф-ия! Даже оператор присваивания — это ф-ия над lvalue. А в дотнете — только ограниченное подмножество операторов доступно для переопределения и то, с ограничениями даже для такого переопределения.
Получается, что для обсуждаемого здесь класса задач, т.е. как минимум для записи вычислений через привычные операторы, Swift будет намного удобнее C#.
K>Но нередко бывает и так, когда библиотека нужных инстансов не содержит. Тогда пользователь сам описывает инстансы-"сироты". Что собственно я и зделал в своем примере на C#.
Кста! Нечто похожее есть как методы-раширения в C# и Swift. Но, опять же, в дотнете методы-расширения не подхватываются в генериках, а в Swift, насколько я понял — подхватываются.
V>>Ммм... ты действительно не понял пару постов выше намек на то, как это надо было сделать в C#? )) K>Понял, но я не согласен с тем, что в C# надо так делать. Надо было делать именно как я показал.
А смысл???
Мне пока приходит в голову лишь тот аргумент, что необходимо иметь несколько независимых наборов определений операторов с одним и тем же синтаксисом, но разной семантикой. Правда, сложно представить пользу от этого на примере complex1+xomplex2.
V>>Блин, ты же сам всё правильно говорил про Хаскель! Модель типов дотнета позволяет делать так же. Просто не сделано для встроенных типов. K>Продемонстрированная мной техника позволяет определять инстансы для любых типов. K>В хаскеле, кстати, для "встроенных" типов полиморфизм вообще не поддерживается.
Через классы типов + боксирование значений + диспетчеризацию в рантайм этого бокса по тегу завернутого в нем типа — поддерживается аж бегом. Как и в дотнет для value-type, собсно. Сорри, что опять перешел на механику происходящего, но она не сильно-то и отличается. Такой же точно переход по таблице для выборки адреса ф-ии. С той лишь разницей, что в ООП эта таблица принадлежит конкретному типу, а в Хаскеле — конкретному участку кода, где требуется рантайм-полиморфизм, т.е. типу конкретного выражения, ограниченного классами типов (т.е. заданных через "абстрактные" интерфейсы, с учетом специфики ФП языка).
V>>Но даже при этом можно было бы арифметические операторы подхватывать автоматом и на этапе генерации бинарников подставлять в тела генериков нужный код. Даже можно обойтись существующим стандартом на метаинформацию и байт-код, достаточно компилятором генерить фиктивный IOperators<> в байт-коде, а во время JIT-а просто знать этот интерфейс "в лицо" и при его фиктивной реализации просто подставлять статически-переопределенные операторы, тогда тебе не надо было бы ручками описывать свой ComplexReal.
K>Нет уж, лучше написать инстанс руками и положить в библиотеку
Опять и снова вопрос — а переопределенные операторы чем не "инстанс"?
K>а в компилятор универсальный солвер для подстановки любых инстансов, чем встраивать в реализацию компилятора и рантайма какие-то подхватывания избранных операторов.
Ну уж какие есть для переопределения. Не так уж и много.
K>Да даже и без автоподстановки инстансов — все равно лучше.
Чем?
V>>А зачем параметрический полиморфизм в сценариях, где уточненные типы выводятся еще на этапе компиляции? V>>Эдак тебя несет. Мы обсуждали конкретный пример, где параметрический полиморфизм времени исполнения не нужен ни разу.
K>Параметрического полиморфизма времени исполнения не существует, он бывает только времени компиляции.
Диспетчеризация, однако, в том же Хаскель зачастую выполняется в рантайм.
K>Этим он от завтипов отличается, для которых полное стирание типов осуществить нельзя.
От сценариев зависит, так же как и у Хаскеля. Где-то разруливает компилятор, а где-то — на этапе исполнения.
V>>Насмешил. В Хаскеле не всегда параметрический полиморфизм нужен в рантайм. 99% сценариев разруливаются на этапе компиляции, т.е. обобщенное программирование в этих сценариях не далеко ушло от С++ — обычная "текстовая подстановка" в итоге. Собсно, даже формат библиотек Хаскеля — это упакованный и размеченный результат парсинга текста (считай тупо AST исходников либы), а не объектный код.
K>Нет, это код, с которым могут поставляются, а могут и не поставляться "развертки", т.е. результат парсинга части кода. Развертки могут использоваться для оптимизации, но все работает и без них — просто медленнее. Это техническая деталь реализации межмодульной оптимизации, реализация параметрического полиморфизма от этого не зависит.
Сам себе противоречишь. Если точные конечные типы можно разрулить на этапе компиляции, то получаем аналог шаблонов С++. Если нет — то у нас рантайм-полиморфизм во всей его кривой красе.
Я когда-то подробно разбирался с Хаскель. Но не с тем, как на нём решать задачи, а как оно работает "унутре". Всё печально, кароч: при экономной записи исходника — в итоге диспетчеризация в рантайм на каждый мало-мальский чих. Даже в случаях, когда казалось бы, что должен применяться обычный ad-hoc полиморфизм, когда просто идет выбор из "глобальных" с т.з. С++, ф-ий, но вместо ad-hoc — рантайм-механика ПМ по аргументу, а имя ф-ии получается как некое обобщение над всеми наблюдаемыми в точке компиляции типами её аргмента... бррр... Поэтому дальнейшего интереса не возникло. Таким языкам еще не время. Нужна суперкомпиляция в её настоящем понимании, чтобы ЭТО взлетело.
K>Упомянутый 1% сценариев — это экзистенциальные типы, там словарь действительно не может быть подставлен в комайл-тайм и ссылка на него хранится в объекте, как в ООП.
В боксе оно хранится и идет "распаковка" этого бокса на той же механике, что и ПМ. И печаль здесь в том, что в ООП типы описываются явно и их вполне счетное кол-во, а в Хаскель это просто типы неких выражений, которых может быть несчетное кол-во, хоть по десятку в теле каждой более-менее большой ф-ии.
V>>А конкретно в этой ветке мне постарались надавать по щщам именно из-за попытки сравнения со "священной коровой". Я лишь заметил, что многих проблем C# в Swift нет.
K>Я сильно сомневаюсь, что обсуждаемая проблема в сабже решена нормально, а не в стиле C++.
Обсуждаемой проблемы в Swift нет вообще, как и в С++.
V>>Я не спорю, что до "чистых" языков ему далеко. Это гибрид и как любой гибрид состоит из компромиссов. Но в C# есть даже такие компромиссы, увы, которые вовсе не требовались. И ты наглядно их показал в своей собственной реализации yet another IArithmetic<T>.
K>Похоже на то, что и в сабже таких "компромиссов", которые не требовались, хватает.
Например?
V>>И всё-таки в джаве и дотнете не в языке гвоздь, а в миллионах строк библиотек со сложным, но достаточно надежно оттестированным функционалом.
K>Ну да, правильно.
V>>Хотя для value-типов для тех же генереков JIT генерит код, который нигде по-факту методы интерфейсов не вызывает!
K>Ну, на этом техника и основывается. если бы не это — реализовывать арифметику таким способом не было бы смысла.
V>>Т.е. сие ограничение интерфейсов только на экземплярные методы можно было бы обойти, добавив возможность задавать некий "интерфейс для статических методов", как раз арифметика туда попала бы, а связь T->C в твоём примере была однозначной и не требовала бы явного задания. (Это был бы, конечно не интерфейс в ООП-смысле, а чистый "контракт", бо интерфейс описывает лишь контракт на экземплярные методы).
K>Зачем какие-то загадочные "интерфейсы для стат.методов" придумывать, если можно просто красиво оформить передачу словаря, т.е. описанную мной технику?
Затем, что многословность. Затем, что лишняя работа, где можно допустить ошибку.
Например, в С++ передачу словарей делают через красивую идеологию traits, которая работает в compile time, через некий traits<T>::something без надобности этот traits подставлять явно. Вернее, дизайн библиотек такой, есть некий traits<>, задаваемый по-умолчанию, но его можно подставить и явно в стиле твоего решения. В итоге, всё работает "изкаробки" для 99% нужд, но у нас остаётся возможность подавать словари явно, как и у тебя, для целей изменения умолчательного поведения.
V>>Что касается по-делу. Параметрический полиформизм генериков C# показывает свою силу только в рекурсивных, относительно типов, сценариях
K>Да, совершенно верно, полиморфная рекурсия например. И да, чтоб это использовать нужны более развитые возможности тайплевел-программирования, которых в шарпе нет.
А сама CLR позволит необходимый уровень тайплевел-программирования?
K>Но вообще параметрический полиморфизм, а не шаблоны в дотнете ради раздельной компиляции сделаны. Передача словаря вполне с раздельной компиляцией совместима.
Не понял последнего абзаца.
K>>>Собственно, всякие костыльные воркараунды — единственные способы писать обобщенный код в индус триальных языках V>>Ну вот мне сходу показалось, что в Swift таких воркараундов должно быть поменьше.
K>Что-то не похоже. Вон https://github.com/maxpow4h/swiftz уже какие-то бедолаги мучаются.
Ты дал ссылку на либу, ОК. Но я не вижу там никаких "костылей". Дважды описать словарь — это костыль. Подать его затем ручками — это костыль. А если просто полезная либа, работающая "изкаробки", в чем костыльность-то? Совсем не надо либы разрабатывать или как? Наоборот, судя по примеру, им вполне удаётся всё делать в нормальном, с т.з. этого языка, синтаксисе. Посмотри сам — словари ручками подавать не надо. )))
Насчет крешей компилятора на Either<A, B>... Мы же о языке, а не о компиляторе. Бету компилятора допилят, ес-но. Насчет С++ template-template аргументов, то популярные компиляторы стали поддерживать эту фичу аж спустя примерно 5 лет после ввода её в сам язык. А непопулярные компиляторы генерили медленный код. ))
Здравствуйте, vdimas, Вы писали:
V>>>Всё намного проще. Я пока тупо тянул время, бо в эти выходные ни с какой виртуалкой макоси возиться не собирался.
I>>Все почти верно, кроме одной детали — тянуть время ты можешь годами, или выдать "пфф любой студент за два часа, мы не в детсаде" I>>Вспомнишь сам или ссылкой дать ?
V>Да пофиг. На руках было только описание языка. Согласно его описанию вашу задачку можно решить как тем способом, что настаивал D.Mon, так и тем, что настаивал я. Просто, коль уважаемый мной коллега УТВЕРЖДАЛ, что во встроенных массивах нет итераторов (!!! и я ему ПОВЕРИЛ, т.к. еще не прошелся по базовой либе) я предложил ему решение БЕЗ итераторов вообще.
Это уже третья версия происходящего если считать только твои.
Здравствуйте, vdimas, Вы писали:
V>Продемонстрированное тобой решение работает даже в С++, где нет полноценного параметрического полиморфизма. Ууупс?
Ну да. и что? Я вроде не говорил, что оно полноценного полиморфизма требует. Оно просто позволяет совместить полноценный параметрический полиморфизм с ad-hoc.
V>Не получится, если компилятор не видит конечный вызываемый тип для генерика. Т.е. "подхватывать" операторы только компилятором не выйдет. ИМХО, JIT должен "знать в лицо" некий IOperators<> и делать всю эту работу сам.
Но для приведенного мной решения поддержка джита не требуется. JIT ничего не знает про мой CReal, однако инлайнит вызовы потому, что словарь — struct.
Для автоматической подстановки словаря достаточно поддержки компилятора, чтоб он в области видимости искал структуру с имплементацией нужного интерфейса и, допустим, атрибутом TypeClass.
V>Для абстрагирования от конструкторов можно использовать точно такой же трюк как ты показал для операторов
Да нет, я не то имел в виду. Я говорил про конструктор типа вроде List или Dictionary. Чтоб можно было писать <C,T> C<T>
V>По мне обобщенное решение — это которое можно использовать изкаробки. Твоё — нельзя. Оно требует дополнительного явного определения под конкретные типы.
Ну да. "Дополнительное определение под конкретные типы" — это и есть ad-hoc полиморфизм. Посмотрел бы я как вы сможете арифметику без дополнительных определений под конкретные типы реализовать.
Решение же "из каробки" использовать моджно, если положить в коробку словари-имплементации.
V>менно поэтому в базовых либах дотнета показанный тобой трюк не используется, ведь любое решение на нём не будет готово для непосредственного использования.
Почему? В библиотеке есть классы Complex — само число и ComplexNumber — словарь с имплементациями всей арифметики. все можно использовать с любым обобщенным кодом для CNumber.
V>Я бы не говорил так громко, что нет. Классы типов — это и есть аналог подтипирования в ООП, когда речь об абстрактной базе/интерфейсах.
Нет, потому что имплементацию интерфейса можно привести к интерфейсу, а тип, для которого имплементация класса типов есть привести к классу типов нельзя. Я именнно об этом.
V>Фактически идентично в Хаскеле компилятором формируются таблицы для рантайм-полиморфизма, как для виртуальных методов в мейнстримовом ООП.
Нет, это таблицы для компайл-тайм полиморфизма (с редкими исключениями о которых ниже) и в этом тоже принципиальная разница с ООП.
V>Да какая фиг разница, какой механизм мы использовали для задания отношения двух типов???
Большая разница, потому что подтипирование — это грабли.
V>Твой аргумент выглядит как утверждение, что необходимо избежать связи м/у неким типом и набором операций над ним. Почему?
Нет, связи избегать не нужно. Нужно, по возможности, избегать того, что некий тип может быть представлен как набор операций над ним. Это приводит к потере информации о типе, всяким опасным кастам и т.д.
V>Если бы ты показал аналог, тебе не надо было бы явно указывать ComplexReal.
Если бы мне было не нужно подставлять словарь вручную — это был бы уже скорее эквивалент.
V>Дважды, потому что operator+ УЖЕ был однажды описан до этого, а не дан свыше.
Ну да, и он переиспользуется, а не реализуется заново. понятно, что то, что в каком-нибудь хаскеле выглядит как foo = bar тут обросло всякими декларациями скобками и ретурнами, ну так на то и индустриальный язык, чтоб жизнь медом не казалась. В принципе, можно и в шарпе сделать менее уродливый dictionary passing, но только он будет тормозить, с ним инлайнер не справится.
V>Ну да. Ты пришпилил к готовому публичному интерфейсу ООП-класса еще один фасад. Поздравляю, чо!
Ну да. И что с того? При написании обобщенного кода "публичный интерфейс ООП-класса" никак не пригодится, но это ж не ФЯ, в ООП обобщенный код скорее исключение, чем правило.
V>Ну так тогда были бы проблемы с синтаксисом на C#. Ты бы не смог писать привычные a+b.
Да, конечно. Но когда я говорил "надо было делать как в моем примере", я не имел в виду накостылить всю стандартную библиотеку без всяких средств для поддержки этого стиля в языке. Поддержка для операторов естественно нужна, помимо прочего.
V>В С++ тоже именно так и делается.
Нет, так не делается, потому что разделения на тип и словарь нет.
V>Получается, что для обсуждаемого здесь класса задач, т.е. как минимум для записи вычислений через привычные операторы, Swift будет намного удобнее C#.
Да, скорее всего. Но я же не говорил, что эта задача там не решена — она просто решена способом костыльным в другом аспекте. С проблемами для раздельной компиляции, например.
V>Кста! Нечто похожее есть как методы-раширения в C# и Swift. Но, опять же, в дотнете методы-расширения не подхватываются в генериках, а в Swift, насколько я понял — подхватываются.
Ну, с методами-расширениями тут мало общего. Чтоб заключение по Swift сделать — я его еще недостаточно знаю.
V>А смысл???
Например в том, что нет ограничения на волшебные интерфейсы, которые JIT-у известны. Можно определять интерфейс без доступа к коду класса и след. легковесно адаптировать несколько разных библиотек друг к другу. Больше полиморфизма рарешается на этапе компиляции. Мой подход просто быстрее интерфейсов (ну, не для struct, но по обсуждаемой технике можно и class расширять используя struct словари, а значит все будет работать так же быстро и для class).
V>Мне пока приходит в голову лишь тот аргумент, что необходимо иметь несколько независимых наборов определений операторов с одним и тем же синтаксисом, но разной семантикой. Правда, сложно представить пользу от этого на примере complex1+xomplex2.
Несколько словарей для одного типа — это как раз довольно спорное решение. тут есть трейдофф между когерентностью инстансов и модульностью подхода. В том же хаскеле выбрали первое, а в скале — второе.
V>Через классы типов + боксирование значений
Да, так поддерживается. Но довольно странно называть боксированный инт "встроенным", тем более, что каким-то особым типом со специальной поддержкой этот боксированный инт уже не является.
V>диспетчеризацию в рантайм этого бокса по тегу завернутого в нем типа
Никакой диспетчеризации в рантайм не будет. Диспетчеризация в рантайм для сумм, т.е. если конструкторов больше одного. а у забоксенного инта — один конструктор.
V>Как и в дотнет для value-type, собсно.
Совсем не так. В дотнете JIT-компайл тайм генерируются специализации для value-типов. В хаскеле JIT нет, так что либо все работает как для всех остальных боксированных, а код универсальный для всего, либо если доступны "развертки" — будет специализация и инлайн, worker-wrapper трансформация, чтоб разбоксировать инты. В результате "в цикле" все будет в регистрах. Но это если развертки доступны, т.е. при потере раздельной компиляции на объем этих разверток.
V>Сорри, что опять перешел на механику происходящего,
Ничего плохого в этом нет.
V>но она не сильно-то и отличается.
На самом деле отличается сильно.
V>Такой же точно переход по таблице для выборки адреса ф-ии. С той лишь разницей, что в ООП эта таблица принадлежит конкретному типу, а в Хаскеле — конкретному участку кода, где требуется рантайм-полиморфизм, т.е. типу конкретного выражения, ограниченного классами типов (т.е. заданных через "абстрактные" интерфейсы, с учетом специфики ФП языка).
В том и дело, что в ООП нужно "по таблице переходить" потому, что на какие функции ссылается эта таблица — только в рантайме известно. В случае тайпклассов же функции известны на этапе компиляции, потому их можно заинлайнить (если есть что инлайнить, но в любом случае никакой диспетчеризации уже не будет — только лишняя косвенность и вызовы). В тех случаях, когда подставить словарь в компайл тайм нельзя, (в случае экзистенциальных типов) ссылка на него хранится вместе с данными, как в ООП.
> class Pet a where kill :: a -> String
> data Dog = Dog deriving Show
> data Cat = Cat deriving Show
> instance Pet Dog where kill = const "dead"
> instance Pet Cat where kill = const "c_1|dead> + c_2|alive>"
> map kill [Cat, Cat] -- диспетчеризация времени компиляции
["c_1|dead> + c_2|alive>","c_1|dead> + c_2|alive>"]
> map kill [Dog, Dog] -- диспетчеризация времени компиляции
["dead","dead"]
> data PetBox where Box :: Pet a => a -> PetBox
> map (\(Box pet) -> kill pet) [Box Dog, Box Cat] -- динамическая диспетчеризация
["dead","c_1|dead> + c_2|alive>"]
Т.е. одно и то же языковое средство работает и как плюсовой шаблон пока может, и как ООП-класс с виртуальными методами, когда без динамической диспетчеризации действительно не обойтись.
И если ООП-класс дает весь оверхед дин. диспетчеризации даже если он невостребован, то класс типов — нет. И для такой оптимизации никаких трассирующих JIT-ов и прочих ухищрений для оптимизации динамики не нужно. Классы типов проще оптимизировать.
V>Опять и снова вопрос — а переопределенные операторы чем не "инстанс"?
Ну а инстансом чего они являются? В принципе, конечно, можно считать, что любой стат. метод это словарь из одной функции для класса типов "сигнатура стат.метода с заменой всех параметров с конкретным типом того класса в котором метод определен на параметры типов".
Может быть это даже приемлемый вариант для добавления классов типов в уже готовый язык.
V>Ну уж какие есть для переопределения. Не так уж и много.
Ну, это ведь не только для операторов должно работать.
V>Чем?
выше, начиная с "Например в том, что нет ограничения на..." и дальше.
V>Диспетчеризация, однако, в том же Хаскель зачастую выполняется в рантайм.
Такое происходит крайне редко, и до появления экзистенциальны типов (это расширение, хотя и старое) вообще не было возможно.
V>От сценариев зависит, так же как и у Хаскеля. Где-то разруливает компилятор, а где-то — на этапе исполнения.
Да нет, параметричность в том и заключается, упрощенно говоря, что проанализировать тип, а значит и диспетчеризовать по нему нельзя. То, что в шарпе с параметром типа можно много чего сделать — это скорее дырявость реализации параметрического полиморфизма в нем.
V>Сам себе противоречишь. Если точные конечные типы можно разрулить на этапе компиляции, то получаем аналог шаблонов С++. Если нет — то у нас рантайм-полиморфизм во всей его кривой красе.
Никакого противоречия тут нет. Параметрический тип с неподставленными в параметры типами на этапе компиляции вполне конечный и полный. Собственно поэтому и полиморфная рекурсия работает. А в плюсошаблонах все параметры для получения "конечного" типа должны быть заполнены.
Понятно, что для запуска программы и при параметрическом полиморфизме параметры нужно подставить (упрощенно говоря, там тоже свои нюансы есть) но библиотечного кода это не касается. Естественно, если все забоксено, то вполне можно генерировать обобщенный код для любых типов. Для оптимизации нужны развертки, но и без них все работает (медленно в случае арифметики, но есть и другие случаи).
V>Я когда-то подробно разбирался с Хаскель. Но не с тем, как на нём решать задачи, а как оно работает "унутре". Всё печально, кароч: при экономной записи исходника — в итоге диспетчеризация в рантайм на каждый мало-мальский чих.
Как-то странно вы смотрели, потому что это не соответствует действительности.
V>Даже в случаях, когда казалось бы, что должен применяться обычный ad-hoc полиморфизм, когда просто идет выбор из "глобальных" с т.з. С++, ф-ий, но вместо ad-hoc — рантайм-механика ПМ по аргументу, а имя ф-ии получается как некое обобщение над всеми наблюдаемыми в точке компиляции типами её аргмента... бррр...
Ничего не понял.
V>В боксе оно хранится и идет "распаковка" этого бокса на той же механике, что и ПМ.
Это даже не та же механика — распаковка это и есть паттерн-матчинг. Ну так не каждый маттерн-матчинг — диспетчеризация.
V>И печаль здесь в том, что в ООП типы описываются явно и их вполне счетное кол-во, а в Хаскель это просто типы неких выражений, которых может быть несчетное кол-во, хоть по десятку в теле каждой более-менее большой ф-ии.
Не понял, о чем речь идет. Вы про то, что каждому параметру типов соответствует параметр функции в промежуточном представлении? Ну так в рантайме этих параметров не будет. или о чем вообще?
V>Обсуждаемой проблемы в Swift нет вообще, как и в С++.
Там обсуждаемая проблема решена костыльным способом.
V>Например?
Например, отсутствие абстрагирования от конструктора типа, о котором выше.
K>>Зачем какие-то загадочные "интерфейсы для стат.методов" придумывать, если можно просто красиво оформить передачу словаря, т.е. описанную мной технику? V>Затем, что многословность. Затем, что лишняя работа, где можно допустить ошибку.
Ну так если ее нормально оформить — как в хаскеле том же — никакой многословности не будет.
Разумеется, обязательная ручная подстановка — это недостаток моего решения.
V>А сама CLR позволит необходимый уровень тайплевел-программирования?
Тайплевел программирование можно до рантайма и не доводить.
V>Не понял последнего абзаца.
Чего же тут непонятного. Решение с параметрическим полиморфизмом и передачей словарей с раздельной компиляцией совместимо, а "подстановочное" плюсошаблонное — нет.
V>Ты дал ссылку на либу, ОК. Но я не вижу там никаких "костылей".
Посмотрите, как они там с функторами/монадами мучаются.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, AlexRK, Вы писали:
ARK>Ради интереса: можно в двух словах, зачем нужно комбинирование комбинаторов и что это вообще такое? ARK>Нечто типа порождения функций из неких примитивов? Если да, то в чем преимущество перед простым вызовом одной функции из другой?
Комбинирование комбинаторов — это собирание кода из функций с помощью функций, обычно называется "функциональное программирование".
Нужно затем, что это удобный для некоторых (например, для меня) способ декомпозиции.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, Ikemefula, Вы писали:
I>>Я бы не сказал, что это типичный код для Си
K>Мы вроде говорили не про то, какой код обычный, а про то, что плохо в си-синтаксисе, нет?
Если мы отказываемся рассматривать какой код типичный, а какой нет, то в разговоре смысла нет, что очевидно, т.к. в любом языке можно сделать код состоящий из набора закорючек.
Здравствуйте, Klapaucius, Вы писали:
K>Комбинирование комбинаторов — это собирание кода из функций с помощью функций, обычно называется "функциональное программирование".
Ясно, я как-то так и представлял.
K>Нужно затем, что это удобный для некоторых (например, для меня) способ декомпозиции.
А есть ли преимущества, помимо личных предпочтений, по сравнению с банальным вызовом функции из другой функции?
Здравствуйте, AlexRK, Вы писали:
ARK>Ясно, я как-то так и представлял.
K>>Нужно затем, что это удобный для некоторых (например, для меня) способ декомпозиции.
ARK>А есть ли преимущества, помимо личных предпочтений, по сравнению с банальным вызовом функции из другой функции?
В основном потери перформанса и расход памяти Зато код становится проще, декларативнее и его легче майнтейнить.
Здравствуйте, Ikemefula, Вы писали:
I>Зато код становится проще, декларативнее и его легче майнтейнить.
Про декларативнее — пожалуй. А вот простота разработки, чтения и поддержки, ИМХО, под очень большим вопросом.
I>Более того — узкие места находить легче
Здравствуйте, AlexRK, Вы писали:
I>>Зато код становится проще, декларативнее и его легче майнтейнить.
ARK>Про декларативнее — пожалуй. А вот простота разработки, чтения и поддержки, ИМХО, под очень большим вопросом.
I>Напиши полный аналог этого кода. Я писал его около 10 секунд, это почти 1 к 1 код из текущей задачи.
Минутку, а какое отношение это имеет к комбинированию комбинаторов?
Если это комбинирование комбинаторов, то что значит фраза "в отличие от комбинирования комбинаторов, которое если попытаться сделать нормально — целый "полноценный ФЯ" за собой притянут"?
В C# никакого полноценного ФЯ нет.
I>>>Более того — узкие места находить легче ARK>>За счет чего это происходит? I>За счет того, что комбинаторы не обычные, а чистые. Можно заменить хоть один, хоть всю цепочку на оптимизированую версию без каких либо проблем.
Ну ведь это применимо и к чистым функциям. В чем профит именно подхода под названием "комбинирование комбинаторов"?
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Ikemefula, Вы писали:
ARK>>>Про декларативнее — пожалуй. А вот простота разработки, чтения и поддержки, ИМХО, под очень большим вопросом.
ARK>
I>>Напиши полный аналог этого кода. Я писал его около 10 секунд, это почти 1 к 1 код из текущей задачи.
ARK>Минутку, а какое отношение это имеет к комбинированию комбинаторов?
Прямое.
ARK>Если это комбинирование комбинаторов, то что значит фраза "в отличие от комбинирования комбинаторов, которое если попытаться сделать нормально — целый "полноценный ФЯ" за собой притянут"?
Карриинг, частичная апликация и тд.
ARK>В C# никакого полноценного ФЯ нет.
Нет, потому комбинаторы слабоватые.
I>>>>Более того — узкие места находить легче ARK>>>За счет чего это происходит? I>>За счет того, что комбинаторы не обычные, а чистые. Можно заменить хоть один, хоть всю цепочку на оптимизированую версию без каких либо проблем.
ARK>Ну ведь это применимо и к чистым функциям. В чем профит именно подхода под названием "комбинирование комбинаторов"?
Здравствуйте, AlexRK, Вы писали:
ARK>А есть ли преимущества, помимо личных предпочтений, по сравнению с банальным вызовом функции из другой функции?
Тут ложное противопоставление. Функции вызывающие другие функции — это результат. А комбинирование комбинаторов — процесс получения этого результата.
Если рассмотреть реальные альтернативы: собирать функции, вызывающие функции из готовых блоков или не иметь ни готовых блоков, ни средств их объединения — то сразу все будет понятно.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Тут ложное противопоставление. Функции вызывающие другие функции — это результат. А комбинирование комбинаторов — процесс получения этого результата.
Т.е. "комбинирование комбинаторов" — это процесс, как "программирование"?
Или конечный артефакт все же существует в виде программного кода?
K>Если рассмотреть реальные альтернативы: собирать функции, вызывающие функции из готовых блоков или не иметь ни готовых блоков, ни средств их объединения — то сразу все будет понятно.
Выделенное следует читать как "при помощи готовых блоков собирать функции, вызывающие другие функции" или как "собирать функции, вызывающие из готовых блоков другие функции"?
Если первое, то чем некий "готовый блок" чем отличается от куска кода в другой форме — например, обычной функции?
Можно ли вот тут сказать, что я собрал функцию из двух готовых блоков:
int combined(int arg)
{
return func1(func2(arg));
}
Здравствуйте, AlexRK, Вы писали:
ARK>Т.е. "комбинирование комбинаторов" — это процесс, как "программирование"? ARK>Или конечный артефакт все же существует в виде программного кода?
Не понял вопроса.
ARK>Выделенное следует читать как "при помощи готовых блоков собирать функции, вызывающие другие функции" или как "собирать функции, вызывающие из готовых блоков другие функции"?
Не уловил принципиальное различие.
ARK>Если первое, то чем некий "готовый блок" чем отличается от куска кода в другой форме — например, обычной функции?
"Готовый блок" в данном случае это функция и есть.
ARK>Можно ли вот тут сказать, что я собрал функцию из двух готовых блоков: ARK>
Здравствуйте, Klapaucius, Вы писали:
V>>Не получится, если компилятор не видит конечный вызываемый тип для генерика. Т.е. "подхватывать" операторы только компилятором не выйдет. ИМХО, JIT должен "знать в лицо" некий IOperators<> и делать всю эту работу сам.
K>Но для приведенного мной решения поддержка джита не требуется. JIT ничего не знает про мой CReal, однако инлайнит вызовы потому, что словарь — struct.
Так я и не для твоего решения предлагал, а для гипотетического автоматического.
K>Для автоматической подстановки словаря достаточно поддержки компилятора, чтоб он в области видимости искал структуру с имплементацией нужного интерфейса и, допустим, атрибутом TypeClass.
В дотнете иногда используется разметка типов через поддержку интерфейсов-атрибутов с нулевым кол-вом методов в нем, вместо собсно дотнетных атрибутов. Банально быстрее в рантайм.
V>>Для абстрагирования от конструкторов можно использовать точно такой же трюк как ты показал для операторов K>Да нет, я не то имел в виду. Я говорил про конструктор типа вроде List или Dictionary. Чтоб можно было писать <C,T> C<T>
А да. В плюсах более менее полноценно поддерживается через template-template, в Swift пока ограничено — можно наследоваться от параметра генерика, т.е. в некоторых сценариях выкрутиться можно. На генериках дотнета принципиально нельзя, ес-но, ведь для такого трюка нужна та самая "текстовая развертка" как ты её обозвал.
V>>По мне обобщенное решение — это которое можно использовать изкаробки. Твоё — нельзя. Оно требует дополнительного явного определения под конкретные типы.
K>Ну да. "Дополнительное определение под конкретные типы" — это и есть ad-hoc полиморфизм. Посмотрел бы я как вы сможете арифметику без дополнительных определений под конкретные типы реализовать. K>Решение же "из каробки" использовать моджно, если положить в коробку словари-имплементации.
Ладно, конкретно с этим спорить надоело.
1. Я не приемлю повторного определения этого словаря (ведь в первый раз уже определили глобальные операторы).
2. Не приемлю ручное задание соответствия типа и словаря.
3. не приемлю AST-синтаксис арифметических выражений: d.mul(d.add(var1, var2), var3).
Принципиальную возможность определения и использования словаря в дотнете я и не отрицал. Просто эта техника не стала популярной именно из-за перечисленных ограничений. Именно поэтому тебе даже опытные разработчики на дотнете привели необобщенное решение (тело решения было необобщенным), потому что у них уже мозжечок так натренирован. Увы.
V>>менно поэтому в базовых либах дотнета показанный тобой трюк не используется, ведь любое решение на нём не будет готово для непосредственного использования.
K>Почему? В библиотеке есть классы Complex — само число и ComplexNumber — словарь с имплементациями всей арифметики. все можно использовать с любым обобщенным кодом для CNumber.
Что-то я не вижу в базовой библиотеке типа System.Numerics.ComplexNumber. Может, не туда смотрю?
V>>Я бы не говорил так громко, что нет. Классы типов — это и есть аналог подтипирования в ООП, когда речь об абстрактной базе/интерфейсах. K>Нет, потому что имплементацию интерфейса можно привести к интерфейсу, а тип, для которого имплементация класса типов есть привести к классу типов нельзя. Я именнно об этом.
Я опять и снова НЕ ПОНИМАЮ, что ты так к этому подтипированию прицепился и что тут плохого. В ООП интерфейсы используются как контракт типа. Приведение типа к интерфейсу нужно далеко не всегда, а только лишь в тех случаях, когда требуется рантайм-полиморфизм. В остальных случаях методы могут вызываться явно по их адресу, а не через таблицу диспетчеризации. В Хаскель аналогично — когда компилятор может — вызывает ф-ии, реализующие интерфейс класса, явно. Когда нет — через таблицу диспетчеризации. Приведение к интерфейсу в ООП нужно только для возможности вызывать методы контракта, когда другой возможности нет. Но есть же ООП-языки, которые позволяют т.н. "утиную типизацию", и там приведение к базе не требуется, но через контракты всё еще можно задать требования на интерфейс типа.
V>>Фактически идентично в Хаскеле компилятором формируются таблицы для рантайм-полиморфизма, как для виртуальных методов в мейнстримовом ООП. K>Нет, это таблицы для компайл-тайм полиморфизма (с редкими исключениями о которых ниже) и в этом тоже принципиальная разница с ООП.
Это игра терминов. Происходящее фактически идентично. Разница лишь в том, чему именно принадлежат эти таблицы и как формируются.
V>>Да какая фиг разница, какой механизм мы использовали для задания отношения двух типов??? K>Большая разница, потому что подтипирование — это грабли.
В случае value-type мы имеем один уровень иерархии, так что граблей не много.
V>>Твой аргумент выглядит как утверждение, что необходимо избежать связи м/у неким типом и набором операций над ним. Почему?
K>Нет, связи избегать не нужно. Нужно, по возможности, избегать того, что некий тип может быть представлен как набор операций над ним. Это приводит к потере информации о типе, всяким опасным кастам и т.д.
Ага, ну так бы сразу и сказал, что нужно по-возможности избегать парадигмы ООП. )))
Я бы даже не пытался возражать в эту сторону. )))
V>>Если бы ты показал аналог, тебе не надо было бы явно указывать ComplexReal. K>Если бы мне было не нужно подставлять словарь вручную — это был бы уже скорее эквивалент.
Если бы словарь не надо было организовывать в виде вспомогательного (по-сути, фиктивного) типа, то был бы эквивалент. Если в С++ введут полноценные ограничения на аргументы шаблонов, то эквивалент будет возможно реализовать на С++.
K>При написании обобщенного кода "публичный интерфейс ООП-класса" никак не пригодится, но это ж не ФЯ, в ООП обобщенный код скорее исключение, чем правило.
У нас на С++ только целевые классы обычно не обобщенные, но сами они практически целиком и полностю построены как комбинация обобщенных кубиков низлежащего уровня. Что мы делаем не так?
K>Нет, так не делается, потому что разделения на тип и словарь нет.
Есть, конечно. Через области видимости. И это можно делать как неймспейсы:
template<template<class, class> class Collection, class Number>
Number roughAvg(const vector<complex> & v)
{
using namespace RoughMath;
complex sum = 0;
for(blah-blah-blah)
sum += *it;
return sum / v.size();
}
template<template<class, class> class Collection, class Number>
Number precisionAvg(const Collection<complex> & v)
{
using namespace PrecisionMath;
Number sum = 0;
for(blah-blah-blah)
sum += *it;
return sum / v.size();
}
Так и через traits-тип, когда словарь идет как тип-аргумент:
V>>Получается, что для обсуждаемого здесь класса задач, т.е. как минимум для записи вычислений через привычные операторы, Swift будет намного удобнее C#.
K>Да, скорее всего. Но я же не говорил, что эта задача там не решена — она просто решена способом костыльным в другом аспекте. С проблемами для раздельной компиляции, например.
В чем суть этих проблем?
V>>А смысл??? K>Например в том, что нет ограничения на волшебные интерфейсы, которые JIT-у известны.
Если бы это был первый такой интерфейс — то возражение понятно. Но в дотнете есть неразрывная связь м/у многими типами, компилятором и нижележащей средой исполнения. Так что, этот суп ты уже ничем не испортишь.
K>Можно определять интерфейс без доступа к коду класса и след. легковесно адаптировать несколько разных библиотек друг к другу. Больше полиморфизма рарешается на этапе компиляции. Мой подход просто быстрее интерфейсов (ну, не для struct, но по обсуждаемой технике можно и class расширять используя struct словари, а значит все будет работать так же быстро и для class).
Даже в дотнете это делается через области видимости, через технологию методов-расширений. Сами методы-расширения могут быть генериками.
Просто в дотнете, опять же, полно ограничений в методах-расширениях. Например, те же переопределённые операторы — тю-тю.
V>>Мне пока приходит в голову лишь тот аргумент, что необходимо иметь несколько независимых наборов определений операторов с одним и тем же синтаксисом, но разной семантикой. Правда, сложно представить пользу от этого на примере complex1+xomplex2.
K>Несколько словарей для одного типа — это как раз довольно спорное решение. тут есть трейдофф между когерентностью инстансов и модульностью подхода. В том же хаскеле выбрали первое, а в скале — второе.
Ну вот... а в С++ и Swift можно использовать любой подход по-вкусу. В общем, всё будет зависеть от дизайна конкретной либы.
V>>Через классы типов + боксирование значений K>Да, так поддерживается. Но довольно странно называть боксированный инт "встроенным",
Для программиста происходящее прозрачно, он по-прежнему оперирует простым инт, поэтому не вижу ничего странного. Просто речь о том, простые типы могут участвовать в сценариях, где их выбор происходит в рантайм. В этом смыслу классы типов ну ОЧЕНЬ похожи на интерфейсы ООП.
K>Никакой диспетчеризации в рантайм не будет. Диспетчеризация в рантайм для сумм, т.е. если конструкторов больше одного. а у забоксенного инта — один конструктор.
В случае Хаскеля мы имеем "автосуммы" допустимых типов выражений прямо в точке вызова некоей ф-ии, описанной в классе типов. Компилятор лепит там рантайм-ПМ прозрачно для программиста.
K>На самом деле отличается сильно.
V>>Такой же точно переход по таблице для выборки адреса ф-ии. С той лишь разницей, что в ООП эта таблица принадлежит конкретному типу, а в Хаскеле — конкретному участку кода, где требуется рантайм-полиморфизм, т.е. типу конкретного выражения, ограниченного классами типов (т.е. заданных через "абстрактные" интерфейсы, с учетом специфики ФП языка).
K>В том и дело, что в ООП нужно "по таблице переходить" потому, что на какие функции ссылается эта таблица — только в рантайме известно.
Известно только если компилятор не видит точный (конечный) тип объекта. Если же видит, то вызывает виртуальные методы напрямую, без таблицы. Именно поэтому я вижу тут аналогию.
K>В случае тайпклассов же функции известны на этапе компиляции, потому их можно заинлайнить (если есть что инлайнить, но в любом случае никакой диспетчеризации уже не будет — только лишняя косвенность и вызовы). В тех случаях, когда подставить словарь в компайл тайм нельзя, (в случае экзистенциальных типов) ссылка на него хранится вместе с данными, как в ООП. K>
...
K>
Во-во.
Например, там где в Хаскель ЛЮБЫМИ ср-ва языка необходимо было бы выразить последовательность Pet a, там в любом случае поимел бы динамическую диспетчеризаию в стиле ООП. А там, где эта полиморфизм времени исполнения не требуется, там и в ООП прекрасно обходятся без абстрактных классов/интерфейсов.
K>Т.е. одно и то же языковое средство работает и как плюсовой шаблон пока может, и как ООП-класс с виртуальными методами, когда без динамической диспетчеризации действительно не обойтись.
Замечание насчет непосредственного вызова методов вместо виртуальных в ООП я уже делал. Например в С++, если у нас vector<Cat*> — была бы динамическая диспетчеризация, а в случае vector<Cat> — этапа компиляции. В первом случае Cat рассматривался бы как корень некоей иерархии (вдруг там наследник был подан?), а во втором — как точный тип.
K>И если ООП-класс дает весь оверхед дин. диспетчеризации даже если он невостребован, то класс типов — нет.
Это даже в дотнете не так, насколько я знаю.
K>И для такой оптимизации никаких трассирующих JIT-ов и прочих ухищрений для оптимизации динамики не нужно. Классы типов проще оптимизировать.
Это еще на этапе компиляции делается, например, в случае:
var pet = new Cat();
pet.Kill();
Метод Kill будет скомпилирован как обычный вызов, а не виртуальный, в отличие от:
var pet = petFactory.GetSomePet();
pet.Kill();
V>>Опять и снова вопрос — а переопределенные операторы чем не "инстанс"?
K>Ну а инстансом чего они являются? В принципе, конечно, можно считать, что любой стат. метод это словарь из одной функции для класса типов "сигнатура стат.метода с заменой всех параметров с конкретным типом того класса в котором метод определен на параметры типов". K>Может быть это даже приемлемый вариант для добавления классов типов в уже готовый язык.
Вот из этого я и исходил в своих рассуждениях.
V>>Ну уж какие есть для переопределения. Не так уж и много. K>Ну, это ведь не только для операторов должно работать.
Ну так есть GoF паттерн "стратегия" и даже "визитор", для разных сценариев обсуждаемого. Да, стратегия или визитор подаются "извне".
V>>Диспетчеризация, однако, в том же Хаскель зачастую выполняется в рантайм. K>Такое происходит крайне редко, и до появления экзистенциальны типов (это расширение, хотя и старое) вообще не было возможно.
А как же в случае, когда надо было выразить генератор последовательности Pet a?
V>>Сам себе противоречишь. Если точные конечные типы можно разрулить на этапе компиляции, то получаем аналог шаблонов С++. Если нет — то у нас рантайм-полиморфизм во всей его кривой красе.
K>Никакого противоречия тут нет. Параметрический тип с неподставленными в параметры типами на этапе компиляции вполне конечный и полный.
Но не является уточненным, всё-равно.
K>Собственно поэтому и полиморфная рекурсия работает. А в плюсошаблонах все параметры для получения "конечного" типа должны быть заполнены.
Да.
K>Понятно, что для запуска программы и при параметрическом полиморфизме параметры нужно подставить (упрощенно говоря, там тоже свои нюансы есть) но библиотечного кода это не касается. Естественно, если все забоксено, то вполне можно генерировать обобщенный код для любых типов. Для оптимизации нужны развертки, но и без них все работает (медленно в случае арифметики, но есть и другие случаи).
Да.
V>>В боксе оно хранится и идет "распаковка" этого бокса на той же механике, что и ПМ. K>Это даже не та же механика — распаковка это и есть паттерн-матчинг. Ну так не каждый маттерн-матчинг — диспетчеризация.
Если в рантайм, то почему не диспетчеризация?
V>>И печаль здесь в том, что в ООП типы описываются явно и их вполне счетное кол-во, а в Хаскель это просто типы неких выражений, которых может быть несчетное кол-во, хоть по десятку в теле каждой более-менее большой ф-ии.
K>Не понял, о чем речь идет. Вы про то, что каждому параметру типов соответствует параметр функции в промежуточном представлении? Ну так в рантайме этих параметров не будет. или о чем вообще?
О решении популярного примера на проверку на этапе компиляции длин двух последовательностей на Хаскеле, например.
V>>Обсуждаемой проблемы в Swift нет вообще, как и в С++. K>Там обсуждаемая проблема решена костыльным способом.
V>>Например? K>Например, отсутствие абстрагирования от конструктора типа, о котором выше.
Ммм... Не думаю, что для Complex это актуально, даже если у нас Complex<T>.
V>>А сама CLR позволит необходимый уровень тайплевел-программирования? K>Тайплевел программирование можно до рантайма и не доводить.
Ну тогда не будет CLR библиотек, а только текстовые include их исходников, либо распаршенных вариантов, как в Хаскель. ))
V>>Не понял последнего абзаца. K>Чего же тут непонятного. Решение с параметрическим полиморфизмом и передачей словарей с раздельной компиляцией совместимо, а "подстановочное" плюсошаблонное — нет.
Почему??? Реализация словаря вполне может быть частью библиотеки.
V>>Ты дал ссылку на либу, ОК. Но я не вижу там никаких "костылей". K>Посмотрите, как они там с функторами/монадами мучаются.
Видел. В MSVC++ мучались аж до 2005-го года. ))
Потом взлетело.
Здравствуйте, vdimas, Вы писали:
V>Так я и не для твоего решения предлагал, а для гипотетического автоматического.
Если из моего решения сделать "автоматическое" — поддержка джита точно так же не понадобится (кроме той, что уже есть).
V>В дотнете иногда используется разметка типов через поддержку интерфейсов-атрибутов с нулевым кол-вом методов в нем, вместо собсно дотнетных атрибутов. Банально быстрее в рантайм.
А смысл? Словари никто в рантайме не ищет, только в компайлтайм.
V>А да. В плюсах более менее полноценно поддерживается через template-template, в Swift пока ограничено — можно наследоваться от параметра генерика, т.е. в некоторых сценариях выкрутиться можно. На генериках дотнета принципиально нельзя, ес-но, ведь для такого трюка нужна та самая "текстовая развертка" как ты её обозвал.
Нет, не нужна. В хаскеле, скале и других для этого текстовая развертка не требуется. Ее, в принципе, даже в шарп можно добавить без изменения CLR при отказе от возможности обобщать конструкторы value-типов, что, прямо скажем, очень экзотический юзкейс.
V>Ладно, конкретно с этим спорить надоело. V>1. Я не приемлю повторного определения этого словаря (ведь в первый раз уже определили глобальные операторы).
Т.е. классы типов вы не примемлете в принципе. Они ведь всегда это требуют (в некоторых случаях, правда "мономорфные" операции не определены, сразу с инстанса и начинают).
V>2. Не приемлю ручное задание соответствия типа и словаря.
Это мне самому не нравится, хотя у ручной подстановки есть как некоторые плюсы по сравнению с автоподстановкой, так и реальные сторонники среди хаскелистов http://www.haskellforall.com/2012/05/scrap-your-type-classes.html
V>3. не приемлю AST-синтаксис арифметических выражений: d.mul(d.add(var1, var2), var3).
Это безоговорочно плохо, но подавляющее большинство имен в дотнетных либах — альфанумерик и эта проблема касается мало чего кроме арифметики.
V>Принципиальную возможность определения и использования словаря в дотнете я и не отрицал. Просто эта техника не стала популярной именно из-за перечисленных ограничений. Именно поэтому тебе даже опытные разработчики на дотнете привели необобщенное решение (тело решения было необобщенным), потому что у них уже мозжечок так натренирован. Увы.
Думаю, что причина малого использования — то, что стандартная библиотека реализована не в такой технике. Обычно именно она и диктует, каким должен быть "идеоматический" код. Перечисленные недостатки имеются в том или ином составе во множестве языков и реализаций и как-то преодолеваются программистами (программистам ко всяким проблемам на ровном месте не привыкать, их преодоление они часто, наоборот, считают за доблесть). К примеру, существуют программистские культуры, которые неприемлют операторы в принципе, а значит 3 для них не недостаток, существуют сообщества вокруг языков, где практикуется ручная подстановка словаря в той или иной форме (всякие MLи), а "недостаток" 1 существует во всех реализациях без исключения.
V>Что-то я не вижу в базовой библиотеке типа System.Numerics.ComplexNumber. Может, не туда смотрю?
В базовой библиотеке и Complex не так давно появился. А небазовую библиотеку кто угодно может написать. Главное, что это можно в библиотеку положить, а не писать всякий раз по месту, как лямбды в соседнем примере с Aggregate.
V>Я опять и снова НЕ ПОНИМАЮ, что ты так к этому подтипированию прицепился и что тут плохого.
Просто подтипирование это действительно плохо. Что проявляется на многих уровнях, от стимулирования написания полудинамического глюкокода до проблем со взрывающими мозг ко/контравариантностями (и соотвествующими багами, вроде дыры в дотнет-массивах) и выводом/реконструкцией типов.
Фан факт: чтоб сделать хаскель полностью непригодным для функционального программирования — в него достаточно сабтайпинг добавить и все, больше ничего делать не нужно.
V>В ООП интерфейсы используются как контракт типа. Приведение типа к интерфейсу нужно далеко не всегда, а только лишь в тех случаях, когда требуется рантайм-полиморфизм.
Что характерно, даже для рантайм полиморфизма "приведение к интерфейсу" не нужно — если экзистенциальные типы есть.
V>Это игра терминов. Происходящее фактически идентично. Разница лишь в том, чему именно принадлежат эти таблицы и как формируются.
В том и дело. Разница между "можно заинлайнить в 99% случаев" и "нельзя заинлайнить в 99% случаев" одной "игрой терминов" не достигается.
V>В случае value-type мы имеем один уровень иерархии, так что граблей не много.
А в случае class — имеем не один уровень.
V>Ага, ну так бы сразу и сказал, что нужно по-возможности избегать парадигмы ООП. ))) V>Я бы даже не пытался возражать в эту сторону. )))
Под ООП люди что угодно могут подразумевать, так что я выразился конкретнее.
V>Если бы словарь не надо было организовывать в виде вспомогательного (по-сути, фиктивного) типа, то был бы эквивалент. Если в С++ введут полноценные ограничения на аргументы шаблонов, то эквивалент будет возможно реализовать на С++.
Так ведь словарь и в хаскеле реализован с помощью "вспомогательного фиктивного типа", что в имплементациях где дикшнари пассинг, что в тех где для этого GADT применяют. Поэтому и аналог.
V>У нас на С++ только целевые классы обычно не обобщенные, но сами они практически целиком и полностю построены как комбинация обобщенных кубиков низлежащего уровня. Что мы делаем не так?
Все же уровень не сравнимый. В плюсах обобщение явное и синтаксически тяжеловесное. В ФЯ обобщение по умолчанию.
K>>Нет, так не делается, потому что разделения на тип и словарь нет.
V>Есть, конечно.
Ну да, делается в том числе и так, но это более позднее изобретение. Первоначальный ООП-подход предполагает, что словарь и данные — вместе.
V>В чем суть этих проблем?
В отсутствии раздельной компиляции.
V>Если бы это был первый такой интерфейс — то возражение понятно. Но в дотнете есть неразрывная связь м/у многими типами, компилятором и нижележащей средой исполнения. Так что, этот суп ты уже ничем не испортишь.
Какие-то интерфейсы, конечно, будут волшебными. Я о том, что для нормальной работы все подряд волшебным не сделать.
V>Даже в дотнете это делается через области видимости, через технологию методов-расширений. Сами методы-расширения могут быть генериками.
Нет, полиморфизм на методах расширений не сделать. Реальная альтернатива описываемому подходу — виртуальные методы.
V>Просто в дотнете, опять же, полно ограничений в методах-расширениях. Например, те же переопределённые операторы — тю-тю.
Это не самая серьезная проблема с ними.
K>>Несколько словарей для одного типа — это как раз довольно спорное решение. тут есть трейдофф между когерентностью инстансов и модульностью подхода. В том же хаскеле выбрали первое, а в скале — второе. V>Ну вот... а в С++ и Swift можно использовать любой подход по-вкусу. В общем, всё будет зависеть от дизайна конкретной либы.
Как в С++ можно когерентность инстансов организовать?
V>Для программиста происходящее прозрачно, он по-прежнему оперирует простым инт, поэтому не вижу ничего странного.
И где повод назвать этот инт "встроенным"? всеми остальными объектами он тоже оперирует, так же как этим интом.
V>Просто речь о том, простые типы могут участвовать в сценариях, где их выбор происходит в рантайм.
Не понял, о чем идет речь.
V>В этом смыслу классы типов ну ОЧЕНЬ похожи на интерфейсы ООП.
У вас, по-моему, далекое от реальности представление о классах типов.
Да, без всякой оптимизации класс типов это та же структура с ссылками на функции. Но разница в том, что для класса типов мы обычно уже в компайл тайм знаем, что это за функции. Именно потому инлайн и возможен (хотя для инлайна еще требуется доступность того, что инлайнится). В случае же ООП мы наоборот как правило не знаем в компайл-тайм на какие функции там ссылки, доступны эти функции для инлайна или нет — уже не важно, нам не известно что инлайнить.
V>В случае Хаскеля мы имеем "автосуммы" допустимых типов выражений прямо в точке вызова некоей ф-ии, описанной в классе типов. Компилятор лепит там рантайм-ПМ прозрачно для программиста.
Нет, никакой автосуммы типов и рантайм-ПМ по ней в точке вызова функции-члена класса нет. Компилятор подставляет вместо члена класса код специализированной функции в лучшем случае и ссылку на специализированную функцию в худшем.
V>Известно только если компилятор не видит точный (конечный) тип объекта. Если же видит, то вызывает виртуальные методы напрямую, без таблицы. Именно поэтому я вижу тут аналогию.
Но компилятор обычно не видит конечный тип объекта. И из-за сабтайпинга в том числе, кстати.
V>Во-во. V>Например, там где в Хаскель ЛЮБЫМИ ср-ва языка необходимо было бы выразить последовательность Pet a, там в любом случае поимел бы динамическую диспетчеризаию в стиле ООП. А там, где эта полиморфизм времени исполнения не требуется, там и в ООП прекрасно обходятся без абстрактных классов/интерфейсов.
В ООП сложно обозначить область где рантайм-полиморфизм не требуется. Крайне сложно выявить ее статическим анализом. Виртуальные вызовы только какой-нибудь трассирующий джит нормально устранить сможет.
Поэтому, там где рантайм полиморфизм требуется — там он везде будет. А там, где не требуется — в ООП скорее всего будет, а в хаскеле — нет.
K>>Т.е. одно и то же языковое средство работает и как плюсовой шаблон пока может, и как ООП-класс с виртуальными методами, когда без динамической диспетчеризации действительно не обойтись.
V>а в случае vector<Cat> — этапа компиляции.
Что достигается тем, что параметрического полиморфизма нету, а есть подстановка и кодогенерация, так что было бы сложно сделать как-то иначе. В дотнете же, если Cat не struct придется бессмысленно тормозить на виртуальных методах, даже если все элементы одного типа на самом деле — из за сабтайпинга это установить невозможно.
V>Это даже в дотнете не так, насколько я знаю.
Дотнет устраняет этот ненужный оверхед для struct. Но типичный класс в дотнете — реф.тип.
K>>И для такой оптимизации никаких трассирующих JIT-ов и прочих ухищрений для оптимизации динамики не нужно. Классы типов проще оптимизировать.
V>Это еще на этапе компиляции делается, например, в случае: V>
V>var pet = new Cat();
V>pet.Kill();
V>
V>Метод Kill будет скомпилирован как обычный вызов, а не виртуальный, в отличие от: V>
V>var pet = petFactory.GetSomePet();
V>pet.Kill();
V>
Мы сейчас про дженерики и констрейнты-интерфейсы. "Мономорфный" код к обсуждению отношения не имеет — там, конечно, проблем с оптимизацией меньше (ровно по той же причине, почему с темплейтами выше все работает — ведь дело нужно иметь только с мономорфным кодом, шаблонный не типизируется и не компилируется).
V>Ну так есть GoF паттерн "стратегия" и даже "визитор", для разных сценариев обсуждаемого. Да, стратегия или визитор подаются "извне".
Ну так это по сути и есть обсуждаемая техника.
V>А как же в случае, когда надо было выразить генератор последовательности Pet a?
Тогда бы хаскелист просто делал последовательность "санков" kill Cat/ kill Dog. Вместо класса со многими функциями — словарь бы завел. Многие хаскелисты и сейчас скорее так сделают, чем экзистенциальные типы используют.
Естественно, такое решение хуже в смысле потребления памяти (для экзистенциального типа достаточно иметь один словарь в памяти на каждый инстанс, при ручной передаче такое разделение словаря между значениями нужно будет специально организовывать) и удобства вроде синтаксиса и когерентности (при ручной передаче программисту самому следить за этим придется), тем не менее экзистенциальные типы многие почему-то не любят.
K>>Никакого противоречия тут нет. Параметрический тип с неподставленными в параметры типами на этапе компиляции вполне конечный и полный. V>Но не является уточненным, всё-равно.
Ну да, так в этом и смысл параметрического полиморфизма.
V>Если в рантайм, то почему не диспетчеризация?
По моему, диспетчеризация подразумевает выбор между какими-то ветками вычислений.
Т.е. если у нас сумма — диспетчеризация есть
foo (Just a) = первый_вариант
foo Nothing = второй_вариант
А Int — не сумма.
foo (I# a) = без_вариантов
Где тут диспетчеризация? Это просто dereferencing.
V>О решении популярного примера на проверку на этапе компиляции длин двух последовательностей на Хаскеле, например.
А, так их там не по десятку, а сколько угодно. Ну и они "сотрутся".
V>Ммм... Не думаю, что для Complex это актуально, даже если у нас Complex<T>.
Для Complex это, конечно, не актуально, но программирование на Complex не заканчивается.
V>Ну тогда не будет CLR библиотек, а только текстовые include их исходников, либо распаршенных вариантов, как в Хаскель. ))
CLR библиотек с такими сигнатурами (с навороченным тайплевелом) да, не будет.
K>>Чего же тут непонятного. Решение с параметрическим полиморфизмом и передачей словарей с раздельной компиляцией совместимо, а "подстановочное" плюсошаблонное — нет.
V>Почему??? Реализация словаря вполне может быть частью библиотеки.
Ну да, можно и на плюсах писать со стиранием, ссылками и передачей словарей, но обычно не пишут. Но это не "подстановочное" решение для которого библиотека нужна будет в исходниках.
V>Видел. В MSVC++ мучались аж до 2005-го года. )) V>Потом взлетело.
Подозреваю, что на сабж потратят гораздо меньше человекочасов, чем плюсам достались, так что это не тот ориентир.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, AlexRK, Вы писали:
ARK>Почему? ARK>Не придираюсь, просто хочу понять. ARK>Есть "готовые блоки" func1 и func2. Я их скомбинировал и получил третью функцию.
Есть калькулятор, у которого только цифровые клавиши, 2 + 2 = набрать нельзя. Но клавиши для операций над числами не нужны: можно же посчитать в уме и набрать сразу 4 (и многие другие числа).
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
I>>О, круто, в Swift появилась поддержка шаблонов С++. Любопытная идейка.
V>Да, генерики Swift по-устройству аналогичны шаблонам С++, а не генерикам дотнета. Поэтому вполне корректно.
Ты не волнуйся, я смотрю на твои заявления черз призму "просто я тянул время", "любой студент за два часа", "ios давно не трогал" и тд
Здравствуйте, vdimas, Вы писали:
K>>Нет, связи избегать не нужно. Нужно, по возможности, избегать того, что некий тип может быть представлен как набор операций над ним. Это приводит к потере информации о типе, всяким опасным кастам и т.д.
V>Ага, ну так бы сразу и сказал, что нужно по-возможности избегать парадигмы ООП. ))) V>Я бы даже не пытался возражать в эту сторону. )))
Тип в ООП это АТД + представление + реализация. Если тип это класс то к указаному добавляется еще и модуль где хранится реализация.
Отсюда ясно, что нет никакого избегания ООП.
Соответсвенно, представляя тип как набор операций теряем практически всю информацию. Компилятор не сможет помочь, поскольку только в рантайме будет известно чего же вызовется на самом деле.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, andyag, Вы писали:
A>>На дворе 2014ый год, а появляется новый "альтернативно одарённый" язык, которому глубоко плевать на этот самый 2014ый год.
ARK>А что из 2014 года не хватает в Swift?
Как я уже раз 5 здесь написал, хороший яркий пример — рефлексия.
Здравствуйте, NeoCode, Вы писали:
NC>Здравствуйте, andyag, Вы писали:
A>>У вас любимая кошка сходила в туалет по-большому прямо в центре кухни. Предлагаются варианты:
A>>1. Организовать на кухне музей альтернативного искусства A>>2. Убрать A>>3. Посыпать сахаром и оставить на потом
A>>Ваши действия?
NC>Указать оппоненту на то, что сравнение нового языка программирования с продуктом жизнедеятельности кошки как минимум нужно еще обосновать, и весьма серьезно обосновать.
Предложите вашу метафору, с радостью испаганю аналогичным образом.
Здравствуйте, AlexRK, Вы писали:
ARK>Почему? ARK>Не придираюсь, просто хочу понять. ARK>Есть "готовые блоки" func1 и func2. Я их скомбинировал и получил третью функцию.
Да нормальная это комбинация. Просто речь об отсутствие синтаксического сахара соответствующего. Что кстати тоже может быть принципиально в некоторых случаях, т.к. от этого будет зависеть частота применения данной техники. Тем более, что обычно в таких случаях результат комбинации тоже отправляют в какую-то функцию. Т.е. вот допустим у нас есть функции float f1(int) и string f2(float). И мы хотим применить их последовательно к каждому элементу некого массива. Понятно что в этом случае вариант вида:
Однако вариант выше совсем не единственный. В большинстве современных императивных языков можно записать что-то вроде:
map(x=>f2(f1(x)),...)
Ну а если язык хорошо поддерживает шаблоны и перегрузку операторов (типа C++ или D), то можно вообще перегрузить какой-нибудь подходящий оператор и получить код типа такого:
map(f1|f2)
что уже в общем то ничем не отличается от варианта, где у нас есть "комбинирование комбинаторов". Естественно это не единственный нюанс, который требуется для таких дел. Для полного удобства надо добавить в язык ещё несколько подобных вспомогательных штуковин. Но делается абсолютно без проблем, аналогично примеру выше, и более того, уже давно сделано в соответствующих библиотеках.
Здравствуйте, vdimas, Вы писали:
V>Да, генерики Swift по-устройству аналогичны шаблонам С++, а не генерикам дотнета. Поэтому вполне корректно.
А это точно так? Т.е. для меня то это звучит очень позитивно (хотя я не планирую работать на Swift'e, просто из общих соображений). Потому как даже если в шаблон нельзя передавать int'ы и т.п. (т.е. факториал не посчитаешь ), то всё равно будет очень большое пространство для разных сложных и полезны штук из области МП. Но я что-то не заметил в документации каких-то описаний деталей реализации этого дела...
Но зато я заметил вместо этого другое любопытное явление. Как у них сделана параметризация интерфейсов. Не как классов, а с помощью некого typealias. И соответственно реализовать такой интерфейс можно как с помощью обычного класса (тогда надо определить typealias в нём), так и с помощью generic'а (и там Swift автоматом подхватит параметр в качестве typealias). Весьма забавная техника.
Здравствуйте, Klapaucius, Вы писали:
V>>В дотнете иногда используется разметка типов через поддержку интерфейсов-атрибутов с нулевым кол-вом методов в нем, вместо собсно дотнетных атрибутов. Банально быстрее в рантайм. K>А смысл? Словари никто в рантайме не ищет, только в компайлтайм.
Для случая ООП и рантайм-вариант прозрачно для программиста работает.
V>>А да. В плюсах более менее полноценно поддерживается через template-template, в Swift пока ограничено — можно наследоваться от параметра генерика, т.е. в некоторых сценариях выкрутиться можно. На генериках дотнета принципиально нельзя, ес-но, ведь для такого трюка нужна та самая "текстовая развертка" как ты её обозвал.
K>Нет, не нужна. В хаскеле, скале и других для этого текстовая развертка не требуется. Ее, в принципе, даже в шарп можно добавить без изменения CLR при отказе от возможности обобщать конструкторы value-типов, что, прямо скажем, очень экзотический юзкейс.
Все-равно не представляю, как ср-вами CLR хранить описание таких типов.
И если не сложно, раскрой, плиз выделенное.
V>>3. не приемлю AST-синтаксис арифметических выражений: d.mul(d.add(var1, var2), var3). K>Это безоговорочно плохо, но подавляющее большинство имен в дотнетных либах — альфанумерик и эта проблема касается мало чего кроме арифметики.
В среднем коде наблюдается этой арифметики, в т.ч. булевой логики — до половины. Весь остальной мильон альфанумериков делят оставшиеся %% кода м/у собой. Отсюда такое внимание именно операторам языка — они ведь составляют приличную долю синтаксиса исходника.
K>Просто подтипирование это действительно плохо. Что проявляется на многих уровнях, от стимулирования написания полудинамического глюкокода до проблем со взрывающими мозг ко/контравариантностями (и соотвествующими багами, вроде дыры в дотнет-массивах) и выводом/реконструкцией типов.
Ко/контрвариантность — тоже инструмент упорядочивания кода при глубине иерархий больше 2. В плюсах раньше всего это ввели в сигнатуры виртуальных методов — это моментально помогло решить проблему с избыточным дауншифтингом при реализации интерфейсов на сложных иерархиях. Т.е. элегантно и типобезопасно побороли самую страшную ООП-граблю.
K>Фан факт: чтоб сделать хаскель полностью непригодным для функционального программирования — в него достаточно сабтайпинг добавить и все, больше ничего делать не нужно.
Тогда это будет гибрид, как C# или C++ с чуть более продвинутой системой типов. ))
В любом случае, нечто вроде сабтайпинга накрутить можно и в Хаскель:
type OutputStream a = StreamBase (COutputStream a)
Ведь контракты ООП — это тоже ограничения. ))
В классике системного подхода любое требование автоматически является ограничением.
В итоге, иерархия ограничений Хаскеля в точности равна иерархии интерфейсов ООП с т.з. дизайна.
K>В том и дело. Разница между "можно заинлайнить в 99% случаев" и "нельзя заинлайнить в 99% случаев" одной "игрой терминов" не достигается.
Ну это в дотнете, разве что, а не плюсах (или Swift). Ты не обратил ниже внимание на разницу Cat и Cat*. Просто для дотнета этой разницы нет, ведь в нем всегда Cat* для классов.
V>>Ага, ну так бы сразу и сказал, что нужно по-возможности избегать парадигмы ООП. ))) V>>Я бы даже не пытался возражать в эту сторону. )))
K>Под ООП люди что угодно могут подразумевать, так что я выразился конкретнее.
Ну да, св-ва гибридных языков начинают приписывать ООП в целом. Но ты выразился именно про парадигму ООП. Спорить не хочу, т.к. полно сценариев, где ООП-парадигма работает прекрасно. Например, сокет или окошко GUI, кароч везде, где конечный объект "непрозрачен" по объективным причинам. Даже в Хаскеле в сетевых и GUI либах сплошное ООП.
V>>Если бы словарь не надо было организовывать в виде вспомогательного (по-сути, фиктивного) типа, то был бы эквивалент. Если в С++ введут полноценные ограничения на аргументы шаблонов, то эквивалент будет возможно реализовать на С++.
K>Так ведь словарь и в хаскеле реализован с помощью "вспомогательного фиктивного типа"
Класс типов это не тип, а контракт. Его "воплощения" в природе не существует.
V>>У нас на С++ только целевые классы обычно не обобщенные, но сами они практически целиком и полностю построены как комбинация обобщенных кубиков низлежащего уровня. Что мы делаем не так?
K>Все же уровень не сравнимый. В плюсах обобщение явное и синтаксически тяжеловесное. В ФЯ обобщение по умолчанию.
Это лишь в языках-наследниках ML. Обобщение и ФП — вещи глубоко ортогональные друг другу, так же как обобщение в ООП. Полно функциональных языков безо-всякого обобщения. Как альтернатива — в таких языках обычно есть макросы.
K>>>Нет, так не делается, потому что разделения на тип и словарь нет. V>>Есть, конечно. K>Ну да, делается в том числе и так, но это более позднее изобретение. Первоначальный ООП-подход предполагает, что словарь и данные — вместе.
Ну да. Но мы же сравниваем конкретные языки. А они гибридные. ))
V>>В чем суть этих проблем? K>В отсутствии раздельной компиляции.
Сам словарь-то для конкретного типа зачастую не обобщенный нифига, какие проблемы с раздельной компиляцией?
K>Как в С++ можно когерентность инстансов организовать?
Если я правильно понял вопрос, то через области видимости. Через неймспейсы, например.
Если не в тему, то расшифруй вопрос, плиз.
V>>В этом смыслу классы типов ну ОЧЕНЬ похожи на интерфейсы ООП.
K>У вас, по-моему, далекое от реальности представление о классах типов. K>Да, без всякой оптимизации класс типов это та же структура с ссылками на функции. Но разница в том, что для класса типов мы обычно уже в компайл тайм знаем, что это за функции.
Можно мне, тупому, показать на пальцах пример в Хаскель, когда бы у нас была последовательность абстрактных Pet a, и к ней некоторая библиотека, которая вызывает kill pet, проходя по этой последовательности. Причем, конкретная конечная сумма {Dog, Cat, Parrot, ...} этой библиотеке заранее не известна (на то она и библиотека). И еще, чтобы это была раздельная компиляция. Вот сценарий: из файла мы читаем список РАЗНЫХ животных и обрабатываем их последовательность библиотечной ф-ией, а не делаем предварительный ПМ на клиентской, по отношению к либе, стороне.
K>Именно потому инлайн и возможен (хотя для инлайна еще требуется доступность того, что инлайнится).
Вот давай посмотрим на инлайн в этой задаче.
K>В случае же ООП мы наоборот как правило не знаем в компайл-тайм на какие функции там ссылки, доступны эти функции для инлайна или нет — уже не важно, нам не известно что инлайнить.
Это зависит от того, что "видит" компилятор — сам объект или только его адрес. Если компилятор С++ видит Cat по-значению (на стеке, глобальную переменную или как поле другого объекта), то он вызывает методы напрямую, если же он видит Cat* или Cat&, то он понятия не имеет (в общем случае) о точном типе объекта по адресу, поэтому работает рантайм-полиморфизм.
V>>В случае Хаскеля мы имеем "автосуммы" допустимых типов выражений прямо в точке вызова некоей ф-ии, описанной в классе типов. Компилятор лепит там рантайм-ПМ прозрачно для программиста.
K>Нет, никакой автосуммы типов и рантайм-ПМ по ней в точке вызова функции-члена класса нет. Компилятор подставляет вместо члена класса код специализированной функции в лучшем случае и ссылку на специализированную функцию в худшем.
В последнем неточность. Если в бинарнике вшит адрес ф-ии (прямая адресация) то диспетчеризации нет. Если же там переменная/ячйка, в которой хранится адрес (а в ФП так почти всегда), то это косвенная адресация, она же диспетчеризация. Последнее — это полный аналог интерфейса с одним методом, то бишь тот самый рантайм-полиморфизм.
В любом месте виртуального вызова метода в ООП мы имеем дело с ОДНИМ только методом, т.е. всего с одной интересующей ячейкой для косвенного вызова, т.е. глубоко пофиг, один метод содержится в интерфейсе или несколько. Целиком таблица виртуальных вызовов не нужна ни разу и никем не просматривается — сразу берется нужный адрес в известной, на этапе компиляции, её строке.
V>>Известно только если компилятор не видит точный (конечный) тип объекта. Если же видит, то вызывает виртуальные методы напрямую, без таблицы. Именно поэтому я вижу тут аналогию.
K>Но компилятор обычно не видит конечный тип объекта. И из-за сабтайпинга в том числе, кстати.
Это в джаве-дотнете, бо эти языки работают не с самими объектами, а с указателями на них, то бишь ВСЕГДА речь идет о косвенных вызовах, всегда речь идет о диспетчеризации. Там же, где доступна прямая адресация, там известен точный тип. Например, value-type в дотнете.
K>В ООП сложно обозначить область где рантайм-полиморфизм не требуется.
Чем больше возможности обобщенного программирования, тем меньше надо разводить иерархий и паттернов GoF на ровном месте. Цель-то всех этих техник банальна — повторное использование кода. Полиморфизм — лишь одна из техник. По отношению к парадигме ООП, наследование реализаций — это просто некий трюк где-то сбоку. Можно взять для рассмотрения более строгую парадигму КОП — наследование только интерфейсов.
Ну и в обычных пользовательских классах доля виртуальных методов далеко не 100%, а как бы заметно ниже 50%.
K>Крайне сложно выявить ее статическим анализом.
Блин...
Если компилятор "видит" как сформирована ячейка памяти, то он знает точный её тип.
Например, средний граф объектов в памяти при решении одной и той же задачи на С++ и C# резко отличается. В C# будет взрывающий мозг граф из-за того, что 99.99% объектов будут ссылочные. А в С++ используют владение по ссылке в самом крайнем случае — только если сама задача диктует такой дизайн, когда конечный тип объекта заведомо не может быть известен. То-бишь, такой рантайм-полиморфизм является целевым и был бы таким же "рантайм-чего-то-там" на любом языке. В остальных случаях в С++, при разработке типов, обычно располагают поля по-значению (исключу пока подход p-impl, он специфичен, обычно только для фасадных/публичных классов проприетарных библиотек).
В итоге, в методах объектов верхних уровней, при обращении к методам собственных объектов-полей, реализуется статический вызов методов. Причем, речь всё еще идет не о гибридных возможностях языка, а о самых что ни на есть ООП-фичах.
В общем, с заявлением "В ООП сложно обозначить область где рантайм-полиморфизм не требуется" согласиться оч сложно. По-сути, ты приписал всему ООП ограничения пары популярных платформ — дотнета/джавы.
Более того, нет никаких ограничений, даже в условиях GC, располагать объекты по-значению в теле объектов-владельцев. В современном дотнете есть управляемые ссылки на "где-то в середине объекта", которые во время исполнения представлены точно таким же обыкновенным адресом, как и рутовая управляемая ссылка на объект и точно так же обрабатывается GC. Поэтому эта техника вполне могла бы быть реализована уже сейчас.
K>Виртуальные вызовы только какой-нибудь трассирующий джит нормально устранить сможет.
Намного больше их устранит нивелирование избыточной/ненужной косвенности.
K>Поэтому, там где рантайм полиморфизм требуется — там он везде будет. А там, где не требуется — в ООП скорее всего будет, а в хаскеле — нет.
В дотнете/джаве скорее будет. В других ООП-языках — скорее нет (C++/D/ObjectPascal/Swift и т.д.)
Косвенность и ООП — тоже ведь вещи ортогональные.
V>>а в случае vector<Cat> — этапа компиляции. K>Что достигается тем, что параметрического полиморфизма нету, а есть подстановка и кодогенерация, так что было бы сложно сделать как-то иначе.
Странно, что ты не понял еще в прошлый раз, о чем речь. Пофиг на шаблонный vector<>, пусть у нас будет два обычных массива:
Cat cats;
Cat* catsByPtr[];
При обработке первого массива методы объектов будут вызываться напрямую (со всей оптимизацией и инлайнингом, на которую способен компилятор), при обработке второго массива — как виртуальные.
K>В дотнете же, если Cat не struct придется бессмысленно тормозить на виртуальных методах, даже если все элементы одного типа на самом деле — из за сабтайпинга это установить невозможно.
Это не из-за сабтайпинга, а из-за того, что только при косвенной адресации сабтайпинг начинает нам мешать. Никто не мешал в дотнете придумать, например, наследование структур. Это вообще никак не запрещено и ничего бы не поломало. Про стирание грани м/у ref- и value-type я уже высказывался.
V>>Это даже в дотнете не так, насколько я знаю. K>Дотнет устраняет этот ненужный оверхед для struct. Но типичный класс в дотнете — реф.тип.
Во-во. Сам себе ответил.
Это всё унаследованный от джавы кретинизм. Парадигма ООП тут не при чем.
K>Мы сейчас про дженерики и констрейнты-интерфейсы. "Мономорфный" код к обсуждению отношения не имеет — там, конечно, проблем с оптимизацией меньше (ровно по той же причине, почему с темплейтами выше все работает — ведь дело нужно иметь только с мономорфным кодом, шаблонный не типизируется и не компилируется).
V>>Ну так есть GoF паттерн "стратегия" и даже "визитор", для разных сценариев обсуждаемого. Да, стратегия или визитор подаются "извне". K>Ну так это по сути и есть обсуждаемая техника.
В С++ более распространены их статические варианты: traits и "статический визитор". А так-то да. Если забыть, что речь шла про операторы... ))
С операторами удобнее таки через явное указание "модуля", то бишь области видимости. Именно таким образом мы "передаем словарь" один раз на всю текущую область видимости (через указание других видимых явно "модулей"), т.е. не надо передавать в каждый метод. Очень даже оправданный подход, коль речь не о вызовах методов, а о глобальных ф-иях/операторах.
V>>А как же в случае, когда надо было выразить генератор последовательности Pet a? K>Тогда бы хаскелист просто делал последовательность "санков" kill Cat/ kill Dog.
Меня интересует библиотечная либа, умеющая вызывать kill Pet a, которая еще ничего не знает о Cat и Dog, и которая принимает на входе выраженную каким-либо способом последовательность абстрактных Pet a.
K>Вместо класса со многими функциями — словарь бы завел. Многие хаскелисты и сейчас скорее так сделают, чем экзистенциальные типы используют.
Я бы посмотрел на оба варианта. Если можно.
K>Естественно, такое решение хуже в смысле потребления памяти (для экзистенциального типа достаточно иметь один словарь в памяти на каждый инстанс, при ручной передаче такое разделение словаря между значениями нужно будет специально организовывать) и удобства вроде синтаксиса и когерентности (при ручной передаче программисту самому следить за этим придется), тем не менее экзистенциальные типы многие почему-то не любят.
Есть соображения насчет последнего?
V>>Если в рантайм, то почему не диспетчеризация? K>По моему, диспетчеризация подразумевает выбор между какими-то ветками вычислений.
Самый популярный способ диспетчеризации на сегодня — это косвенная адресация. Есть код, который вызывает другой код не по известному на момент компиляции адресу, а по фактическому поданному в процессе работы программы. Собсно, большинство паттернов GoF на этом построены, кроме совсем уж экзотических, типа "интерпретатора".
K>Где тут диспетчеризация? Это просто dereferencing.
)))
Вызов виртуального метода и есть "просто dereferencing".
K>Для Complex это, конечно, не актуально, но программирование на Complex не заканчивается.
Ну... в С++ есть template-template, а в дотнете можно рожать в рантайм конечные типы из генериков через рефлексию. Согласен, что можно было бы добавить в синтаксис.
V>>Почему??? Реализация словаря вполне может быть частью библиотеки.
K>Ну да, можно и на плюсах писать со стиранием, ссылками и передачей словарей, но обычно не пишут. Но это не "подстановочное" решение для которого библиотека нужна будет в исходниках.
В плюсах в исходниках нужны только заголовочные файлы для этого случая, а тело методов может быть библиотечным. Если мы всё еще об одном и том же — о реализации словаря ComplexNumber, например. ну и инлайнинг на сегодня может выполняться во время линковки, не только во время компиляции.
V>>Видел. В MSVC++ мучались аж до 2005-го года. )) V>>Потом взлетело.
K>Подозреваю, что на сабж потратят гораздо меньше человекочасов, чем плюсам достались, так что это не тот ориентир.
— Сабж изначально проще в синтаксисе, сам синтаксис имеет более однозначную семантику, в отличие от жутко неоднозначной семантики выражений С++ (которая зависит от увиденных "где-то раньше" чего угодно, например using blah-blah).
— Сабжу не надо воровать львиную долю человекочасов на собственный бэкенд и оптимизацию конечного бинарного кода. Особенно это актуально для современного числодробления.
— LLVM последних версий отстаёт от самого лучшего GC уже всего лишь в полтора раза на специальных тестах и почти не отстаёт на "обычном" коде.
В общем, потенциал неплох. По-сути, это прямой конкурент D. Причем, за этим языком стоит IT-компания из первой тройки. Неплохо.... это тебе не Sun+Java когда-то. А ведь "взлетело" в итоге и это сановское г-но на палочке... )))
Здравствуйте, Ikemefula, Вы писали:
V>>Да, генерики Swift по-устройству аналогичны шаблонам С++, а не генерикам дотнета. Поэтому вполне корректно. I>Ты не волнуйся, я смотрю на твои заявления черз призму "просто я тянул время", "любой студент за два часа", "ios давно не трогал" и тд
Тебе вообще тут нечего делать. Только лишний шумовой фон.
Здравствуйте, vdimas, Вы писали:
K>>Для автоматической подстановки словаря достаточно поддержки компилятора, чтоб он в области видимости искал структуру с имплементацией нужного интерфейса и, допустим, атрибутом TypeClass.
V>В дотнете иногда используется разметка типов через поддержку интерфейсов-атрибутов с нулевым кол-вом методов в нем, вместо собсно дотнетных атрибутов. Банально быстрее в рантайм.
Чудеса да и только. Маркер-интерфейс требует примерно таких же расходов в рантайме, как и поиск по атрибутам. Затраты на разработку меньше с аттрибутами. Итого — где тут "быстрее", не ясно.
Если речь только про типы, которые доступны компилятору, то самый быстрый способ — компайл-тайм интроспекция. Все остальное, типа маркер-интерфейсы или атрибуты, нужно в том случае, кода типы недоступны компилятору. Например, они будут известны только после деплоймента — плагины-аддоны всех сортов, новые версии фремворка и тд и тд
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, AlexRK, Вы писали:
ARK>>Почему? ARK>>Не придираюсь, просто хочу понять. ARK>>Есть "готовые блоки" func1 и func2. Я их скомбинировал и получил третью функцию.
K>Есть калькулятор, у которого только цифровые клавиши, 2 + 2 = набрать нельзя. Но клавиши для операций над числами не нужны: можно же посчитать в уме и набрать сразу 4 (и многие другие числа).
А без аналогий можете пояснить, что в моем случае не так?
Здравствуйте, alex_public, Вы писали:
_>что уже в общем то ничем не отличается от варианта, где у нас есть "комбинирование комбинаторов". Естественно это не единственный нюанс, который требуется для таких дел. Для полного удобства надо добавить в язык ещё несколько подобных вспомогательных штуковин. Но делается абсолютно без проблем, аналогично примеру выше, и более того, уже давно сделано в соответствующих библиотеках.
Понял. То есть речь просто о сахаре для вызовов цепочек функций. Тогда зачем же притягивать целый ФЯ?
Здравствуйте, Klapaucius, Вы писали:
K>В том и дело, что дорогие/сложные фичи из функциональщины вроде лямбд, дженериков и иммутабельных строк вполне в мейнстрим пролезли. Отсюда и вопрос: что такого с ПМ, что он не пролезает? Я на него ответа не знаю, а вы?
С того, что эффективный и безопасный ПМ возможен только на закрытых суммах типов, а не на открытых, которые представляют из себя иерархии классов в ООП.
Еще непонятно как эффективно разместить размеченное объединение в памяти, т.е. как эффективно всем этим пользоваться при минимуме накладных расходов. Например, динамическое приведение в ПМ в Немерле показывает всю кривизну такой попытки.
K>Ну вот, вы же сами написали, что все, кроме C и C++. Остальные это ведь не только пара-тройка ФЯ но и бразиллион языков никакого отношения к ФП в основном не имеющих. Как видите, страшный синтаксис им никак не помог. При этом сабж явно не окажется в категории С/C++, а наоборот — в категории "остальные", в которой ФЯ часто смотрятся в смысле производительности очень хорошо.
Наверно, стоит сравнивать примерно равные по популярности языки.
I>>Сишный синтаксис очень хорош для структур данных, ООП и подобных вещей. Скажем, для описания данных лучше чем JSON не придумаешь.
K>Довольно странное утвеждение. Описание структур данных в С-подобных языках как раз часто очень многословное и навороченное. K>Вообще, я считаю, что где нет сумм — там и нормальных возможностей описания структур данных нет.
+1
любые IDL/MIDL и т.д. умеют описывать размеченные объединения.
I>>Убогий паттерн матчинг на порядок лучше его отсутствия. K>Вопрос был в том, зачем делать убогим, если можно не убогим? Что мешает-то?
Отсутствие размеченных объединений в языке.
K>Нет, я не про убогие возможности, а именно про навороченность синтаксиса.
Дык, если в Хаскель всего три типа данных — это туплы, размеченные объединения и сигнатуры ф-ий, то синтаксис будет минимальным, конечно. Тем более, что в условиях иммутабельности нет надобности скрывать устройство типов, т.е. отпадают еще всякие public/protected/private.
А если бы были еще отдельно структуры, отдельно классы (не классы типов, а классы ООП), интерфейсы и т.д. и т.п. + разметка прав доступа к членам составных типов — то вот тебе сразу куча синтаксиса.
Избыток синтаксиса в ООП только в оформлении деклараций типов. Тела ф-ий в С++-синтаксисе смотрится нормально, особенно с переопределением операторов.
Здравствуйте, Ikemefula, Вы писали:
K>>Нет, вывести такое следствие не из чего. Вот если бы были языки с равными инфраструктурами и сильно различающиеся по фичам — тогда можно было бы какие-то выводы делать.
I>Хорошая инфраструктура почему то появляется только для самых убогих языков с твоей точки зреня. Тебе самому не смешно ?
Так и есть. Для одного из самых убогих языков — Джавы, серьезная инфраструктура появилась одной из первых.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Ikemefula, Вы писали:
K>>>Нет, вывести такое следствие не из чего. Вот если бы были языки с равными инфраструктурами и сильно различающиеся по фичам — тогда можно было бы какие-то выводы делать.
I>>Хорошая инфраструктура почему то появляется только для самых убогих языков с твоей точки зреня. Тебе самому не смешно ?
V>Так и есть. Для одного из самых убогих языков — Джавы, серьезная инфраструктура появилась одной из первых.
"одной из первых" — смеялся. Эдак окажется, что до джавы жизни вообще не было.
Здравствуйте, AlexRK, Вы писали:
_>>что уже в общем то ничем не отличается от варианта, где у нас есть "комбинирование комбинаторов". Естественно это не единственный нюанс, который требуется для таких дел. Для полного удобства надо добавить в язык ещё несколько подобных вспомогательных штуковин. Но делается абсолютно без проблем, аналогично примеру выше, и более того, уже давно сделано в соответствующих библиотеках.
ARK>Понял. То есть речь просто о сахаре для вызовов цепочек функций. Тогда зачем же притягивать целый ФЯ?
А как ты думаешь это всё работает унутре ? Этот 'просто сахар' внятной поддержки компилятора, рантайма и фремворка. В частности, нужны толковые структуры данных. Кроме того обязательно требуются замыкания. Замыкания для полноценной реализации требуют GC. Опаньки !
Здравствуйте, Ikemefula, Вы писали:
ARK>>Понял. То есть речь просто о сахаре для вызовов цепочек функций. Тогда зачем же притягивать целый ФЯ?
I>А как ты думаешь это всё работает унутре ? Этот 'просто сахар' внятной поддержки компилятора, рантайма и фремворка. В частности, нужны толковые структуры данных. Кроме того обязательно требуются замыкания. Замыкания для полноценной реализации требуют GC. Опаньки !
Ну, GC и замыкания — это не целый ФЯ. Кстати, а нафига тут вообще замыкания?
Здравствуйте, AlexRK, Вы писали:
I>>А как ты думаешь это всё работает унутре ? Этот 'просто сахар' внятной поддержки компилятора, рантайма и фремворка. В частности, нужны толковые структуры данных. Кроме того обязательно требуются замыкания. Замыкания для полноценной реализации требуют GC. Опаньки !
ARK> Ну, GC и замыкания — это не целый ФЯ. Кстати, а нафига тут вообще замыкания?
GC и замыкания это 90% от ФЯ Замыкания нужны для комбинирования функций. компилер по сахару будет генерить эти самые замыкания, т.е. фактически, именно через них все и будет работать.
Не всегда конечно, в стандартных случаях можно обойтись предопределенными функциями.
Здравствуйте, AlexRK, Вы писали:
ARK>Понял. То есть речь просто о сахаре для вызовов цепочек функций.
Ну там не только для организации цепочки, но и ещё нескольких близких нюансов.
ARK>Тогда зачем же притягивать целый ФЯ?
Ну так в этих ФЯ это есть из коробоки, а скажем в C++ нет. ))) Другое дело, что скажем взяв соответствующую библиотеку (например такую https://github.com/beark/ftl) мы легко получим подобное и в C++... Но сторонники всяческих маргинальных языков обычно игнорируют этот аргумент. )))
Здравствуйте, Ikemefula, Вы писали:
I>А как ты думаешь это всё работает унутре ? Этот 'просто сахар' внятной поддержки компилятора, рантайма и фремворка. В частности, нужны толковые структуры данных. Кроме того обязательно требуются замыкания. Замыкания для полноценной реализации требуют GC. Опаньки !
Вот не надо повторять везде этот миф, что типа для замыканий обязательно нужен сборщик мусора.
Здравствуйте, Ikemefula, Вы писали:
V>>Так и есть. Для одного из самых убогих языков — Джавы, серьезная инфраструктура появилась одной из первых. I>"одной из первых" — смеялся. Эдак окажется, что до джавы жизни вообще не было.
Настолько всеобъемлющая инфраструктура была только для COM/DCOM/COM+/ActiveX/OLE. Но степень удобства для разработки была намного ниже, разве что на VB/VBA неплохо получалось в плане удобства. Но на этом языке невозможно было выразить и/или использовать все возможности низлежащей платформы.
Та же CORBA отставала и оч сильно. Ну и всё, собсно. Среды для Smalltalk, Forth, ObjectPascal были намного попроще и намного `уже по покрытию прикладных областей "изкаробки".
Здравствуйте, alex_public, Вы писали:
I>>А как ты думаешь это всё работает унутре ? Этот 'просто сахар' внятной поддержки компилятора, рантайма и фремворка. В частности, нужны толковые структуры данных. Кроме того обязательно требуются замыкания. Замыкания для полноценной реализации требуют GC. Опаньки !
_>Вот не надо повторять везде этот миф, что типа для замыканий обязательно нужен сборщик мусора.
Не надо называть костыли в С++ замыканиями и все будет хорошо.
Здравствуйте, vdimas, Вы писали:
I>>Не надо называть костыли в С++ замыканиями и все будет хорошо.
V>При чём тут С++? Для иммутабельных замыканий GC не нужен ни разу, т.к. сразу отсутствует требование передачи контекста по ссылке.
Здравствуйте, Ikemefula, Вы писали:
V>>При чём тут С++? Для иммутабельных замыканий GC не нужен ни разу, т.к. сразу отсутствует требование передачи контекста по ссылке. I>GC нужен для upward funarg
Еще раз по-русски.
Это только для мутабельных сценариев.
Здравствуйте, vdimas, Вы писали:
V>>>При чём тут С++? Для иммутабельных замыканий GC не нужен ни разу, т.к. сразу отсутствует требование передачи контекста по ссылке. I>>GC нужен для upward funarg
V>Еще раз по-русски. V>Это только для мутабельных сценариев.
Здравствуйте, Ikemefula, Вы писали:
I>GC нужен для upward funarg
Ерунда это. Можно обсуждать только вопросы эффективности (по быстродействию) решения, а само оно есть в любом языке с возможностью написания функторов (в терминологии C++).
Для решения же проблемы быстродействия (т.е. грубо говоря копирования больших кусков данных) возможны различные решения, типа дополнительных лёгковесных контейнеров, автоматического подсчёта ссылок и т.п. Но скажем в C++ с появлением move semantics в последней версии стандарта про проблему быстродействия можно смело забывать... )))
Здравствуйте, alex_public, Вы писали:
I>>GC нужен для upward funarg
_>Ерунда это. Можно обсуждать только вопросы эффективности (по быстродействию) решения, а само оно есть в любом языке с возможностью написания функторов (в терминологии C++).
Вот видишь, о чем и речь — ты смотришь исключительно с т.з. быстродействия, но почему то считаешь, что и другие делают тоже самое.
_>Для решения же проблемы быстродействия (т.е. грубо говоря копирования больших кусков данных) возможны различные решения, типа дополнительных лёгковесных контейнеров, автоматического подсчёта ссылок и т.п. Но скажем в C++ с появлением move semantics в последней версии стандарта про проблему быстродействия можно смело забывать... )))
Здравствуйте, Ikemefula, Вы писали:
I>Вот видишь, о чем и речь — ты смотришь исключительно с т.з. быстродействия, но почему то считаешь, что и другие делают тоже самое.
Так если забыть о быстродействие, то как бы и вообще проблем нет — просто все нужные данные тупо копируются в возвращаемый функциональный объект.
Здравствуйте, Ikemefula, Вы писали:
V>>>>При чём тут С++? Для иммутабельных замыканий GC не нужен ни разу, т.к. сразу отсутствует требование передачи контекста по ссылке. I>>>GC нужен для upward funarg
V>>Еще раз по-русски. V>>Это только для мутабельных сценариев.
I>Покажи кодом.
Что тебе даст код?
#include <boost/assign.hpp>
int main(int argc, char* argv[])
{
using namespace std;
using namespace boost::assign;
vector<int> vec;
vec += 10, 2, 31, 15, -5, 42;
int max = 15;
// по значению
sort(vec.begin(), vec.end(), [=](int lhs, int rhs) {
return lhs < rhs && rhs < max;
});
// по ссылке
sort(vec.begin(), vec.end(), [&](int lhs, int rhs) {
return lhs < rhs && rhs < max;
});
return 0;
}
В первом случае замыкание можно безопасно сохранить во внешнем контексте, во втором — нет.
Тебе этот код помог? ))
Для понимания рассуждений надо было сообразить, что в иммутабельном сценарии становится не важно, как передаются данные — по ссылке или по-значению. А код тут только мешает.
Здравствуйте, Ikemefula, Вы писали:
_>>Ерунда это. Можно обсуждать только вопросы эффективности (по быстродействию) решения, а само оно есть в любом языке с возможностью написания функторов (в терминологии C++). I>Вот видишь, о чем и речь — ты смотришь исключительно с т.з. быстродействия, но почему то считаешь, что и другие делают тоже самое.
Ну да. Поэтому ты пользуешься ГЦ, а другие коллеги не могут себе позволить этой роскоши.
_>>Для решения же проблемы быстродействия (т.е. грубо говоря копирования больших кусков данных) возможны различные решения, типа дополнительных лёгковесных контейнеров, автоматического подсчёта ссылок и т.п. Но скажем в C++ с появлением move semantics в последней версии стандарта про проблему быстродействия можно смело забывать... )))
I>Так себе решение.
Явная передача владения — это не так себе. Это нечто близкое к происходящему при передаче владения в uniqueness-типах.
Здравствуйте, vdimas, Вы писали:
V>>>>>При чём тут С++? Для иммутабельных замыканий GC не нужен ни разу, т.к. сразу отсутствует требование передачи контекста по ссылке. I>>>>GC нужен для upward funarg
V>Что тебе даст код?
Здравствуйте, vdimas, Вы писали:
I>>Покажи, где и как освобождать память.
V>Покажи, где и как освобождать память для value-type в дотнет?
Вижу, ты сменил тактику. С кодом не получилось, попутал downward и upward, и сейчас ты переключился на value-type. Как только разберешься с upward, приходи, поговорим про value-type и почему надо освобождать память даже в этом случае.
Один нюанс — приходи не иначе как с кодом. Не можешь сам — проси или жди пока кто нибудь не выдаст код вместо тебя.
Здравствуйте, Ikemefula, Вы писали:
V>>Покажи, где и как освобождать память для value-type в дотнет? I>Вижу, ты сменил тактику.
Вижу, ты решил не отвечать на прямо составленный вопрос.
I>С кодом не получилось, попутал downward и upward,
Это у тебя в голове путаница. Причем, полнейшая.
Вот тебе downward в С.
Сравни с приведенным примером.
Там же ниже downward в Паскале.
I>и сейчас ты переключился на value-type.
Сейчас я задал кокретный простейший вопрос, который отвечает на все твои вопросы.
I>Как только разберешься с upward, приходи
С твоим пониманием "upward" не разберусь. Похоже, ты не понимаешь этого термина.
I>поговорим про value-type и почему надо освобождать память даже в этом случае.
Конечно, надо!
Только вопрос в том, что освобождать надо не на том уровне, на котором описана лямбда. Вот такие они, value-type.
I>Один нюанс — приходи не иначе как с кодом. Не можешь сам — проси или жди пока кто нибудь не выдаст код вместо тебя.
Я тебе уже ответил там же. Меня удивляет, где ты умудряешься находить такие глубокие лужи, чтобы садиться. Уже не в состоянии прочесть простейший код.
Почитай про лямбды С++, что ле...
Здравствуйте, vdimas, Вы писали:
V>>>Покажи, где и как освобождать память для value-type в дотнет? I>>Вижу, ты сменил тактику.
V>Вижу, ты решил не отвечать на прямо составленный вопрос.
Разумеется. Если ты путаешь downward и upward, то твои слова ничего не стоят.
Здравствуйте, alex_public, Вы писали:
I>>Покажи, где и как освобождать память.
_>Память очевидно освобождается при удаление функционального объекта. Причём всё автоматически — RAII же.
Понял, память освобождается при освобождения. А я то, дурак, думал, когда же она освобождается.
Здравствуйте, alex_public, Вы писали:
I>>Понял, память освобождается при освобождения. А я то, дурак, думал, когда же она освобождается.
_>Даже боюсь допустить, что ты тут не придуриваешься... )
Ты сам начал. У меня был простой вопрос — когда и как. А ты кинулся играть в слова пополам с баззвордами.
Здравствуйте, alex_public, Вы писали:
I>>Понял, память освобождается при освобождения. А я то, дурак, думал, когда же она освобождается. _>Даже боюсь допустить, что ты тут не придуриваешься... )
Он реально НЕ понимает.
Наверно он считает, что память полей value-type в дотнете тоже уделяется каким-то специфическим образом. ))
Здравствуйте, Ikemefula, Вы писали:
V>>Вижу, ты решил не отвечать на прямо составленный вопрос. I>Разумеется. Если ты путаешь downward и upward, то твои слова ничего не стоят.
Здравствуйте, Ikemefula, Вы писали:
V>>Наоборот. Я увидел язык без встроенных болезней дотнета. А эти болезни тоже не из космоса взялись, а получились как некий компромисс м/у наличием ГЦ и желанием сделать легковестные value-типы.
I>Покажи кодом, условие задачи напомнить ?
Здравствуйте, Ikemefula, Вы писали:
I>Ты сам начал. У меня был простой вопрос — когда и как. А ты кинулся играть в слова пополам с баззвордами.
Ответ был дан и он был абсолютно точным. В соседней темке я тебе показал ещё и код по этому вопросу, который вроде тебя всё прояснил. Так вот мой ответ в этой темке полностью соответствует тому коду.
А чем плох ответ в последнем комментарии, что ассоциированные типы более расширябельны?
Насколько я помню, в предлагаемых концептах С++ ассоциированные типы тоже были, именно для того, чтобы избежать засерания кода генерик-аргументами, не несущими никакой информации.
Здравствуйте, alex_public, Вы писали:
I>>Ты сам начал. У меня был простой вопрос — когда и как. А ты кинулся играть в слова пополам с баззвордами.
_>Ответ был дан и он был абсолютно точным. В соседней темке я тебе показал ещё и код по этому вопросу, который вроде тебя всё прояснил. Так вот мой ответ в этой темке полностью соответствует тому коду.
Здравствуйте, vdimas, Вы писали:
V>>>Наоборот. Я увидел язык без встроенных болезней дотнета. А эти болезни тоже не из космоса взялись, а получились как некий компромисс м/у наличием ГЦ и желанием сделать легковестные value-типы.
I>>Покажи кодом, условие задачи напомнить ?
V>Лучше ты покажи кодом как избегать граблей дотнета тут:
Ты слишком много хочешь и ничего не можешь дать взамен.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Ikemefula, Вы писали:
V>>>Вижу, ты решил не отвечать на прямо составленный вопрос. I>>Разумеется. Если ты путаешь downward и upward, то твои слова ничего не стоят.
V>Никто ничего не путает.
Я просил upward, a ты выдал downward. За ликбезом смотри рядом пост alex_public.
Здравствуйте, Ikemefula, Вы писали: V>>В дотнете иногда используется разметка типов через поддержку интерфейсов-атрибутов с нулевым кол-вом методов в нем, вместо собсно дотнетных атрибутов. Банально быстрее в рантайм.
I>Чудеса да и только. Маркер-интерфейс требует примерно таких же расходов в рантайме, как и поиск по атрибутам.
Это просто ловкая подмена задачи. Есть два сценария:
1. Найти все типы в некотором scope (например, в модуле), которые предназначены для определённой цели.
2. Проверить, предназначен ли некоторый объект для определённого сценария.
В сценарии 1 все варианты реализации примерно одинаково тормозные (кроме случая явной регистрации при помощи обратного вызова), что совершенно неважно, т.к. они выполняются редко — в компайл-тайм, деплой-тайм, или стартап-тайм.
В сценарии 2 проверка через (obj is ISupportsSessionState) действительно гораздо быстрее, чем (obj.GetType().GetCustomAttributes(typeof(SupportsSessionStateAttribute), true).Length > 0).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
K>>А смысл? Словари никто в рантайме не ищет, только в компайлтайм. V>Для случая ООП и рантайм-вариант прозрачно для программиста работает.
В ООП словари в рантайме тоже никто не ищет, на словарь уже есть ссылка. (если речь не идет про какие-нибулдь скриптовые языки)
V>Все-равно не представляю, как ср-вами CLR хранить описание таких типов. V>И если не сложно, раскрой, плиз выделенное.
Точно так же, как любые дженерики реализуются в языках для JVM (Я в курсе, что это размен одних костылей на другие). Поддержка value-типов при таком подходе невозможна, потому я и написал, что обобщать конструкторы value-типов не получится.
V>В среднем коде наблюдается этой арифметики, в т.ч. булевой логики — до половины. Весь остальной мильон альфанумериков делят оставшиеся %% кода м/у собой. Отсюда такое внимание именно операторам языка — они ведь составляют приличную долю синтаксиса исходника.
Если речь идет о коде с for-ами а-ля C и if-ами со всякими сложными условиями — да. Если код в более современном стиле — нет.
Впрочем, обобого смысла обсуждать это направление я не вижу, я сам сторонних возможности объявлять произвольные операторы с заданным приоритетом/ассоциативностью, возможности использования альфанумерик-имен в качестве инфиксных операторов и т.д.
V>Тогда это будет гибрид, как C# или C++ с чуть более продвинутой системой типов. ))
Ну, система типов будет ощутимо продвинутее, только использовать ее будет нельзя из-за того, что уточнения типов будут больше чем код места занимать.
V>В любом случае, нечто вроде сабтайпинга накрутить можно и в Хаскель: V>
V>type OutputStream a = StreamBase (COutputStream a)
V>
Не уловил сходства с сабтайпингом. (хотя "что-то вроде" сабтайпинга при наличии параметрического полиморфизма делать конечно можно, но на это упомянутые проблемы сабтайпинга не распространяются)
V>Ведь контракты ООП — это тоже ограничения. ))
Если это статически проверяемые контракты вроде refinement types, то можно и так сказать.
V>В итоге, иерархия ограничений Хаскеля в точности равна иерархии интерфейсов ООП с т.з. дизайна.
Если речь про "классический" ООП без всяких дженериков — то это точно не так. Если речь про дженерики, то да, сходдство есть, и то и другое параметрический полиморфизм с ограниченной квантификацией.
V>Ну это в дотнете, разве что, а не плюсах (или Swift). Ты не обратил ниже внимание на разницу Cat и Cat*. Просто для дотнета этой разницы нет, ведь в нем всегда Cat* для классов.
Это распространенный подход. Какие без * ООПешные полиморфизм и подтипирование?
V>Даже в Хаскеле в сетевых и GUI либах сплошное ООП.
Для такого ООП надо уж слишком широко трактовать.
V>Класс типов это не тип, а контракт.
С некоторых пор это тип.
V>Его "воплощения" в природе не существует.
Вполне существует в виде словаря функций/GADT в зависимости от реализации.
V>Это лишь в языках-наследниках ML.
Да, т.е. во всех функциональных языках кроме схемы и ее диалектов.
V>Обобщение и ФП — вещи глубоко ортогональные друг другу
Смотря какое обобщение. Параметрический полиморфизм как в ML, Haskell, Java, C# — это ФП. Плюсовые темплейты, генеративные дженерики в Аде и Модуле-3 — судя по всему, глубоко ортогональны ФП и никакой связи с параметрическим полиморфизмом не имеют.
V>Ну да. Но мы же сравниваем конкретные языки. А они гибридные. ))
Я вроде бы явно написал, что сравниваю именно с ООП, а вы сами заявили, что любые свойства гибридных языков на ООП не распространяются.
V>Сам словарь-то для конкретного типа зачастую не обобщенный нифига, какие проблемы с раздельной компиляцией?
Словарь, конечно, не обобщенный — в этом и весь смысл ad-hoc полиморфизма. Но причем тут это? Я же говорю, подход с передачей словаря проблем с раздельной компиляцией не имеет. Проблему с ней имеет подход нарушающий параметричность "подхватыванием" каких-то операторов в виде констрейнта нигде не фигурирующих (т.е. типичный плюсовой, например).
V>Если я правильно понял вопрос, то через области видимости. Через неймспейсы, например. V>Если не в тему, то расшифруй вопрос, плиз.
Нет, разрешение противоречий при поиске словарей с использованием областей видимости нарушает когерентность инстансов.
Когерентность инстансов означает, что одному типу соответствует один инстанс/словарь данного класса.
V>Можно мне, тупому, показать на пальцах пример в Хаскель, когда бы у нас была последовательность абстрактных Pet a
Для Pet (без a) диспетчеризация будет в рантайме. Ничего заинлайнить нельзя. Для Pet a (обратите внимание, что тут a есть, это ключевой момент) "диспетчеризация" будет в комайлтайм.
V>Это зависит от того, что "видит" компилятор — сам объект или только его адрес. Если компилятор С++ видит Cat по-значению (на стеке, глобальную переменную или как поле другого объекта), то он вызывает методы напрямую,
Ну так тут и полиморфизма ООПешного нет.
V>если же он видит Cat* или Cat&, то он понятия не имеет (в общем случае) о точном типе объекта по адресу, поэтому работает рантайм-полиморфизм.
Ну да.
V>>>Известно только если компилятор не видит точный (конечный) тип объекта. Если же видит, то вызывает виртуальные методы напрямую, без таблицы. Именно поэтому я вижу тут аналогию.
ОК, сформулирую по-другому. При параметрическом полиморфизме больше сценариев использования, когда компилятор видит "точный (конечный)" тип, полиморфизм через сабтайпинг достигается "стиранием" информации о "точном" типе. Естественно, совсем без "стирания" не обойтись и для этого средства везде есть, но ООП-подход такому стиранию благоприятствует.
V>По отношению к парадигме ООП, наследование реализаций — это просто некий трюк где-то сбоку. Можно взять для рассмотрения более строгую парадигму КОП — наследование только интерфейсов.
И чем это нам тут поможет?
V>Ну и в обычных пользовательских классах доля виртуальных методов далеко не 100%, а как бы заметно ниже 50%.
Мы вроде про полиморфный код говорим. Как тут в ООП без виртуальных методов?
V>В общем, с заявлением "В ООП сложно обозначить область где рантайм-полиморфизм не требуется" согласиться оч сложно. По-сути, ты приписал всему ООП ограничения пары популярных платформ — дотнета/джавы. V>Более того, нет никаких ограничений, даже в условиях GC, располагать объекты по-значению в теле объектов-владельцев.
Как их располагать по значению в условиях полиморфизма? Разные типы по размеру отличаются. Поэтому и хранится ссылка, котороая по размеру не отличается, вне зависимости от того, на какой наследник Pet она указывает.
K>>Виртуальные вызовы только какой-нибудь трассирующий джит нормально устранить сможет. V>Намного больше их устранит нивелирование избыточной/ненужной косвенности.
Как ее для полиморфного кода нивелировать?
K>>Поэтому, там где рантайм полиморфизм требуется — там он везде будет. А там, где не требуется — в ООП скорее всего будет, а в хаскеле — нет.
V>Косвенность и ООП — тоже ведь вещи ортогональные.
И что без нее от ООП остается? ООП-ешный полиморфизм без нее не работает.
V>Странно, что ты не понял еще в прошлый раз, о чем речь. Пофиг на шаблонный vector<>, пусть у нас будет два обычных массива: V>
V>Cat cats;
V>Cat* catsByPtr[];
V>
V>При обработке первого массива методы объектов будут вызываться напрямую (со всей оптимизацией и инлайнингом, на которую способен компилятор), при обработке второго массива — как виртуальные.
Непонятно, какой смысл сравнивать Cat и Cat* если речь идет про, скажем, Pet*. Как в Cat cats хранить Dogs и применять к каждому эдементу такого массива обобщенную функцию kill, которая для Cat и для Dog определена?
K>>В дотнете же, если Cat не struct придется бессмысленно тормозить на виртуальных методах, даже если все элементы одного типа на самом деле — из за сабтайпинга это установить невозможно.
V>Это не из-за сабтайпинга, а из-за того, что только при косвенной адресации сабтайпинг начинает нам мешать.
Ну естественно. Он и работать только при косвенной адресации начинает.
V>Это всё унаследованный от джавы кретинизм. Парадигма ООП тут не при чем.
Никакой джава-специфики тут нет. ООП-полиморфизм в основном так и реализуется.
V>В С++ более распространены их статические варианты: traits и "статический визитор". А так-то да. Если забыть, что речь шла про операторы... ))
Ну так и обсуждаемый вариант на C# — статический.
V>С операторами удобнее таки через явное указание "модуля", то бишь области видимости. Именно таким образом мы "передаем словарь" один раз на всю текущую область видимости (через указание других видимых явно "модулей"), т.е. не надо передавать в каждый метод. Очень даже оправданный подход, коль речь не о вызовах методов, а о глобальных ф-иях/операторах.
Не считаю, что это хороший подход (хотя широко практикуемый в ML-ях). В одном выражении и в одной области видимости может быть + и для int и для double.
V>Меня интересует библиотечная либа, умеющая вызывать kill Pet a, которая еще ничего не знает о Cat и Dog, и которая принимает на входе выраженную каким-либо способом последовательность абстрактных Pet a.
Если работать c Pet (без a) — то будет рантайм диспетчеризация, как в ООП — как иначе-то?
V>Я бы посмотрел на оба варианта. Если можно.
Пример см. по ссылке чуть ниже.
V>Есть соображения насчет последнего?
Некоторые хаскелисты не любят тайпклассы, некоторые — любые расширения. Вот тут http://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-typeclass/ позиция противника такого подхода.
K>>По моему, диспетчеризация подразумевает выбор между какими-то ветками вычислений. V>Самый популярный способ диспетчеризации на сегодня — это косвенная адресация. Есть код, который вызывает другой код не по известному на момент компиляции адресу, а по фактическому поданному в процессе работы программы.
Ну да, и что? Это никак не отменяет фактической разницы случаев, когда нужно выбирать между ветками вычислений и когда не нужно. Во втором случае "выбор" устраним на этапе компиляции и на практике устраняется в значительном числе случаев.
V>Вызов виртуального метода и есть "просто dereferencing".
Не просто. Мы не знаем до рантайма какой метод вызываем. Тут же все в компайл-тайм известно, это как поле структуры прочитать.
V>в дотнете можно рожать в рантайм конечные типы из генериков через рефлексию.
Не самая хорошая идея по-моему.
K>>Ну да, можно и на плюсах писать со стиранием, ссылками и передачей словарей, но обычно не пишут. Но это не "подстановочное" решение для которого библиотека нужна будет в исходниках. V>В плюсах в исходниках нужны только заголовочные файлы для этого случая, а тело методов может быть библиотечным. Если мы всё еще об одном и том же — о реализации словаря ComplexNumber, например. ну и инлайнинг на сегодня может выполняться во время линковки, не только во время компиляции.
Так я и говорю, решение с передачей словаря лучше подходит для раздельной компиляции.
V>- Сабжу не надо воровать львиную долю человекочасов на собственный бэкенд и оптимизацию конечного бинарного кода. Особенно это актуально для современного числодробления. V>- LLVM последних версий отстаёт от самого лучшего GC уже всего лишь в полтора раза на специальных тестах и почти не отстаёт на "обычном" коде.
Разница в производительности генерируемого кода между clang и компиляторами других языков, использующих LLVM вполне наблюдаема.
V>В общем, потенциал неплох. По-сути, это прямой конкурент D.
У меня впечатление, что у D возможности побогаче. Но существенного роста популярности D я не ожидаю.
V>Причем, за этим языком стоит IT-компания из первой тройки.
Тут как раз не все так просто. Эппл, конечно, имеет возможность сделать его не менее популярным, чем Objective-C и тем же самым способом, ну так и за пределами эппловской платформы у него будет популярность, как у Objective-C.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, vdimas, Вы писали:
V>С того, что эффективный и безопасный ПМ возможен только на закрытых суммах типов, а не на открытых, которые представляют из себя иерархии классов в ООП. V>Еще непонятно как эффективно разместить размеченное объединение в памяти, т.е. как эффективно всем этим пользоваться при минимуме накладных расходов. Например, динамическое приведение в ПМ в Немерле показывает всю кривизну такой попытки.
Так в сабже же суммы произведений есть. Только рекурсии нет.
V>Наверно, стоит сравнивать примерно равные по популярности языки.
По меркам непопулярных языков, производительность у ФЯ вполне хорошая.
K>>Вопрос был в том, зачем делать убогим, если можно не убогим? Что мешает-то?
V>Отсутствие размеченных объединений в языке.
Какое отсутствие? Есть же enum (спасибо эппл, за не название с неверными ассоциациями).
V>Дык, если в Хаскель всего три типа данных — это туплы, размеченные объединения и сигнатуры ф-ий
Еще и рекурсия, мутабельные ячейки, массивы. Ну а в ООП языке обычно меньше — сумм, например, нету.
V>, то синтаксис будет минимальным, конечно.
Ну так в чем необходимость навороченного синтаксиса для описания типов, если их разновидностей даже меньше?
V>Тем более, что в условиях иммутабельности нет надобности скрывать устройство типов, т.е. отпадают еще всякие public/protected/private.
public/protected/private там на уровне модуля задается.
V>Избыток синтаксиса в ООП только в оформлении деклараций типов.
О них и речь.
V>Тела ф-ий в С++-синтаксисе смотрится нормально, особенно с переопределением операторов.
Тут еще сильно неспособствует легковестности то, что не все является выражением, а так да, нормально, бывает куда хуже.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, AlexRK, Вы писали:
ARK>Понял. То есть речь просто о сахаре для вызовов цепочек функций. Тогда зачем же притягивать целый ФЯ?
Нет, речь идет не только о сахаре. Для комбинирования комбинаторов нужно чтоб комбинация комбинаторов по производительности не сильно отличалась от ручного фьюжена в лапшу, а объем кода и его читаемость наоборот отличались сильно, чтоб комбинирование комбинаторов можно было действительно использовать, а не обсуждать его на форумах.
Для этого нужно:
0) Контроль эффектов, чтоб были функции и было что комбинировать.
1) Быстрый сборщик мусора для нормальных замыканий.
2) Карринг и соответствующая поддержка от рантайма.
3) Ленивость и соответствующая поддержка от рантайма.
4) Оптимизирующий компилятор.
5) Стек в куче чтоб нормальная поддержка рекурсии была.
6) Легковесный синтаксис.
7) Что-то еще, что навскидку не вспомнилось.
итого, целый ФЯ, да еще и не любой-каждый ФЯ.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
В пункте 1 большой проблемой считается невозможность написания обобщённого интерфейса для произвольного функтора (в терминологии хаскеля). А оно вообще кому-то надо? )))
В пунктах 2 и 3 ругаются на падения компилятора (который в бета-версии) — это вообще странно комментировать...
Здравствуйте, alex_public, Вы писали:
DM>>http://schani.wordpress.com/2014/06/11/associated-types-considered-weird/
_>В пункте 1 большой проблемой считается невозможность написания обобщённого интерфейса для произвольного функтора (в терминологии хаскеля). А оно вообще кому-то надо? ))) _>В пунктах 2 и 3 ругаются на падения компилятора (который в бета-версии) — это вообще странно комментировать...
Твои пункты — совсем из другой статьи. Ссылку-то открой.
А по поводу хитрой системы совмещения шаблонов и интерфейсов я как раз писал уже здесь, что заметил это, но пока ещё не разобрался зачем оно так. И от данной критики особо понятнее пока не стало. )))
Здравствуйте, alex_public, Вы писали:
_>В пункте 1 большой проблемой считается невозможность написания обобщённого интерфейса для произвольного функтора (в терминологии хаскеля). А оно вообще кому-то надо? )))
_>>В пункте 1 большой проблемой считается невозможность написания обобщённого интерфейса для произвольного функтора (в терминологии хаскеля). А оно вообще кому-то надо? ))) DM>Мне надо.
Так а где там универсальный интерфейс "Imappable"? ) Я вижу там реализацию одиночного класса и вроде как это не должно быть проблемой на Swift'e.
Здравствуйте, VladD2, Вы писали:
V>>Бывает так, что запуск программы требует время (на всю установку некоего тяжеловесного окружения). Скажем, запуск вижуал-студии. V>>В этом смысле REPL банально удобнее, т.к. уже при установленном некоем окружении позволяет "играть" с ним. VD>В отладчике можно вызвать функцию, поменять значения и даже изменить код программы. Этого более чем достаточно для отладки. А вот писать большую программу из репла — это утопия.
Оказывается, LISP и Forth это утопии. Ах да, BASIC образца ранних персоналок — тоже.
Почитал ветку/поучаствовал в ней. И все, что могу сказать: вы все наркоманы, и не лечитесь.
«О боже Apple не сделали в своем языке <вставить один из 100500 фич двух десятков разных языков разной степени маргинальности>».
Вы с дуба рухнули? У Apple'а была задача:
— избавиться от Objective-C, который дальнейшим улучшениям не поддается
— создать язык, полностью совместимый с Objective-C на уровне рантайма
— создать язык, полностью совместимый с Objective-C на уровне библиотек
— создать язык, в первую очередь предназначенный для разработки для и работы под iOS
— создать язык, совместимый с существующим инструментарием
— создать язык, в первую предназначенный для:
-- людей, которые уже разрабатывают под iOS
-- людей, которые хотят начать разрабатывать под iOS
В рамках заданных ограничений Apple создали достаточно приятный язык.
Здравствуйте, NeoCode, Вы писали:
NC>Странный подход, написано free, в фиг скачаешь без этого вашего тунца. Как они собираются привлекать разработчиков, не имевших до этого дела с эппл?
Вот здесь http://swiftlang.eu/
можно свободно почитать в pdf формате. Плюс к этому куча примеров.
Здравствуйте, Klapaucius, Вы писали:
V>>Это зависит от того, что "видит" компилятор — сам объект или только его адрес. Если компилятор С++ видит Cat по-значению (на стеке, глобальную переменную или как поле другого объекта), то он вызывает методы напрямую,
K>Ну так тут и полиморфизма ООПешного нет.
Так он и не нужен. ООП-полиморфизм нужен там где нужен, т.е. где именно в рантайм, согласно условию, требуется диспетчеризация. В этом случае ООП-полиморфизм делает сию диспетчеризацию типобезопасной, только и всего (в сравнении с аналогиным решением на С, например).
V>>>>Известно только если компилятор не видит точный (конечный) тип объекта. Если же видит, то вызывает виртуальные методы напрямую, без таблицы. Именно поэтому я вижу тут аналогию.
K>ОК, сформулирую по-другому. При параметрическом полиморфизме больше сценариев использования, когда компилятор видит "точный (конечный)" тип, полиморфизм через сабтайпинг достигается "стиранием" информации о "точном" типе. Естественно, совсем без "стирания" не обойтись и для этого средства везде есть, но ООП-подход такому стиранию благоприятствует.
Это попахивает твоими собственными ощущениями.
Поделюсь своими.
Среди всех случаев вызовов методов объектов в реальных программах на С++ можно наблюдать лишь единицы %% мест с виртуальными вызовами. Обобщенное программирование даже в реалиях С++ и общепринятая в нём же идеология преимущественного размещения объектов по-значению сводит кол-во этих рантайм-диспетчеризаций ровно к тому кол-ву, которое у тебя было бы и на других языках, даже на тех, где есть параметрический полиморфизм. Например, где речь шла бы о последовательности абстрактных Pet.
Повторюсь, я внимательно одно время рассматривал скомпилированные примеры на Хаскеле с использованием классов типов и параметрическим полиморфизмом, где в ООП в аналогичном случае без виртуальных вызовов не обойтись, — наблюдал, что происходит точно такая же диспетчеризация в рантайм по адресу ф-ии, аналогично вызову виртуальной ф-ии в ООП-программе (то бишь вызов не по вшитому адресу ф-ии, а по прочитанному из памяти).
V>>По отношению к парадигме ООП, наследование реализаций — это просто некий трюк где-то сбоку. Можно взять для рассмотрения более строгую парадигму КОП — наследование только интерфейсов.
K>И чем это нам тут поможет?
По безопасности это будет аналог классов типов, т.к. единственная страшная грабля ООП — это дауншифтинг или любое динамическое приведение типов. В этом гипотетическом случае, если классом объекта нельзя будет оперировать напрямую, а только через интерфейс, то будут так же безопасно.
V>>Ну и в обычных пользовательских классах доля виртуальных методов далеко не 100%, а как бы заметно ниже 50%. K>Мы вроде про полиморфный код говорим. Как тут в ООП без виртуальных методов?
Да вот так! ))
По дизайну метод виртуальный. А реальных мест, где этот же самый метод нужен именно как виртуальный — оч мало.
ООП — это не столько виртуальные методы, сколько концепция типов-черных ящиков с собственным состоянием. При наличии шаблонов даже уровня С++, виртуальность становится необходима ровно там, где в решении не обойтись без рантайм-диспетчеризации. В Хаскеле в аналогичных случаях будет или параметрический полиморфизм + классы типов и деспетчеризация по адресу ф-ии, либо обычная диспетчеризация на паттерн-матчинге.
V>>В общем, с заявлением "В ООП сложно обозначить область где рантайм-полиморфизм не требуется" согласиться оч сложно. По-сути, ты приписал всему ООП ограничения пары популярных платформ — дотнета/джавы. V>>Более того, нет никаких ограничений, даже в условиях GC, располагать объекты по-значению в теле объектов-владельцев.
K>Как их располагать по значению в условиях полиморфизма? Разные типы по размеру отличаются. Поэтому и хранится ссылка, котороая по размеру не отличается, вне зависимости от того, на какой наследник Pet она указывает.
Вот так и располагать, если процедура создания объекта не требует абстракции (а она оч редко требует абстракции, абстракции при создании графов объектов обычно нужны на уровне совсем "крупных мазков" архитектуры).
Зато этот внутренний объект, размещенный как поле по значению, можно подавать на "входную точку" некоего внешнего алгоритма, принимающего абстракции. А если этот алгоритм обобщенный на шаблонах — то опять методы могут быть вызваны не виртуально, т.к. компилятор, наблюдая в месте вызова объект по значению, знает его точный тип.
В общем, если сравнивать ссылочный граф объектов в памяти в программе на дотнете/джаве с графом объектов программы на С++, то в последнем случае этот граф будет на порядок-другой скромнее. Ссылочные места будут ровно в тех случаях, где это требуется по дизайну, а не потому, что другого способа комбинирования типов и нет. ))
K>>>Виртуальные вызовы только какой-нибудь трассирующий джит нормально устранить сможет. V>>Намного больше их устранит нивелирование избыточной/ненужной косвенности.
K>Как ее для полиморфного кода нивелировать?
Вопрос неправильно поставлен. На было спросить так: "как нивелировать рантайм-полиморфизм там, где она не требуется по алгоритму". Об этом я и распинаюсь уже 3-й пост.
Собсно, все твои аргументы стоят на том, что в Хаскель легко избежать избыточного рантайм-полиморфизма, а в привычном тебе C# — нет.
K>>>Поэтому, там где рантайм полиморфизм требуется — там он везде будет. А там, где не требуется — в ООП скорее всего будет, а в хаскеле — нет. V>>Косвенность и ООП — тоже ведь вещи ортогональные. K>И что без нее от ООП остается? ООП-ешный полиморфизм без нее не работает.
От ООП остаётся способ комбинирования типов с хранимым состоянием. Спор тут идёт лишь относительно того, что из полиморфного работает на этапе компиляции, а что на этапе исполнения.
K>Непонятно, какой смысл сравнивать Cat и Cat* если речь идет про, скажем, Pet*. Как в Cat cats хранить Dogs и применять к каждому эдементу такого массива обобщенную функцию kill, которая для Cat и для Dog определена?
Именно что. Давай ограничим сценарии фактического применения рантайм-полиморфизма только заранее запланированными по сути решения задачи.
V>>Это не из-за сабтайпинга, а из-за того, что только при косвенной адресации сабтайпинг начинает нам мешать. K>Ну естественно. Он и работать только при косвенной адресации начинает.
Проблема в том, что в дотнете/джаве он работает даже тогда, когда в конкретном месте вызова метода этого вовсе не требуется.
V>>Это всё унаследованный от джавы кретинизм. Парадигма ООП тут не при чем. K>Никакой джава-специфики тут нет. ООП-полиморфизм в основном так и реализуется.
Нет. ))
Изначально именно такого ООП-полиморфизма и не было. Но само ООП было. ))
V>>В С++ более распространены их статические варианты: traits и "статический визитор". А так-то да. Если забыть, что речь шла про операторы... )) K>Ну так и обсуждаемый вариант на C# — статический.
Дудки. Для каждого типа-словаря value-type в твоём примере в рантайм будет генерироваться уникальный код генерика. По моим представлениям это оч далеко от статики. ))
V>>С операторами удобнее таки через явное указание "модуля", то бишь области видимости. Именно таким образом мы "передаем словарь" один раз на всю текущую область видимости (через указание других видимых явно "модулей"), т.е. не надо передавать в каждый метод. Очень даже оправданный подход, коль речь не о вызовах методов, а о глобальных ф-иях/операторах.
K>Не считаю, что это хороший подход (хотя широко практикуемый в ML-ях). В одном выражении и в одной области видимости может быть + и для int и для double.
Ты не понял. Как раз перегруженные сигнатуры операторов + для int и для double прекрасно разруливаются компилятором в одной области видимости. Речь о случае когда для надо указать некую специальную реализацию + для некоего пользовательского Double, — например, у нас есть быстрая арифметика пониженной точности на SSE-регистрах, и медленная повышенной точности на стандартных регистрах с плавающей запятой. У тебя на C# надо явно передавать словарь в каждой строчке кода, а в С++ можно указать произвольный using namespace в произвольном по охвату scope.
V>>Меня интересует библиотечная либа, умеющая вызывать kill Pet a, которая еще ничего не знает о Cat и Dog, и которая принимает на входе выраженную каким-либо способом последовательность абстрактных Pet a. K>Если работать c Pet (без a) — то будет рантайм диспетчеризация, как в ООП — как иначе-то?
О чем и речь. В ООП вполне можно свести кол-во рантайм диспетчеризаций к аналогичному в ФП.
Наконец я вернулся к самому началу того, о чем говорил насчет Swift.
K>Ну да, и что? Это никак не отменяет фактической разницы случаев, когда нужно выбирать между ветками вычислений и когда не нужно. Во втором случае "выбор" устраним на этапе компиляции и на практике устраняется в значительном числе случаев.
Это зависит от системы типов и принципов формирования бинарного кода. В C# не устранимо никак в большинстве случаев.
V>>Вызов виртуального метода и есть "просто dereferencing". K>Не просто. Мы не знаем до рантайма какой метод вызываем. Тут же все в компайл-тайм известно, это как поле структуры прочитать.
Там где в Хаскеле тоже будет рантайм-диспетчеризация, там тоже будет точно такой же косвенный вызов, а не прямой.
V>>В плюсах в исходниках нужны только заголовочные файлы для этого случая, а тело методов может быть библиотечным. Если мы всё еще об одном и том же — о реализации словаря ComplexNumber, например. ну и инлайнинг на сегодня может выполняться во время линковки, не только во время компиляции.
K>Так я и говорю, решение с передачей словаря лучше подходит для раздельной компиляции.
Ортогонально. Прочитать объявления ф-ий и скомпилировать их тела — это несравнимая работа для компилятора. Если рассматривать компиляцию тел ф-ий, то получим раздельную компиляцию и в С++.
V>>- LLVM последних версий отстаёт от самого лучшего GC уже всего лишь в полтора раза на специальных тестах и почти не отстаёт на "обычном" коде. K>Разница в производительности генерируемого кода между clang и компиляторами других языков, использующих LLVM вполне наблюдаема.
Это больше проблема самой LLVM. Оптимизирующие компиляторы — это дорогое удовольствие.
V>>В общем, потенциал неплох. По-сути, это прямой конкурент D. K>У меня впечатление, что у D возможности побогаче.
Они у него противоречивее, увы. Кое-что "красивого" добавлялось позже, но не удалялась первоначальная кривизна. ))
K>Тут как раз не все так просто. Эппл, конечно, имеет возможность сделать его не менее популярным, чем Objective-C и тем же самым способом, ну так и за пределами эппловской платформы у него будет популярность, как у Objective-C.
Там достаточная емкость рынка для того, чтобы язык был оч популярным. Сотни тыщ разрабов по всему миру — это не мелочь. В первые 5 лет у джавы было меньше.
Здравствуйте, Ikemefula, Вы писали:
I>Я просил upward, a ты выдал downward. За ликбезом смотри рядом пост alex_public.
Ты порядком утомляешь своей невнимательностью. Иногда обсуждать что-либо с тобой просто невозможно — настолько жестоко ты тормозишь. Ладно бы еще извинился и поправился, но ты же проявляешь упрямство, сравнимое только с твоей несообразительностью.
Последний раз. Для жителей Крайнего Севера — репост:
В первом случае замыкание можно безопасно сохранить во внешнем контексте, во втором — нет.
В первом случае хоть вверх, хоть вбок. Во втором случае — только вниз по стеку.
Обрати внимание на комменты:
// по значению
...
// по ссылке
В первом случае будут копии значений. Именно поэтому пропадает зависимость от контекста, что мы не ссылаемся ни на какой контекст, а захватили копии значений в лямбду. Саму лямбду затем можно копировать произвольное кол-во раз, порождая произвольное кол-во копий. Такая лямбда иммутабельна, со всеми вытекающими.
Здравствуйте, vdimas, Вы писали:
I>>Я просил upward, a ты выдал downward. За ликбезом смотри рядом пост alex_public.
V>Ты порядком утомляешь своей невнимательностью. Иногда обсуждать что-либо с тобой просто невозможно — настолько
До свидания. Приходи когда научишься приводить адекватный код.
Здравствуйте, vdimas, Вы писали:
V>Ес-но, реализация арифметических операторов для Complex должна быть где-то описана. Но не дважды же! В Хасклеле бери любую либу с каким-нить MegaComplex, да пользуйся. А в твоём решении на C# надо еще раз по операторам пройтись да продублировать их. Что-то не так в консерватории, не правда ли? ))
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, vdimas, Вы писали:
V>>Ес-но, реализация арифметических операторов для Complex должна быть где-то описана. Но не дважды же! В Хасклеле бери любую либу с каким-нить MegaComplex, да пользуйся. А в твоём решении на C# надо еще раз по операторам пройтись да продублировать их. Что-то не так в консерватории, не правда ли? ))
AVK>Все течет, все изменяется. http://referencesource.microsoft.com/#mscorlib/system/int32.cs — обрати внимание на закомментированное.
Здравствуйте, alex_public, Вы писали:
_>Вообще то как раз только интроспекция времени компиляции (как в том же D) и имеет смысл для статически типизированных компилируемых языков. А убогие интроспекции времени исполнения, как в Java/C# — это только от недостатка умения.
Видишь ли, есть задачи для рефлексии, которые статически нерешаемы в принципе.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, alex_public, Вы писали:
_>Ты конечно же можешь привести примеры практических задач, которые эффективно решались бы только с помощью динамической интроспекции? )
Безусловно. Собственно, большая часть задач как раз статически и не решаема. Типичный пример — метаданные всевозможных плагинов. На момент компиляции анализирующего кода анализируемый недоступен даже в бинарном виде.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
_>>Ты конечно же можешь привести примеры практических задач, которые эффективно решались бы только с помощью динамической интроспекции? )
AVK>Безусловно. Собственно, большая часть задач как раз статически и не решаема. Типичный пример — метаданные всевозможных плагинов. На момент компиляции анализирующего кода анализируемый недоступен даже в бинарном виде.
Непонятно как это может быть примером подобной задачи, если существует множество различных реализаций плагинов и даже целых платформ на эту тему, без всякой интроспекции вообще.
Здравствуйте, alex_public, Вы писали:
_>Непонятно как это может быть примером подобной задачи, если существует множество различных реализаций плагинов и даже целых платформ на эту тему, без всякой интроспекции вообще.
Ну да, там интроспекция реализована вручную, обычно в виде метода, отдающего те же самые метаданные.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alex_public, Вы писали:
_>>Непонятно как это может быть примером подобной задачи, если существует множество различных реализаций плагинов и даже целых платформ на эту тему, без всякой интроспекции вообще.
AVK>Ну да, там интроспекция реализована вручную, обычно в виде метода, отдающего те же самые метаданные.
Тоже вариант, особенно если этот метод реализован автоматически (через статическую интроспекцию). Но это вариант для передачи метаданных. А я вот что-то пока не вижу вообще необходимости в метаданных для системы плагинов, т.к. вызывающий код обычно всё же знает все возможные интерфейсы и надо только выяснить какие предоставляет конкретный плагин. Т.е. грубо говоря IUnknown более чем достаточно для реализации нормальной системы плагинов. Или быть может подразумевалась какая-то особенная хитрая система? )
Так может будет ещё какой-то пример пользы динамической интроспекции? А то этот как-то совсем не убедил пока.
Здравствуйте, AndrewVK, Вы писали:
_>>Непонятно как это может быть примером подобной задачи, если существует множество различных реализаций плагинов и даже целых платформ на эту тему, без всякой интроспекции вообще.
AVK>Ну да, там интроспекция реализована вручную, обычно в виде метода, отдающего те же самые метаданные.
+1
Итого, интроспекции подлежит только некая явно обозначенная часть метаинформации, а не вообще вся. Причем, на стороне этого плагина такая метаинформация доступна статически.
