В отличие от классических языков программирования, которые независимы от БД и прикладных объектов,
программа 1С сильно привязана к структурам данных в БД и к визуальным объектам.
А что если это выгодно не только Apple, но и пользователям?
Intel x86 тоже десятилетия существует, но в последние годы стал буксовать и проваливать планы по развитию
Софт, софт, софт.
x86 на рынке держит софт.
А Apple такая контора, что может заставить переписать софт на новую платформу. Это уже было в её истории.
Насчет выгоды пользователям я бы посомневался:
1) Если ваш любимый софт более не развивается, не поддерживается, но вас устраивает в том виде что он есть, то вы его просто потеряете.
2) Процессоры AMD/Intel внутри давно уже не x86 и никакого значительного преимущества по простоте и экономичности у ARM нет. Ну если конечно не забывать еще и про производительность, которая у ARM сильно отстает.
Intel x86 тоже десятилетия существует, но в последние годы стал буксовать и проваливать планы по развитию, тогда как Apple Silicon продолжает расти в производительности год от года.
Растет по производительности но не догоняет Intel/AMD. Даже рядом.
Но при этом вы беретесь делать то, для чего нужно быть каким-никаким, но экспертом в конкретной области?
Обсуждать качество того, чего никогда и не видели?
Конечно, у 1С, как у любого крупного продукта есть косяки.
Но чтобы их обсуждать — нужно разбираться в теме обсуждения.
Вы вообще представляете себе — какие именно задачи решает типичный программист 1С? Типичная работа — корректировка кода под изменившийся бизнес-процесс.
При такой схеме работы написание юнит-теста, займет сопоставимо времени с собственно модификацией программы.
Важно: этот юнит-тест уже не будет иметь смысла уже очень скоро в следующей итерации бизнес-процессов.
Просто не возникает ситуации, где автоматические тесты полезны — когда пишем код, вновь написанное ломает код, и тестами проверяем поломанное.
P.S.:
Чтобы не считали воинстующим невеждой:
Я организую автоматическое тестирование, когда пишу совсем другие вещи. Например, бэкенд-сервера.
Но если вы просто обслуживаете 1С на предприятии — то пользы от автоматического тестирования просто не поймаете.
Язык программирования D со встроенной поддержкой тестов появился в 2001.
1С: Предприятие 8.0 появился в 2002, а тестов как не было, так за почти 20 лет и не прикрутили.
Ну не логично же.
В 2001 году появился какой то язык, так и не ставший известным и популярным.
И разработчики 1С, которые к тому времени уже вовсю пилили свой продукт — должны были понять, что эти концепции никому не известного нового языка ценны? И тут же начать переделку, с этого нового языка тут же взять концепции?
Вы сейчас демонстрируете пословицу «Задним умом все крепки».
А если я мак покупаю только ради железа, а сама макось мне принципиально не подходит для работы (CADы, ПЛИСы и прочий софт, который отсутствует под макосью, а любая эмуляция для него выливается в потерю производительности/отказ запускаться), он(тачбар) под линуксом/виндой работать нормально будет?
Windows можно поставить. Для этого есть такая штука Boot Camp, штатная функциональность, сделанная Apple.
Linux — крайне затруднительно.
Ради железа — можно взять не Mac за примерно такие же деньги взять с таким же хорошим железом, но где встанет нормально Linux.
1С Предприятие — стабильное решение не годы, не отличающееся качеством кода.
Нормальное там качество кода. Для продукта такой сложности количество ошибок в 1С удивительно невелико.
Но большее число ошибок содержит не сама 1С, а большее число ошибок совершают те, кто её обслуживают на местах. К сожалению, они не все достаточно квалифицированы.
ЗАПЛАТИТЬ за возможность разрабатывать под их платформу
Вы только вдумайтесь в эту фразу, тут вообще без коментариев.
Для малопопулярной платформы — ага, звучит глупо.
Но, поскольку делать под Мак нет недостатка в разработчиках желающих, отчего бы и не брать денег за вход.
Я давно убедился: разработчики языков ничуть не лучше обычных программистов. У них нет никакого уникального знания или экспертизы, которая делала бы их лучше, чем вы.
«Программист» — это всего лишь название большой группы людей с очень разной квалификацией.
Если судить по разнице в оплате труда — то разница по квалификации составляет и сотни тысяч раз.
Осмелюсь предположить, что большая часть отписавшихся тут на Хабре в комментариях — те еще компьютерные «задроты» (не в обиду будет сказано, а с юмором), работающие с мышами по много-много часов ежедневно.
Ну, как уже было сказано, сценарий использования, от которого зависит потребление, и тип батареек сейчас играют решающую роль.
Тип батареек сейчас влияет прежде всего на вес.
Современные мыши хороших производителей уже несколько лет как крайне экономичны, если там нет подсветки. Разве что кроме наибюджетнейших вариантов.
А года 2 назад появились сверхэкономичные сенсоры…
Возьмите какую нибудь Logitech G603, поставьте туда литиевые батарейки (не литиевые аккумуляторы), включите её в неигровой режим.
Я сказал, что постоянная текучка на более-менее сложном и важном проекте — это стресс для начальства, так как плывут строки, надежность зачастую уменьшается и так далее. Если проект не сильно важный (хоть управленец с умным лицом скажет, что это не так), то можно и смириться с текучкой. Если проект не особо сложный (например, в типичном сценарии «сложное ядро — простые плагины»), то текучка тоже не так страшна (в моем примере — текучка в «командах плагинов»).
Я вас уверяю:
Если текучка есть, то она стратегически запланирована руководством.
Скажем, на заре моей карьеры работал в такой фирме: десяки низкоквалифицированных менялись чуть ли не каждые 3 месяца. И всего несколько человек высококвалифицированных (и хорошо оплачиваемых) работали годами (2-3 из них еще там работают, а это более 20 лет). По итогу фирме это было выгодно. Постоянная текучка низкоквалифицированных ничуть не мешала.
Это был не просто важный, а ключевой проект для компании.
У них и сейчас низкоквалифицированные меняются чаще, чем высококвалифицированные. Не раз в 3 месяца, но раз в год — запросто. Ничуть не мешает. Потому как основные мозги просто так от них не уходят.
О!
Метаданные в 1С?
«Нет, не слышал»?
В отличие от классических языков программирования, которые независимы от БД и прикладных объектов,
программа 1С сильно привязана к структурам данных в БД и к визуальным объектам.
Софт, софт, софт.
x86 на рынке держит софт.
А Apple такая контора, что может заставить переписать софт на новую платформу. Это уже было в её истории.
Насчет выгоды пользователям я бы посомневался:
1) Если ваш любимый софт более не развивается, не поддерживается, но вас устраивает в том виде что он есть, то вы его просто потеряете.
2) Процессоры AMD/Intel внутри давно уже не x86 и никакого значительного преимущества по простоте и экономичности у ARM нет. Ну если конечно не забывать еще и про производительность, которая у ARM сильно отстает.
Растет по производительности но не догоняет Intel/AMD. Даже рядом.
Так что это не одно и то же.
Что там c MS Dynamics? ABAP? SAP?
За 2 года как правило люди проходят путь от начинающего новичка до крепкого джуна. Лучшие через 2 года уже могут считаться начинающим миддлом.
А джун — это не эксперт.
Это тот чел, в косяках которого виноват кто-то другой.
Я бы предположил, что вы особо талантливы и за 2 года стали спецом, но судя по тому что вы не знали, что тесты в 1С есть, то, извините, нет.
Позвольте не поверить вашему
неэкспертному мнению.Еще раз:
Вы рассуждаете о тех вещах, о которых понятия не имеете, вот цитата вашего комментария:
И это вы пишете об известнейшем продукте.
Еще раз:
Вы рассуждаете о вещах, в которых некомпетентны.
Но при этом вы беретесь делать то, для чего нужно быть каким-никаким, но экспертом в конкретной области?
Обсуждать качество того, чего никогда и не видели?
Конечно, у 1С, как у любого крупного продукта есть косяки.
Но чтобы их обсуждать — нужно разбираться в теме обсуждения.
Вы вообще представляете себе — какие именно задачи решает типичный программист 1С? Типичная работа — корректировка кода под изменившийся бизнес-процесс.
При такой схеме работы написание юнит-теста, займет сопоставимо времени с собственно модификацией программы.
Важно: этот юнит-тест уже не будет иметь смысла уже очень скоро в следующей итерации бизнес-процессов.
Просто не возникает ситуации, где автоматические тесты полезны — когда пишем код, вновь написанное ломает код, и тестами проверяем поломанное.
P.S.:
Чтобы не считали воинстующим невеждой:
Я организую автоматическое тестирование, когда пишу совсем другие вещи. Например, бэкенд-сервера.
Но если вы просто обслуживаете 1С на предприятии — то пользы от автоматического тестирования просто не поймаете.
Ну не логично же.
В 2001 году появился какой то язык, так и не ставший известным и популярным.
И разработчики 1С, которые к тому времени уже вовсю пилили свой продукт — должны были понять, что эти концепции никому не известного нового языка ценны? И тут же начать переделку, с этого нового языка тут же взять концепции?
Вы сейчас демонстрируете пословицу «Задним умом все крепки».
Технические оценки там не причем. ARM уже много десятилетий как существует.
Денег больше хотят — самим делать процы выгоднее.
Это очень известный продукт.
Если лично вы не слышали — то это ваша проблема как
непрофессионала.Какая разница стоит на продукте шильдик 1С или нет, если он решает свои задачи.
Например, так
github.com/xDrivenDevelopment/xUnitFor1C
Python, PHP, JavaScript — живут себе без статической типизации.
А юнит-тесты в 1С есть. Но не все об этом знают, как мы видим по вашему тексту.
Ну или более свежие и более дорогие процессоры на более тонком тех. процессе.
Windows можно поставить. Для этого есть такая штука Boot Camp, штатная функциональность, сделанная Apple.
Linux — крайне затруднительно.
Ради железа — можно взять не Mac за примерно такие же деньги взять с таким же хорошим железом, но где встанет нормально Linux.
Нормальное там качество кода. Для продукта такой сложности количество ошибок в 1С удивительно невелико.
Но большее число ошибок содержит не сама 1С, а большее число ошибок совершают те, кто её обслуживают на местах. К сожалению, они не все достаточно квалифицированы.
Но да, виновата у них всегда 1С.
Для малопопулярной платформы — ага, звучит глупо.
Но, поскольку делать под Мак нет недостатка в разработчиках желающих, отчего бы и не брать денег за вход.
«Программист» — это всего лишь название большой группы людей с очень разной квалификацией.
Если судить по разнице в оплате труда — то разница по квалификации составляет и сотни тысяч раз.
Осмелюсь предположить, что большая часть отписавшихся тут на Хабре в комментариях — те еще компьютерные «задроты» (не в обиду будет сказано, а с юмором), работающие с мышами по много-много часов ежедневно.
Тип батареек сейчас влияет прежде всего на вес.
Современные мыши хороших производителей уже несколько лет как крайне экономичны, если там нет подсветки. Разве что кроме наибюджетнейших вариантов.
А года 2 назад появились сверхэкономичные сенсоры…
Возьмите какую нибудь Logitech G603, поставьте туда литиевые батарейки (не литиевые аккумуляторы), включите её в неигровой режим.
И о батарейках вы вспомните лет через 5…
Есть еще CAD 3D, использование GPGPU в нейросетях и пр. задачи, где нужна видеокарта — и всё это на работе.
У AMD Ryzen — нет.
Эта область занята кэшем.
Там радикальная разница — с встроенной графикой кэша всего 4, а без встронной графики кэша сразу 32.
Я вас уверяю:
Если текучка есть, то она стратегически запланирована руководством.
Скажем, на заре моей карьеры работал в такой фирме: десяки низкоквалифицированных менялись чуть ли не каждые 3 месяца. И всего несколько человек высококвалифицированных (и хорошо оплачиваемых) работали годами (2-3 из них еще там работают, а это более 20 лет). По итогу фирме это было выгодно. Постоянная текучка низкоквалифицированных ничуть не мешала.
Это был не просто важный, а ключевой проект для компании.
У них и сейчас низкоквалифицированные меняются чаще, чем высококвалифицированные. Не раз в 3 месяца, но раз в год — запросто. Ничуть не мешает. Потому как основные мозги просто так от них не уходят.
Это таки зависит от вашего бюджета и от желания.
Как правило в офис берут самое дешевое (уж корпус то да).