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

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

 Откуда можно было бы Drag-n-Drop'ом перетащить интересующие вас в файл.

Как не читая документацию понять, что тебе нужна эта функция, которую ты перетащил мышкой в редактор?

Или просто кусок кода из интернета.

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

Но есть небольшой нюанс в таком подходе)

По названию, плюс в IDE есть быстрая документация

В большинстве случаев сейчас нужны не ключевые операторы, они реально несложные, а работа с библиотеками, или вообще запросы на какие-то API

"Лучший способ проверки - выполнение фрагмента" в данном случае не поможет. Выполнение произвольного куска кода, без контекста, без инициализации данных, без взаимодействия с остальным кодом?

Лучшим способом проверки как была так и останется отладка, а в современных IDE несложно вставить брейкпоинт на нужные фрагменты

Так эти фичи выполнения кода, показанные в гифке, это изначально фичи отладки - Quick Evaluate Expression, и Evaluate Expression (выполнение в отдельном окне). Они и в отладке довольно полезны, но там они предназначены для выполнения в контексте точки останова, и в радиусе нескольких строк от нее.

Просто с отладкой есть сложности, начиная с того что ее может быть сложно настроить (тот же Xdebug языка Php), и заканчивая тем, что не всегда можно быстро воспроизвести сценарий, при котором будет достигнута точка останова.

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

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

Лучшим способом проверки как была так и останется отладка, а в современных IDE несложно вставить брейкпоинт на нужные фрагменты

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

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

Нейминг далеко не всегда очевиден. В итоге, нужно найти в списке функцию, во всплывающем окне прочесть часть документации, чтобы убедится - это то что нужно. Не проще и быстрее сразу в полной документации использовать поиск? Зачем drag and drop?

Нейминг далеко не всегда очевиден

Особенно в моем любимом php. За шесть лет работы так и не удалось запомнить названия многих встроенных функций для работы со строками. Хотя, я и не пытался) php.net в помощь всегда

Welsh or C library function?

mbsrtowcs, rhowch, strxfrm, cwtch, mwyn, wcstold, wcsoll, wmffre

Ответы
  • mbsrtowcs - C

  • rhowch - Welsh (давать)

  • strxfrm - C

  • cwtch - Welsh (обнимать)

  • mwyn - Welsh (руда)

  • wcstold - C

  • wcsoll - C

  • wmffre - Welsh (имя: [Хэмфри])

Так список в первую очередь несет обзорную функцию, а не поисковую. Он предназначен для ответа на вопрос "а что здесь вообще есть?". Чтобы это можно было узнать, когда делаешь первые шаги с каким-то языком программирования. И сразу перепробовать все что интересно. А заодно и не упустить что-нибудь. А то спустя несколько лет работы с языком, до сих пор обнаруживаешь встроенные функции, о которых раньше не слышал

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

Drag-n-Drop нужен не сам по себе, на гифке он был в связке с Live Template. Что нужно было для того, чтобы не писать вручную и избежать синтаксических ошибок

Вот список всех классов в стандартной библиотеке Java SE 10: https://docs.oracle.com/javase/10/docs/api/allclasses-noframe.html Их примерно 6000. Как этот список кому-то поможет освоиться? А если по иерархии разложить, то и в документации, и в IDE это уже есть. И это ещё только классы без методов.

Понятное дело что он должен быть разложен по иерархии, иначе от него толку не будет. А насчет того, чтобы это было в IDE, такого не видел. Ну если вы не имели ввиду пакет Java OpenJDK, который и использовался для гифок. Но это просто пакет из папок и файлов, где дополнительно отображаются классы и функции из этих самых файлов. Специально туда никто не полезет ради этого. И это именно в Java так, в других языках по другому.

Документация далеко не всегда разложена иерархически, а даже если и так - то далеко не всегда ее можно сходу найти. А если не найти, то может быть сделан вывод, что ее нет и вовсе. Так было со мной например, когда я в первый раз искал документацию по Java, зашел на сайт, и не смог найти, где же там описание функций. Мне тогда повезло, что я знал с чего начать, загуглил функции для работы со строками, и попал на страницу, где они были (вроде эта была). А если не знать с чего начать, то на этом все и закончится

На php.net к примеру список тоже есть, но опять же он там находится в неочевидном месте, и тоже нужно знать с чего начать. А даже если его и найти, то по нему еще и не вдруг поймешь, что это он - вот страница с ним

