Почему все так сложно?

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

Например, чтобы написать приложение на vue
нужно выдумывать подключение к api
которое нужно писать на django (например) и у которого десятки файлов с "кодом" с моделями, вьюхами, урлами, подключением к postgresql

дальше нужно настраивать синхронизацию, потом писать разрешения и в vue и в django...



Или на php - пишем код, потом берем фронтенд, более менее приличный, получается только на angular, vue, react

пишем отдельно код на php
потом пишем структуру базы данных , схему, саму базу формируем и создаем
потом описываем подключение

хорошо, если программист знает, что нужно сразу писать api к которому подключаться любым фронтом, а если нет... тогда или tpl-ки клепать, или придумывать php+html в котром тоже, гемор еще тот ...

почему до 2010 года был линукс, мягко говоря, "консольный"...
и пока до них дошло, что система должна быть визуальной - как windows - зато теперь красота! ubuntu 18 - почти идеальна!



Также и с программированием!
Зачем все эти сложности?

Теоретически, ведь можно взять принцип моделей от django, которые простым python3 manage.py makemigrations + migrate делает всю работу по моделированию базы данных...

но! Встает вопрос - а как потом работать? Нужно что-то похожее на vue, но только в ЖЕСТКОЙ связке с api с моделями!



Обсудим? Какие есть решения?

Добавлено через 27 минут
по сути, это должно быть простым CRUD приложением
но с возможностью подключения к базе данных

0

Сообщение от Shamil1 Матрицу Вы называете хэш-таблицей.

Покажите где именно. То похоже вы просто не знаете что хеш-таблица далеко не единственный способ построения индекса словаря.

Добавлено через 13 минут

Сообщение от Shamil1 Я не пытаюсь городить "список копий"

Толку тогда от вашего "копирования" которое на самом деле не разу не копирование а константная ссылка?

Главный момент всего этого дела - возможность изменения данных - неотъемлимая возможность как машины Поста так и машины Тюринга. Без этой возможности они теряют вычислимость. В 50-х с лектронной ОЗУ было напряжно. Сваповать можно было только на перфоленту а это устройство однократной записи. Соответственно пришлось изобретать эмуляцию изменений путем копирования с внесением изменений. Любая эмуляция имеет квадратичное время.
Вы же тепрь пытаетесь эмулировать еще и копирование. Получите экспоненциальное время и прочие накладные расходы.
Вопрос - и какие такие коврижки несет неизменяемость данных чтобы ради нее иметь столько геммороя?

Добавлено через 25 минут

Сообщение от Shamil1 Вы сказали, что без матрицы вообще никак не получить О(1). Я привёл способ, как получить О(1) без матрицы.

Не привели. А тем более способа изменения словаря без изменения данных и копирования при производстве хода за O(1).
Так кстати о птичках - хеш-таблица это всего лишь способ ужатия табличного индекса словаря. При этом хеш это далеко не O(1), это не хуже амортизированного Log(n). В небольших словарях когда количество возможных значений ключей сильно ограниченно можно и без ужатия. Матрица это не ужатая таблица.

Добавлено через 6 минут

Сообщение от Shamil1 Неизменяемые типы данных Вы называете неизменямыми данными, но потом вдруг выясняется, что int32 к ним не относится

int32 - изменяемый тип. const int32 - неизменяемый. но интом 32 не перестал быть не один не другой.

Добавлено через 46 секунд

Сообщение от Shamil1 Я не знаю, что Вы называете "деревянным индексом"

Дерево бинарного поиска.

Добавлено через 7 минут

Сообщение от Shamil1 И про "ленту изменений", кстати, тоже исключительно Ваша выдумка. Если у Вас есть что возразить по существу против моего высказывания

Если вы не можете изменять данные вы можете только их добавлять. Эмулировать изменения за O(1) невозможно. Соответственно, за O(1) вы можете только вести лог команд изменений по которому можно воспроизвести изменения в будущем. Но воспроизведение изменений в модели потребует и изменений самой модели. Если же следующая команда в качестве исходных данных использует данные из модели полученные в результате предыдущей команды, то вы с вашими неизменяемыми данными заходите в тупик.

Добавлено через 3 минуты

Сообщение от Shamil1 И про "ленту изменений", кстати, тоже исключительно Ваша выдумка

