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

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

Например, чтобы написать приложение на 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, java C# F# во первых являться универсальным немогут по определению. Все это узконишевые языки. А в главных имеют слишком урезанные языковые средства по сравнению с С++ поэтому не могут в плане лаконичности с плюсами конкурировать по определению.

1

Fulcrum_013, перечисленные выше языки являются языками общего назначения. Вся их "ограниченность" исключительно в их управляемой природе. Да, драйверов на них не напишешь, да и числодробильный код будет уступать неуправляемым языкам, но "нишевыми" их это не делает.

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

Сообщение от Fulcrum_013 К примеру код перенасыщенный лямбдами.

А язык тут причём?

0

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

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

Сообщение от Usaga А язык тут причём?

В ФП-языках при всем богатстве выбора альтернативы лямбде с замыканием нет.

1

Fulcrum_013, очередная порция херни. Всё как обычно. Спасибо, вы не подводите.

0

Usaga, Ну продемонстрируйте локанизм шарпа в действии вместо голословных заявлений. Только на крупном проекте. В 10 тыс строк то что на плюсах в такой объем вкладывается никогда не вложите по определению.

0

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

Но вы могли бы привести простой сравнительный пример лАконичного выражения на плюсах и соответстующего на шарпе\яве\что-угодно и показать всё наглядно. И с GC мне тоже хотелось бы увидеть подтверждение ваших слов.

1

Usaga, Дак в том то и дело что у вас все голословно. А соскакивать с темы в духе все проприентарно можно сколько угодно.
Ну давайте так выразите на шарпе что нибудь простенькое. К примеру оконный ООП-фреймверк оборачивающий стандартные контролы винды. У меня пока что в пределах 1000 строк, хотя конечно еще не все настройки контролов поддерживаются (типа шрифта цвета и т.п). Ну да то мелочи. Откатаю до конца связность структуры данных, то все моментом и мизером кода появится. Вчерась часть обработки инфраструктуры связей на боковики автомата вычистки висячих ссылок вынес. Выкинул процентов 50 кода в результате. Просто выкинул а не заменил на что то, при сохранении той же функциональности. Шарп такие абстракции делать если и позволит то сильно затруднит реализацию.

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

Сообщение от Usaga И с GC мне тоже хотелось бы увидеть подтверждение ваших слов.

А GC в таких инфраструктурах вообще штука бесполезная. Представьте себе древовидную структуру которая растет от рута. Каждый нод имеет указатель на всех потомков и на предка. Указатель на предка в обязаловке дается при выделении нода и при этом автоматом (в конструкторе) указатель на нод заносится в список нодов предка. Очевидно что в такой структуре GC ничего убрать не в состоянии в принципе, поскольку все объекты структуры данных всегда имеют трассу на рут, а соответственно для того чтобы GC мог их собрать потребуется вручную разрывать взаимосвязи. Это в принципе ничем от вызова delete не отличается, кроме невозможности организовать автомат разрыва взаимосвязей в автоматически вызываемом деструкторе.

0

Fulcrum_013, я не соскакивал. Я прямо попросил: обоснуйте свои утверждения о том, что всё кроме С++ - говно. Это вы с меня начали какие-то крупные проекты и фреймворки требовать. Я очень хочу от вас, как автора голословщины (я так считаю, уж извините), увидеть сравнительные примеры.

Пока что ничего нет. И не особо надеюсь видеть. Просто потому, что вы и не используете ничего кроме С++ (что нормально). Но тогда ваши утверждения основаны на ваших же домыслах и субъективного негативного отношения ко всему, что не имеет двух плюсов в названии (что уже не нормально).

Сообщение от Fulcrum_013 Представьте себе древовидную структуру которая растет от рута.

Представил. Если на ноды есть ссылки, то GC не имеет права ничего тут удалять. Всё честно. В каком месте вы увидели подвох?

0

