LINUX.ORG.RU
Форум — Talks  

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

 ,


0

1

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

На мой взгляд за последние лет 30 языки программирования не стали выше уровнем. Если взять тот же Haskell, который в каком-то виде в первый раз появился в 1990 году, то я бы не сказал, что Rust последней версии чем-то категорично его превосходит. В целом примерно одни и те же идеи тусуют в разных пропорциях. Я тут говорю исключительно про то, насколько язык помогает программисту писать код.

Мне интересно, как вообще можно совершить качественный скачок в языках программирования, оставаясь в той же парадигме, т.е. мы не будем рассматривать фантастику вроде того, что ты пытаешься там в чате чего-то объяснять роботу. А мы так же пишем формальный строгий текст латинницей, который преобразуется в машинный код. Но при этом то, что сейчас требует месяца работы, будет требовать трёх дней. Там, где сейчас 10 багов, будет 1 баг.

Предполагать, что что-то придёт взамен тексту, я тоже не буду. Текст доказал свою пользу на протяжении тысячелетий. Думаю, что ничего лучше текста не придумать.

Или же программирование в текущем виде достигло своего апогея и никаких принципиально новых идей уже не стоит ожидать?

★★★★★

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

Ты же в курсе, что C — язык высокого уровня?

На мой взгляд за последние лет 30 языки программирования не стали выше уровнем.

They’re evolving, just backwards.

t184256 ★★★★★
()

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

goingUp ★★★★★
()
Ответ на: комментарий от goingUp

Хотя, может и нет. chatGPT все-таки нейросеть, а не компилятор, она наверное не будет строго работать по правилам.

goingUp ★★★★★
()
Ответ на: комментарий от t184256

Ну да, если такое и будет, то этим будут заниматься программисты.

goingUp ★★★★★
()
Ответ на: комментарий от t184256

is-odd

Версия 3, 24 коммита, 4 контрибьютера. Что там коммитить? Зависит от is-number, версии 4. Пойду выпью.

rupert ★★★★★
()
Ответ на: комментарий от DumLemming

maven, cpan это начало 2000х. Тоже ничего нового.

vbr ★★★★★
() автор топика
Ответ на: комментарий от javascript

Ну что мне, маркетолога эппл изображать с super high-level pro max? (: Речь об уровне качественно выше текущего. C это уровень качественно выше ассемблера. TypeScript это уровень качественно выше C. А что дальше?

vbr ★★★★★
() автор топика
Последнее исправление: vbr (всего исправлений: 1)

У меня вот такие мысли.

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

Поэтому нужно двигаться в другую сторону.

К примеру с данными можно работать вручную. Сохранять в CSV файлы, парсить их и тд. Но в 80-х Кодд придумал реляционные базы и язык SQL (считаю, что он гений). SQL это сверхвысокоуровневый язык для реляционных данных.

Нужно в текущем софте выделять архитектурно независимые модули и реализовывать работу с ними некими, вероятно декларативными, способами. Пять строк SQL заменяют 50 строк кода на JavaScript, которые будут делать то же самое. Причём речь именно о принципиально независимых модулях, которые в каждом проекте реализовывают снова и снова.

Из примеров таких модулей:

аутентификация (openid connect как пример такого подхода)

авторизация (тут, кажется, каких-то стандартов пока нет, хотя продукты уже есть, к примеру ory keto на основе google zanzibar)

инфраструктурный код (service mesh)

генерация API серверов и клиентов (на самом деле тут попыток было много, начиная от CORBA, WSDL Web Services, OpenAPI сейчас).

vbr ★★★★★
() автор топика
Ответ на: комментарий от vbr

Короче, ты сейчас пытаешься DSL изобрести как концепт. Его уже изобрели.

hateyoufeel ★★★★★
()
Ответ на: комментарий от javascript

Ох ты ж наивный чукотский юноша. В хачкелле ручного управления памятью – хоть жопой жуй. Как и в жабе. Потому что иначе ты off heap objects не сделаешь никак, а без них – тормоза, хтонь и ужос. Но да, средний быдлокодир об этом не задумывается.

А ещё есть другие ресурсы, кроме памяти. Сокеты, файлы и так далее. Для них автомагического управления нету.

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)

Будут, конечно. Навертят ещё несколько уровней абстракций и всё ещё сильнее будет тормозить => новое намного более мощное железо, аппаратные защиты от уязвимостей (заодно защиты от плохого контента), всем профит.

Dimez ★★★★★
()
Ответ на: комментарий от javascript

Ещё раз: Хаскель от Паскаля отличает автоматическое управление памятью.

в паскале тоже автоматическое управление памятью для интерфейсов. Пиши на одних интерфейсах и будет у тебя автоматическое управление памятью.

Также есть паскаль на .NET, там просто автоматическое управление памятью

fsb4000 ★★★★★
()

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

Программисту пофиг на чем писать, погромисту нужен определенный ЯП.

anc ★★★★★
()