Если бы лента рекдактирования была бы моей придумкой я давно был бы миллиардером. На самом деле ее изобрела SolidWorks Corporation еще в те времена когда я кружочки с прямоугольниками на школьном УК-НС рисовал на васике.

Добавлено через 1 час 14 минут

Сообщение от Shamil1 Придумываете свой алгоритм решения задачи другим, не Вашим методом

НУ вы как бы делаете заявки о алгоритмической сложности O(1) ,высасонные из пальца, с добавлением условий исключаемых вычислимость. ПРи этом полный молчек о деталях как вы это будете реализовывать. Вот и приходится ванговать как вы это сможете сделать, хотя капитан очевидность дает только один ответ - никак.

1

Сообщение от Fulcrum_013 Покажите где именно. То похоже вы просто не знаете что хеш-таблица далеко не единственный способ построения индекса словаря.

Вы утверждаете, что матрица - это единственный способ добиться О(1). Я привожу другой способ - хеш-таблицу. Вы говорите, что это тот же самый способ. Значит, для Вас матрица и хеш-таблица - одно и то же.

Сообщение от Fulcrum_013 Главный момент всего этого дела - возможность изменения данных - неотъемлимая возможность как машины Поста так и машины Тюринга.

Есть ещё лямбда-исчисление.
Не знаю, что Вы подразумеваете под "данными". Я говорю про неизменяемые переменные. Например, функция, добавляющая узел в дерево, не изменяет исходное дерево, а создаёт и возвращает новое.

Сообщение от Fulcrum_013 Вы же тепрь пытаетесь эмулировать еще и копирование. Получите экспоненциальное время и прочие накладные расходы.

Я не получу экспоненциальное время.
Не знаю, что Вы подразумеваете под "копированием". Если физическое копирование памяти, то при создании нового дерева на основе исходного (в функции замены одного узла из предыдущего абзаца) в этом нет необходимости.

Накладные расходы обычно не существенны.
Даже если Вы в своём шахматном алгоритме вдруг решите при каждом изменении матрицы копировать её целиком (то есть, всю память, которую она занимает), Вы не заметите разницы. На каждое копирование памяти (сотые доли микросекунды) у Вас будет 2 (для коня) или 3 (для ферзя) вложенных цикла с плохо предсказуемым ифом внутри каждого из вложенных циклов.

Сообщение от Fulcrum_013 int32 - изменяемый тип

int32 - неизменяемый тип. Вы не можете изменить число. Вы можете только заменить его на другое.

Сообщение от Fulcrum_013 вы как бы делаете заявки о алгоритмической сложности O(1)

Об алгоритмической сложности О(1) чего я заявлял?
В одном месте - что можно сделать проверку занятости клетки на доске. При этом я не обещал, что используемая структура данных будет неизменяемой.
В другом месте - что можно сделать независимую копию объекта. При этом раз пять повторил, что копирование и изменение - это разные операции.

0

Сообщение от Shamil1 Я привожу другой способ - хеш-таблицу

хеш таблица не есть O(1). Это есть не хуже Log(n) -коллизии тама знаете тоже бывают и сравнивать ключи тоже надо. Если считать количество сравнений ключей для доступа то неужатая таблица это вообще O(0). Внесение изменений в хеш-таблицу тоже не есть O(1).
Но вопрос не в этом - как вы собираетесь в эту хеш таблицу вносить изменения если она неизменяемая копия?

Добавлено через 36 секунд

Сообщение от Shamil1 Об алгоритмической сложности О(1) чего я заявлял?

Об алгоритмической сложности копирования модели космодрома Байконур с заменой винтика.

Добавлено через 2 минуты

Сообщение от Shamil1 int32 - неизменяемый тип. Вы не можете изменить число. Вы можете только заменить его на другое.

а типа ++c это не изменение числа?

Добавлено через 4 минуты

Сообщение от Shamil1 Накладные расходы обычно не существенны.

В вашем 400-метровом двусвязном списке интов накладных расходов ровно 800 метров без GC и 1600 метров с GC который не дружит с Xor-связностью. 4 раза по памяти это не существенно?

Добавлено через 14 минут

Сообщение от Shamil1 Даже если Вы в своём шахматном алгоритме вдруг решите при каждом изменении матрицы копировать её целиком

