Как стать автором
Обновить

Комментарии 56

Принципиально новые подходы существуют, но большинство о них не знает и, возможно, не осилит.

Например?
И что 1С?
Платформа 1С это пример «Принципиально новые подходы существуют, но большинство о них не знает и, возможно, не осилит»
Причем и новые (8.3 УФ с веб-клиент/МП/МК новье)
И «большинство не знают»
И к сожалению на данный момент «не осилят», сейчас проще Python c Golang освоить чем полный стек 1С.
Извините, я не понял вашего сарказма.
Это не сарказм а реальность.
Платформа 1С на данный момент это кроссплатформенная (win/lin/macos/веб-клиент/android/ios) разработка приложений с единой кодовой базой.
С кучей плюшек и платформенных механизмов для удобной и быстрой разработки.
Только лицензирование слегка подкачало но для мобильных приложений полегче.
1С? Принципиально новый подход? Извините, вы в каком-то параллельном мире живёте? Пожалуйста, скажите, что это просто затянувшаяся шутка :-)

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

Хочу программу.
Какую?
Навороченную.
Кто будет пользоваться?
Все.
Ок, компилирую, ожидайте...
В таком примере больше вопросов к постановке требований к разработке ПО, а не к языку программирования, который вообще отсутствует.

А чем это не язык программирования?
Я даже название ему придумал: AnyTZCompiler.
Его ещё просто не реализовали. А после реализации? Может это и есть та самая вершина "идеальной цепи развития"?

Сделай, чтобы было «хорошо» :-)

Это аннотация к книге Д. Крокфорда "JavaScript: сильные стороны":


В этой книге среди множества самых ужасных JavaScript-конструкций выделены наиболее надежные, понятные и удобные в сопровождении — то подмножество языка, которое позволяет создавать по-настоящему расширяемый и эффективный код. ©


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

Конечно, можно ограничить возможности языка на уровне CodeStyle, например, «не выше C++11». Но это используется, как правило, только для обеспечения обратной совместимости с легаси кодом. А обычно ограничения делают «не ниже чем», например, начиная с версии Python 3.5 и выше.

Другими словами, разработчики языка вынуждены реализовывать обратную совместимость (естественно), что практически всегда выливаться в усложнение, не зависимо от того, будут эти возможности использоваться или нет. Соответственно и изучать эти возможности так же нужно, даже если они и не входят в набор отобранных для текущего использования.
Не выше Visual Studio 6 SP5 + Processor Pack
Все зависит от конкретного проекта и его зависимостей.
Особенно хорошо получается, когда ты отбираешь одни возможности языка, а потом приходишь в проект, где тимлид отобрал совсем другие.

И это нормально — другой проект, другая предметная область, другие требования к языку. Как разработчик, ты должен знать (желательно) все возможности языка, а какие из них применять в конкретном проекте — это решает команда (делегирует это решение тимлиду).


Google, например, предпочитает использовать расширение *.js для всех исходников и игнорирует возможность использования расширений *.mjs для ES6-модулей.


В программировании самое сложное смириться с тем, что твоя работа устарела уже сегодня, а лучший твой код проработает от силы лет 10-20. Так себе продолжительность по сравнению с результатом работы строителей хотя бы Нотр-Дам-де-Пари, не говоря уже о строителях египетских пирамид. На этом фоне переключиться на другое подмножество этого же языка — всё равно, что пересесть с БМВ на Мерседес или наоборот. Если вы ищете стабильность или хотя бы рациональность, то программирование — это явно не то место, где всё это обитает. Так сложилось исторически...

А мне кажется, нормально пользоваться языком, в котором все возможности одинаково необходимы и ничего лишнего нет. А когда с одной стороны тебя учат, как правильно пользоваться this, а с другой стороны учат никогда не пользоваться this − это архитектурная проблема языка.
Мне тоже так кажется. Может быть имеет смысл, например раз в десятилетие пересматривать старые стандарты и убирать их из языка.

Или хотя бы отключать некоторые их них с помощью опций компилятора.
Тогда у вас будет один вид развития экосистемы. Что-то вроде Питона, где пересмотрели и убрали, и теперь все сидят только на Python 3.х (oh, wait...) А можно идти путём C++ и убирать только в самом крайнем случае — это другая концепция и другая траектория развития.
Ну так язык программирования, это не только синтаксис. Это действительно экосистема, и дополнитенльные модули/библиотеки, инструменты, редакторы кода, но самое главное люди, которые делают все это.
Это больше относится к стилю оформления кода, а не к самому языку. Например, неважно какая марка, БМВ или Мерседес, но обязательно черного цвета.