Думаю, что ничего лучше текста не придумать.

Не надо ничего придумывать, решает «абстрактный» рынок.

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

Зря, автоматизация разработки может привести к визуальному программированию. (кто к ночи сказал метапрог?)

Для «неонки» без разницы, чем оперировать текстом или нодами, разница есть для людей. Неонку надо обучить это раз, её надо контролировать - понять насколько релевантные решения получаются, это два.

Если в случае условного Node-Red это будет проще, то визуальное программирование порешает. Но это если «если».

супер высокого уровня

В каком-то виде dataflow programming уже есть. Пора уже не код писать, а решения.

vvn_black ★★★★★
()
Последнее исправление: vvn_black (всего исправлений: 1)
Ответ на: комментарий от javascript

Автоматическим управлением памятью.

Т.е. по-твоему Си с gcc’шными raii-расширениями становится языком сверхвысокого уровня?

Ivan_qrt ★★★★★
()
Ответ на: комментарий от vbr

SQL это сверхвысокоуровневый язык для реляционных данных.

Это называется «декларативный язык». Когда ты описываешь в его (вполне жёстко зафиксированном) синтаксисе требуемый результат, а его внутренняя «машина» – универсальный алгоритм (также вполне жёстко зафиксированный) этот требуемый результат получает. Из этой же серии есть ещё пролог. Никаких мутных недетерминированных ИИ и прочей магии, всё предельно конкретно, и DSL заточен под конкретную область/класс задач.

dimgel ★★★★★
()
Последнее исправление: dimgel (всего исправлений: 1)

Но при этом то, что сейчас требует месяца работы, будет требовать трёх дней. Там, где сейчас 10 багов, будет 1 баг

Да с какого перепуга вдруг?

imul ★★★★★
()
Ответ на: комментарий от imul

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

vbr ★★★★★
() автор топика
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от vbr

Про ассемблер->куда угодно — это общеизвестный факт. Про с->js можно подробнее? А то звучит как с->excel для электронных таблиц.

imul ★★★★★
()
Ответ на: комментарий от vbr

Если ничего, значит конец развития.

Нет конечно.
Нужно и должно развивать технологии.

Forum0888
()
Ответ на: комментарий от vbr

Си - Жаваскрипт дают ускорение написания кода раз в десять

а на васике так вообще в тысячи раз... write only он такой...

anc ★★★★★
()
Ответ на: комментарий от vbr

Нужно в текущем софте выделять архитектурно независимые модули и реализовывать работу с ними некими, вероятно декларативными, способами. Пять строк SQL заменяют 50 строк кода на JavaScript, которые будут делать то же самое.

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

То ли дело, например, Datalog, в котором модель изначально структурирована и парсить-форматировать ничего не надо.

Nervous ★★★★★
()
Ответ на: комментарий от Nervous

Неструктурированный текст, как в случае SQL, для этого плохо подходит

Вот потом и получаем мильон select * с left join... поубивавбы... Почему-то формулировка «Неструктурированный текст» не приходит в голову при обсуждении ЯП, но как только касается обработки данных, так «я нисмогла, а виноват сикул».

anc ★★★★★
()
Ответ на: комментарий от anc

Почему-то формулировка «Неструктурированный текст» не приходит в голову при обсуждении ЯП

Почему же. Лисперы постоянно это дело акцентируют — что программы на лиспах программно модифицировать и генерировать гораздо проще, потому что они изначально представляют собой структуры данных, а не просто текст с кудрявым синтаксисом (который еще и имеет кучу диалектов — привет, сиквел; или к нему каждый год добавляется еще один мешок нескучного синтаксиса — привет, жопаскрипт), который перед модификацией надо сначала распарсить в структуру данных.

как только касается обработки данных, так «я нисмогла, а виноват сикул».

Пока все пишется (опытными) руками, особых проблем нет в любых языках. Когда же хочется, чтобы железяка наконец за тебя немного поработала, то у неопытных начинается конкатенация строк для добавления параметров к запросу, и да, в этом отчасти виноват SQL.

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 2)
Ответ на: комментарий от Nervous

Пока все пишется (опытными) руками, особых проблем нет в любых языках.

Процитировал одно, подчеркиваю одно, из ваших правильных высказываний. Вы все верно написали! Цитату решил только эту оставить.

anc ★★★★★
()

10х даёт опыт, фреймворки и IDE. В синтаксисе наверное ничего уже не изобрести. По мне идеальный синтаксис получился бы при смешении джавы и питона. От джавы строгая типизация, от питона отсутствие фигурных скобок и многострочные комментарии внутри методов без вот этих во звёздочек на каждой строке.

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

Фреймворки могут дать серьёзный буст в производительности и на данный момент здесь огромное поле для копаний и исследований. Здесь еще будет масса открытий.