В реальном шахматном алгоритме ее действительно потребуется копировать в словарь уже рассмотренных позиций. Но еще раз - смотрите на это как на аналог.
Вообще команду в САПР можно представить в виде функции Fn([Cn],Mn-1)->Mn. Cn- ветор параметров команды Mn - описание модели после выполнения n-ой команды. При этом Сn может содержать ссылки на элементы Mn-1.
Сответсвенно всю ленту редактирования можно представить в виде Fn(C[Cn],Fn-1([Cn-1,]..F1[C1],M0)) M0 - пустая модель.
При этом пользователь может изменять как параметры в любом из векторов Сi так и в ограниченных пределах порядок вложенности команд (вектор параметра команд может содержать ссылки только на элементы уже созданные предыдущими командами). Дальнейшим вышестоящим алгоритмам нужна именно Mn, а не список Fn, поскольку каждая из команд имеет полиномиальное время имплементации.
Теперь представьте что пользователь поменял что то в векторе С5. Кому нафиг нужна неизменяемая копия модели M1000 если все начиная с M5 стало неактуальным?

0

Сообщение от Fulcrum_013 Но вопрос не в этом - как вы собираетесь в эту хеш таблицу вносить изменения если она неизменяемая копия?

Я говорил только об О(1) для операции "определение занятости клетки".
Вы написали: "В алгоритме построения списков ходов наиболее используемая и вообще единственная операция связанна непосредственно с моделью - определение занятости клетки, при этом других операций там практически нет. За O(1) эта операция выполняется только по матрице. "
Я ответил: "2) за O(1) она выполняется не только на матрице."
Где здесь я написал про изменение?

Сообщение от Fulcrum_013 Об алгоритмической сложности копирования модели космодрома Байконур с заменой винтика.

Я говорил про копирование, а не изменение. Предположив, что Вы неправильно меня поняли, в следующем сообщении я уточнил:

Сообщение от Shamil1 Вы путаете копирование и изменение. Полностью скопировать за О(1) получится - добавляем ещё одну ссылку на ту же область памяти. Внести изменения - зависит от структуры данных. Для дерева это O(logN). Но при желании можно добиться практических О(1).

Сообщение от Fulcrum_013 а типа ++c это не изменение числа?

Нет. Изменение значения переменной.
Предположим, что в переменной содержалось значение "ноль". Эта операция не изменяет этот "ноль", а заменяет его на "единицу".

Сообщение от Fulcrum_013 В вашем 400-метровом двусвязном списке интов накладных расходов ровно 800 метров без GC и 1600 метров с GC который не дружит с Xor-связностью. 4 раза по памяти это не существенно?

У меня нет и никогда не было "400-метрового двусвязного списка интов". Так что это не мой, а Ваш список. Поэтому объясняйте сами, зачем Вы хороший инструмент используете таким жутким способом.

Вы опять:

Сообщение от Shamil1 Приводите какой-то случай, в котором использование некого метода нецелесообразно... и делаете вывод, что нет ни одного случая, когда использование этого метода было бы целесообразно.

0

Сообщение от Shamil1 Я говорил только об О(1) для операции "определение занятости клетки".

Хеш-таблица доступ O(1) не обеспечивает.

Добавлено через 4 минуты

Сообщение от Shamil1 Предположим, что в переменной содержалось значение "ноль". Эта операция не изменяет этот "ноль", а заменяет его на "единицу"

Как это не изменяет? Регистр-счетчик не ищет в хешах на что заменить 0 при инкременте. Он просто модифицирует биты того что в нем лежит.

Добавлено через 6 минут

Сообщение от Shamil1 У меня нет и никогда не было "400-метрового двусвязного списка интов".

Сообщение от Shamil1 А что касается последовательного доступа к связанному списку, то на моём компьютере список из 100 миллионов инт32 чисел суммируется в одном потоке за 70-100 мс (дот.нет код на эфшарп).

А это разве не 400-метровый список интов?

Добавлено через 1 минуту

Сообщение от Shamil1 Где здесь я написал про изменение?

А какой в ней смысл если она не изменяется при осуществлении хода? Без изменений она вообще доступ не обеспечивает поскольку хранит неактуальные данные.

0

