А хотя по идее тогда length надо задать

либо использовать Appender

так он же на массиве будет почти как capacity работать как я понимаю

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

а как put использовать? int [] arr = [1,2,3,4,5]; arr.put(7); Error: no property 'put' for type 'int[]'

сигнатура: void put(U)(U item)

auto arr = [1,2,3]; auto app = appender(&arr); app.put(4);

А как ты по сигнатуре понял как надо?

все просто)

google: dlang appender -> https://dlang.org/phobos/std_array.html#appender

а если вкратце - какие есть преимущества у динамических массивов перед контейнерами?

(мб, киллерфича какая есть)

перед какими конкретно контейнерами?)

ну вот динамический массив VS контейнерный массив, например

Покажи пример плиз контейнерного массива

просто я тут зачитался темами типа - https://forum.dlang.org/post/mailman.307.1468487593.3131.digitalmars-d-learn@puremagic.com

google: dlang appender -> https://dlang.org/phobos/std_array.html#appender

а как ты понял что этот метод с appender связан? Я по его сигнатуре не пойму

просто закрались подозрения)

ну, например, Array!int a = make!(Array!int)();

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

и потом в него и из него что хочешь то и делай

хошь инсерт

А контейнерные массивы не опираются на GC и работают поэффективнее

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

просто закрались подозрения)

тоесть иначе как гуглить не вариант?

тоесть иначе как гуглить не вариант?

в Eclipse можно еще перейти к определению, VS Code с этим хуже справляется, но в большинстве случаев тоже может

а там уже читать, смотреть и гуглить, если что не понятно, другого выхода нет)

я просто думал мало ли. вдруг там именно по функции что-то понять можно

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

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

А контейнерные массивы не опираются на GC и работают поэффективнее

а если, например, удалить объпект из контейнера - его GC подхватит? или надо вручную убивать?

Вручную ты его не убьешь, разве что извращаться с GC.free(). GC подхватит, только не сейчас а когда сам сочтет нужным.

понятно. тогда - хорошо (:

Иногда в самый неудобный момент, например когда к тебе прилетело 2000 запросов и надо их все за секунду обработать, а тут ГЦ решает провести уборочку и замораживает на полсекунды все треды.

но ведь это проблема в любом языке с уборщиком мусора?

как минимум в большинстве)

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

Ну я на го и жаве не разрабатывал, но мне кажется там вылизан гц очень сильно

Так что это почти незаметно

Кроме того, я видел доклад какого-то человека про то как он написал свой ГЦ который работает на всех тредах, и там где обычный гц отрабатывает за секунду, его гц работает 40мс

То есть потенциал оптимизаций огромный

в D сборщик — достаточно прямолинейный парень)

видит, что памяти не хватает, останавливает всех и освобождает ее)

хочется за ним последить

поглядеть что и как

Вопрос не по теме. А на Python кто в чем пишет из IDE?

выбор не велик. Хорошая поддержка есть только в Pycharm

Я тут децл одну картинку подправил.

мне нравится вот это на тему язков - https://www.youtube.com/watch?v=niO16JEbpWs

Go2 га картинке чем то Emacs напоминает.

)))

Красиво сказано: "Красиво сказано: "Преобладающая парадигма программирования, — объектно-ориентированное программирование, не дает вам ничего в области параллелизма, а вместо этого поощряет опасный и подверженный ошибкам дизайн. Основные принципы объектной ориентированности: cокрытие, совладение и мутация данных — идеальная среда для гонок данных. Идея объединения данных с мьютексом, который их защищает, хороша, но, к сожалению, блокировки не компонуемы, и сокрытие блокировок делает дедлоки более вероятными и менее отлаживаемыми.""

Красиво сказано: "Красиво сказано: "Преобладающая парадигма программирования, — объектно-ориентированное программирование, не дает вам ничего в области параллелизма, а вместо этого поощряет опасный и подверженный ошибкам дизайн. Основные принципы объектной ориентированности: cокрытие, совладение и мутация данных — идеальная среда для гонок данных. Идея объединения данных с мьютексом, который их защищает, хороша, но, к сожалению, блокировки не компонуемы, и сокрытие блокировок делает дедлоки более вероятными и менее отлаживаемыми.""

А где сказано?

https://habrahabr.ru/post/245797/

