SiemarglДа. Он _очень_ сложный.
Хотя наступила более-менее стабильность языка и фобоса.

Кто сложный? D? С чего это? Отличный язык с огромным потенциалом, реально убирающий массу огрехов С++ и вроде как не добавляющий новых. Я пробовал на нём кодить, каеф.

SiemarglЭто поверхностное мнение, я тоже так думал.
Но потом выяснилось, что на нем можно написать такое %;:;%№, что ни в сказке. Вот выборка примеров
https://github.com/Hackerpilot/Idiotmatic-D

Ну согласен, с сахаром местами переборщили, это так сказать "Остапа понесло.." ))

ЕвгенийВhVosttНу согласен, с сахаром местами переборщили, это так сказать "Остапа понесло.." ))
Хуже нет, когда какой нибудь умник понасует везде такого "сахара".

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

ViPRosЯ несколько раз пытался, но по привычке сваливался на C# - хреново что там все можно делать так же как и в C#

У меня наоброт, другое впечатление сложилось.

ViPRosЯ не могу что то просто "изучить". Сразу пытаюсь решить некую проблему и если я могу эту проблему решить привычным образом, то автоматом на это решение и сваливаюсь.

Это нормально для любого живого существа.

ViPRosА вот если нет привычного шаблона, тогда изучаешь что то новое.

Вот тут и приходится преодолевать препятствие, ты не видишь что за горой, пока не заползёшь на вершину, т.е. не освоишь знание. Пока ты её не освоил, трудно оценить масштаб пользы. А бывает, что за горой ничего толкового нет. Но польза тут как минимум в самом процессе.

Например, многим непонятно в чём смысл паттернов, принципов разработки. Потому что они их не знают и не имеют опыта. И объяснить им очень тяжело. Потому что быстро накодить выглядит достижимым, а как оно там на паттернах -- непонятно, и зачем тоже непонятно. Многие так и доживают с этим не пониманием, потому что когда-то не смогли осилить и продолжают обезьянить, потому что так проще.

ViPRosДоходит до абсурда - был горд, что некоторые вещи на C# делал параллельно - выигрыш налицо, кругом красота... через некоторое время (с год) надо было расширить функционал в тех местах и анализ алгоритма показал, что "параллелизм" ложный, существует более эффективное однопоточное решение :(

В 98% случаев нужна асинхронность, а не параллелизм :)

ViPRos,

Хотя с такими задачами, как расчёт расписания, наверное таки есть большой смысл в распараллеливании.

ViPRosесть, конечно
тут I/O мало, потому асинхронность ничего не дает
но распараллелить обработку графа практически негде, так как свалиться на перебор всех путей - NP
да и всегда находится эвристика, оценочная функция и т.д.

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

ViPRosЗадача простая и общая -
к решению проблемы ведут много путей (способов)
надо найти оптимальный путь (способ) не пройдя все пути

частный случай - например, задача коммивояжера

Ну это понятно.

У нас сейчас есть задачи прогнозирования и аналитики, которые должны находить при имеющихся ресурсах найти максимально эффективные пути их расходования на отрезке времени (год, полугодие), учитывая показатели за предыдущие года.

Решаем с помощью OLAP-кубов.

ViPRosэто другая задача - факторный анализ
такие задачи ошибочны в своей постановке
типа

было +- дельта -> будет

Да, только для N! вариантов.

ZyK_BotaNно прототипы пишу на эф-шарпе. на нем гораздо удобней и быстрее прототипировать, экспериментировать.

respecto )