Сообщение от Fulcrum_013 Вообще команду в САПР можно представить в виде функции Fn([Cn],Mn-1)->Mn. Cn- ветор параметров команды Mn - описание модели после выполнения n-ой команды. При этом Сn может содержать ссылки на элементы Mn-1. Сответсвенно всю ленту редактирования можно представить в виде Fn(C[Cn],Fn-1([Cn-1,]..F1[C1],M0)) M0 - пустая модель. При этом пользователь может изменять как параметры в любом из векторов Сi так и в ограниченных пределах порядок вложенности команд (вектор параметра команд может содержать ссылки только на элементы уже созданные предыдущими командами). Дальнейшим вышестоящим алгоритмам нужна именно Mn, а не список Fn, поскольку каждая из команд имеет полиномиальное время имплементации. Теперь представьте что пользователь поменял что то в векторе С5. Кому нафиг нужна неизменяемая копия модели M1000 если все начиная с M5 стало неактуальным?

Вы всё это придумали, поэтому Вам и отвечать, зачем это могло понадобиться.

Я могу свой пример придумать.
Есть дерево из 1000 элементов, каждый по 100 байт. Я передаю его в функцию. Функции может потребоваться внести в него изменения. Если используются только изменяемые типы данных, то ей придётся делать для этого глубокую копию всего дерева (скопировать 1000 узлов и 1000 элементов в узлах). Если используются только неизменяемые типы данных, то она создаёт новое дерево на основе текущего. Для этого ей придётся создать около 10 узлов (пусть 20, если потребовалась балансировка) и 1 элемент. Для не изменившихся элементов (все, кроме одного) и не изменившихся узлов (все, кроме предков изменившегося узла) будет совместно использоваться та же память.

Добавлено через 23 минуты

Сообщение от Fulcrum_013 Хеш-таблица доступ O(1) не обеспечивает.

Продолжается то, о чём я писал выше. Теперь Вы пытаетесь придумать новый смысл для "доступ O(1)".

Сообщение от Fulcrum_013 Регистр-счетчик

Как это устроено физически, не имеет значения. С точки зрения программы экземпляр типа инт32 изменить нельзя.

Сообщение от Fulcrum_013 А это разве не 400-метровый список интов?

Нет, это не "400-метровый двусвязный список интов".
Что касается списка, который я использовал для тестирования времени выполнения одной итерации, то да, разница в занимаемой памяти не существенна. Более того, разницы вообще не видно.

Добавлено через 2 минуты

Сообщение от Fulcrum_013 А какой в ней смысл если она не изменяется при осуществлении хода?

Это вопрос не ко мне. Я в своём алгоритме не собираюсь использовать хеш-таблицу.

0

Сообщение от Shamil1 Это вопрос не ко мне. Я в своём алгоритме не собираюсь использовать хеш-таблицу.

Это вообще вопрос о ваших неизменяемых данных. Какой в них смысл?

Добавлено через 1 минуту

Сообщение от Shamil1 Вы всё это придумали, поэтому Вам и отвечать, зачем это могло понадобиться.

Так вот в том и дело что ее придется изменять.

Добавлено через 3 минуты

Сообщение от Shamil1 Для этого ей придётся создать около 10 узлов (пусть 20, если потребовалась балансировка) и 1 элемент.

А для этого придется изменить метаданные. Ну и вообще мало понятно зачем дерево в стек пихать?

Добавлено через 13 минут

Сообщение от Shamil1 Я в своём алгоритме не собираюсь использовать хеш-таблицу.

Ну вы же говорили про словарь на хешах в качестве хранилища модели (позиции).

Добавлено через 1 минуту

Сообщение от Shamil1 Вы всё это придумали, поэтому Вам и отвечать, зачем это могло понадобиться.

На самом деле вы придумали что модель изменять вредно.Вот и потрудитесь объяснить альтернативный способ актуализации данных модели.

Добавлено через 1 минуту

Сообщение от Shamil1 Что касается списка, который я использовал для тестирования времени выполнения одной итерации, то да, разница в занимаемой памяти не существенна. Более того, разницы вообще не видно.

Тогда это что угодно но не связный список. Связный список имеет не менее одного указателя на каждый элемент.

Добавлено через 59 секунд

Сообщение от Shamil1 С точки зрения программы экземпляр типа инт32 изменить нельзя.

с каких делов?

0

Сообщение от Fulcrum_013 Это вообще вопрос о ваших неизменяемых данных. Какой в них смысл?