Usaga, Подвох в том что других структур данных в не найдете днем с огнем. Это исходит из того что в любой предметной области существует подобная древовидная группировка объектов без которой объекты не имеют смысла. Т.е. к примеру бессмысленно существование линий чертежа без содержащего их объекта чертеж, бессмысленно существование объекта "поле БД" без содержащего его объекта "таблица БД" и т.д. Соответсвенно бессмыслено и существование GC. Он по большому счету не в состоянии решить проблему утечек поскольку не знает критериев возможности существования объектов в предметной области. Мало того только ведет к проблемам с утечками вынуждая использовать кучу вместо стека, и затрудня создание автоматов разрыва взаимосвязей.
Касательно же другой полезной функции GC - а именно дефрагментации - то в подобных структурах объекты имеют свойства выделяться по оддному при этом локальность данных пр обработке не достижима в принципе. Соответственно наиболее оптимальным решением для ускорения выделения памяти будет не дефрагментация а типизированные пулы константного распределения. Но как бы самый простой способ их реализации - перегрузка операторов new и delete что GC напрочь исключает.

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

Сообщение от Usaga Просто потому, что вы и не используете ничего кроме С++ (что нормально)

Вот потому и использую преимущественно С++ потому что C++ не ограничивает программиста в использовании высокоуровневых абстракций чем и достигается высокая локаничность. JS и PHP пользовать тоже приходилось, так же как и другие универсальные (нативные) языки, так что материал для сравнения есть.

Добавлено через 10 минут
Usaga, Для начала обоснуйте свои утверждения о том что Java, которая не имеет вообще никаких языковы средств ,типа перегрузки операторов, свойств и делегатов, может быть локаничнее зыков которые эти средства имеют. С шарпом же разговор отдельный. Там огромные потери локаничности будут именно в следствие отсутствия автоматической генерации и вызова деструкторов. Это кстати причина по которой паскаль/дельфа и остальные паскалеподобные языки не могут быть настолько лаконичным насколько плюсы, хотя помех со стороны GC не имеет. То же самое касательно дженериков которые сильно урезаны по возможностям по сравнению с полноценными шаблонами. Так что голословщиной на самом деле занимаетесь вы.

0

Сообщение от Fulcrum_013 java C# F# во первых являться универсальным немогут по определению

Нет такого определения.

Сообщение от Fulcrum_013 А в главных имеют слишком урезанные языковые средства по сравнению с С++ поэтому не могут в плане лаконичности с плюсами конкурировать по определению.

И такого определения нет.

Давайте, например, напишем тип данных "дерево" и универсальную функцию обхода для него. А потом посмотрим, во сколько раз на С++ больше кода потребуется - в пять или в десять.

0

Сообщение от Shamil1 Нет такого определения.

Есть. Поскольку GC имеет противопоказания к применению то эти же противопоказания имеют и все имеющие его языки. А то что не может использоваться где угодно не может называться универсальным. Т.е. все языки имеющие GC по определению узконишевые языки околовсяческого назначения.

1

Сообщение от Fulcrum_013 Подвох в том что других структур данных в не найдете днем с огнем. Это исходит из того что в любой предметной области существует подобная древовидная группировка объектов без которой объекты не имеют смысла. Т.е. к примеру бессмысленно существование линий чертежа без содержащего их объекта чертеж, бессмысленно существование объекта "поле БД" без содержащего его объекта "таблица БД" и т.д.

Из того, что линия чертежа содержится в чертеже вовсе не следует, что тип данных "линия чертежа" должен содержать ссылку на тип данных "чертёж". Или Вы считаете, что в каждом узле дерева обязательно должна быть ссылка на дерево?

Сообщение от Fulcrum_013 перегрузка операторов new и delete что GC напрочь исключает.

Вместо перегрузки оператора new пишем функцию, которая создаёт объекты.
Оператор delete обычно вообще не нужен. Но если требуется освобождать какие-то системные ресурсы (кроме памяти), то пишем метод Dispose.
Из того, что Вы не знаете, как задача решается на другом ЯП, вовсе не следует, что она не имеет решения.

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

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

Ни один язык не может использоваться "где угодно". На С++ Вы не сможете написать программу для Java-машины или запрос к БД типа MS SQL.

Универсальный - значит подходящий для большинства задач.

1

Сообщение от Shamil1 Из того, что линия чертежа содержится в чертеже вовсе не следует, что тип данных "линия чертежа" должен содержать ссылку на тип данных "чертёж"

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

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

И вызываете его вручную. Браво. И это в ситуации когда ноде даже не известен точный тип дочерних нод. Для корректной разборки придется иметь Dispose у всего и вся и вызывать его в ручную. В чем отличие от деструкторов, кроме того что деструкторы для подобного обхода сгенерируются автоматически?