Гарантии того, что с ходу получится найти доки (либо функции в них) на такой-то язык - нет. Также как и нет гарантии того, что они структурированы, и получится быстро по ним пробежаться, и понять, что есть в языке

Я про это говорю:

Оно есть в IDE для джавы уже больше 20 лет. Аналогичная иерархия есть в IDE для дотнета, и в Rider, и в Visual Studio.

А в php/js такого нет. И наверняка не только в них. То есть единым стандартом это не является. И это просто исходники, папки с файлами. Которые предназначены для другого (как я понимаю, это видимо stubs для быстрой документации и автодополнения, которые в том же php накиданы линейно по файлам). Может и можно этим списком пользоваться для того чтобы сориентироваться, но с натяжкой. Потому что он на это не заточен

Которые предназначены для другого (как я понимаю, это видимо stubs для быстрой документации и автодополнения

что?

stubs - это заглушки. Тут я ошибся, потому что в Java это вообще исходники, но например в php для встроенных функций есть отдельные файлы заглушки, которые содержат функции без тела, но с описанием в /** */. И вот эти файлы-заглушки нужны чисто чтобы была быстрая документация и автодополнение

В php просто нету такого, чтобы встроенные стандартные функции были тоже на php написаны

Так и для JS вы не построите список классов и функций. Нужны описания типов от TypeScript.

На Typescript и сейчас все stubs-ы написаны, насколько я знаю

Я про это и говорю. Но то, что вы пытаетесь все языки объяснить терминологией php — неправильно.

Не проще и быстрее сразу в полной документации использовать поиск?

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

Зачем drag and drop?

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

Код в любом случае нужно будет писать самому рано или поздно. Когда учишься водить машину, то с самого начала садишься за руль.

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

Это имелось ввиду для тех функций и конструкций, которые никогда раньше не использовал. Если какой-нибудь if-else впервые в глаза видишь, и нет уверенности, что напишешь его правильно, то есть немалая вероятность, что даже и пробовать не будешь, и просто пройдешь мимо. Потому что если написать неправильно, кусок кода просто не заработает, а сколько попыток исправить, на то чтобы сработало, неизвестно. А все что более-менее знакомо, конечно же писать самому, потому что это быстрее, чем каждый раз дергать из списка

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

То, что человек будет знать о функции, не означает, что он будет использовать её правильно. С этой точки зрения написать комментарий для ИИ: «Сделай вот тут мне такое» даст больше эффекта.

Ну глядя на то как Copilot предлагал дополнять код, не знаю насколько это будет полезно

То, что человек будет знать о функции, не означает, что он будет использовать её правильно.

Если он ее будет писать в IDE, а не в блокноте, то сам вызов функции он уже напишет правильно, поскольку IDE (как минимум те, что от Jetbrains) подсвечивают все необходимые параметры уже сейчас, а также указывают их типы.

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

С этой точки зрения написать комментарий для ИИ: «Сделай вот тут мне такое» даст больше эффекта.

Вот только написание промптов само по себе может стать рутиной, особенно если пробовать за день по 100 функций. А тот же Drag-n-Drop может в случае необходимости обратиться к ИИ автоматически, имея заранее заготовленный шаблон промпта. И в итоге будет тот же сгенерированный ИИ код, но без необходимости ручного обращения к ИИ

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

Выискивать это уже скорее другой случай, список больше нужен чтобы было с чем поиграться, когда из любопытства зашел в IDE произвольного языка. И зашел из любопытства - это не тоже самое, что зашел с конкретной идеей и попросил ИИ ее реализовать. Тут как раз случай когда такой идеи нет. Я вот пробовал ради интереса зайти в рандомную IDE (вроде это PyCharm был) и попросил ИИ-помощник что-то написать. Так он взял и написал hello world. А дальше все по старому - по прежнему непонятно что делать. Просить его что-нибудь добавить - ну он может и добавит еще одну строчку, но свою фантазию проявить явно не получиться - для нее список и нужен

А какой список в том же PyCharm вы ожидаете, чтобы можно было с чем-то «поиграться»? Python же язык общего назначения, на нём можно и консольную утилиту написать, и графическое приложение, и веб-сервис, и ещё бог знает что. Если вас интересует создать сайт, то вы и пишете в промте ИИ-помощника "Хочу создать сайт на Python". Мало того, что ИИ вам даст начальный код, так он и проинструктирует, как именно его нужно запустить и что дальше с ним делать. На этом этапе ИИ может заменить только десяток стартовых шаблонов, сделанных вручную, как это было в старых IDE 1990-2000-х. Но дальше число возможных вариантов комбинаторно растёт, и без ИИ вам никто список «блоков» не предоставит.

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

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

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

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

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

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

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

Если же вы открываете IDE и не понимаете, зачем она вам нужна и зачем вам этот язык программирования, то зачем вы их вообще тогда устанавливали?

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

Что сделает 1 человек из 10, а остальные развернутся и уйдут. А главное, из ответа ИИ все также нельзя будет получить общую картину о языке, ведь он приведет 2-3 примера. И то это будут даже не примеры кода, а примеры того, что можно сделать, примеры придется выпрашивать дополнительно. Пройтись по возможностям языка не получиться, ведь каждый раз нужно будет по кругу задавать ИИ цепочку вопросов ради каждого нового действия.

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

До которой опять доберется один человек из 10, кто-то не найдет, а кто-то даже искать не будет. Помимо того, что нет гарантии, что ее найдут, также нет и гарантии, что она разложена иерархически, как я уже писал в другом коменте. Встроенная документация на то и нужна, чтобы не гуглить ее.

Что сделает 1 человек из 10, а остальные развернутся и уйдут

Так и хорошо же. Что им делать в профессии?

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

А что именно из тысячи функций там показывать, если даже сам автор данного поста не знает, чего хочет?

Список структурированный, что относится к такому-то разделу - то там и будет

Но вы же всё равно не будете знать, чего хотите.

Список как раз и будет решением, к примеру увижу в нем функцию - захочу попробовать запустить ее

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

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

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

Кстати, можно было бы и библиотеки вывести списком, и возможно с возможностью установки при клике. Но только список не весь, а допустим первые 10-20 наиболее популярных, с возможностью подгрузки. Ну и поиском, чтобы отфильтровать результаты. Ну в общем, сделать примерно как на сайтах репозиториев этих самых библиотек - только уже встроить в IDE.
Конечно, могут быть сложности с реализацией - у каких нибудь языков может не быть центрального репозитория для этого, но думаю что проблемы можно будет решить при желании. Если будет список, то хотя бы можно будет узнать о том, что библиотеки вообще есть. А если уж нужно понять, какая библиотека нужна для решения конкретной задачи, то тут уже конечно лучше ИИ спросить.

Это значит, что IDE должна будет откуда-то получить статус репозитория: список пакетов, их описание и статистику использования.

проблемы можно будет решить при желании

Так даже у вас нет такого желания. Зачем разработчикам IDE тратить время и силы на обслуживание потенциально бесполезных пользователей, которые даже ИИ использовать не будут?

которые даже ИИ использовать не будут

А кто сказал что не будут? Будут, но не по каждому чиху. То что вокруг ИИ большой хайп, это не значит, что он применим вообще везде. Нельзя например у людей забрать карту города и сказать: "Теперь спрашивайте у ИИ, где вы находитесь". Хотя ИИ и может стать дополнением к тем же навигаторам.

А пользователи потенциально бесполезны как раз в том случае, если они отвалятся. А если нет, то не такие уж они и бесполезные

Так вы же не пользуетесь. Да и старыми решениями вроде Гугла или официальной документации пользоваться не хотите.

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

> Зачем drag and drop?

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

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

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

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

Почему бы вам самому тогда не написать для Идеи плагин, который бы выводил в дереве информацию о сущности?

Кажется тут довольно однообразное представление о языках. Освоить Scheme с его скобочками, Erlang в котором нет ни переменных ни циклов, Assembler безо всяких if-else-ов или Haskell с его монадами и IO-типами... Сомнительно. Да что там - если вы впервые смотрите на селект для каналов в Go, если для вас невдомёк что такое мьютекс - вас весь JetBrains за один день ничему не научит. Всё-таки слишком броское название, не кажется оправданным.

Так скобки (если я вас правильно понял) это синтаксис, а для IDE подсветка и проверка синтаксиса - одна из базовых вещей. Это во всяких там текстовых редакторах, если забыл поставить точку с запятой, то программа не запуститься, и придется гадать, а что не так. А для IDE эта проблема уже в прошлом.

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

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

ну получается статья о том "как освоить любой язык похожий на те с которыми вы уже и так знакомы" :)