Я ничего не знаю про "неизменяемые данные". Я даже не знаю, что это такое. Или Вы имели ввиду "типы данных"?

Сообщение от Fulcrum_013 А для этого придется изменить метаданные.

Что Вы подразумеваете под "метаданными"?

0

Сообщение от Shamil1 Для этого ей придётся создать около 10 узлов (пусть 20, если потребовалась балансировка) и 1 элемент.

Для этого ей придется пересоздать все трассы на изменяемые узлы от самого рута. Но как бы какие с этим могут быть проблемы при COW-семантике узлов?

Добавлено через 1 минуту

Сообщение от Shamil1 Что Вы подразумеваете под "метаданными"?

Ну вот как раз узлы и есть метаданные. т.е. данные о месте расположения данных.

Добавлено через 4 минуты

Сообщение от Shamil1 Или Вы имели ввиду "типы данных"?

А что между ними может быть какая то разница?

0

Сообщение от Fulcrum_013 Ну вы же говорили про словарь на хешах в качестве хранилища модели (позиции).

Я говорил, что есть другой способ получить О(1) для операции "определение занятости клетки". Но не говорил, что собираюсь его использовать.

Сообщение от Fulcrum_013 На самом деле вы придумали что модель изменять вредно.

Предположу, что модель - это экземпляр некого типа данных.
Я не говорил, что изменять вредно. Я говорил, что можно использовать неизменяемые переменные.
И я не говорил, что использовать неизменяемые переменные вредно. Разные задачи - разные способы решения.

Сообщение от Fulcrum_013 от и потрудитесь объяснить альтернативный способ актуализации данных модели.

Я уже объяснял - создаём новый экземпляр.

Сообщение от Fulcrum_013 Тогда это что угодно но не связный список. Связный список имеет не менее одного указателя на каждый элемент.

И что? Всё равно разницы не видно. У меня сиквел-сервер забрал 5Гб, и ещё несколько приложений по 1Гб. Думаете я смогу без специальных измерений заметить расход памяти на 100 миллионов ссылок? Тем более, что через секунду приложение завершилось и вернуло всю память.

Сообщение от Fulcrum_013 с каких делов?

Потому что он целый и неделимый. Чтобы можно было изменить объект, он должен состоять из отдельных частей, которыми мы можем манипулировать.

0

Сообщение от Shamil1 Даже если Вы в своём шахматном алгоритме вдруг решите при каждом изменении матрицы копировать её целиком (то есть, всю память, которую она занимает), Вы не заметите разницы.

У меня на каждое копирование будет копирование 8 интов 64.

Добавлено через 1 минуту

Сообщение от Shamil1 Я говорил, что можно использовать неизменяемые переменные.

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

1

Сообщение от Fulcrum_013 Для этого ей придется пересоздать все трассы на изменяемые узлы от самого рута.

Поэтому я и написал, что придётся создать 10-20 узлов (логарифм от 1000).

Сообщение от Fulcrum_013 при COW-семантике узлов

Что это такое?

Сообщение от Fulcrum_013 А что между ними может быть какая то разница?

Для меня данные - это информация. Меняется она или нет, зависит от постановки задачи. Поэтому "изменяемость данных" и "изменяемость типов данных" - это ортогональные понятия (все четыре комбинации допустимы).

Добавлено через 3 минуты

Сообщение от Fulcrum_013 Какой в них смысл? Никакого интереса кроме потокобезопасности это не представляет, но резко затрудняет решение практически любой задачи.

Интерес в том, что это резко облегчает решение практически любой задачи.

Сообщение от Fulcrum_013 У меня на каждое копирование будет копирование 8 интов 64.

Не понял, про какие 8 интов Вы говорите. В любом случае разницы Вы не заметите. Копирование участка памяти размером 64 байта занимает гораздо меньше времени, чем составление списка возможных ходов.

0

Сообщение от Shamil1 Не понял, про какие 8 интов Вы говорите.

про 64 байта модели доски. это 8 интов 64. кстати так о птичках в эти 64 байта можно и обратный индекс запихнуть. т.е список фигур с координатами. 32 байта доска 32 байта список фигур. Ну правда при таком ужати коды фигур придется из тетрад доставать.

Добавлено через 9 минут

Сообщение от Shamil1 Интерес в том, что это резко облегчает решение практически любой задачи.

