Вы теоретик который во власти своего солепсизма находится. ВЫ - можете заставить ее работать на тех задачах которые у вас есть. Как программист, например. А бизнес вообще - не всегда может это сделать. Так как кроме технических компетенций которыми можно закрыть все или большинство недостатков 1С - требуется еще время и другие ресурсы. Сочетание которых и делает 1С в ряде случаев невыгодной. В ряде - неожиданно (после нескольких лет "успешной" работы) невыгодной. Это и заставляет отказаться от нее в пользу других решений. И эта тенденция будет только развиваться, если в 1С не придумают какой то качественный переход.
Да, гораздо логичнее если бизнес не большой, писать чтото под конкретную задачу, чем кстати многие и занимаются наевшись 1С.
Заставить, при прочих равных, работать 1с гораздо сложнее. Она будет или тормозить сильнее, или дороже обходится в разработке.
А то что ею пользуются, ну это во первых привычка, во вторых - некоторым так проще с государством взаимодействовать, а в третих - заслуга лукавой модели самой 1с, в которой часть разработки (актуализацию конфигурации под современную платформу например) можно вынести за скобки, как будто ее и нет. Пока петух в зад не клюнет.
Это все основано на бизнесс модели прошлого века где все стандартизировано. Но сегодня все несколько иначе. И такие негибкие авторитарные модели не везде продолжают работать (так же хорошо как раньше).
Мы же не про вас говорим - я прекрасно понимаю что в 1С много людей есть которые могут использовать 1С гораздо лучше. Но устроена эта система так, что потворствует зарытым нелучшего вида решениям. О чем и речь
Вы когда читаете мой текст все время исходите из контекста в котором я якобы утверждаю о наличии проблем в 1с, и одновременном их отсутствии в других системах. Это лишает смысла всю переписку так как в моем тексте ничего похожего нет. Во всех системах есть проблемы с обновлением, и тп. Скажем вот вы утверждаете что во всех языках есть горе разработчики. Но с этим никто и не спорит, ваши возражения бессмысленны. Здесь речь идет о том что сама концепция 1С рассчитана на них. Она располагает к тому, чтобы тащить в проекты все что формально работает даже обладая при этом чудовищной избыточностью. А то и вовсе наоборот - писать самобытный код руководствуясь только фантазией. Причем основанный не на каких то устоявшихся подходах, абстракциях, структурах, а чисто на 1Сных фичах оставшихся еще наверное, с того периода когда они запилили бухгалтерию.
И да - мы говорим о проблеме разработки 1С в том числе и как о проблеме разработчика, так как в 1С довольно замкнутое и косное сообщество гораздо сильнее влияющее на любого кто решил себя связать с этой платформой. Собственно - о чем и речь, 1С не просто не очень хороша, она так задумана. Именно поэтому ruby постоянно выбирают абстрактные программисты и его доля растет естественным путем. А 1С даже в условиях авторитарности и директивности - нишевое решение, во многом основанное на недальновидности бизнеса.
ровно это же применимо к нонейм-девелоперам на РОР, только замените слово "регистр" на слово "таблица". Я больше скажу - с РОР дело будет даже хуже. Ибо 1с-ник, в силу специфики, вынужден хоть как-то изучать бизнес. "чистые программисты" говнокодят не думая, чисто по ТЗ.
Да - применимо, но только в 1с для них создана "питательная среда".
я вам больше скажу - пользователям вообще код не нужен.
А бизнесу - очень даже нужен. Так им с ним жить.
Нет. Существует достаточное количество самописных конфигураций, тупо работающих годами... например, в далеком 2004 я чисто от нехрен делать написал простенькую конфигу для "ведомственной столовки". Как оказалось, она проработала до банкротства конторы, примерно 2015 года.
С этим никто и не спорит - это как раз одно из оснований проблемы, которое в сочетании с концепцией 1с дает проблемы. Причем чем позже эти проблемы возникают - тем труднее решаются. Тем временем все эти годы для бизнеса создается видимость что конфа полноценно поддерживается разработчиками. А потом выясняется что для какой то фичи на управляемых формах - надо всю ее переписать с нуля (в том числе и в той части в которой она никогда не была нужна, в том числе и в той части, в которой она - плод сочетания уникальной фантазии разработчика (зачастую с самыми базовыми знаниями с аналогом которых он бы на ROR в прод не вышел ) и каких то чисто 1Сных фищечек).
Переписывать надо потому, что изменения в платформе не учитывались при доработках сразу. Потому что очень ресурсоемки и по деньгам и по времени, а еще и не очевидны бизнесу "на берегу". И еще надо найти того, кто возьмется за 15 летний проект.
Мне тоже кажется - что не нужна. Но мы не говорим о том что кажется. Мы говорим о том что есть. И пример вполне конкретный. Или вам dt`шку надо выгрузить? Я думаю нет. Вот конкретная задача - управление 10 таблицами. Оно реализовано на базе УТ. Что вам еще нужно знать, чтобы сравнить этот реальный кейс с другими подходами, навроде RoR? В которых такое попросту даже невозможно?
Модульность - так есть расширения и обработки. Даже перезапускать локально не нужно 1С в большинстве случаев
Я так понимаю, претензии к модульности не в том что не подключить чтото по желанию, а в том что основа включает сразу все. От чего нельзя отказаться со всеми вытекающими. Грубо говоря - захотели вы покататься на велосипеде, а купили небольшой кантон в Швейцарии где локализовано все производство которое вам в итоге его и дает.
Например есть простая система из 10 таблиц, для ведения которой понадобилось взять целое управление торговлей с доработками. При том что 99 процентов задач под который УТ написана - не нужны. Но так проще - программисты пишут как проще. Причем проще в данном случае - может быть выражено самыми разными способами (в меру понимания каждого программиста, которая для случаев 1с - имеет большой разброс)
Любой универсальный инструмент всегда отличается от специализированного. В обе стороны.
В том то и дело что большинству пользователей 90 процентов кода который они получат в 1С - вообще не нужны. Так что эта универсальность она не просто универсальность а неиспользуемая универсальность (нуждающаяся в поддержке). Чтобы оставаться актуальной в какой то одной небольшой нужной части - любая самописная конфигурация нуждается периодически в существенных изменениях самого разного рода, от внедрения поддержки фичь новой платформы, в том числе и ненужных, но тех, без которых переход не будет возможен , до смены подходов к каким то задачам которые 10 лет назад прихотливо подобрал некий ноунейм-девелопер по своему разумению и по наличию каких-то внутренних самобытных регистров, которые можно использовать 150 разными способами . Этот набор проблем гораздо более выражен у 1С, чем у чего либо еще. Причем он существует на фундаменте низкого порога входа. Человек уже втянулся, а издержках узнает потом.
При этом тот же подход ROR - он тоже универсален, за счет того что основан на устоявшихся и развивающихся стандартах. Ну навроде описания данных, не привязанного к какому-то нишевому языку. И благодаря этому же - еще и достаточно специален.
Я уже привел пример выше (даже два). Более подробно нет смысла писать. Да и не могу я такое публиковать дентально, на самом деле.
т.е. написанное на РОР не может иметь недостатков?
Мы не обсуждаем то что может или не может быть. Мы обсуждаем то что есть. Разработчик который продетектирует базу на языке в котором методология отталкивается от стандартов которые используются везде - имеет пишет менее самобытный (в плохом смысле этого слова) код.
Мы говорим не о том что можно - об этом я отдельно отписался что можно все. Мы говорим о том как все в реальности пишется в 1с. Либо дорого и долго (понятно почему - темный лес из абстракций 1с не каждый решится осваивать глубоко, так как он не относится к фундаментальным знаниям, в отличии кстати - от ddl) либо быстро и говнокод.
1с хуже по принципу швейцарского ножа, которым можно делать все, но плохо. Конечно же не о том что сделать хорошо невозможно. А о том что культура разработки (включая концепцию самой 1с ) способствует именно этому. Это чисто личное впечатление на основе разных проектов с которыми встречался. И проблем (часто не решаемых оптимально за разумные деньги ).
Плюсы того же ror в том что на нем разработчик часть кода напишет фактически на ddl. В 1с для этого нужны еще и абстракции 1с.
А часть вариантов с реализацией 1с будет еще и с какими нибудь недостатками которые вылезут потом.
Еще одна история есть про 1С. Локальный какой то полуфранчайзи в регионе - постпредством полутора программистов поддерживал систему УП, помоему, и существенно переработал ев специализированную. Речь идет о бизнесе близком к среднему. В итоге сегодня эту конфигурацию реальному среднему бизнесу не потянуть в той полноте разработки которая бы сделала ее актуальной с точки зрения соответствия платформе. И фактически это приводит к патовой ситуации, когда нужно разрабатывать старую версию. И не иметь всех тех плюшек которые есть в новой. И это не считая огромного техдолга, который накопившись - стал оказывать влияние на быстродействие. И требовать отдельной работы. В итоге контора в части филиалов соскочила уже с 1С. Там тоже есть свои проблемы, но не такие глобальные.
Никакие изменения в планировании вообще никак нас не касаются. Мы получаем конкретный набор данных выгрузкой. И нам без разницы чем и как она генерируется. Да мы и не знаем таких деталей - знаем что из 1с. Но в принципе уже недалеко от того чтобы самостоятельно их генерировать на своей стороне, прямо сразу в свою структуру таблиц. Я пока что этим занят в порядке самообучения - на rails. И это выгляди гораздо круче по возможностям. Хотя практика покажет конечно.
Я не хочу сказать что у Rails есть качество убийцы 1C но ряд типовых задач среднего бизнеса на нем на порядки быстрее выходят, например интерфейсы к БД. А сама разработка - фактически отталкивается от абстракций DDL (в отличии от 1С с ее регистрами и тд.). Для разработчика SQL Rails прямо как продолжение рук). Я считаю что он серьезно потреплет 1С.
Вы теоретик который во власти своего солепсизма находится. ВЫ - можете заставить ее работать на тех задачах которые у вас есть. Как программист, например.
А бизнес вообще - не всегда может это сделать. Так как кроме технических компетенций которыми можно закрыть все или большинство недостатков 1С - требуется еще время и другие ресурсы.
Сочетание которых и делает 1С в ряде случаев невыгодной. В ряде - неожиданно (после нескольких лет "успешной" работы) невыгодной. Это и заставляет отказаться от нее в пользу других решений. И эта тенденция будет только развиваться, если в 1С не придумают какой то качественный переход.
Да, гораздо логичнее если бизнес не большой, писать чтото под конкретную задачу, чем кстати многие и занимаются наевшись 1С.
Заставить, при прочих равных, работать 1с гораздо сложнее. Она будет или тормозить сильнее, или дороже обходится в разработке.
А то что ею пользуются, ну это во первых привычка, во вторых - некоторым так проще с государством взаимодействовать, а в третих - заслуга лукавой модели самой 1с, в которой часть разработки (актуализацию конфигурации под современную платформу например) можно вынести за скобки, как будто ее и нет. Пока петух в зад не клюнет.
Очнь интересно но ничего не понятно. Новости удручают.
Это все основано на бизнесс модели прошлого века где все стандартизировано. Но сегодня все несколько иначе. И такие негибкие авторитарные модели не везде продолжают работать (так же хорошо как раньше).
Мы же не про вас говорим - я прекрасно понимаю что в 1С много людей есть которые могут использовать 1С гораздо лучше. Но устроена эта система так, что потворствует зарытым нелучшего вида решениям. О чем и речь
Вы когда читаете мой текст все время исходите из контекста в котором я якобы утверждаю о наличии проблем в 1с, и одновременном их отсутствии в других системах. Это лишает смысла всю переписку так как в моем тексте ничего похожего нет. Во всех системах есть проблемы с обновлением, и тп.
Скажем вот вы утверждаете что во всех языках есть горе разработчики. Но с этим никто и не спорит, ваши возражения бессмысленны. Здесь речь идет о том что сама концепция 1С рассчитана на них. Она располагает к тому, чтобы тащить в проекты все что формально работает даже обладая при этом чудовищной избыточностью. А то и вовсе наоборот - писать самобытный код руководствуясь только фантазией. Причем основанный не на каких то устоявшихся подходах, абстракциях, структурах, а чисто на 1Сных фичах оставшихся еще наверное, с того периода когда они запилили бухгалтерию.
И да - мы говорим о проблеме разработки 1С в том числе и как о проблеме разработчика, так как в 1С довольно замкнутое и косное сообщество гораздо сильнее влияющее на любого кто решил себя связать с этой платформой.
Собственно - о чем и речь, 1С не просто не очень хороша, она так задумана.
Именно поэтому ruby постоянно выбирают абстрактные программисты и его доля растет естественным путем. А 1С даже в условиях авторитарности и директивности - нишевое решение, во многом основанное на недальновидности бизнеса.
Да - применимо, но только в 1с для них создана "питательная среда".
А бизнесу - очень даже нужен. Так им с ним жить.
С этим никто и не спорит - это как раз одно из оснований проблемы, которое в сочетании с концепцией 1с дает проблемы. Причем чем позже эти проблемы возникают - тем труднее решаются.
Тем временем все эти годы для бизнеса создается видимость что конфа полноценно поддерживается разработчиками. А потом выясняется что для какой то фичи на управляемых формах - надо всю ее переписать с нуля (в том числе и в той части в которой она никогда не была нужна, в том числе и в той части, в которой она - плод сочетания уникальной фантазии разработчика (зачастую с самыми базовыми знаниями с аналогом которых он бы на ROR в прод не вышел ) и каких то чисто 1Сных фищечек).
Переписывать надо потому, что изменения в платформе не учитывались при доработках сразу. Потому что очень ресурсоемки и по деньгам и по времени, а еще и не очевидны бизнесу "на берегу". И еще надо найти того, кто возьмется за 15 летний проект.
Мне тоже кажется - что не нужна. Но мы не говорим о том что кажется.
Мы говорим о том что есть.
И пример вполне конкретный. Или вам dt`шку надо выгрузить? Я думаю нет.
Вот конкретная задача - управление 10 таблицами. Оно реализовано на базе УТ. Что вам еще нужно знать, чтобы сравнить этот реальный кейс с другими подходами, навроде RoR? В которых такое попросту даже невозможно?
Я так понимаю, претензии к модульности не в том что не подключить чтото по желанию, а в том что основа включает сразу все. От чего нельзя отказаться со всеми вытекающими. Грубо говоря - захотели вы покататься на велосипеде, а купили небольшой кантон в Швейцарии где локализовано все производство которое вам в итоге его и дает.
Например есть простая система из 10 таблиц, для ведения которой понадобилось взять целое управление торговлей с доработками. При том что 99 процентов задач под который УТ написана - не нужны. Но так проще - программисты пишут как проще. Причем проще в данном случае - может быть выражено самыми разными способами (в меру понимания каждого программиста, которая для случаев 1с - имеет большой разброс)
В том то и дело что большинству пользователей 90 процентов кода который они получат в 1С - вообще не нужны. Так что эта универсальность она не просто универсальность а неиспользуемая универсальность (нуждающаяся в поддержке).
Чтобы оставаться актуальной в какой то одной небольшой нужной части - любая самописная конфигурация нуждается периодически в существенных изменениях самого разного рода, от внедрения поддержки фичь новой платформы, в том числе и ненужных, но тех, без которых переход не будет возможен , до смены подходов к каким то задачам которые 10 лет назад прихотливо подобрал некий ноунейм-девелопер по своему разумению и по наличию каких-то внутренних самобытных регистров, которые можно использовать 150 разными способами .
Этот набор проблем гораздо более выражен у 1С, чем у чего либо еще. Причем он существует на фундаменте низкого порога входа. Человек уже втянулся, а издержках узнает потом.
При этом тот же подход ROR - он тоже универсален, за счет того что основан на устоявшихся и развивающихся стандартах. Ну навроде описания данных, не привязанного к какому-то нишевому языку. И благодаря этому же - еще и достаточно специален.
Я уже привел пример выше (даже два). Более подробно нет смысла писать. Да и не могу я такое публиковать дентально, на самом деле.
Мы не обсуждаем то что может или не может быть. Мы обсуждаем то что есть. Разработчик который продетектирует базу на языке в котором методология отталкивается от стандартов которые используются везде - имеет пишет менее самобытный (в плохом смысле этого слова) код.
Мы говорим не о том что можно - об этом я отдельно отписался что можно все.
Мы говорим о том как все в реальности пишется в 1с. Либо дорого и долго (понятно почему - темный лес из абстракций 1с не каждый решится осваивать глубоко, так как он не относится к фундаментальным знаниям, в отличии кстати - от ddl) либо быстро и говнокод.
1с хуже по принципу швейцарского ножа, которым можно делать все, но плохо. Конечно же не о том что сделать хорошо невозможно. А о том что культура разработки (включая концепцию самой 1с ) способствует именно этому. Это чисто личное впечатление на основе разных проектов с которыми встречался. И проблем (часто не решаемых оптимально за разумные деньги ).
Плюсы того же ror в том что на нем разработчик часть кода напишет фактически на ddl. В 1с для этого нужны еще и абстракции 1с.
А часть вариантов с реализацией 1с будет еще и с какими нибудь недостатками которые вылезут потом.
Они указаны как частный случай. Речь не шла про то что задачи бизнеса это только интерфейсы.
Еще одна история есть про 1С. Локальный какой то полуфранчайзи в регионе - постпредством полутора программистов поддерживал систему УП, помоему, и существенно переработал ев специализированную. Речь идет о бизнесе близком к среднему.
В итоге сегодня эту конфигурацию реальному среднему бизнесу не потянуть в той полноте разработки которая бы сделала ее актуальной с точки зрения соответствия платформе. И фактически это приводит к патовой ситуации, когда нужно разрабатывать старую версию. И не иметь всех тех плюшек которые есть в новой.
И это не считая огромного техдолга, который накопившись - стал оказывать влияние на быстродействие. И требовать отдельной работы. В итоге контора в части филиалов соскочила уже с 1С. Там тоже есть свои проблемы, но не такие глобальные.
Никакие изменения в планировании вообще никак нас не касаются. Мы получаем конкретный набор данных выгрузкой. И нам без разницы чем и как она генерируется. Да мы и не знаем таких деталей - знаем что из 1с.
Но в принципе уже недалеко от того чтобы самостоятельно их генерировать на своей стороне, прямо сразу в свою структуру таблиц. Я пока что этим занят в порядке самообучения - на rails. И это выгляди гораздо круче по возможностям. Хотя практика покажет конечно.
Нет, не лезем. Нам делают выгрузки и мы уже с ними работаем.
Я не хочу сказать что у Rails есть качество убийцы 1C но ряд типовых задач среднего бизнеса на нем на порядки быстрее выходят, например интерфейсы к БД. А сама разработка - фактически отталкивается от абстракций DDL (в отличии от 1С с ее регистрами и тд.).
Для разработчика SQL Rails прямо как продолжение рук). Я считаю что он серьезно потреплет 1С.