думаю Вам будет хорошо ненадолго отложить PHP и продукты JetBrains и расширить кругозор в этих самых любых языках :)

Нет, скорее речь идет о востребованных языках, а они и покрываются платформой Intellij

востребованные языки рождаются программистами которые знают много невостребованных, как-то так :)

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

Если вы за день сможете хотя бы, например, понять семантику функции call/cc языка Scheme (не говоря о том, чтобы её научиться применять по делу), то это будет крайне удивительно. А синтаксис Scheme простой: слова в круглых скобочках.

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

>Если вы за день сможете хотя бы, например, понять семантику функции call/cc языка Scheme

Зачем для этого больше получаса?

Возьмите с полки пирожок.

Если любите такие вещи, вот вам вопрос на понимание семантики вызова функции в Scheme.

Предположим, у нас в программе есть такая функция:

(define (f)
  (pp "Нисходящая ветка")
  (f)
  (pp "Восходящая ветка"))

Зачем в этой функции предусмотрен код в восходящей ветке бесконечной рекурсии? Существует ли контекст вызова, в котором он сработает?

Существует ли контекст вызова, в котором он сработает?

Language: racket [custom].
> (define (f) (println "Нисходящая ветка") (f) (println "Восходящая ветка"))
> (define g f)
> (set! f (λ () null))
> (g)
"Нисходящая ветка"
"Восходящая ветка"
> 

