Здравствуйте, 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-типы.