https://habrahabr.ru/post/245797/

Спасибо)

Красиво сказано: "Красиво сказано: "Преобладающая парадигма программирования, — объектно-ориентированное программирование, не дает вам ничего в области параллелизма, а вместо этого поощряет опасный и подверженный ошибкам дизайн. Основные принципы объектной ориентированности: cокрытие, совладение и мутация данных — идеальная среда для гонок данных. Идея объединения данных с мьютексом, который их защищает, хороша, но, к сожалению, блокировки не компонуемы, и сокрытие блокировок делает дедлоки более вероятными и менее отлаживаемыми.""

Какова тогда область применения ооп?

Красиво сказано: "Красиво сказано: "Преобладающая парадигма программирования, — объектно-ориентированное программирование, не дает вам ничего в области параллелизма, а вместо этого поощряет опасный и подверженный ошибкам дизайн. Основные принципы объектной ориентированности: cокрытие, совладение и мутация данных — идеальная среда для гонок данных. Идея объединения данных с мьютексом, который их защищает, хороша, но, к сожалению, блокировки не компонуемы, и сокрытие блокировок делает дедлоки более вероятными и менее отлаживаемыми.""

> Основные принципы объектной ориентированности: cокрытие, совладение и мутация данных Ну глупость же.

Причём это переводчик переврал, заметьте. В оригинале было корректно: > Data hiding, the basic premise of object orientation, when combined with sharing and mutation, becomes a recipe for data races.

я хз, мы с приятелем тему ООП долго обсуждали в итоге возможно нужны нормальные модули, а не объекты. Ведь по идее вместо класса может быть просто модуль. Правда я не претендую хоть на какую то грамотность в основах CS.

в императивном языке модуль будет аналогом синглтона же)

банальность скажу, но просто думал тема холиваров "чистая функциональность против ООП" уже мертва. "Молоток хуже пласкогубцев, потому что им не так удобно выкручивать шурупы" - основной посыл холиварщиков. Много всего было сказано на эту тему, но по факту мы видим, что мультипарадигмальные языки приобретают наибольшую популярность

+1

