Пусть сначала появится модель, стабильно выдающая результат миддла, тогда и оценки появятся. А пока ее нет, можно почитать про случаи где существующие, работающие в минус, за день сжигает токенов на огромные суммы. Причем не какой-то там ошибкой, как у кожаных мешков, а просто настойчивыми попытками решить задачу. И это не какое-то там исключение, целые отделы компаний свои лимиты в рекордные сроки растрачивают, в чем можно усмотреть и прямой интерес провайдеров облачных моделей.
Только вот не получается пока в долгосроке "x2" продуктивности, зато топовые модели работают в жирный минус, и при изменении расценок до окупаемости будут стоить как полноценный разработчик в команду, а то и больше.
Кстати, а почему вопрос поставлен именно со стороны "уволить"? Если ИИ все же дойдет до уверенного уровня с приемлемой стоимостью, то сам разработчик может стать самозанятым, и выполнять "x2" заказов по демпингованным расценкам, т.к. ему не нужно кроме себя кормить команду начальников, менеджеров, и офисного собственника. В случаях попроще конечный потребитель может вообще сам запросы ИИ отсылать.
Потому что раньше почти каждая хорошая игра была целым событием в рамках отдельной платформы, их носили друг другу на флопиках, картриджах, (а позже на CD, флешках), долго обсуждали, проходили по нескольку десятков раз. А сейчас в неделю выходит больше игр, чем можно пройти за год, причем даже не плохих, и любую можно получить почти мгновенно.
Дайте вам миллион, вы купите что-то за миллион, за это получат профиты те, у кого вы это купили, и за капнувшее в карман тоже что-то купят, принеся профиты дальше по цепочке, и через сколько-то там итераций условная сотня детей выпросит по сколько-то там баксов у родителей на покупку в планшете.
Т.е. своего-то предела вы уже достигли, но есть еще другие люди, пока еще не достигнувшие собственного предела, но на которых косвенно влияют ваши денежные операции.
Напишите пожалуйся “устоявшееся” определения, чем же, по вашему, «Expression» принципиально отличается от «Statement»
Ну например. Для statement: "syntactic unit of an imperative programming language that expresses some action to be carried out". Для expression: "a sequence of operators and operands, that specifies a computation".
Можете привести примеры этих statement?
stmt if expr
stmt unless expr
stmt while expr
stmt until expr
stmt rescue expr
var = method expr
x,y = expr
Давайте, пожалуйста, не будем притягивать за уши лишние сущности, и сперва определимся, чем же «Expression» принципиально отличается от «Statement», а потом уже посмотрим, что есть в LISP, а чего нет.
Какие конкретно сущности являются лишними? Статья была посвящена терминам statement и expression, разделение которых продиктовано синтаксическими нюансами императивных ЯП, например банальным нежеланием разрешать и как-то обрабатывать конструкции вроде "print(return)", "if(break)", "while(import)" и т.п. Теперь вы приводите в пример LISP, в грамматике которого вообще не прописано ни statement, ни expression в значениях аналогичных императивным языкам.
Ведь я и пишу о том, что жесткое разделение на stmt и expr, это только дань привычке
Настолько же дань привычке, как использование латиницы в ключевых словах, организация кода по строкам с выполнением сверху вниз, позиционной десятиричной системы счисления. Можно ли сделать язык с египетскими иероглифами, выполнением по спирали на сетке против часовой стрелки и римскими числами? Можно. Является ли "дань привычке" основной причиной почему так не делают? Сомнительно.
Вот если сначала доказать, что альтернативный способ объективно лучше используемого (например, приводит к меньшему числу ошибок, или ускорению написание кода при прочих равных), но не используется без видимых причин - вот тогда это действительно может быть данью привычки.
Это детали реализации грамматики, которые разработчики реализовали именно таким образом
Так про что угодно можно сказать. Все ЯП это формальные системы, в которых если захотеть можно букве имени класса номер строки в исходниках присвоить. Но это не значит что можно перечеркнуть все устоявшиеся определения.
В одном случае это будут одни правила, а в другом - другие. Просто разработчики написали их именно так и нетерминал в парсере назвали stmt, а в другом языке нетерминал грамматики взяли и назвали stmt_or_expr, но что в итоге доказывает или объясняет?
Так уж случилось, что есть сотни императивных языков программирования, в которых отдельно stmt, отдельно expr, и назвать их можно как уходно, хоть a и b, но это две отдельные сущности, которые соотносятся определенным образом, и это не только деталь реализации, но и прописанная в документациях особенность. И так уж случилось, что нет языков, в которых есть один терминал названный stmt_or_expr, либо это две отдельные сущности, либо одной из них просто нет. Определения нужны, чтобы люди могли одинаково понимать о чем идет речь, когда слышат конкретное слово, и обычно они отражают конкретную сложившуюся по факту действительность. И она сложилась именно вот так.
Тем более, что речь изначально шла про Ruby, в котором это разделение такое же явное, как и в С/С++/Java. Т.е. прямо указано, что некоторые statement не являются expression, и использование их там, где ожидается expression является синтаксической ошибкой.
LISP, это не академический язык, в котором все является выражением и вся программа состоит тоже только из выражений.
LISP это не императивный язык, в нем программа это список атомов, а не последовательность строк/команд. В нем просто нет statement как сущности, и это не то же самое что тождественность stmt и expr. При этом он вполне академический.
Тогда по вашему выходит, что “expression” не может содержать инструкции?
Напрямую не может, конечно. И это не "по моему", это прямо отражено в документациях, грамматиках, и реализациях любого языка программирования в котором заданы эти сущности. Нет, ну можно конечно заморочиться и создать собственный язык, где все это принципиально схлопнуто в одну сущность, но это будет не более чем академический (если не эзотерический) эксперимент.
в чем тогда между ними различие?
Отличие в том, что из последовательности statement состоит вся программа, а expression это лишь одна из подкатегорий statement в некоторых языках, кроме которой существуют множество других.
Общепринятое определение, это “statement” не возвращает значения
Источник можно? В англоязычной википедии например используется "statement is a syntactic unit of an imperative programming language that expresses some action to be carried out", в русскоязычной "наименьшая автономная часть языка программирования ... Программа обычно представляет собой последовательность инструкций". И примерно то же самое написано во всех учебниках.
При этом каждое expression в Ruby буквально включено в statement. Это отражено как в его правилах грамматики: stmt : expr, так и в документации, что можно заметить по цитате выше: "statements that are not expressions ...". И Ruby в этом не одинок, в тех же C и C++ это тоже верно.
В Ruby есть явное разделения на statement и expression, и в официальной документации подписано что есть что. Например: break, next и redo это statements.
А вот грамматические правила для statements в Ruby, это очень старая версия, от 2004 года, но тем не менее. Видно что есть stmt, а есть expr и expr_value.
Ну-ну. Лучшие модели весьма недешевые, при том что работают по сути в глубокий минус, и каждая новая требует все больше и больше ресурсов. А на выходе еще и код, который совсем не тот же самый код.
Книги дают систематизацию. Нельзя спросить у ИИ вопрос, которого ты сам еще не знаешь.
В среднем может и на уровне миддлов. Но иногда их "клинит", особенно в ненатоптанных темах. Нужно чтобы человек следил.
Тем временем Apple: "вот ваши хотелки, я скозал".
Пусть сначала появится модель, стабильно выдающая результат миддла, тогда и оценки появятся. А пока ее нет, можно почитать про случаи где существующие, работающие в минус, за день сжигает токенов на огромные суммы. Причем не какой-то там ошибкой, как у кожаных мешков, а просто настойчивыми попытками решить задачу. И это не какое-то там исключение, целые отделы компаний свои лимиты в рекордные сроки растрачивают, в чем можно усмотреть и прямой интерес провайдеров облачных моделей.
Только вот не получается пока в долгосроке "x2" продуктивности, зато топовые модели работают в жирный минус, и при изменении расценок до окупаемости будут стоить как полноценный разработчик в команду, а то и больше.
Кстати, а почему вопрос поставлен именно со стороны "уволить"? Если ИИ все же дойдет до уверенного уровня с приемлемой стоимостью, то сам разработчик может стать самозанятым, и выполнять "x2" заказов по демпингованным расценкам, т.к. ему не нужно кроме себя кормить команду начальников, менеджеров, и офисного собственника. В случаях попроще конечный потребитель может вообще сам запросы ИИ отсылать.
Потому что раньше почти каждая хорошая игра была целым событием в рамках отдельной платформы, их носили друг другу на флопиках, картриджах, (а позже на CD, флешках), долго обсуждали, проходили по нескольку десятков раз. А сейчас в неделю выходит больше игр, чем можно пройти за год, причем даже не плохих, и любую можно получить почти мгновенно.
Определение числа Райо можно сократить и уместить в 280 символов.
Обесценил не только написание кода, но иногда и сам продукт.
Стартап: "ну все, теперь-то с ИИ мы можем за неделю сделать приложение для X".
Пользователь: "Окей, ChatGPT, вот файлы - сделай мне X".
Дайте вам миллион, вы купите что-то за миллион, за это получат профиты те, у кого вы это купили, и за капнувшее в карман тоже что-то купят, принеся профиты дальше по цепочке, и через сколько-то там итераций условная сотня детей выпросит по сколько-то там баксов у родителей на покупку в планшете.
Т.е. своего-то предела вы уже достигли, но есть еще другие люди, пока еще не достигнувшие собственного предела, но на которых косвенно влияют ваши денежные операции.
Ну например.
Для statement: "syntactic unit of an imperative programming language that expresses some action to be carried out".
Для expression: "a sequence of operators and operands, that specifies a computation".
Какие конкретно сущности являются лишними? Статья была посвящена терминам statement и expression, разделение которых продиктовано синтаксическими нюансами императивных ЯП, например банальным нежеланием разрешать и как-то обрабатывать конструкции вроде "print(return)", "if(break)", "while(import)" и т.п. Теперь вы приводите в пример LISP, в грамматике которого вообще не прописано ни statement, ни expression в значениях аналогичных императивным языкам.
Настолько же дань привычке, как использование латиницы в ключевых словах, организация кода по строкам с выполнением сверху вниз, позиционной десятиричной системы счисления. Можно ли сделать язык с египетскими иероглифами, выполнением по спирали на сетке против часовой стрелки и римскими числами? Можно. Является ли "дань привычке" основной причиной почему так не делают? Сомнительно.
Вот если сначала доказать, что альтернативный способ объективно лучше используемого (например, приводит к меньшему числу ошибок, или ускорению написание кода при прочих равных), но не используется без видимых причин - вот тогда это действительно может быть данью привычки.
Так про что угодно можно сказать. Все ЯП это формальные системы, в которых если захотеть можно букве имени класса номер строки в исходниках присвоить. Но это не значит что можно перечеркнуть все устоявшиеся определения.
Так уж случилось, что есть сотни императивных языков программирования, в которых отдельно stmt, отдельно expr, и назвать их можно как уходно, хоть a и b, но это две отдельные сущности, которые соотносятся определенным образом, и это не только деталь реализации, но и прописанная в документациях особенность. И так уж случилось, что нет языков, в которых есть один терминал названный stmt_or_expr, либо это две отдельные сущности, либо одной из них просто нет. Определения нужны, чтобы люди могли одинаково понимать о чем идет речь, когда слышат конкретное слово, и обычно они отражают конкретную сложившуюся по факту действительность. И она сложилась именно вот так.
Тем более, что речь изначально шла про Ruby, в котором это разделение такое же явное, как и в С/С++/Java. Т.е. прямо указано, что некоторые statement не являются expression, и использование их там, где ожидается expression является синтаксической ошибкой.
LISP это не императивный язык, в нем программа это список атомов, а не последовательность строк/команд. В нем просто нет statement как сущности, и это не то же самое что тождественность stmt и expr. При этом он вполне академический.
Советы категории "лучший способ успокоить мужчину: - да что ты истеришь как баба!".
Напрямую не может, конечно. И это не "по моему", это прямо отражено в документациях, грамматиках, и реализациях любого языка программирования в котором заданы эти сущности. Нет, ну можно конечно заморочиться и создать собственный язык, где все это принципиально схлопнуто в одну сущность, но это будет не более чем академический (если не эзотерический) эксперимент.
Отличие в том, что из последовательности statement состоит вся программа, а expression это лишь одна из подкатегорий statement в некоторых языках, кроме которой существуют множество других.
Источник можно? В англоязычной википедии например используется "statement is a syntactic unit of an imperative programming language that expresses some action to be carried out", в русскоязычной "наименьшая автономная часть языка программирования ... Программа обычно представляет собой последовательность инструкций". И примерно то же самое написано во всех учебниках.
При этом каждое expression в Ruby буквально включено в statement. Это отражено как в его правилах грамматики:
stmt : expr, так и в документации, что можно заметить по цитате выше: "statements that are not expressions ...". И Ruby в этом не одинок, в тех же C и C++ это тоже верно.Имею ввиду общеиспользуемое их определение, которое в том числе применяется в официальной документации Ruby.
Как и все другие в языке кроме корневого, с которого начинается парсинг.
А вот еще такой пример из документации:
В Ruby есть явное разделения на statement и expression, и в официальной документации подписано что есть что. Например: break, next и redo это statements.
А вот грамматические правила для statements в Ruby, это очень старая версия, от 2004 года, но тем не менее. Видно что есть stmt, а есть expr и expr_value.
- Ваш дизайн - говно.
- Это дизайн говна.
- Тогда недурно.
Ну-ну. Лучшие модели весьма недешевые, при том что работают по сути в глубокий минус, и каждая новая требует все больше и больше ресурсов. А на выходе еще и код, который совсем не тот же самый код.
У кого как. Месяц назад примерно статья была, где человек сравнивал GLM 5.2 и Opus 4.8. Результаты были такие:
Да, этот вопрос задал пользователь реддита Diligent_Ad_6530. Вопрос получил тысячи лайков.