На самом деле резко затрудняет. По причине того что изменение метаданных это такое же изменение. При этом с актуализацией данных будет очень тяжко. В чем может быть облегчение если нужно пересоздать тяжелый объект при изменении одного его свойства и при этом еще обновить на него ссылки у всех его связей вместо того чтобы переписать одно число значение которого никому кроме самого этого объекта нафиг не улыбалось?
Вот поэтому такая потокобезопасность и не нужна. Либо она вообще ни к селу ни к городу, потому что параллелить нужно совсем в другом месте, либо полностью ложила на такое понятие как актуальность данных. В том смысле что пофиг что данные стали неактуальны, пусть дальше по неактуальным молотит. Так жить нельзя. А то совсем непонятно на кой ляд калькулятору виндовскому потоков нужно больше чем кнопок (аж 25) и 50 метров памяти. Вот это показатель эффективности гуглеров из майкрософта.

Добавлено через 5 минут

Сообщение от Shamil1 Что это такое?

Copy-on-Write. Ну как массивы и строки в дельфе/билдере живут. т.е. фактически массив/строка это указатель на буфер. При присваивании строки копируется указатель и увеличивается рефкаунт. При записи в строку если рефкаунт больше одного создается копия и изменения производятся в ней. Рефкаунт исходной строки уменьшается, ссылка через которую было вызвано изменение получает указатель на новый буфер.

1

Сообщение от Fulcrum_013 Copy-on-Write.

Знаю. Писал когда-то в учебных целях класс для строк на С++ с этим свойством.

Сообщение от Fulcrum_013 Для этого ей придется пересоздать все трассы на изменяемые узлы от самого рута. Но как бы какие с этим могут быть проблемы при COW-семантике узлов?

Придётся написать и отладить кучу лишнего кода, который делает по сути делает всё то же самое, но по-другому (в другой момент). А выигрыша никакого (если точно известно, что функция поменяет дерево).

Сообщение от Fulcrum_013 На самом деле резко затрудняет.

Это только Ваше личное мнение. Причём по принципу "не читал, но осуждаю".

Сообщение от Fulcrum_013 При этом с актуализацией данных будет очень тяжко.

Вы до этого писали, что при использовании COW никаких проблем (пересоздать все трассы на изменяемые узлы от самого рута).

Добавлено через 1 минуту

Сообщение от Fulcrum_013 А то совсем непонятно на кой ляд калькулятору виндовскому потоков нужно больше чем кнопок (аж 25) и 50 метров памяти.

Это всё от того, что его писали в императивном стиле с использованием изменяемых типов данных.

1

Сообщение от Shamil1 Придётся написать и отладить кучу лишнего кода, который делает по сути делает всё то же самое, но по-другому (в другой момент).

Узел - массив указателей на массивы. все. COW под капотом у массива.

Сообщение от Shamil1 Вы до этого писали, что при использовании COW никаких проблем (пересоздать все трассы на изменяемые узлы от самого рута).

Адреса узлов поменялись так же как и рута. Это уже другое дерево. А вообще главный негаразд этой штуки в том что управляется она исключительно наличием на нее ссылок а не возможностью существования по правилам предметной области. Мелочь типа строк и массивов так в общем то нормально и даже удобно. А объекты посерьезней никак. Огромная их часть единственна и неповторима во всех своих ипостасях. К примеру поверхности и кривые можно на COW сажать и это будет довольно удобно. Вектор параметров команд о них напрямую знать не может. А вот ребра точки и грани которые на них живут, и на которые могут ссылаться вектора последующих команд, так уже нельзя. Она или может существовать или не может по геометрическим условиям после модификации вектора создавшей ее команды. Если может то все последующие ссылающиеся на нее команды должны перестроится с учетом ее изменений. Если не может - ну тут остается только матерится по поводу кривизны рук прослойки между стулом и клавиатурой которая деталь редактирует. Главное при этом четко показать (цветом, звуком, остановкой перестроения, и прочими спецэффектами) что именно отвалилось - это его проблемы найти новые привязки. Т.е. жить это должно на двунаправленных связях. И потоков ему боятся не надо.
Потому что параллелить нужно пересчет данных для изменения состояния (то что параллелится - пачка уравнений пересечения кривой с поверхностью - параллелится в режиме разделения ресурсов).т.е. на момент непосредственно изменения других потоков просто не существует ибо нефиг. И так очень много с чем. Потому что подавляющее большинство простых численных методов либо не параллелится в принципе, либо векторится лучше чем параллелится. А вот сложные которые под капотом имеют пачку вычислений простыми - либо параллелятся либо векторятся просто абсолютно.