В статьях и блогах часто мелькает идея, что ФП это прям очень круто для параллелизма, спасение просто. А на деле множество функциональных языков вообще не умеют параллелизм (окамл, например), а в некоторых других нередко получается "чем больше потоков, тем медленнее" (например https://ghc.haskell.org/trac/ghc/ticket/9221 ), ибо сборщик мусора останавливает все потоки и чем больше потоков, чем быстрее они генерят мусор, тем чаще приходится их останавливать, а это тоже время занимает приличное (т.е. не только сама сборка, но синхронизация всех потоков). Найти функциональный язык, где действительно хорошо все с параллелизмом, - это еще надо постараться.

Просто тезис "иммутабельные данные позволяют не заботиться о доступе к ним из параллельных потоков команд" раздули до "все круто"

ERROR: S client not available

Я постоянно путаюсь. Какая из этих функций мне нужна, чтобы текстовую строку перевести в объект типа JSON http://vibed.org/api/vibe.data.json/serializeToJson Строка именно текстовая

http://vibed.org/api/vibe.data.json/parseJsonString

а в чем отличие от serializeToJson?

сериализация - это процесс превращения сложного объекта в скаляр(строку)

а тут чтот строка со структурой как у JSON чем не подходит? http://vibed.org/api/vibe.data.json/serializeToJson Вроде бы сигнатуры совпадают: static T fromString(string src);

почему тут может выпадать?

выпадает на строке: writeln(x["names"]);

Не надо использовать serializeTojson над строкой. Используй parseJsonString.

чем ему конец то не нравится?

нет идей что может быть не так?

Ошибка не гуглится

вот тока что нашел https://github.com/dlang/dub/blob/master/source/dub/internal/vibecompat/data/json.d#L967

чем ему конец то не нравится?

Не хватает внешних объектных скобок

{ "names" : ... }

О! точно!

пробую разобраться с шаблонами никак не могу понять, почему происходит такая штука:

class cContainerArray{ template container(T){Array!T objects;} this(){} void add(T)(T obj){container!(T).objects ~= obj;} ulong getSize(T)(){return container!(T).objects.length;} } cContainerArray cA = new cContainerArray(); cContainerArray cB = new cContainerArray(); cA.add!(object)(obj1); cB.add!(object)(obj2); writeln(«cB size is ", cB.getSize!(object)());

получаю результат - «cB size is 2», по идее должно быть 1

то есть obj1 и obj2 попадают в оба массива

переписал класс вот так:

class cContainerArray(T){ //template container(T){Array!T objects;} Array!T objects; this(){} void add(T obj){objects ~= obj;} ulong getSize(){return objects.length;} }

и дело пошлО

В статьях и блогах часто мелькает идея, что ФП это прям очень круто для параллелизма, спасение просто. А на деле множество функциональных языков вообще не умеют параллелизм (окамл, например), а в некоторых других нередко получается "чем больше потоков, тем медленнее" (например https://ghc.haskell.org/trac/ghc/ticket/9221 ), ибо сборщик мусора останавливает все потоки и чем больше потоков, чем быстрее они генерят мусор, тем чаще приходится их останавливать, а это тоже время занимает приличное (т.е. не только сама сборка, но синхронизация всех потоков). Найти функциональный язык, где действительно хорошо все с параллелизмом, - это еще надо постараться.

мб, erlang?

Да, кстати, эрланг хороший вариант. Там ко многому можно придраться, но мы не будем. В целом там с конкурентностью и параллельностью весьма хорошо, это его центральная тема.

А как там она построена? Чем от Дишной отличается?

Похоже на std.concurrency. Есть набор параллельно исполняемых сущностей (называемых там акторами), которые могут обмениваться сообщениями, как-то на них реагировать, порождаеть новые акторы. Под капотом там "зеленые потоки", примерно как наши файберы. Много таких потоков могут работать в пределах одного потока ОС, держать и обслуживать их дешево, можно их иметь миллионы на одной машине. В отличие от Дишных файберов, эрланг подсчитывает для каждого зеленого потока сколько тот сделал операций и сам переключает с одного на другого, не надо вручную делать yield, и один задумавшийся зеленый поток не будет задерживать других. При передаче сообщений, если там простые и небольшие данные, они копируются. У каждого потока свой GC, пока в одном зеленом потоке идет сборка мусора, остальные продолжают работать. В языке все иммутабельное, что сильно упрощает реализацию GC (старые объекты не могут начать указывать на молодые, поэтому граф указателей ориентирован, и сборщик его может легко обработать за один проход, не нужно париться всякими card marking, remembered sets и write barriers). Длинные бинарные данные лежат в общей куче, при передаче в сообщении передается лишь ссылка на них. Вот тут есть слабое место, как я понимаю, - общую кучу таки надо иногда собирать. Хотя в ней мусор не копится так активно, там счетчики ссылок, вроде как, так что часть памяти освобождается еще в процессе обычной работы, без остановки на GC. В языке удобные средства конструировать структуры данных и разбирать их (pattern matching). Типизация динамическая, структуры строятся из одних и тех же конструкций, поэтому данные легко отправлять по сети акторам на других машинах. В результате твое дерево акторов элементарно можно распределить по нескольким машинам. Что локально посылать, что подальше - все одно. Масштабирование из коробки, так сказать. Еще при создании акторов им может назначаться актор-супервизор, над ним - свой, и т.д. Получается такое дерево супервизоров, которые следят за своими детьми и если те плохо себя ведут (падают/виснут), перезапускают их, что обеспечивает какую-то надежность при наличии сбоев и ошибок. Если падает один актор, это не рушит другие, не рушит весь процесс, это безопасно и дешево. Поэтому практикуют принцип "fail fast" - кодишь оптимистично, забивая на потенциальные ошибки, если что-то идет не так, то актор падает и перезапускается. Можно быстро говнокодить и результат будет стабильно работать в большинстве случаев, сбои не убивают программу.

Самое смешное, что отцы ООП так свое видение и описывали: множество сущностей (объектов), которые обмениваются сообщениями, реагируют на них, создают новые объекты. Это философия Смолтолка и Руби. И в этом смысле Эрланг - чисто ОО язык. :)

шикарно написал! спасибо большое!

@thedeemon а плюсы у Ди какие ты бы называл? Я просто думаю твой пост с указанием твоего авторства в FAQ ( dlang.ru/faq ) добавить

Ровно 3 года назад я тут формулировал: http://www.infognition.com/blog/2014/why_d.html