IDE это следующая недооценная фича, которая не меньше фреймворков может бустануть разработку и доработку кода. Впрочем макакам на джаваскриптах, гошечках и прочих креcтах этого не понять. Только джава разрабы что-то начали понимать. Но даже Eclipse и прочии Айдеи - каменный век. Здесь огромное поле для исследований.

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 3)
Ответ на: комментарий от foror

многострочные комментарии внутри методов без вот этих во звёздочек на каждой строке.

Кто тебя заставляет в многострочных комментариях ставить звёздочки на каждой строке?

Комментарий начинается с /* и заканчивается */ Тут всего две звездочки которые требуются.

javascript ★
()

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

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

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

Компонентом такого компилятора может быть нейронка.

atrus ★★★★★
()
Ответ на: комментарий от foror

Фреймворки могут дать серьёзный буст

Можно ли писать фреймворки на фреймворках, чтобы было проще писать фреймворки? Вот в чем вопрос.

Nervous ★★★★★
()
Ответ на: комментарий от vbr

неправильные мысли :)
чисто кодерские как сделать кодинг еще покодеристее, чтоб не кодить, но кодить. ты, не выпрыгивая из сферического коня кода в ваккуме, пытаешься создать новый пузырь, который будет напоминать картинку про пятнадцатый стандарт.

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

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

вот к этому все придет. в принципе тони старк так и общается своей супергероски умной машиной при производстве всяких своих штучек :)

а так совсем недалеко до следующего квантового шага, где человек будет в принципе не нужен :)

pfg ★★★★★
()
Ответ на: комментарий от pfg

Это понятно но это фантастика. Если это будет, то компьютер сможет вообще любого заменить. И тогда тут уже обсуждать нечего, люди будут не нужны. Я всё же думаю про то, что можно представить себе.

vbr ★★★★★
() автор топика

Я думаю, что всё должно прийти к стандартизации описания алгоритмов на формальном языке. Потом уже написание максимально лаконичного кода на C++.

Сделать интернет магазин. - Пишется основа с БД, создаётся админ и один пользователь. БД имеет минимальный набор полей для хранения базы товаров уличного ларька.
Подключить магазин к интернету - создаётся сайт на каком-нибудь php, связывается с БД.
То есть пользователь не думает о именах переменнах, выгрузки памяти и т.д. Он работает с единственным выверенным алгоритмом с полным ООП, как в Qt. Что-то похожее на UML, но на две головы выше.
Потом пользователь уже руками наводит красоту и т.д. А лучше вообще ничего не трогает, как по типу, если меню, то только кнопка в левом верхнем углу как делают уже многие интернет-магазины. Это мне кажется будет потолком.

Ещё раз - верх совершенства - это стандартизация и единство.

xwicked ★★☆
()
Последнее исправление: xwicked (всего исправлений: 1)
Ответ на: комментарий от goingUp

Хотя, может и нет. chatGPT все-таки нейросеть, а не компилятор, она наверное не будет строго работать по правилам.

А строго по правилам никому и не надо. Дай одну и ту же задачу десяти программистам, получишь десять разных программ. Смотри. Одна нейросеть генерирует пару сотен программ по спецификации. Вторая нейросеть — столько же наборов автоматических тестов по той же спецификации. Затем каждый набор тестов запускается против каждой версии программы, и экспертная система выберет лучшую пару.

Гарантирую, это будет работать лучше 95% того говна, что генерируют люди.

filosofia ☆
()
Ответ на: комментарий от Nervous

Ты бы еще спросил можно писать ЯП на ЯП, чтобы было проще писать ЯП. Такая же бессмыслица.

foror ★★★★★
()
Ответ на: комментарий от javascript

Комментарий начинается с /* и заканчивается */ Тут всего две звездочки которые требуются.

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

А использование /* и */ в многострочном комментарии выглядит несимметрично. В питоне """ и """ лучше для многострочных комментов смотрится.

foror ★★★★★
()
Ответ на: комментарий от foror

/* и */ ничем не отличается от """ и """.

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

В твоем идеальном языке, все могут начать писать так, как тебе не понравится - что будешь делать?

/*/
Добaвил тебе симметрии
/*/
javascript ★
()
Последнее исправление: javascript (всего исправлений: 1)
Ответ на: комментарий от javascript

В твоем идеальном языке, все могут начать писать так, как тебе не понравится - что будешь делать?

Я ничего не буду делать, в моём идеальном ЯП это будет невозможно. Я ведь 21 веке живу, а не в 80-х на консольных терминалах. В моём ЯП исходник изначально будет бинарным, а форматирование каждый погромист под себя настроит в специальной IDE.

Добaвил тебе симметрии

Стало еще уродливее )

foror ★★★★★
()
Ответ на: комментарий от alex1101

Это любой естественный язык

Глупости. Ты резко просядешь в производительности, если начнёшь на естественном языке программировать. Даже если нейронке это скормишь результат будет недетерминированным.

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 2)

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

ugoday ★★★★★
()
Вы не можете добавлять комментарии в эту тему: топик перемещен в архив.