Сообщение от Shamil1 Оператор delete обычно вообще не нужен.

Если есть new который берет объекты из пула должен быть и delete который их в тот же пул возвращает. т.е. придется еще и функцию free написать. В общем паскалем воняет от вашего шарпа во всю. В принципе учитывая кто автор сей поделки в этом нет ничего удивительного. Но и ничего хорошего. Рожденный паскалить абстракции строить не может.

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

Сообщение от Shamil1 На С++ Вы не сможете написать программу для Java-машины или запрос к БД типа MS SQL.

Для джава-машины можно но не нужно. Выходной таргет от языка вообще то не зависит. Вообще байткода той или иной ВМ пользуется многими компиляторам в качестве промежуточного представления. Clang к примеру компилит через байт-код LLVM.
А с каких пор SQL стал языком программирования? Давайте не будем путать языки программирования с языками описания данных.

2

Сообщение от Fulcrum_013 Даже если обратной ссылки не будет GC все равно удалить ничего не сможет. На самом деле нужны ссылки не на дерево а на каждого ссылающегося, для обеспечения разрыва взаимосвязей при принудительном удалении.

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

Сообщение от Fulcrum_013 И вызываете его вручную.

Зачем в ручную? В одном месте вместо "let" надо написать "use".
(когда исполнение выйдет за пределы блока, где определена переменная resp, автоматически вызовется метод Dispose)

Сообщение от Fulcrum_013 Для корректной разборки придется иметь

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

Сообщение от Fulcrum_013 Если есть new который берет объекты из пула должен быть и delete который их в тот же пул возвращает.

Повторюсь:
Если кто-то не умеет по-другому, то ему, конечно, придётся. Ну а тот, кто умеет программировать, обойдётся без этого.

0

Shamil1, Во первых ссылок у вас будет массивчик. А во вторых жить он будет в другом объекте. посему let и use там не проканают.

0

Сообщение от Fulcrum_013 Для джава-машины можно но не нужно.

Чтобы не быть голословным, напишите мне простейший класс для джава-машины.

Сообщение от Fulcrum_013 Выходной таргет от языка вообще то не зависит.

Если так рассуждать, то можно использовать F# для любой задачи. Достаточно написать соответствующий компилятор. Поэтому давайте ограничимся тем, что можно прямо сейчас.

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

Во-первых, data definition language (DDL) - это всего лишь одна из составных частей SQL.
Во-вторых, не уходите от ответа. Признайте, что Вы не можете на С++ написать запрос к БД. (Только не предлагайте вариант "сначала написать свою СУБД на С++").

0

Shamil1 экзамен принимаете, нуну )). Почему бы просто не признать что Fulcrum_013 больше Вашего разбирается.

0

Сообщение от Fulcrum_013 Во первых ссылок у вас будет массивчик. А во вторых жить он будет в другом объекте. посему let и use там не проканают.

Что и как у меня будет, я сам решу, в зависимости от задачи.

Для меня Ваши аргументы выглядят примерно так:
"Отверстие в доске можно сделать только гвоздём, а сверлом нельзя. Я беру гвоздь и несколько раз бью по нему молотком, затем вытаскиваю гвоздь - и отверстие готово. А сколько ни бей по сверлу молотком, отверстие не сделаешь."
И как мне убедить Вас, что бить молотком - это не единственный способ делать отверстия?

2

Сообщение от Redee экзамен принимаете

Нет. Просто констатирую факт, что на С++ нельзя сделать то, что на Java или SQL делается за 5 минут. Ну и предлагаю опровергнуть меня, если я вдруг неправ.

Сообщение от Redee Почему бы просто не признать что Fulcrum_013 больше Вашего разбирается.

В чём?

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

Сообщение от Shamil1 Просто констатирую факт, что на С++ нельзя сделать то, что на Java или SQL делается за 5 минут.

И делаю я это не с целью доказать, что С++ не является универсальным ЯП (он является), а чтобы объяснить, что Fulcrum_013 неправильно понимает определение универсальности. Или намеренно подгоняет определение под ответ (см. Истинный шотландец)

1

Не знаю в этих "священных войнах" получаю в разы больше конструктивной информации именно от Fulcrum_013. Так что польза от дискуссий все таки есть, даже в таком ключе ).

1