Лучшим способом проверки как была так и останется отладка, а в современных IDE несложно вставить брейкпоинт на нужные фрагменты
Лучший способ изучения программирования - изучение опытным путем, путем экспериментов. Выполнение каждого выражения - по сути отдельный эксперимент, по результату которого новичок сможет сразу получить обратную связь и сделать выводы. Отладка загоняет в рамки пошагового выполнения программы, тогда как опыты чаще всего удобнее проводить в произвольном порядке.
И отладка - это вообще про другое, это про выяснение, почему конкретная программа не работает, попытка найти место, в котором что-то пошло не так. А не про глубокое изучение того, что делают конкретные фрагменты кода и выражения
Вот на примере JSON. 8-летний ребенок без знания того, что это такое может попросить нейронку написать json. А еще 8-летний ребенок может (в теории) зайти в онлайн конструктор json (например, https://jsoneditoronline.org/, https://onlinejsoneditor.com/, или какой-нибудь еще), и сделать все самому, и тоже без знаний, потому интуитивность интерфейса отбрасывает необходимость знания json. Но это в теории, а на практике все еще пока что не сможет, но только потому, что пока что интуитивность в этих онлайн конструкторах еще недостаточно доведена до совершенства. Но они очень близки к этому, идея в целом верна. И рано или поздно это произойдет
А потом владелец бизнеса осознает, что было бы все же неплохо иметь представление, что же там под капотом происходит. Возможно что осознает тогда, когда уже наступят последствия
еще и образовательная революция потом будет. Программирование изучается опытным путем, а что будет, когда появится инструмент, позволяющий ставить эти самые опыты в 100 раз быстрее? Правильно, программирование будет изучаться в 100 раз быстрее
Кто-то просто хайпит... и пытается получить деньги с инвесторов на развитие очередных ИИ систем.
И заодно отвлечь внимание от текущих проблем. Ведь GPT-5 все никак выпустить не могут, и возможно не выпустят, так как во всем мире не хватает данных для его обучения, а денег при этом вложено столько, что текущие достигнутые результаты их даже и близко не окупают. Вот и цепляются за любую соломинку в надежде оттянуть разочарование инвесторов
Это во времена когда и графического интерфейса не было? Тогда "играли примерно все" среди тех, кто пользовался ПК в то время. Вот только до появления графического интерфейса самих пользователей ПК было гораздо меньше
Если внедрить условный ChatGPT в Minecraft, то приведет ли это к тому, что игроки перестанут строить сами и будут всегда пользоваться ИИ? Что-то мне подсказывает, что если и будут, то точно не всегда, и часто все равно будут обходится без него. Другое дело что программирование пока что нельзя сравнить с Minecraft. Но можно было бы, если каждый блок ставился бы не кликом мыши, а командой в консоли. Только тогда бы в эту игру играли бы не школьники, а заядлые айтишники. А потом с внедрением искусственного интеллекта были бы те же самые разговоры о том, что ChatGPT заменит игроков в майнкрафт
То когда есть идеи что нужно сделать, но может быть и такое, что зашел в IDE просто ради интереса. И тут либо можно будет сходу узнать, что есть в языке, и начать "играться" с этим, либо нет. Тут не факт что именно Drag-n-Drop-ом в файл, помимо этого был еще вариант выполнения в отдельном окне наподобие того, что описано в пункте 2
А ИИ помогает только в начале, и до того момента, пока не появится ошибка, которую он не сможет исправить даже с нескольких попыток. А дальше все по старому. Сам пользуюсь ChatGPT чуть ли не с самого его появления, и как только он переставал справляться, дальше приходилось делать самому
Насчет навигации по коду, я не упомянул про это в статье, но вообще чтобы путаницы не было, можно в рядом с названием файла во вкладке в скобочках подписывать, что на самом деле мы пришли оттуда-то из такого-то потомка, и смотрим в контексте него. И чтобы была возможность сбросить этот "контекст".
Плюс есть еще второй вариант реализации, описанный в тикете, но не упомянутый в статье. При переходе в унаследованный метод родительского класса, вообще не открывать этот самый класс, а вместо этого этот метод отображать в теле того класса, где мы находились изначально, но так, чтобы было понятно, что это унаследованный метод. Например, окрасить его серым, не дать его редактировать (для этого уже нужно будет в родительский класс перейти), просто где-нибудь сверху сделать подпись, что это унаследованный метод. Но остальные унаследованные методы не отображать в теле класса без перехода в них, то есть отображаются они "ленивым" способом а не "жадным".
В списке методов это кстати уже есть, но тут жадным способом они отображаются.
Вообще конечно подсказка имеет больше смысла для изучения готового кода. Но если я не ошибаюсь, для случаев, когда вариантов несколько для документации было, то эти варианты можно было пролистывать стрелочками вперед/назад, то есть в один момент в окошке мог быть только один вариант документации. По крайней мере это точно так работает для предпросмотра кода в Quick Definition
Насчет того, что нейминг неочевиден, можно решить тем, что рядом с названием функции очень кратко, в двух словах, написать что она делает. Не то, чтобы это сведет к нулю те случаи, когда нужно открыть всплывающее окно с документацией, но их хотя бы будет значительно меньше. Писать конечно серым цветом, ну или таким, с которым эти два слова были бы менее контрастным, чем название функции, чтобы тех, кому это не надо - это не отвлекало, а тех кому надо - смогли бы прочитать. Ну как те же даты у файлов:
Хотя можно было бы и и целым предложением писать, как здесь. Ведь точно также ничего не мешает регулировать ширину окна, в котором этот список находится, также как мы все можем регулировать ширину окна, в котором находиться файловая структура проекта. Если вдруг это кому-то будет мешать, то это можно решить опциональностью отображения подписи
Это имелось ввиду для тех функций и конструкций, которые никогда раньше не использовал. Если какой-нибудь if-else впервые в глаза видишь, и нет уверенности, что напишешь его правильно, то есть немалая вероятность, что даже и пробовать не будешь, и просто пройдешь мимо. Потому что если написать неправильно, кусок кода просто не заработает, а сколько попыток исправить, на то чтобы сработало, неизвестно. А все что более-менее знакомо, конечно же писать самому, потому что это быстрее, чем каждый раз дергать из списка
Слова естественных языках более короткие, и последствия ошибки менее серьезны (к тому же сам ворд предложит исправление), поэтому нет случаев, когда кто-нибудь не написал бы какое-нибудь слово, боясь ошибиться в нем
Не проще и быстрее сразу в полной документации использовать поиск?
Кстати, неоднократно бывают случаи, когда не нашел поиском то что нужно, и в итоге не знаешь, есть ли это в языке или нет. В итоге все равно приходится проходить по списку (сейчас это на сайте в документации) и смотреть описание каждой функции, просто чтобы убедится, что не упустил это
Зачем drag and drop?
Вот еще аргумент, помимо того что я описал в комментарии, зачем он нужен. Чтобы преодолеть "порог лени" и не уйти, когда вы хотите добавить функцию/языковую конструкцию в свой код, но боитесь допустить ошибку и в итоге ее не пишете. Необходимость писать самому может просто многих остановить
stubs - это заглушки. Тут я ошибся, потому что в Java это вообще исходники, но например в php для встроенных функций есть отдельные файлы заглушки, которые содержат функции без тела, но с описанием в /** */. И вот эти файлы-заглушки нужны чисто чтобы была быстрая документация и автодополнение
В php просто нету такого, чтобы встроенные стандартные функции были тоже на php написаны
Лучший способ изучения программирования - изучение опытным путем, путем экспериментов. Выполнение каждого выражения - по сути отдельный эксперимент, по результату которого новичок сможет сразу получить обратную связь и сделать выводы. Отладка загоняет в рамки пошагового выполнения программы, тогда как опыты чаще всего удобнее проводить в произвольном порядке.
И отладка - это вообще про другое, это про выяснение, почему конкретная программа не работает, попытка найти место, в котором что-то пошло не так. А не про глубокое изучение того, что делают конкретные фрагменты кода и выражения
Вот на примере JSON. 8-летний ребенок без знания того, что это такое может попросить нейронку написать json. А еще 8-летний ребенок может (в теории) зайти в онлайн конструктор json (например, https://jsoneditoronline.org/, https://onlinejsoneditor.com/, или какой-нибудь еще), и сделать все самому, и тоже без знаний, потому интуитивность интерфейса отбрасывает необходимость знания json.
Но это в теории, а на практике все еще пока что не сможет, но только потому, что пока что интуитивность в этих онлайн конструкторах еще недостаточно доведена до совершенства. Но они очень близки к этому, идея в целом верна. И рано или поздно это произойдет
А потом владелец бизнеса осознает, что было бы все же неплохо иметь представление, что же там под капотом происходит. Возможно что осознает тогда, когда уже наступят последствия
еще и образовательная революция потом будет. Программирование изучается опытным путем, а что будет, когда появится инструмент, позволяющий ставить эти самые опыты в 100 раз быстрее? Правильно, программирование будет изучаться в 100 раз быстрее
И заодно отвлечь внимание от текущих проблем. Ведь GPT-5 все никак выпустить не могут, и возможно не выпустят, так как во всем мире не хватает данных для его обучения, а денег при этом вложено столько, что текущие достигнутые результаты их даже и близко не окупают. Вот и цепляются за любую соломинку в надежде оттянуть разочарование инвесторов
Это во времена когда и графического интерфейса не было? Тогда "играли примерно все" среди тех, кто пользовался ПК в то время. Вот только до появления графического интерфейса самих пользователей ПК было гораздо меньше
Нет, просто порог вхождения был бы выше, и по зубам он был бы как раз только айтишникам в основном
Если внедрить условный ChatGPT в Minecraft, то приведет ли это к тому, что игроки перестанут строить сами и будут всегда пользоваться ИИ? Что-то мне подсказывает, что если и будут, то точно не всегда, и часто все равно будут обходится без него. Другое дело что программирование пока что нельзя сравнить с Minecraft. Но можно было бы, если каждый блок ставился бы не кликом мыши, а командой в консоли. Только тогда бы в эту игру играли бы не школьники, а заядлые айтишники. А потом с внедрением искусственного интеллекта были бы те же самые разговоры о том, что ChatGPT заменит игроков в майнкрафт
Сказано, просто это в спойлере
Ну глядя на то как Copilot предлагал дополнять код, не знаю насколько это будет полезно
То когда есть идеи что нужно сделать, но может быть и такое, что зашел в IDE просто ради интереса. И тут либо можно будет сходу узнать, что есть в языке, и начать "играться" с этим, либо нет. Тут не факт что именно Drag-n-Drop-ом в файл, помимо этого был еще вариант выполнения в отдельном окне наподобие того, что описано в пункте 2
А ИИ помогает только в начале, и до того момента, пока не появится ошибка, которую он не сможет исправить даже с нескольких попыток. А дальше все по старому. Сам пользуюсь ChatGPT чуть ли не с самого его появления, и как только он переставал справляться, дальше приходилось делать самому
Кстати, в Java еще 13 лет назад использовали "фейковую" сессию отладки в качестве REPL, и предлагали вынести Evaluate Expression за пределы отладки. Вполне возможно, что тогда и JShell не было (но тут я могу ошибаться)
По идее должно вернуть в метод класса, из которого изначально начали "путешествие". Вот в коменте описаны способы, как избежать путаницы
Насчет навигации по коду, я не упомянул про это в статье, но вообще чтобы путаницы не было, можно в рядом с названием файла во вкладке в скобочках подписывать, что на самом деле мы пришли оттуда-то из такого-то потомка, и смотрим в контексте него. И чтобы была возможность сбросить этот "контекст".
Плюс есть еще второй вариант реализации, описанный в тикете, но не упомянутый в статье. При переходе в унаследованный метод родительского класса, вообще не открывать этот самый класс, а вместо этого этот метод отображать в теле того класса, где мы находились изначально, но так, чтобы было понятно, что это унаследованный метод. Например, окрасить его серым, не дать его редактировать (для этого уже нужно будет в родительский класс перейти), просто где-нибудь сверху сделать подпись, что это унаследованный метод. Но остальные унаследованные методы не отображать в теле класса без перехода в них, то есть отображаются они "ленивым" способом а не "жадным".
В списке методов это кстати уже есть, но тут жадным способом они отображаются.
Вообще конечно подсказка имеет больше смысла для изучения готового кода. Но если я не ошибаюсь, для случаев, когда вариантов несколько для документации было, то эти варианты можно было пролистывать стрелочками вперед/назад, то есть в один момент в окошке мог быть только один вариант документации. По крайней мере это точно так работает для предпросмотра кода в Quick Definition
Насчет того, что нейминг неочевиден, можно решить тем, что рядом с названием функции очень кратко, в двух словах, написать что она делает. Не то, чтобы это сведет к нулю те случаи, когда нужно открыть всплывающее окно с документацией, но их хотя бы будет значительно меньше. Писать конечно серым цветом, ну или таким, с которым эти два слова были бы менее контрастным, чем название функции, чтобы тех, кому это не надо - это не отвлекало, а тех кому надо - смогли бы прочитать. Ну как те же даты у файлов:
Хотя можно было бы и и целым предложением писать, как здесь. Ведь точно также ничего не мешает регулировать ширину окна, в котором этот список находится, также как мы все можем регулировать ширину окна, в котором находиться файловая структура проекта. Если вдруг это кому-то будет мешать, то это можно решить опциональностью отображения подписи
Это имелось ввиду для тех функций и конструкций, которые никогда раньше не использовал. Если какой-нибудь if-else впервые в глаза видишь, и нет уверенности, что напишешь его правильно, то есть немалая вероятность, что даже и пробовать не будешь, и просто пройдешь мимо. Потому что если написать неправильно, кусок кода просто не заработает, а сколько попыток исправить, на то чтобы сработало, неизвестно. А все что более-менее знакомо, конечно же писать самому, потому что это быстрее, чем каждый раз дергать из списка
Слова естественных языках более короткие, и последствия ошибки менее серьезны (к тому же сам ворд предложит исправление), поэтому нет случаев, когда кто-нибудь не написал бы какое-нибудь слово, боясь ошибиться в нем
Кстати, неоднократно бывают случаи, когда не нашел поиском то что нужно, и в итоге не знаешь, есть ли это в языке или нет. В итоге все равно приходится проходить по списку (сейчас это на сайте в документации) и смотреть описание каждой функции, просто чтобы убедится, что не упустил это
Вот еще аргумент, помимо того что я описал в комментарии, зачем он нужен. Чтобы преодолеть "порог лени" и не уйти, когда вы хотите добавить функцию/языковую конструкцию в свой код, но боитесь допустить ошибку и в итоге ее не пишете. Необходимость писать самому может просто многих остановить
На Typescript и сейчас все stubs-ы написаны, насколько я знаю
stubs - это заглушки. Тут я ошибся, потому что в Java это вообще исходники, но например в php для встроенных функций есть отдельные файлы заглушки, которые содержат функции без тела, но с описанием в /** */. И вот эти файлы-заглушки нужны чисто чтобы была быстрая документация и автодополнение
В php просто нету такого, чтобы встроенные стандартные функции были тоже на php написаны