Комментарии 57
Принципиально новые подходы существуют, но большинство о них не знает и, возможно, не осилит.
Причем и новые (8.3 УФ с веб-клиент/МП/МК новье)
И «большинство не знают»
И к сожалению на данный момент «не осилят», сейчас проще Python c Golang освоить чем полный стек 1С.
Платформа 1С на данный момент это кроссплатформенная (win/lin/macos/веб-клиент/android/ios) разработка приложений с единой кодовой базой.
С кучей плюшек и платформенных механизмов для удобной и быстрой разработки.
Только лицензирование слегка подкачало но для мобильных приложений полегче.
1С всегда был нишевым продуктом. И нишевым умрёт. Может 1С и идеальна, исключителтно в определённой области, но тут по-моему вопрос вообще некорректный. Вроде как "какой должна быть идеальная цепь развития у ручных инструментов (плотника, сварщика, электрика)?". На поставленный вопрос нет однозначного ответа и скорее всего никогда не будет. Вопрос на пофилософствовать разве что.
Хочу программу.
Какую?
Навороченную.
Кто будет пользоваться?
Все.
Ок, компилирую, ожидайте...
Это аннотация к книге Д. Крокфорда "JavaScript: сильные стороны":
В этой книге среди множества самых ужасных JavaScript-конструкций выделены наиболее надежные, понятные и удобные в сопровождении — то подмножество языка, которое позволяет создавать по-настоящему расширяемый и эффективный код. ©
Возможно, путь разработчиков языка — сделать его максимально гибким, а путь разработчиков приложений — выбрать из всех возможностей языка те, что наилучшим образом подходят для конкретной предметной области. Причём в зависимости от области набор отобранных возможностей может изменяться (асинхрон или многопоточность, например).
Другими словами, разработчики языка вынуждены реализовывать обратную совместимость (естественно), что практически всегда выливаться в усложнение, не зависимо от того, будут эти возможности использоваться или нет. Соответственно и изучать эти возможности так же нужно, даже если они и не входят в набор отобранных для текущего использования.
И это нормально — другой проект, другая предметная область, другие требования к языку. Как разработчик, ты должен знать (желательно) все возможности языка, а какие из них применять в конкретном проекте — это решает команда (делегирует это решение тимлиду).
Google, например, предпочитает использовать расширение *.js для всех исходников и игнорирует возможность использования расширений *.mjs для ES6-модулей.
В программировании самое сложное смириться с тем, что твоя работа устарела уже сегодня, а лучший твой код проработает от силы лет 10-20. Так себе продолжительность по сравнению с результатом работы строителей хотя бы Нотр-Дам-де-Пари, не говоря уже о строителях египетских пирамид. На этом фоне переключиться на другое подмножество этого же языка — всё равно, что пересесть с БМВ на Мерседес или наоборот. Если вы ищете стабильность или хотя бы рациональность, то программирование — это явно не то место, где всё это обитает. Так сложилось исторически...
this, а с другой стороны учат никогда не пользоваться this − это архитектурная проблема языка.Или хотя бы отключать некоторые их них с помощью опций компилятора.
Именно к языку. Попробуйте использовать import в *.cjs файлах.
(node:36993) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.Стиль оформления — это отступы, переносы, CamelCase/snake_case и т.п. Это цвет машины, согласен. А какие возможности языка использовать в проекте (использовать this или нет, ФП или ООП) — это уже не оформление кода. Я бы сравнил с приводом — задний/передний/полный. Или с КПП — автомат или механика. Да, ездить можно, но придётся подстраиваться, особенно поначалу.
Так какие там были улучшения в ЯП в последние годы? Поддержка многопоточности? Увеличение производительности?
Короче, надо прекращать утрировать. Однако же какова цель — это правильный вопрос.
Ответ: цель — постоянное совершенствование в соответствии с запросами и вызовами. Конкретно ничего нельзя сказать, просто улучшение во имя чего-либо. Причина улучшений — это неидеальность языка изначально.
Но и про изначальную «не идеальность» тоже говорить как-то неправильно. Если ЯП выражает некие алгоритмические концепции, известные разработчикам на момент создания языка, то это не «не идеальность».
Короче, ответ «не париться» :-)
По моим наблюдениям примерно до 90-х годов многие языки выбирались из-за буквально одной «киллер-фичи», по нынешним временам не очень масштабной: простота, скорость, продвинутая математическая библиотека, средства работы с графикой, развитые инструменты.
В наше время стоит появиться чему-нибудь интересному где угодно, как тут же начинается прессинг: «а почему нам Х не завезли?» Ну вот в конечном итоге и завозят всё и везде. Конечно, исходное «ДНК» языков отличается, и Python не будет C++, а C++ не будет Haskell'ем, но так или иначе всё больше речь идёт о вкусах и предпочтениях, а не о реальных возможностях, которые где-то точно есть, а где-то ну никак.
Ну и, соответственно, абсолютно все языки усложняются. Вот с чем плохо, так это с простотой. Сначала Бейсик был «простой» альтернативой, потом Java, потом Python. Теперь уже нет. А если кто предлагает что-то новое «простое», можете не сомневаться, что это ненадолго.
В целом согласен. Мысль «а почему нам это не завезли» появляется, как мне кажется, вполне естественно. Т.к. языки это средство выражения логики через код. Мы мыслим образами и концепциями, а не кодом. Соответственно если кто-то сформулировал концепцию «абстракции», то понятно, что ты захочешь это использовать, потому что удобно.
Тут проглядывается аналогия с обычными языками: они разные, где-то при произношении нужно щёлкать языком, где-то подлежащее строго в начале предложения, но в целом, они похожи, т.к. реализуют общие концепции.
В отличие же от естественных языков, языки программирования по своей природе интернациональны. Именно этот вывод напрашивается в результате обсуждения другой статьи про Интернациональное программирование на естественных языках
Любой язык программирования является интернациональным, т.к. его синтаксис не зависит от естественного языка, на котором общается программист.
А если текст программы будет на «естественном» языке, то она станет понятной только для знающих этот язык, одновременно становясь непонятной для всех остальных.
Если вспомнить Microsoft с их Embrace, Extend, and Extinguish применительно к JS, то если специально вносить измерения в язык, чтобы захватить и единолично править его экосистемой, то согласитесь, ведь это не имеет ничего общего с «куда надо стремиться»?
Но это, скажем так, «исходное ДНК». А дальше если авторам хочется, чтобы язык оставался на плаву, приходится следовать общей логике потока.
Думаю, что тенденция усложнения справедлива и для языков программирования. Так что я в сами согласен,
чтобы язык оставался на плаву, приходится следовать общей логике потока.
К сожалению, гипотеза не доказана, более того, имеется по меньшей степени один контр-пример.
Существование того или иного естественного языка ещё не обозначает, что мышление на нём приводит к решению основных проблем существования. Вполне возможно, что как раз наоборот, языки возникшие и развивавшиеся в условиях повторяющихся типичных задач некоего этноса, могли накапливать ошибки и блокировать невыгодные в конкретных условиях решения, на уровне семантики языка. И в силу самой семантики вновь попадать в аналогичные ситуации закрепляя ошибку взаимодействия с другими этносами.
К тому же сама естественность развития естественных языков, ещё требует точного отделения от целенаправленных политических решений.
Иначе говоря, такой мощный инструмент формирования мышления, а следовательно познания мира, как язык (программирования) должен строиться от общих задач человечества, а не от частных выгод закреплённых в паттернах мышления исторически.
можно предположить существование некоего «естественного» языка программирования, который будет интуитивно понятен и прост в понимании, к которому мы и должны стремиться.
Этот естественный язык программирования — картинка. Показываем визуально что хотим, и компьютер пытается понять логику. Доступно всем людям.
Похоже на обучение нейросети, но при этом будет и обратная уточняющая связь от неё.
Сейчас разрабатываю такую нейросеть и надеюсь в будущем опубликовать на Хабре про это.
Нейросеть безусловна нужна, но она не должна быть центральной частью всей системы. Это только один из способов реализации отдельных алгоритмов, и не более. В некоторых случаях гораздо проще формальный — алгоритмический подход.
Идеал текстовых языков программирования — литературное программирование.
Идеал программирования — человек получает то, что хотел. Раз мысли пока читать не умеем, то лучший способ объяснить компьютеру что хотим — визуальное общение.
Удобно написать — пиши, удобнее сказать — скажи, удобнее показать на примере — покажи.
Человек не всегда выдерживает объяснять другому человеку ("Левее..." "Теперь чуть правее." "Нет, не так"), читать-писать тем более не любит. Обычно берёт и показывает, или рисует.
Для слов и текста потребуется более сложная нейросеть, чем для графики.
Вход — универсальй, а на выходе что?
Ничего не понял. Что за "приземлять"? Что за входы-выходы?
А компьютеру нужен машинный код, который будет выполняться. Как получить машинный код из выходных данных нейросети? Это будет «выход».
Из-за сложности с голосом, текстом, жестами и чем там ещё не только для нейросети, но и для самого человека, эти варианты не рассматриваю.
Картинка — вот что понятнее и проще.
Показываем нейросети круг. Теперь нажимаем нужную клавишу/кнопку и двигаем кругом в нужном направлении. Так учим нейросеть, что хотим, чтобы при нажатии круг двигался в нужном направлении.
А как получит код из нейросети — это ведь уже техническая часть. А статья и обсуждение — больше теоретическая, может даже философская.
А как получит код из нейросети — это ведь уже техническая часть. А статья и обсуждение — больше теоретическая, может даже философская.Я боюсь, что вот как раз на этом этапе и возникнут проблемы.
Пониманию, что сама статья теоретическая, просто я уже давно перешел к практической стороне и после этого пришлось пересматривать начальные задумки.
Надеюсь, что у вас такой проблемы не возникнет.
Где-то можно ознакомиться с вашими работами?
Сейчас доделывают компиляторв в исполняемый код, поле чего можно будет открыть первую версию.
Как будет готово (думаю через 2-3 месяца), могу дать ранний доступ еще до основной публикации в качестве первого внешнего ревьювера.
Уже можно https://habr.com/ru/post/681960/
Какая «идеальная» цель развития у языков программирования?