без set!, думаю, нельзя. ну и варианты с переопределение println, define или там #%app и других внутренних форм не рассматриваем.

Точно.

Ну или

(begin (thread f) (set! f (lambda () 0)))

Любой язык так или иначе изучается опытным путем. Если вдруг появляется возможность ускорить проведение экспериментов в 100 раз, значит и язык будет освоен в 100 раз быстрее. И главная фича, которая должна это обеспечить - это фичи выполнения кода из REPL GUI. Ну и список, если изучение начинается не с готового куска кода, а с пустого проекта. Остальные фичи по большей части нужны для того, для того чтобы компенсировать отсутствие знаний при изучении готового куска кода/проекта.

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

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

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

Встроенный единый список всех функций, языковых конструкций и операторов языка с Drag-n-Drop.

Прежде, чем хотеть эту(и) фичу(и), взгляните на размер MSDN, к примеру.

З.Ы. Android Studio уже начинает захлёбываться, когда открывает класс на >40K строк (а это очень популярный продукт), и во время начала ввода имени метода очень задумывается, составляя список возможных методов.

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

Более того, Android Studio начинает захлёбываеться, когда просто открываешь код View или Context. А это самые базовые вещи в андроиде.

Ага, удачи освоить С++ за один день по подсказкам IDE :)

Так в том то и дело, что при текущем функционале IDE это не получится, вся статья про это

А только лишь на подсказках IDE вы его тоже не освоите

Тут пол статьи не про подсказки

Если вы не понимаете концепции языка, банально что такое указатели, что можно делать указатели на указатели (а это еще может оказаться просто указателем на массив) и так далее в плане указателей тех же, владение памятью, мемори моделы и т.д. и т.п., то вам никакая IDE не поможет, набрали вы * и что? Вам должно показать всю документацию по указателям и работе с памятью (и бонусом на умножение)? Тут уж проще книжечку прочитать (и не за один день)

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

Страница с полной документацией указателя это пол книжки K&R. А что делать с тем что оно может быть умножением, указателем, массивом (технически тоже самое, что указатель конечно, но это надо объяснить если человек не знает про управление памятью). И главный вопрос - а как человек вообще должен узнать что ему нужен в данном случае такой концепт языка как указатель, ссылка, или, скажем, мув семантика? При старте IDE открыть онлайн учебник или ссылку на книжку? Но зачем тогда это в IDE?

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

auto x = ~

...и в этот момент ни компилятор, ни IDE ещё не знают, какой именно будет тип стоять справа от унарного оператора, чтобы получить правильную документацию в момент автодополнения или после него. Или может быть показана «стандартная» документация для побитового NOT, которая не будет иметь смысла, если, предположим, тильда для вектора — это получение противоположного вектора. Или ещё что-нибудь. Выводить же в выпадайке все возможные стандартные и перегруженные унарные операторы (вдобавок ко всем остальным доступным типам, переменным и функциям) — глупо.

