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

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

Например, чтобы написать приложение на 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, На С++ можно сделать абсолютно все. А вот на джаве далеко не все. И далеко не всегда.

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

Сообщение от Shamil1 В чём?

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

2

Сообщение от Fulcrum_013 На С++ можно сделать абсолютно все.

Я предлагал Вам решить две пятиминутные задачи (по 5 строк кода). Вы не можете их решить на С++.

Сообщение от Fulcrum_013 А вот на джаве далеко не все.

Я согласен, что есть вещи, которые нельзя сделать на Java. Но из этого не следует, что Java не является универсальным ЯП общего назначения.

Сообщение от Fulcrum_013 Так я оконный фреймверк на шарпе сегодня увижу или нет?

Я не знаю, какой смысл Вы вкладываете в определение "оконный фреймверк".
Насколько я понял, на С++ код занимает 1000 строк. А его написание потребовало недели или даже месяцы времени. Причём, по ходу разработки Вы несколько раз проводили глобальный рефакторинг. И Вы хотите, что бы я написал всё это за пару часов? Написать оконный фреймворк на C# не является принципиальной проблемой, но займёт много времени (точно больше двух часов).

Я от Вас не дождался даже кода Дерево + обход Дерева. Это меньше 10 строк на F#.

2

Сообщение от Shamil1 Написать оконный фреймворк на C# не является принципиальной проблемой,

АЖ настолько что борланд такие попытки признала неперспективными

1

Может не путать понятия язык и стандартные библиотеки к нему. Да в "стандартах" к плюсам есть "свинушка" - STL называется.

0

Сообщение от Shamil1 Я от Вас не дождался даже кода Дерево + обход Дерева. Это меньше 10 строк на F#.

Мне б ваши проблемы. На самом деле задача в том чтобы его вообще не обходить а само жило своей жизнью. При этом деревьев обычно как минимум два - дерево владения и дерево вложенности. При этом у каждой ноды еще списки подчиненные списку потомков вложенности существуют. Интересно сделать жизнь этих списков параметризируемым на уровне класса "взаимосвязь" c обеспечением автоматической переброски из всех списков в в списки другой ноды по перестановке в дереве вложенности. Так оно конечно делается но это куча однотипного кода на каждом уровне абстракции. Хотя поменьше чем в VCL. Но для быстрого наращивания дальнейшей номенклатуры лучше все таки проработать именно абстракции таких взаимосвязей. Их в принципе всего 4 типа вырисовывается - неизменяемая связь, изменяемая связь и подчиненных связей 2 типа (списки списков обработки в двух вариантах - с нахождением в одном из списков по селектору и с нахождением в любом из списков набора). Реализовал пока что только 2 основных это уже существующий код сократило в 2 раза. Те 2 типа тоже в свое время реализовывал. Но в немного урезанном виде - расширение номенклатуры списков при наследовании было невозможно. Но даже такая реализация в 40 строк сделанная за 2 часа инфраструктурный код движка визуализации сцены и движка анимации сократила практически до нуля, осталась в нем только голая математика. Вот теперя универсал мучаю. Оконный фреймверк это по большому счету не более чем площадка для обкатки абстракции связей.

2

ну а если посмотреть дальше?

универсальные платформы для разработки универсальных приложений которые будут работать НА ЛЮБОМ устройсве

0