1

Сообщение от Fulcrum_013 Узел - массив указателей на массивы. все. COW под капотом у массива.

В любом случае придётся создать копию этого массива, а затем поменять в нём один указатель. Чтобы исходное дерево продолжало использовать старый узел-массив, а новое - новый, немного другой узел-массив.

Сообщение от Fulcrum_013 то что параллелится

Параллельность - далеко не самый важный показатель.
Основное преимущество неизменяемых данных - использование чистых функций.

0

Сообщение от Shamil1 Это всё от того, что его писали в императивном стиле с использованием изменяемых типов данных.

На шарпе выпускники курсов майкрасофт? какой там может быть императивный стиль? Когда его крайний раз инженеры писали в императивном стиле с изменяемыми типами данных винда была 95-ой и вся на диске в 50 мб помещалась.

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

А ученые (бакалавр и магистр - это научные степени) для таких корпораций как Гугл получается не по карману.

Добавлено через 19 минут
Shamil1, Он банально - смотрим сколько тем "как распарсить хтмл-ку регэкспом"? Потом им скорости не хватает потом им параллелить...

Добавлено через 10 минут

Сообщение от Shamil1 Чтобы исходное дерево продолжало использовать старый узел-массив, а новое - новый, немного другой узел-массив.

Это в принципе не вопрос. Вопрос только куда это приткнуть.

Сообщение от Shamil1 Основное преимущество неизменяемых данных - использование чистых функций.

А толку от них? А тем более когда функций нет, есть только методы.

Добавлено через 16 минут
Shamil1, Т.е. банально - зачем пытаться параллеллить reduce который в принципе не параллелится в общем случае, если можно распараллелить map , содержащий пачку этих reduce, который параллелится абсолютно всегда?
Вообще такое впечатление что ФП-никам ядра девать некуда. Так там где их девать некуда на самом деле не параллелится а векторится.

1

Сообщение от Fulcrum_013 Т.е. банально - зачем пытаться параллеллить reduce который в принципе не параллелится в общем случае,

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

Сообщение от Fulcrum_013 А толку от них? А тем более когда функций нет, есть только методы.

Методы - это тоже функции.
Чистые функции гораздо проще отлаживать. И код получается гораздо более читаемым.

Сообщение от Fulcrum_013 А ученые (бакалавр и магистр - это научные степени) для таких корпораций как Гугл получается не по карману.

Сомневаюсь. Вряд ли топ-менеджеры не умеют считать. Если бы им было выгодно нанимать одного крутого спеца вместо трёх средних, они бы так и делали. Деньги те же.

0

Сообщение от Shamil1 Если бы им было выгодно нанимать одного крутого спеца вместо трёх средних, они бы так и делали.

Крутые перцы и средние твердые калачи давно раскуплены промышленностью и всякими организациями типа NASA и Пентагона. Гуглы дать туже цену не в состоянии.

Добавлено через 7 минут

Сообщение от Shamil1 Чистые функции гораздо проще отлаживать. И код получается гораздо более читаемым.

Проще отлаживать кота с нормальной декомпозицией. Т.е. начинать с определения алгебры над сущностями предметной области. В ФП с этим дела обстоят чуть хуже чем никак. У гуглеров впрочем еще хуже. Чем весь гон в сторону ООП и вообще императивного стиля и объясняется.

Добавлено через 12 минут

Сообщение от Shamil1 Методы - это тоже функции.

Только они априори работают с состояниями.

Добавлено через 5 минут
Shamil1, кстати так о птичках противопоставлять декларативно-императивно - сапоги в смятку. любая подпрограмма декларативна по отношению к нижестоящей подпрограмме и императивна по отношению к вызывающей надпрограмме.
А вообще круть получается когда объектно-ориентированный кот декларативно параметризируется. Для этого правда нужны классы и полноценный механизм шаблонов.

2

Сообщение от IRIP Здравствуйте! Почему все так сложно в мире программирования, казалось бы простом?

Если руки растут откуда надо, то все просто. А если нет, то уж извините - Ваши проблемы.

0