Это автор еще не знает про темплейтный адъ (SFINAE, variadic templates, CRTP и так далее) который в языке творится :) Там IDE еще должна будет психологическую помощь оказывать людям, которые за один день будут это всё осиливать даже без других веселостей языка.

Да хотя бы чтобы новичок понял, зачем нужна std::move, нужно гору всего узнать. Или даже как правильно перегрузить operator <=>

Вообще конечно подсказка имеет больше смысла для изучения готового кода. Но если я не ошибаюсь, для случаев, когда вариантов несколько для документации было, то эти варианты можно было пролистывать стрелочками вперед/назад, то есть в один момент в окошке мог быть только один вариант документации. По крайней мере это точно так работает для предпросмотра кода в Quick Definition

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

Тут уж проще книжечку прочитать (и не за один день)

Проще изучать опытным путем, а к документации обращаться уже по мере необходимости

за 21 точно освоит :)

Ага, удачи освоить С++ за один день по подсказкам IDE :)

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

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

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

Для этого нужно максимум десяток другой ключевых слов языка

Приходите в брейнфак, там очень легко. Или самый лёгкий уровень - использовать только mov, всего 1 команда.

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

И в момент написания абзаца про брейнфак я вспоминал... 🙂

Так-то языки, помимо синтаксиса, отличаются ещё и семантикой.

Базовый синтаксис любого языка осваивается за день, чтением туториала на сайте этого языка и написание простейших примеров. Часть, посвещенная синтаксису языка, в Go-tour проходится за полдня.

Да и в целом синтаксисов в промышленных языках и так де-факто две штуки: Си-подобный и ML-подобный.

Только освоение базового синтаксиса языка, это хорошо, если 1% от типичного програмного стека, связанного с языком.

public class Figure {
  public void printArea() {
    double area = getArea(); // <-- строка 3
    System.out.printf("area = %f\n", area);
  }

  public abstract double getArea();
}

public class Square extends Figure {
  public double getArea() {
    ...
  } 
}

public class Triangle extends Figure {
  public double getArea() {
    ...
  }
}

public class Circle extends Figure {
  public double getArea() {
    ...
  }
}

public class Main {
  Figure getFigure() {
    ...
  }

  public static void main(String[] args) {
    
    ...
      
    Figure figure = getFigure();
    figure.printArea();  // <-- строка 38
  }
}

Программист переходит на определение printArea из строки 38, затем оттуда переходит на определение getArea из строки 3. Куда его отправит IDE, если он хочет разобраться, почему у него площадь круга неправильно выводится?

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

Ну это так сейчас происходит. Фича из пункта 7 предназначена для случаев, когда переход был из класса-наследника

Если IDE сможет определить статическим анализом, какой из классов наследников возвращается в строке 37, то можно было бы сразу отправлять в этот класс. Но так как там тип указан Figure (родительский класс), и предполагается, что может быть получен любой дочерний, то тут скорее всего все по старому, то есть дать программисту выбрать самостоятельно, куда идти

То есть если где-то будет ещё один потомок, какой-нибудь IsoscelesTriangle extends Triangle со своим переопределением метода getArea, и функция Triangle getTriangle(), то из triangle.printArea() пользователь попадёт в Figure, а оттуда в базовый метод Triangle.getArea()? Это запутает ещё больше. Так что в подобной ситуации лучше оставить как есть.

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

Половина этих хотелок и так реализована, вторая половина бесполезна.

А у меня вопрос сразу возникает - кому потом это все продать, с учетом спроса на текущий момент, многие пишут в интернетах надо изучать то, что нравится, а нравятся как правило нишевые продукты типа Dart/Flutter или там Ruby...:-)

Однако эти сложности, уже в ближайшем будущем могут быть решены.

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

Так же можете дать любой код и оно уже сегодня объяснить каждую инструкцию пошагово.

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

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

Дорогой дедушка мороз. Напиши мне патч для dropbear, чтобы он пускал с определенного адреса без авторизации. Там пару if добавить.

Даже если и работает сразу (что уже далеко не всегда), то с добавлением правок в какой-то момент все равно всплывают баги. И длиннее чат, тем их больше. Как ему не скидывай ошибки, он либо не правит баг но говорит что правит, либо правит баг но порождает новый, либо правит новый баг, но при этом опять выскакивает старый. А если чат уж очень длинный, то он начинает допускать даже синтаксические ошибки, которые определяются IDE еще на этапе копирования кода в файл. И это не какой-то там старый GPT, это самая последняя модель GPT-4,5. И это с учетом того, что изначально при постановке задачи был приложен весь необходимый контекст (диалог велся не в веб-версии, а в IDE, где сразу можно приложить конкретные файлы либо symbols в качестве контекста). А ошибки скидывались скринами. Сколько не писал с помощью ChatGPT, все равно в конечном итоге с какого-то момента приходилось делать самому.