Смотря что хочешь получить - ну есть уже давно .NET(С#), Java - основной плюс что код работает на любых устройствах где есть эта Платформа.
Минусы - сборщик мусора оно же Garbage Collector оно же GC, ограниченные в своих возможностях языки, Меньшая скорость исполнения нежели у компилируемых языков.

0

Сообщение от Fulcrum_013 Мне б ваши проблемы.

Это не проблема, а примитивная задача. И даже такая задача на С++ требует сотню строк кода, а на F# - меньше десяти. Это к вопросу о лаконичности С++.

Сообщение от Fulcrum_013 АЖ настолько что борланд такие попытки признала неперспективными

Я не знаю, что там борланд признала, но Вы можете скачать в интернете несколько разных фреймворков для построения GUI.

0

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

Вы только учитывайте, что большая часть информации, предоставленной им в этой теме, не соответствует действительности.

0

Допустим самая известная криптовалюта Биткон - его программное обеспечение Bitcoin Core - почему то на С++ же написано.
Напрашивается вопрос а почему - а потому что нужна Скорость и Надежность исполнения.

Добавлено через 14 минут
Не говорю что C#/.Net совсем не понравился, там есть и нормальные, удобные вещи.
Просто НЕ надо тулить .Net везде и всюду - для чего то Хорошо, для чего то НЕТ, для чего то Категорически Противопоказано.

Добавлено через 5 минут
Возьмем теже более менее игровые движки Cry, Unreal - что видим ? Опять C++.
Что это показывает - где серьезные дела и требования к производительности там "плюсы".

Добавлено через 57 секунд
А Вы спрашиваете код когда "под ногами" уже есть все Примеры.

0

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

1

Сообщение от Redee Минусы - сборщик мусора

Сборщик мусора - это не только минус, но и плюс. Сборщик мусора даёт бОльшую надёжность в смысле секретности. Есть гарантия, что программа, которая не использует прямой доступ к памяти, не испортит память другого приложения.

Сообщение от Redee Меньшая скорость исполнения нежели у компилируемых языков.

C# - тоже компилируемый язык, поэтому Ваше высказывание некорректно.
Видимо, Вы имели ввиду языки, которые компилируются в нативный код. Но в общем случае это тоже неверно. Плюс компиляции в нативный код в том, что можно тратить очень много времени на компиляцию. Минус компиляции в нативный код в том, что нельзя использовать оптимизацию под конкретный процессор (кроме случая, когда собираетесь запускать её только на своём компьютере).

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

Сообщение от Redee Допустим самая известная криптовалюта Биткон - его программное обеспечение Bitcoin Core - почему то на С++ же написано. Напрашивается вопрос а почему - а потому что нужна Скорость и Надежность исполнения.

Напрашивается ответ - это случайное совпадение. Просто тот, кто писал это ПО лучше всего был знаком с C++.
Много примеров, когда крупные компании не устраивает надёжность языка С++. В результате появляются языки RPG (IBM), Erlang (Ericson), Go (Google). Кстати, обратите внимание, что это языки без прямого доступа к памяти. Так что сборщик мусора не является недостатком.

Сообщение от Redee Просто НЕ надо тулить .Net везде и всюду - для чего то Хорошо, для чего то НЕТ, для чего то Категорически Противопоказано.

Никто и не "тулит" .Net повсюду. Лично я не слышал, чтобы кто-то писал драйвера или код для микроконтроллеров на C#. Зато некоторые пытаются "тулить" повсюду С++. Даже туда, где другие языки лучше.

Сообщение от Redee Возьмем теже более менее игровые движки Cry, Unreal - что видим ? Опять C++. Что это показывает - где серьезные дела и требования к производительности там "плюсы".

Каким образом показывает? Так исторически сложилось.
Много банковского софта написано на RPG. Много вычислительного софта написано на FORTRAN (который, кстати, быстрее, чем С++). И так далее.

Сообщение от Redee А Вы спрашиваете код когда "под ногами" уже есть все Примеры.

Какой из этих примеров показывает, что С++ лаконичнее, чем F#?

ИМХО Ваша предвзятость не позволяет Вам трезво интерпретировать факты.

2

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

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

0

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

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

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

Сообщение от Shamil1 чем F#

На F# нету софта того масштаба что на плюсах. И не будет. Соответсвенно сравнить не получится.

1

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

Непонятно, как Вы считаете "количество приложений". И приравниваете ли Вы при этом приложение "Майкрософт Оффис" к десятистрочной програмульке, управляющий двумя светодиодами в чайнике?

ИМХО более правильно исходить из количества занятых программистов.
Возьмём, к примеру, завод, который производит самые современные российские ПЗРК. Сколько на нём работает программистов? Без учёта тех, которые пишут для бухгалтерии и планового отдела, шесть человек. Почему так мало? Потому что они занимаются в основном настройкой, доводкой, тестированием и поддержкой. Основной софт приходит в готовом виде из головного предприятия. А в головном предприятии, которое пишет софт не только для этого, но и для множества других изделий, которые производятся на других заводах, программистов целых 15 человек (опять не считая тех, кто в непроизводственных отделах).
А теперь возьмём, к примеру, Яндекс или Лабораторию Касперского. Сколько там программистов? Я уж не говорю о монстрах типа Гугл и Майкрософт.

0

Сообщение от Shamil1 Много банковского софта написано на RPG.

Дно индустрии.

Сообщение от Shamil1 Много вычислительного софта написано на FORTRAN

Предшественник С и плюсов все таки в деле универсальных языков. К сожалению для крупномасштабных задач очень мало пригоден. Но на относительно простых числодробилках для суперкомпов - зверем был и зверем будет.

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

Сообщение от Shamil1 Непонятно, как Вы считаете "количество приложений"

Да очень просто. Самый массовый софт живет в лампочке и коммутирует фазы.

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

Сообщение от Shamil1 Много примеров, когда крупные компании не устраивает надёжность языка С++. В результате появляются языки RPG (IBM), Erlang (Ericson), Go (Google).

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

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

Сообщение от Shamil1 что нельзя использовать оптимизацию под конкретный процессор

В софте управляющем оборудованием незнание конкретной конфигурации железа - диверсия.

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

Сообщение от Shamil1 Много банковского софта написано на RPG.

Банковский софт - это как раз аккурат над дном индустрии. Следующий после веб-дна слой.

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

Сообщение от Shamil1 Сколько там программистов?

А теперь давайте сравним общую рыночную стоимость промышленного софта и околовсяческого мелкософта. ДАй бог чтобы мелкомягкие до 1% дотянули вместе с гуглами амазонами и мелочью типа яндекса.

Добавлено через 4 минуты
Shamil1, Чем больше народу тем больше быдлокоду. Высокосложный софт толпой не делается а тем более по SCRUM AGILE и прочим методикам быдлокодинга. В сеерьезном софте рулят высокоуровневые абстракции. Поэтому количество разрабов относительно невелико. Велики з/п в следствии высокого выхлопа на человеко-час. Остальные не шмогли у ушли сайты клепать за копейки.

1

Сообщение от Shamil1 C# - тоже компилируемый язык, поэтому Ваше высказывание некорректно. Видимо, Вы имели ввиду языки, которые компилируются в нативный код. Но в общем случае это тоже неверно. Плюс компиляции в нативный код в том, что можно тратить очень много времени на компиляцию. Минус компиляции в нативный код в том, что нельзя использовать оптимизацию под конкретный процессор (кроме случая, когда собираетесь запускать её только на своём компьютере).

Изначально хотел уточнить что "плюсы" - компиляция в машинный код, видимо НЕ зря ).
Да компиляция в маш. код занимает больше времени, чем компиляция C# в промежуточный байткод.

