Юзерша Эпиграмма захотела в цифровое рабство.
Что ж, дело женское.
Если верить картинкам в интернете - некоторые экземпляры еще любят чтобы их заковывали в пушистые розовые наручники, засовывали в рот теннисные шарики и при этом небольно стегали кнутом.
Нет, крик души https://aftershock.news/?q=node/877077, в принципе - по делу. Но чего она не понимает, не будучи инсайдером в индустрии - это то, что программист ныне не ваяет, А ВАЛЯЕТ..
"Это же я вам не клумба" (ц)
Программист берет одну херню, написанную для такой задачи индусами из другой фирмы, громоздит ее на херню другую, побольше и покривее, созданную китайцами, сбоку приляпывает херню третью, древнюю как говно мамонта, так что никто уже не знает откуда она - но все знают, что без нее ничего работать не будет. Все это содержит плохо поддерживаемые перекрестные ссылки и скрипты, забытые разработчиками баги и коллекцию сторонних заплаток для того, чтобы вся конструкция не расползалась.
В итоге она сильно напоминает пресловутую комбинацию говна и палок, где наиоблее проблемные куски посажены на каркас с помощью клея системы "момент" и для большей устойчивости прихвачены скотчем.
Потом наш программист обвешивает свое творение свистелками-перделками под желания заказчика про три перпендикулярные прозрачные линии и выпускает свой продукт, требующий ежемесячного латания, в большой мир.
Автор начинал карьеру во времена, когда компьютер требовал машинного зала, кондиционирования и дизель-генератора. Автор помнит 80-колонные перфокарты и все еще способен свернуть из них пепельницу для работы в ночь. Автор помнит 5-дорожечные перфоленты, 10-мегабайтные диски с пакетом "блинов" и пишущие машинки вместо дисплеев для ввода команд. Все это богатство имело память 256К, крутило до 14 задач одновременно и в свободный кусок позволяло еще и загрузить игру, где по галактике ползали клингоны, которых следовало лупить торпедами, а пишмашинка печатала карту 10х10 как в морском бое с комментариями.
Программирование времен MASM-ассемблера и Борландовского Турбо-Си перестапо быть искусством и стало ремеслом. Чему немало способствовали в изобилии появившиеся кривые инструментарии типа вижуал бэйсика, позволившие вместо одного программиста нанять пяток "ваятелей". Задача программиста трансформировалась из написания короткого, быстрого и изящного кода, умещающегося, образно говоря, в одной кладовке - в составление монструозного проекта на три гектара с колоннами из тех кубиков, которые ему удалось надыбать (вариант - "которые впендюрили его начальству продавцы различных инструментариев").
Один мой товарищ, настоящий программист - из тех, кому ничего не стоило в три часа ночи разбудить вопросом про какую-то фичу 21-го интеррапта специально купил себе часы подводника, с 24х-часовым циферблатом. Все потому что зимою за окном темно и трудно разобрать, ночь или день на проспекте Мира.
Время художников, расписывающих храмы не просто кончилось - а ушло, как Балрог, в глубины мира. Пришло время маляров, красящих заборы.
Теперь, с прогрессом смартфонов каждый продавец пивного ларька, желающий разбогатеть, пробует свои силы в мобильных приложениях и джава-языке, благо заботится обо всем теперь интерпретатор. Те, кто поумней и не торгует пивом, а оторгует диванами - пробуют то же самое, с таким же успехом, на PHP c Питоном (не Монти!)
Что, в принципе, неизбежно, как переизбрание Трампа.
Я дико извиняюсь, накипело.
Комментарии
Папаша просто вас троллит, это абсолютно нормальный алгоритм. Так везде и это правильно, не может один человек разбираться как работают современные субд и как рендерится 3Д графика. Это называется специализация и это как раз то, что позволяет вещи делать лучше.
Немного не так. Миллион строк - УЖЕ написан и содержится в АПИ Виндовса, подключаемых библиотеках и среде разработки.
То есть не требует больших усилий. Если конечно, использовать ранее сделанное другими людьми.
А вот если писать все это барахло с нуля, то тут понадобится в 1 000 000/200= 5000раз больше времени и усилий, чем на программу тратиться сейчас.
Верить можно всем. Бывают задачи совершенно без интерфейса и рюшечек. У нас был 3х-летний проект по переписыванию сетапа, который на 90% состоял из выковыривания багов, сочинённых недоступными предшественниками.
Добро пожаловать, о источник моего вдохновения.
Беда современного состояния АйТи и в частности Сбербанка - что прогресс делается не аналитиками, понимающими что именно нужно и ставящими задачу разработчиками - а продавцами всяческой херни, которую они написали и теперь успешно впендюривают, во все дыры, куда могут.
Не жалея и дыру г-на Грефа.
Вот это я понимаю. Анализ! Уважуха!
Я как в своей жизни руководивший максимум коллективом из 8-10 человек, понимаю как непросто связать в выполнение задач даже такое небольшое количество людей. а тут 6-7 тысяч только ИТ.
И кто скажет что за последние годы сбер не обновился кардинально? И как то это же управляется. Я вообще не представляю как.
Люди, поставленные управлять - тоже не представляют себе как.
Однако Герман Греф "магически" получает официальные государственные награды. Так что тот, кто его награждал, наверное что-то такое знает.
Улюкаев:
Значит ли это, что вместо архитекторов и инженеров точно так же пришло время, условно, простых каменщиков?
Вместо инженеров теперь работает некое чудо с CAD, наученное жать кнопки в нем.
Можно подумать где-то по-другому, возьмем к примеру велосипед. Рама один производитель, тормоза, к примеру, шимано, цепи - еще один, с сцепление, вообще четвертый. Это нормально.
Чтобы понять аналогию, попробуйте представить, что ось переднего колеса в четыре раза тоньше, чем вырез на передней вилке, куда оно должно крепиться. Есть переходник, но он пластмассовый и ломается через три часа езды.
А тормоза, к примеру, удалось достать только от КАМАЗа.
Так доступно?
Проблема не в разных производителях, а в том, что каждая деталь создавалась без учета того, что когда-то ее вставят в велосипед.
В чем ваша ошибка, это в том что вы думаете что программист должен выбирать именно слабосвязанные вещи, но это не так, если программа нормально пишется, то и бд можно выбрать и все остальное и никто ничего не навязывает. Так что ваша аналогия не верна.
Из чего выбрать? Предположим, у меня в программе используются иерархические справочники и часто необходимо отбирать по условию нахождения в какой-либо группе (на произвольном уровне вложенности). И используются таблицы, в которых тип значения колонки зависит от значения в другой колонке. Какую БД (точнее СУБД) предложите выбрать?
Так что очень даже верна. Уже на уровне языка программирования приходится выбирать от чего отказаться. Нужен разбор XML с учётом всех стандартов? Только Java. Нужны продолжения (continuations)? Scheme (или его диалекты). Нужно и то и другое? Делаем «пластмассовый переходник», чтобы из Scheme можно было дёргать библиотеку Java. Или пишем нормальную библиотеку для работы с XML на Scheme (очень дорого).
Так-то соглашусь, но на мой взгляд, проблема не в китайском движке, вуй имелся ввиду наверное, или в яве, а уже в том коде который пишет конкретный прикладной программист. Чаще ошибки в логике, а не в сторонних компонентах, тем более если они уже в стабильной фазе.
Это про вопрос про СУБД? Так я там не про движок спрашивал ,а про СУБД. Предположим, что я хочу написать свой движок. Какую СУБД мне надо выбрать?
Если задача требует использования продолжений, то на яве придётся писать интерпретатор своего языка. Или, опять же, можете предложить кого-то, у кого можно купить Java с функцией call/cc?
Они чаще в той логике, которая чужда для сторонних компонентов. Поэтому я и пишу про «пластмассовый переходник». Вот, например, люди со всем тщанием попробовали реализовать Scheme поверх Java/JVM: https://www.gnu.org/software/kawa/internals/complications.html - количество хрупких костылей впечатляет.
Чисто для интереса, scala слабее чем scheme?
Почему скала работает на jvm, а scheme нет.
Я из мира c# f#, поэтому спрашиваю.
Они плохо сравнимы. Есть то, что есть в Scheme (удаление хвостовых вызовов, продолжения). Есть то, что есть в Scala (типы, классы). Если по общей сложности, то Scala мощнее чем стандарт Scheme. Если сравнивать с таким диалектом Scheme как Racket, то Racket мощнее.
Потому что Scala родилась на JVM и, как следствие, семантика в ней соответствует Java. И из-за этого для эффективного использования скалы приходится всё равно учить Java. Также как для использования F# желательно знать C#. И в C# также невозможно компилировать Scheme.
Ага, спасибо
Ваша ошибка в том, что вы мне эту мысль приписали. О том, что выбирать слабосвязанные вещи должен программист.
Если она нормально пишется, то и вопросов таких не возникает. Тогда выбирает программист. И он ничего не должен, кроме того, чтобы выдать продукт.
Проблема в том, что очень часто выбирают инструментарий менеджеры, которые о программировании не имеют никакого представления. И это происходит все чаще и чаще. И требование "Надо подружить ежа с ужом" приходит с такого уровня, когда либо выполняй (ты ж программист!), либо увольняйся (не можешь сделать простую вещь).
А доказать менеджерам ошибочность подхода, и необходимость писать программы правильно невозможно, у них нет базовых знаний для понимания.
В 90-е программисты работали в конторах, созданных и управляющихся программистами, пусть и бывшими.
Теперь создают компании финансисты, а управляют ими выпускники МБА, где декларируется, что управленец не должен разбираться в сфере деятельности управляемой им компании.
А если продолжать аналогию представьте, что закупками руководит человек, ни разу в жизни не видевший ни велосипеда, ни КАМАЗа. И не желающий на них смотреть.
И тормоза от КАМАЗа он уже купил, и не хочет заново заниматься закупками. И все ваши аргументы разбиваются об его железобетонное: "Вы хотели тормоз - это тормоз, вот в накладной написано, используйте."
Б И Н Г О ! ! !
Не скажу за весь цифровой секс, но секс в эпоху коронавируса недавно попыталась довести до нас Блондинка.
А в чём проблема?
Мощности растут, библиотеки плодятся как кролики, код становится монстроуозным, тестированию не подлежащему (ресурс машины справится), Ждём новый уровень (2 нм?!))
Маркетинг. НЛ!)
Забудьте времена, когда нужно было код вместить в ПЗУ 256 байт!)))
Поколение FI сейчас рулит (Facebook/Instagram)))
Во многих случаях так и есть. А какому тестированию от не подлежит?
регрессионному? на производительность? на совместимость? все тестируется.
Вопрос в том, что тестирование это очень дорогое удовольствие. При инхаус разработках при упоминании о тестовых контурах обычно у руководства делается кислое лицо. Ведь это дополнительные тестовые среды в количестве N штук, похожих на те что боевых средах. А это "косты".. А их всем ит-руководителям положено резать. По должности, у них в KPI обычно это стоит. их премия от этого зависит. Так что.. тестирование.. "ну как нибудь так" (с) Масяня
Я как то наткнулся на статью в которой рассматривался опрос разработчиков, при работе над каким продуктом вы видели самый плохой код с которым приходилось работать..
Меня очень сильно удивило, что на 3м месте была СУБД (система управления базами данных) Oracle. Я очень сильно удивился, ведь это признанный мировой лидер. На этой СУБД работают миллионы компаний 24х7х365. В итоге программисты жаловались на нечитаемый код, с тысячами флагов разбросанных по коду. Секрет оказался прост. Это система тестирования продукта. сотни серверов 24х7 гоняют регрессионные тесты, тесты на производительность и т.п. безостановочно. И плевать сколько и какого качества там программисты. Пока они не добьются нужных результатов при тестировании, релиз не пойдет дальше.
Вот. программисты могут быть любые. Тесты должны быть идеальны.
но кто ж согласится столько ресурсов гонять "впустую"? ))
В свое время довелось поучаствовал в разработке ERP Scala. Тонны индусского говнокода на бейсике, наследованного от времен текстового режима.
Взаимодействие с СУБД MSSQL тоже на уровне текстовых табличных процессоров.
С антипроизводительностью бейсика боролись промежуточной компиляцией в С.
Координаты текстовых окон транслировались в имена экранных форм.
А вот что делать с говнокодом...Каждый разработчик дописывал в начало исходника комментарий с датой доработки, целью и своим ником.
Большая часть ников была индусской, хотя попадались и мексиканские, и норвежские. Так этих комментов были сотни. Максимально переделанный модуль попался - переживший за полтысячи доработок. Причем доработка - это не просто сам программист что-то исправил, а отлаженное изменение функциональности через ТЗ. Модули офигических размеров, потому что индусы копипастили повторяющиеся куски, и при доработках внутри кусков все эти копипасты надо было отловить. Незабываемые ощущения.
Вся эта хрень жила только за счет того, что толпы тестеров ежедневно гоняли тесты каждой ночной сборки, не появились ли побочные эффекты доработок.
На каждого разработчика - по два тестера. Вот так.
Мало кто тестирует все используемые библиотеки. Например, простенькая программа, которая должна читать XML файл и куда-то записывать из-него данные. Думаете, кто-то будет тестировать, что произойдёт, если в файле будет не XML или XML с длиной тэга в 4 гигабайта или ещё какое непотребство?
Годный срач. Ахтунг - пахнет трольчатиной! Автор, нет ли в обсуждении упырей? Сим повелеваю - внести запись в реестр самых обсуждаемых за день.
Прелестна написано..))) по сути и в точности.. Программирование как ширпотреб.. 1С нуна упомянуть.. Эт ваще верх садомазохизма.. Все кривое-косое..а народ кушает в три горла.. А мета-язык от 1с..эт вааще шедевр самого высокого программирования.. А при етом структура бд.. Нормализации данных? Реаляционные бд? Не.. А шо ето такое? 😮
А ну давайте как в Германии, где каждая фирма бухгалтерию сама для себя пишет.
А речь не об этом.. А так то так и происходит.. Берётся базовый хомнокомплект бухгалтерии.. Склада.. И подпорками и подписьками тупо-хреново алаптируеться кастой 1с-программеров к нуждам предприятия гг.. При этом процесс цикличен во времени.. И как лента мёбиуса бесконечен.. 😂
А что тут не так, если у фирмы уникальные бизнес процессы, то только так и может происходить, зато бухгалтер с одной фирмы легко может устроиться в другой. Плюс минус местые отличия, а не переходить с навижн на какой-нибудь датлеф.
Уникальные бизнес процессы? Не смешите.. 😂
Да запросто, я в казахстане на 1с программировал, бывали очень странные бизнес процессы. Плюс законы меняются постоянно, и если что в 1с уже десятелетия как можно самому скл писать и таблицы организовывать как надо.
Странные бизнес процессы.. Они шо там трусы через голову одевают?)) или наркотой торгуют.. Дык там ничего странного.. Пришло и ушло.. LIFO, FIFO.. Ну или самый грамотный подход.. По средневзешенной 😂
Ну к примеру, создание плейлистов на радио и соответсвенно учет сколько выплачивать авторских.
Даже в этом минимальном примере неоднозначно, что именно пришло и ушло. Пришла "Бумага для лазерного принтера, 10 шт" и "Бумага белая, 10 шт", а ушла "Бумага А4 для принтера, 5 шт". Как средневзвешенную считать? Или на склад товар пришёл 5 января, а документы к нему оформлены 10 января, должна ли его стоимость влиять на средневзвешенную при отгрузке 7 января?
А если ещё добавить комиссию, частичную оплату, резервирование, возврат из эксплуатации с частично списанной стоимостью...
Херня.
Сам херня.
Было время, писал бухгалтерию клиентам на ms access, было несколько фирм которые использовали это.
Было время, когда мой брат написал не то, что "Бухгалтерию", а "Предприятие". И было несколько фирм которые использовали это.
А потом пришел 1С. И все умерли.
И это прекрасно.
Сынок, из того что ты в пылу ажиотажа сваял зачем-то кому-то какую-то хрень не следует не только общая тенденция - вообще НИЧЕГО.
Будете спорить, что в Германии большой зоопарк различных решений для бухучета?
Как бы то ни было, 1с это конструктор позволяющий на базе готовых бизнес объектов писать разные учетные системы. Из конкурентов, Майкрософт, САП. Все остально это готовые решения с минимальной возможностью натсройки, все остально пишут руками.
Сынок, ты мудак.
Буду спорить, что "в Германии, где каждая фирма бухгалтерию сама для себя пишет".
С такой способностью к формулирования тебе даже не программировать - а просто считать на калькуляторе противопоказано.
Ну просто вы далеки от программирования, 1с это был такой конструктор, аналог дельфи, который помогал писать готовые решения. Альтернатив в Германии нет, все остальное или готовые нерасширяемые решения, или дорогие типа сап. Если вы такой умный, назовите какие есть еще прикладные программисты аналог 1с в Германии, кроме абапа и майкрософта.
Сынок, повторюсь.
Ты выдал херню. Ее оспорили. Ты полез в бутылку.
Третий раз объяснять это не стану.
Оспорили что, первичное утверждение что лучше популярное распространенное расширяемое решение, чем зоопарк? Я видел только, что эту фразу вывернули и стали спорить сами с собой.
Твоя фраза "в Германии, где каждая фирма бухгалтерию сама для себя пишет".
Если я "вывернул ее наизнанку" - вверни ее пожалуйста обратно, чтоб все видели..
Есть мелкие типовые решения.
Далее кого не устраивает, какие есть альтернативы:
SAP, Microsoft BMS плюс ряд местных
Или фирма сама пишет на чем попадется или заказывает сторонней фирме, которая тоже пишет на чем захочет.
общей платформы вроде 1с, со средой разработки и готовыми бизнес объектами я не слышал.
Тоесть, все эти решения это велосипеды по нааисанию собсвенных обьектов. Как то справочников, журналов и т.д
Понятно. Мудак.
Тебя попросили фразу ввернуть, а ты сам выворачиваешься.
Нехорошо, сынок.
Нагадил - надобно убирать за собой, а не крутить носом, что, не мое, дескать.
Альтернативы ещё хуже. В 1С хоть исходники открыты, можно переписать если надо.
Нормализация данных всегда идёт лесом как только требуется производительность.
У 1С давно реляционные БД. Хоть HSQL, хоть MS SQL, PostgreSQL и Oracle.
Страницы