Нет, 1с - это не топ продукт. Я, как человек, достаточно хорошо знающий всю кухню 1С и питон могу сказать, что всю 1с можно превратить во фреймворк на питоне. Плюс к этому адаптация средств разработки и плюс что-то типа редактора форм. При полном сохранении функционала и всех возможностей получится:
Стоимость разработки такого фреймворка меньше (снижение цены для конечного пользователя).
Скорость разработки "конфигураций" - такая же высокая. На питоне пишется так же быстро, как на 1С.
Современный развивающийся язык с ООП, значительно более быстрый. Да-да, питон медленный, но язык 1с еще намного медленнее :)
Затраты на поддержку такого фреймворка - так же меньше.
Возможности такого фреймворка и его кастомизация позволяют значительно расширить круг решаемых бизнес-задач, увеличить рынок. Выйти на новые рынки.
Почему 1С этого не сделает? Думаю, потому, что такой продукт значительно труднее монетизировать, особенно в условиях России.
То есть, по сути, 1С часто ухудшает характеристики продукта из-за ограничений по монетизации. Это не упрек, бизнес есть бизнес. Разработчики платформы тоже кушать хотят. Просто констатирую факты.
Да, хорошо читаемо. Обычный процедурный стиль с использованием готовых объектов. Язык простой, без изысков и заскоков. Все необходимое есть. Вот ООП, да, не хватает. Но компания 1С против)
Если исключить из условий выбора "отсутствие подсветки", то база выбора сильно расширяется. Расширение базы выбора очень часто приводит к выбору более оптимальной модели, в том числе и по соотношению цена/качество. А подсветку отключить - это просто выдернуть разъем
У меня никак в голове не могут соединится "топовая должность" и "программист". Наверное, "топовая должность" - это все же не разработка, а менеджмент. Это все же разные вещи
Знаю разработчиков-сеньоров без высшего образования вообще. Так же знаю людей с профильным образованием, из которых разработчики не получились. Я не то что бы против высшего образования, но заголовок статьи точно не соответствует содержанию.
Статья неявно базируется на утверждении "LLM - это ИИ". Но это утверждении ложно...)
LLM - это просто алгоритм, который показал очень интересные результаты. Они, возможно, будут использоваться в AGI, но уж точно не как основа. Это всего лишь маленький кирпичик...
В конце 80х - начало 90х считали зарплату предприятия на 5000 человек на СМ1420. По вычислительной мощности она во много раз слабее смартфона. А база данных жила на двух жёстких дисках по 29 мегабайт, каждый размером с небольшой холодильник. А, да... Там не только зарплата была. Вся кадровая база. И производство там же считали.
Потому что эти 100 Вт (которые на самом деле 200 Вт если сервер что-то там делает), это дополнительное тепло, которое непрерывно добавляется к тому, что излучается в вашей квартире другими источниками. И будет потихоньку увеличивать температуру в квартире до неприятных значений, если им не обеспечить дополнительный теплоотвод.
Пересчитайте эти 100 Вт на суммарную площадь стен, пола и потолка. Если заморочится, можно еще взять тепловое сопротивление материалов стен и рассчитать дельту. В общем, вывод будет такой: даже в не очень большой комнате, даже без вентиляции, 100 Вт рассеится без существенного повышения температуры. Это теория.
Прямо сейчас у меня работает рабочая станция на тредриппере 24/7 в комнате 17 кв.м. Она сейчас в холостом режиме и потребляет около 200 Вт. Кондиционер выключен. Окно тоже закрыто (в режиме микропроветривания). Дверь в комнату тоже закрыта.Температуру прямо сейчас посмотрел в приложении - 24.5 градуса. Это градуса на 3 выше, чем в других помещениях, но... я знаю, что там сейчас шпарит солнце в окна (восток), и нагрев из-за этого). После обеда уйдет солнце, и разница с соседними помещениями будет точно не больше двух градусов. Скорее всего, градус с небольшим. Если запущу расчеты, будет под киловатт и придется включить кондиционер. Это практика.
И еще информация к размышлению. Если в комнату светит солнце, то на каждый квадратный метр плоскости, перпендикулярной потоку солнечных лучей приходится около киловатта. И зимой и летом. У меня прямо сейчас в комнату влетает с солнцем точно больше киловатта, окно там большое)
Попробовал 1 и 2. Лидера побить не могут. Основная причина - эти варианты не работают с нативными строками питон, и преобразование съедает весь выигрыш распараллеливания. - Преобразование в массивы numpy, даже np.frombuffer(b"aeiouAEIOU", dtype=np.uint8) - долго - Нумба умеет работать сразу с байтовыми массивами. Но с ограничениями, она не может распараллелить операции с ними ( - Ну а учитывая предыдущее, torch пробовать смысла нет
Да, результаты LLM впечатляют. Такие задачи делает на ура. Я хочу начат pet-проект с бэком на питоне и фронтом на vue. С питоном я дружу хорошо, а вот во фронтовой части опыта нет, не знаю ни vue, ни js. Попробовал использовать для фронтовой части LLM. В общем, вполне можно работать. Прошу написать компонент, ставлю задачу. На vue делает достаточно хорошо. Потом я вычитываю, проверяю. Что не понятно, спрашиваю. Например, "а вот что означает эта конструкция на js?". LLM подробно объясняет. Что-то немного переделываю. Иногда бывают косяки - в основном, из-за нечеткой постановки. Но вполне можно работать и делать фронт на языке, которого я не знаю) Но опыт разработки должен быть обязательно. Условная "домохозяйка" проект не сделает.
В начале просил LLM сделать полностью заготовку проекта (бэк+фронт). Она не справилась. Это сложно. А вот компоненты на vue клепает очень годно)
Кстати, результатами теста не удивляен. Изначально бы ставил на решение от a_e_k . Операция in в питоне наверняка в итоге сводится на машинном коде в инстукцию ассемблера rep scasb. Вряд ли есть что либо более эффективное для одного ядра. Потери тут только в том, что идет отдельный вызов через медленный интерпретатор для каждой гласной.
Но... все предложенные мной варианты в комментарии выше могут использовать несколько ядер cpu или gpu, поэтому у них есть шанс вырваться вперед на больших строках. Вопрос лишь в стоимости накладных расходов при подготовки данных.
Не хватает: 1. Варианта на numpy 2. Варианта с numba 3. Варианта с torch на cpu 4. Варианта с torch на gpu Возможно, вечером сделаю. Если никто не опередит))
Если случайный закон симметричен относительно времени - то да, он оборвет связь. Но могут быть варианты. Например, из ситуации A следует ситуация 1, 2 или 3 (случайный выбор). Но может быть так, что в ситуации 1 и 2 и 3 можно попасть только из A.
Все верно. Обычный хайп вокруг новой технологии. Пройдет. Так уже было много раз. Станет ясно, где есть польза, а где - нет.
Причем, когда сейчас говорят "ИИ", почему-то имеют ввиду одну-единственную технологию, которая недавно показала впечатляющие результаты, LLM.
Фантазии ни в коем случае оставлять нельзя, это приведет к полной остановке прогресса)
Нет, 1с - это не топ продукт. Я, как человек, достаточно хорошо знающий всю кухню 1С и питон могу сказать, что всю 1с можно превратить во фреймворк на питоне. Плюс к этому адаптация средств разработки и плюс что-то типа редактора форм. При полном сохранении функционала и всех возможностей получится:
Стоимость разработки такого фреймворка меньше (снижение цены для конечного пользователя).
Скорость разработки "конфигураций" - такая же высокая. На питоне пишется так же быстро, как на 1С.
Современный развивающийся язык с ООП, значительно более быстрый. Да-да, питон медленный, но язык 1с еще намного медленнее :)
Затраты на поддержку такого фреймворка - так же меньше.
Возможности такого фреймворка и его кастомизация позволяют значительно расширить круг решаемых бизнес-задач, увеличить рынок. Выйти на новые рынки.
Почему 1С этого не сделает? Думаю, потому, что такой продукт значительно труднее монетизировать, особенно в условиях России.
То есть, по сути, 1С часто ухудшает характеристики продукта из-за ограничений по монетизации. Это не упрек, бизнес есть бизнес. Разработчики платформы тоже кушать хотят. Просто констатирую факты.
Да, хорошо читаемо. Обычный процедурный стиль с использованием готовых объектов. Язык простой, без изысков и заскоков. Все необходимое есть. Вот ООП, да, не хватает. Но компания 1С против)
Можно сделать проще.
Делаем проект в базис-мебельщик. Закупаем фурнитуру.
Отсылаем файлик на производство (их очень много везде, ищем по "распил ЛДСП")
Принимаем заказ и собираем (отверточная сборка).
Сделал так себе прихожую, планирую продолжить.
Но такого шарма, как с лакированной фанерой из статьи, конечно, не будет))
Если исключить из условий выбора "отсутствие подсветки", то база выбора сильно расширяется. Расширение базы выбора очень часто приводит к выбору более оптимальной модели, в том числе и по соотношению цена/качество. А подсветку отключить - это просто выдернуть разъем
Зачем указывать возраст в ТЗ?
Ну и столько внимания подсветке... Она отключается за несколько секунд на любом корпусе.
Выдачу НС обязательно нужно проверять. Бывают неточности, бывают галлюцинации. А ещё они отстают от реального мира на год, а то и два.
А локально запускать НС... Можно, но для того же дипсика нужно около 800 Гб памяти.
У меня никак в голове не могут соединится "топовая должность" и "программист". Наверное, "топовая должность" - это все же не разработка, а менеджмент. Это все же разные вещи
Знаю разработчиков-сеньоров без высшего образования вообще. Так же знаю людей с профильным образованием, из которых разработчики не получились. Я не то что бы против высшего образования, но заголовок статьи точно не соответствует содержанию.
А они по прежнему на вопрос "Как выгрузить таблицу значений 1С в JSON" выдают шикарные и удобные, но не существующие методы? :)
Статья неявно базируется на утверждении "LLM - это ИИ". Но это утверждении ложно...)
LLM - это просто алгоритм, который показал очень интересные результаты. Они, возможно, будут использоваться в AGI, но уж точно не как основа. Это всего лишь маленький кирпичик...
А статья где?
Я застал времена чуть позже, но...
В конце 80х - начало 90х считали зарплату предприятия на 5000 человек на СМ1420. По вычислительной мощности она во много раз слабее смартфона. А база данных жила на двух жёстких дисках по 29 мегабайт, каждый размером с небольшой холодильник. А, да... Там не только зарплата была. Вся кадровая база. И производство там же считали.
Пересчитайте эти 100 Вт на суммарную площадь стен, пола и потолка. Если заморочится, можно еще взять тепловое сопротивление материалов стен и рассчитать дельту. В общем, вывод будет такой: даже в не очень большой комнате, даже без вентиляции, 100 Вт рассеится без существенного повышения температуры. Это теория.
Прямо сейчас у меня работает рабочая станция на тредриппере 24/7 в комнате 17 кв.м. Она сейчас в холостом режиме и потребляет около 200 Вт. Кондиционер выключен. Окно тоже закрыто (в режиме микропроветривания). Дверь в комнату тоже закрыта.Температуру прямо сейчас посмотрел в приложении - 24.5 градуса. Это градуса на 3 выше, чем в других помещениях, но... я знаю, что там сейчас шпарит солнце в окна (восток), и нагрев из-за этого). После обеда уйдет солнце, и разница с соседними помещениями будет точно не больше двух градусов. Скорее всего, градус с небольшим. Если запущу расчеты, будет под киловатт и придется включить кондиционер. Это практика.
И еще информация к размышлению. Если в комнату светит солнце, то на каждый квадратный метр плоскости, перпендикулярной потоку солнечных лучей приходится около киловатта. И зимой и летом. У меня прямо сейчас в комнату влетает с солнцем точно больше киловатта, окно там большое)
Попробовал 1 и 2. Лидера побить не могут. Основная причина - эти варианты не работают с нативными строками питон, и преобразование съедает весь выигрыш распараллеливания.
- Преобразование в массивы numpy, даже np.frombuffer(b"aeiouAEIOU", dtype=np.uint8) - долго
- Нумба умеет работать сразу с байтовыми массивами. Но с ограничениями, она не может распараллелить операции с ними (
- Ну а учитывая предыдущее, torch пробовать смысла нет
Плохого ничего. Но только за деньги вы будете работать так себе)
А вот если вам нравится то, что вы делаете, да еще за это платят деньги - расклад совсем другой)
Да, результаты LLM впечатляют. Такие задачи делает на ура.
Я хочу начат pet-проект с бэком на питоне и фронтом на vue. С питоном я дружу хорошо, а вот во фронтовой части опыта нет, не знаю ни vue, ни js. Попробовал использовать для фронтовой части LLM. В общем, вполне можно работать. Прошу написать компонент, ставлю задачу. На vue делает достаточно хорошо. Потом я вычитываю, проверяю. Что не понятно, спрашиваю. Например, "а вот что означает эта конструкция на js?". LLM подробно объясняет. Что-то немного переделываю. Иногда бывают косяки - в основном, из-за нечеткой постановки. Но вполне можно работать и делать фронт на языке, которого я не знаю) Но опыт разработки должен быть обязательно. Условная "домохозяйка" проект не сделает.
В начале просил LLM сделать полностью заготовку проекта (бэк+фронт). Она не справилась. Это сложно. А вот компоненты на vue клепает очень годно)
Кстати, результатами теста не удивляен. Изначально бы ставил на решение от a_e_k . Операция in в питоне наверняка в итоге сводится на машинном коде в инстукцию ассемблера rep scasb. Вряд ли есть что либо более эффективное для одного ядра. Потери тут только в том, что идет отдельный вызов через медленный интерпретатор для каждой гласной.
Но... все предложенные мной варианты в комментарии выше могут использовать несколько ядер cpu или gpu, поэтому у них есть шанс вырваться вперед на больших строках. Вопрос лишь в стоимости накладных расходов при подготовки данных.
Не хватает:
1. Варианта на numpy
2. Варианта с numba
3. Варианта с torch на cpu
4. Варианта с torch на gpu
Возможно, вечером сделаю. Если никто не опередит))
Если случайный закон симметричен относительно времени - то да, он оборвет связь. Но могут быть варианты. Например, из ситуации A следует ситуация 1, 2 или 3 (случайный выбор). Но может быть так, что в ситуации 1 и 2 и 3 можно попасть только из A.