@ProCxx

Страница 2241 из 2477
Andrei
28.07.2018
13:56:36
Но Линус чувак странный.

Серж
28.07.2018
13:56:44
запомнил только один совет любителя операционных систем, который говорит, что с++ не надо использовать, чтобы держать подальше программистов, которые на нем программируют

Andrei
28.07.2018
13:57:10
Эх. Щас бы лямбды в фортране.

Александр
28.07.2018
13:57:52
С лямбдами (как и с BlueTooth) все становится лучше! Но если предметно, то зачем в Фортране лямбды?

Google
Andrei
28.07.2018
13:58:36
Чтобы студенты с вычфизики мучались поменьше.

Физикам до сих пор фортран преподают.

Из-за сотен легаси специфического физического софта на фортране.

Который, что грустно и смешно, до сих пор работает быстрее плюсов и си в некоторых случаях.

А там даже на 2% менее загруженный грид-кластер — это достаточное основание для поддержания.

Серж
28.07.2018
14:00:14
а кто-то меряет что-ли?

Andrei
28.07.2018
14:00:32
Конечно.

Забыл камешек в огород Хаскеля.

Произведение типов.

Структуры, короче говоря делаются сложно.

Александр
28.07.2018
14:04:29
Andrei
28.07.2018
14:04:47
Простого синтаксиса для структур нет.

Александр
28.07.2018
14:04:59
Наверное, ты имеешь в виду рекорды.

Google
Andrei
28.07.2018
14:05:00
Вместо него оптика, линзы, катаморфизмы

Рекорды, да.

Структуры в си.

Вместо него оптика, линзы, катаморфизмы
Я знаю в целом, что мне на это скажут, что фича, а не бага. Но всё же.

Александр
28.07.2018
14:06:54
Это давняя проблема в Haskell, которая решается совершенно разными способами. Наиболее безумные основаны на разных играх с системой типов, например, это библиотека vinyl. Однако, нужно все-таки уточнить, какие требования. Потому что обычно хватает алгебраических типов данных.

Если использовать DuplicateRecordFields и АДТ, работа со структурами будет весьма похожа на таковую в С++ с учетом иммутабельности. Если при этом добавить линзы, такие рекорды становятся уже нормальным вариантом. И можно присыпать библиотекой aeson для автоматической конвертации в/из JSON. А вот если нужно замапить структуру БД, то да, обход полей в АДТ становится не очень тривиальным делом. Тут нужно либо использовать метапрограммирование, либо идти по пути нескольких разных моделей: АТД для модели предметной области, и всякие страшные штуки навроде vinyl - для модели БД

Andrei
28.07.2018
14:13:10
Линейная алгебра в основном.

Тот же lapack c интелловским компилятором фортрана

Да. По крайней мере последний раз когда я проверял — был быстрее.

Есть много специфичных задач, всякие трёхдиагональные матрицы, методы приближенных вычислений решения слау. И прочее.

Кому кроме физиков надо уметь обращать diagonal-band матрицы? Они появляются только во всяких неявных интеграторах разного порядка.

Или особый тип вычисления матриц для симплектических интеграторов.

Короче люди там по 10 лет могли улучшать две-три сотни строчек.

Для узких физических задач.

Быстрый. И CLapack быстрый.

Но всё еще проигрывал фортрановскому аналогу.

Constantine
28.07.2018
14:30:34
Ой, сколько букв, даже после Войны и Мир столько ниасиливаю. Господа функциональщики, а скажите, а почему ФП еще не поработил мир?

Вот просто, объективные минусы и проблемы всей концепции и почему мы все здесь не в pro.haskell

Привычное IO можно обернуть в IO-монадические функции. Проблема здесь, скорее, в том, что в С++ нет возможности тегировать функцию как _по-настоящему_ чистую. Увы, ни одна из конструкций (const, constexpr, nothrow, и тд.) не удовлетворяет требованиям. Разве что функции на типах, но цена у такого "очищения" функций весьма высока. Однако, монада IO все еще могла бы быть полезна для явного указания, что программист должен быть осторожен. Во всех остальных случаях, конечно, от IO большого прока не будет. Отлаживать монадический код в С++ можно точно так же, как и обычный, потому что это обычный код. Вероятно, из-за природы монад, будет очень много скачков дебаггера по внутренностям, но в остальном монадические функции - это просто функции и лямбды. Любой монадический код можно развернуть в цепочку функций, примененных одна к другой. Что и происходит на самом деле. Поэтому больших отличий в отладке не будет, кроме, возможно, длинного стека вызовов. Но обычно говорят, что монадический код, как и всякий функциональный код, не нужно отлаживать. Его нужно тестировать, - а это просто, ведь мы имеем дело не с состоянием, которое существует в рантайме императивного кода, а мы работаем с функциями, в которые передаем начальный аргумент. Внутреннего состояния у монадической цепочки нет, - кроме тех переменных, что приходят как аргументы. Поэтому мы легко можем подавать в монадическую цепочку "боевые" данные либо же тестовые, - и смотреть, что происходит на выходе. Этого достаточно, чтобы понять, как ведет себя вся (потенциально длинная) монадическая цепочка.
И да, я всеми конечностями за введение в стандарт языка требования чистоты функции

Александр
28.07.2018
14:34:34
Встречный вопрос: почему golang порабощает мир?

Google
Крис
28.07.2018
14:34:59
Constantine
28.07.2018
14:35:22
Ну я на своем опыте как минимум скажу, что я не вижу ни одной причины не использовать императивные описания чистых функций :)

Александр
28.07.2018
14:36:58
А мир про это знает?
Ну хорошо. Давайте заменим на PHP образца 2009 года (я его видел чуть-чуть).