1

Сообщение от Shamil1 Минус компиляции в нативный код в том, что нельзя использовать оптимизацию под конкретный процессор (кроме случая, когда собираетесь запускать её только на своём компьютере).

При этом JIT компиляция всегда будет уступать по качеству компайл-тайм оптимизации в следствие сильных ограничений на время работы JIT. Архитектура же компов меняется не на столько часто чтобы что то было настолько критичным. Да кстати докомпилировать в машкод при развертывании системы тоже в принципе никто не запрещает. Никаких реальных преимуществ у JIT быть не может. У него одно предназначение - торможение крутого железа для того чтобы стимулировать покупку еще более крутого.

0

Сообщение от Fulcrum_013 Дно индустрии.

Ваши представления о дне индустрии, универсальности, повышенной надёжности и т.д. не соответствуют действительности.

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

Давайте сравним. Только приводите цифры со ссылкой на достоверные источники.

0

Сообщение от Shamil1 Ваши представления о дне индустрии, универсальности, повышенной надёжности и т.д. не соответствуют действительности.

Если бы в банке в свое время не работа то так не говорил бы. это реально дно.
Shamil1,
Давайте. Начнем с цен на ОС. Винда офисная - 200 баксов. вина адаптированная сименсом под реалтайм - 50 килобаксов. Терминал путти - бесплатно. Терминалы промышленного назначения - от 25 килоевро. Прошивка пульта управления - это клавиатура с сотней светодиодов которые могут гореть или мигать - 12 килоевро.

1