Именно к языку. Попробуйте использовать 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, то если специально вносить измерения в язык, чтобы захватить и единолично править его экосистемой, то согласитесь, ведь это не имеет ничего общего с «куда надо стремиться»?
Ну это вы переходите от общего к частному. У автора конкретного языка, разумеется, есть конкретная цель, ради которого этот язык и создавался. И тут возможны самые разные варианты: сделать «C с классами» (C++), «свою Java» (C#), «чтобы и мартышка разобралась» (Go) и т.д. Не может же быть так, чтобы у всех цель была одна и та же.

Но это, скажем так, «исходное ДНК». А дальше если авторам хочется, чтобы язык оставался на плаву, приходится следовать общей логике потока.
И да, и нет. Цели безусловно у всех будут разные. Но есть общая динамика от которой не уйти, если хочется шагать в ногу со временем. Как простой пример Разработчик оценил сложность современных браузеров

Думаю, что тенденция усложнения справедлива и для языков программирования. Так что я в сами согласен,
чтобы язык оставался на плаву, приходится следовать общей логике потока.
Вообще с этим есть проблема: высокий порог входа. Раньше был условный Бейсик для начинающих, а сейчас ничего нет. В 2007 году был комикс на XKCD про «Python: programming is fun again». А сейчас уже так себе «fun» — ну то есть всё равно проще C++, но и не прогулочка по парку. Да и IDE одна сложнее другой: просто написать программу, запустить и выполнить по шагам уже нетривиально. Не знаю, что с этим делать. Ничего, наверно — у каждого поколения свои сложности.
Отталкиваясь от известной гипотезы Ноара Хомского о существовании неких глубинных структур естественных языков, отвечающих строению мозга человека, можно предположить существование некоего «естественного» языка программирования, который будет интуитивно понятен и прост в понимании, к которому мы и должны стремиться.
К сожалению, гипотеза не доказана, более того, имеется по меньшей степени один контр-пример.
А что за контр-пример?
Обнаружено племя-изолят, в языке которого нет средств для рекурсии, а Хомский считал ее естественной и необходимой (была статья на Хабре от этом).
Если я правильно понял, то это не противоречит утверждению
о существовании неких глубинных структур естественных языков, отвечающих строению мозга человека
а только лишь то, что рекурсия не является обязательной для «естетвенного» языка.
Скорей всего это и есть идеальная задача. Если учесть, современные исследования о том, что и естественные языки формируют мышление их носителей, тогда задача становится сверх интересной! Могу ошибаться, но основы популярных языков программирования так или иначе завязаны рамками дуального мышления и инструментами мышления представленными английским языком. Получается, что если ставить задачу совместимости с уже имеющимся, то дальнейшее развитие так и останется на этой базе. Со всеми вытекающими.
Существование того или иного естественного языка ещё не обозначает, что мышление на нём приводит к решению основных проблем существования. Вполне возможно, что как раз наоборот, языки возникшие и развивавшиеся в условиях повторяющихся типичных задач некоего этноса, могли накапливать ошибки и блокировать невыгодные в конкретных условиях решения, на уровне семантики языка. И в силу самой семантики вновь попадать в аналогичные ситуации закрепляя ошибку взаимодействия с другими этносами.
К тому же сама естественность развития естественных языков, ещё требует точного отделения от целенаправленных политических решений.
Иначе говоря, такой мощный инструмент формирования мышления, а следовательно познания мира, как язык (программирования) должен строиться от общих задач человечества, а не от частных выгод закреплённых в паттернах мышления исторически.
можно предположить существование некоего «естественного» языка программирования, который будет интуитивно понятен и прост в понимании, к которому мы и должны стремиться.

Этот естественный язык программирования — картинка. Показываем визуально что хотим, и компьютер пытается понять логику. Доступно всем людям.
Похоже на обучение нейросети, но при этом будет и обратная уточняющая связь от неё.
Сейчас разрабатываю такую нейросеть и надеюсь в будущем опубликовать на Хабре про это.

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

Идеал текстовых языков программирования — литературное программирование.
Идеал программирования — человек получает то, что хотел. Раз мысли пока читать не умеем, то лучший способ объяснить компьютеру что хотим — визуальное общение.

Тогда уж идеал языков программирования, это вообще не зависеть от способа программирования.
Удобно написать — пиши, удобнее сказать — скажи, удобнее показать на примере — покажи.

Человек не всегда выдерживает объяснять другому человеку ("Левее..." "Теперь чуть правее." "Нет, не так"), читать-писать тем более не любит. Обычно берёт и показывает, или рисует.
Для слов и текста потребуется более сложная нейросеть, чем для графики.

Вы говорите все правильно, но немного выше я написал немного про другое. Если говорить про язык программирования, то на что вы его собираетесь «приземлять»?
Вход — универсальй, а на выходе что?

Ничего не понял. Что за "приземлять"? Что за входы-выходы?

Ну вот вы сделали нейросеть, которая умеет интерпретировать желания человека (голос, жесты и т.д.). Это будет «вход».
А компьютеру нужен машинный код, который будет выполняться. Как получить машинный код из выходных данных нейросети? Это будет «выход».

Из-за сложности с голосом, текстом, жестами и чем там ещё не только для нейросети, но и для самого человека, эти варианты не рассматриваю.
Картинка — вот что понятнее и проще.
Показываем нейросети круг. Теперь нажимаем нужную клавишу/кнопку и двигаем кругом в нужном направлении. Так учим нейросеть, что хотим, чтобы при нажатии круг двигался в нужном направлении.
А как получит код из нейросети — это ведь уже техническая часть. А статья и обсуждение — больше теоретическая, может даже философская.

А как получит код из нейросети — это ведь уже техническая часть. А статья и обсуждение — больше теоретическая, может даже философская.
Я боюсь, что вот как раз на этом этапе и возникнут проблемы.
Пониманию, что сама статья теоретическая, просто я уже давно перешел к практической стороне и после этого пришлось пересматривать начальные задумки.
Надеюсь, что у вас такой проблемы не возникнет.

Где-то можно ознакомиться с вашими работами?

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

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

Как будет готово (думаю через 2-3 месяца), могу дать ранний доступ еще до основной публикации в качестве первого внешнего ревьювера.
языков уже очень много по напридумано, если посмотреть на задачу исторически то каждый следущий уровень вставал на плечи предыдущих. Машинные коды — ассемблер — макроасемблер — компиляторы(с++) — интерпретаторы(питон) — кодогенератры(визарды всякие, конструкторы сайтов)… дальше очевидно должны быть программы создатели кодогенераторов
дальше очевидно должны быть программы создатели кодогенераторов
Безусловно! Сейчас практически невозможно силами небольшого коллектива разработать язык программирования уровня Python или C++.
Более того, мне кажется, что за счет «кодогенераторов» или LLVM это делать уже совершенно ненужно.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.