Серж
28.07.2018
14:37:08
глобальный стейт эффективнее и по памяти и по производительности будет при прочих равных?

Constantine
28.07.2018
14:37:32
Встречный вопрос: почему golang порабощает мир?
Не знаю про golang, но телега вот проект достаточно новый, и емнип он на плюсах

Серж
28.07.2018
14:38:13
васап на эрланге, достаточно функционально?

Александр
28.07.2018
14:38:49
глобальный стейт эффективнее и по памяти и по производительности будет при прочих равных?
В однопоточном приложении - наверное. В многопоточном - источник чудовищных багов.

Constantine
28.07.2018
14:39:07
Т.е. переход на (нормально работающую) Java/C# в громадной области разработки произошел буквально за лет пять

Серж
28.07.2018
14:39:19
есть еритики, которые утверждают, что потоки это для тех кто не может в реактивное программирование

и что потоки зло, даже пейперы пишут

и говорят, что на самом деле никаких потоков то и нет

Constantine
28.07.2018
14:39:58
И утверждать, что мир программирования консервативен это заведомая глупость В чем проблема у того же haskell?

Александр
28.07.2018
14:40:17
васап на эрланге, достаточно функционально?
Не очень. Эрланг достаточно далек от ФП, несмотря на то, что его так позиционируют. Но факт интересный.

и что потоки зло, даже пейперы пишут
Скорее, пейперы пишут, что голая многопоточная модель сложна для корректной реализации. Поэтому придумали много иных подходов, которые, тем не менее, внутри используют потоки

Серж
28.07.2018
14:44:36
а с++ легко что-ли?

Evgeniy
28.07.2018
14:44:47
Александр
28.07.2018
14:45:36
Гм

Constantine
28.07.2018
14:48:24
Гм
вот я, если честно, совершенно не верю в сложно - кмк функциональное программирование от природы намного более математично, а у всей адекватной группы программирования с этим особых проблем быть не должно так где здоровенный подводный камень?

Google
Серж
28.07.2018
14:49:58
он намекает, что хаскель не взлетел не потому что сложно, а потому что не нужен

Constantine
28.07.2018
14:49:58
я не говорю, что он не нужен (уж это очень сложно оценивать) я говорю, что должен быть подводный камень, который приводит к проблемам

для C++ это все еще чрезвычайно низкий контроль со стороны компилятора для настолько полного всякими UB языка

Александр
28.07.2018
14:51:18
Я не очень понимаю, что значит "не взлетел".

Серж
28.07.2018
14:51:36
нет вакансий на хедхантере

Constantine
28.07.2018
14:51:54
это значит, что популярность Java и всяких его потомков сейчас сильно выше

Александр
28.07.2018
14:52:02
Constantine
28.07.2018
14:52:42
Они не там.
Вот представьте, что нам завтра надо написать телеграмм - будем писать его на хаскеле?

Серж
28.07.2018
14:54:12
много ли программистов могут написать роман, создать симфонию?

Constantine
28.07.2018
14:54:32
Почему бы и нет?
Ну совершенно точно должны быть причины, почему C++ а не haskell

Как я понимаю, в плане стабильности и контроля кодовой базы Haskell должен просто на порядок превосходить плюсы

Evgeniy
28.07.2018
14:55:06
Ну совершенно точно должны быть причины, почему C++ а не haskell
потому что найти 10 хороших прогеров на плюсах в разы проще?

Constantine
28.07.2018
14:55:23
потому что найти 10 хороших прогеров на плюсах в разы проще?
сколько хороших прогеров на Java можно было найти в 2004 году?

Серж
28.07.2018
14:55:52
а не потому что по потреблению памяти и процессорного времени плюсовая аппликуха уделает хаскельную?

Google
Constantine
28.07.2018
14:56:44
нужен один С++ разработчик в команду

Серж
28.07.2018
14:56:55
но большие дяди... капитализм... рыночек... деньги... порешал...

Александр
28.07.2018
14:57:00
Как мне кажется, превалирующий критерий выбора технологии всегда был "нравится/не нравится"

Серж
28.07.2018
14:57:33
если потом за твое нравится дядя будет отваливать больше бабок на сервера, это ему не понравится

Constantine
28.07.2018
14:57:57
Как мне кажется, превалирующий критерий выбора технологии всегда был "нравится/не нравится"
Совершенно точно нет! Выбор зависит от ниши. Ниша заказной разработки, например, хочет, чтобы в проекте было легко заменить человека и разработка была быстрой и по возможности максимально предсказуемой по срокам

Серж
28.07.2018
14:58:18
а почему не на джаве тогда?

я кстати ничего не слышал, насчет того на чем реально серверная часть телеграмма написана

Constantine
28.07.2018
14:59:05
Вообще я верю, что в районе C++25 если все правильно делать, то ВНЕЗАПНО заказной поток может и назад поехать

Серж
28.07.2018
14:59:10
на джаве и человека полегче будет заменить, да и меньше шансов сегфолтов

Constantine
28.07.2018
14:59:21
в Ex25 диалект C++ с выброшенным C legacy

а почему не на джаве тогда?
поэтому в 2004-2005 все уехали в Java/C# (последнее чуть менее экстремально и чуть более серьезные ресурсы имело за собой)

у меня, (и не только у меня) кстати, есть очень простой практический опыт - прихожу я как-то раз и говорю, что мы переходим на полностью реактивную запись вычислений во всем коде работы с гуем (практически чистый код, если я правильно понимаю идеи ФП!), и никаких проблем у людей, не особо упарывавшихся формальной алгеброй

это просто немного другой язык, с другими правилами записи того же, научиться говорить на языке каждый из нас смог еще до школы

ключевое преимущество Java все еще не в простоте

Страница 2241 из 2477