Даже если и работает сразу (что уже далеко не всегда), то с добавлением правок в какой-то момент все равно всплывают баги.

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

JetBrains сама ушла из РФ и сама отказалась от пользователей из РФ, заблокировав все учетные записи. Интересно, что здесь делает этот пост?

Как купить то, что не продаётся на территории РФ? Без использования бубна и ритуальных танцев )

Drag-n-Drop операторов из списка

Ё-мое, вы серьезно?

Если в голове нет абстракции визуализацией которой должен быть код - ничего не поможет. Будет написан проект сложности "Hello World!".

Если человек программирует абстракциями и делает это в голове, такой редактор вобщем-то ему не особо нужен.

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

Как показывает моя практика, самое сложное - это установить среду разработки и добиться запускаемости того самого "Hello World!" с чистого листа. Желательно в виде отдельного запускаемого бинарника перенесенного на другую машину, а не из оболочки. Дальше писать текст вообще не сложно. К сожалению, от этого этапа такая оболочка не избавляет.

  1. Встроенный единый список всех функций, языковых конструкций и операторов языка с Drag-n-Drop.

Имхо, в IntelliJ уже существует фича Generate code in the editor using prompts, которая является более совершенной фичей, чем Drag-n-Drop. Она как раз может использоваться для решения проблемы чистого листа, когда непонятно что писать, но есть идеи что нужно сделать. Ну и не только в IntelliJ, но и в других IDE, например в Cursor.

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

То когда есть идеи что нужно сделать, но может быть и такое, что зашел в IDE просто ради интереса. И тут либо можно будет сходу узнать, что есть в языке, и начать "играться" с этим, либо нет. Тут не факт что именно Drag-n-Drop-ом в файл, помимо этого был еще вариант выполнения в отдельном окне наподобие того, что описано в пункте 2

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

И упомянутая вами фича не является более совершенной хотя бы потому, что содержит в себе элемент рутины - само написание промпта, тогда как обращение к ИИ может быть уже встроено в тот же Drag-n-Drop, без необходимости написания. Да и сам ИИ в данном случае нужен далеко не всегда

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

Если на фичах наберется достаточное число голосов, и они выйдут в топ (для этого нужно около 500 голосов), то скорее всего сразу с этого момента будет начата реализация.

Вообще количество голосов тоже не гарант, что будет начата реализация. Например, есть такая фича 564 голосами: Make git client a standalone app, но я пока не слышал, чтобы ее начали хоть как-то делать. Причем это вроде вообще рекордное количество лайков на issue по всем продуктам JB.

А максимум по вашим тикетам - 24, ну долго придется ждать, если вообще дождетесь. Как-то не очень похоже на "9 фич будущего в IDE".

2. Быстрое выполнение произвольного фрагмента кода/выражения из проекта прямо в редакторе, либо в отдельном окне - REPL GUI

У меня такое и так работает, ну по крайней мере в Java/Kotlin. Alt + Click вычисляет практически любое выражение во время отладки.

7. Навигация по коду с учетом наследования классов ООП

У меня была подобная идея, только во время отладки:

Есть абстрактный класс A с каким-то методом f и его реализация B, где этот метод реализуется. Когда в IDEA на методе f у типа A я нажимаю на goto definition, то перехожу разумеется в A.f. Но при дебаге нам известен конкретный инстанс, поэтому удобней переходить в B.f.

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

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

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

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

В списке методов это кстати уже есть, но тут жадным способом они отображаются.

У меня такое и так работает, ну по крайней мере в Java/Kotlin. Alt + Click вычисляет практически любое выражение во время отладки.

Кстати, в Java еще 13 лет назад использовали "фейковую" сессию отладки в качестве REPL, и предлагали вынести Evaluate Expression за пределы отладки. Вполне возможно, что тогда и JShell не было (но тут я могу ошибаться)

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

Может ну нафиг? Оставим порог вхождения на уровне? Пусть в отрасли будут программисты которые могут. Ну как бы нам потом этими программами пользоваться.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации