"Интерполируем" в лучшем случае. В худшем экстраполируем. Тогда ИИ начинает галлюцинировать. Беда в том, что мы можем отличить интерполяцию от экстраполяции только в простейших случаях, поскольку даже не знаем размерностей "пространства задач" и "пространства решений".
Люди, работающие в командах, организациях и корпорациях - это разные люди, независимо от квалификации. По вашему комментарию ясно, что в корпорацию вам не надо. Пользы не будет ни вам, ни им. Так за тем там HR и сидят, чтобы таких как мы не пускать: любите волю - ищите соучастников и творите в свое удовольствие. "Это АРМИЯ, сынок". Если не готов красить траву и драить плац, то чего приперся? Ответить "как положено" - простейший тест на пригодность к ходьбе строем.
Тем не менее вы, насколько я понял, утверждаете, что есть фирмы, где работает "квалифицированный и ответственный персонал", соблюдающий технологию разработки и где дурацкие ошибки в продукте не встречаются. Увы, я не встречал. А я побывал на всех сторонах всех баррикад в этом бизнесе.
И все же говорил я не о том. А о том, что не встречал разумно устроенной службы поддержки. А это прежде всего персонализация. Если это новичок, который ищет, где галочку поставить, то ему может ответить новичок, умеющий искать ответы в инструкции. А то и ИИ. А если это квалифицированный пользователь со стажем в несколько лет, то его обращение нет смысла перехватывать службе поддержки. Сообщение типа: "Результаты расчета на вот таких данных противоречат физическому смыслу задачи" не нужно рассматривать в службе поддержки. Оно предназначено вообще не программистам.
Нужно было срочно доделать один проект. Мы как всегда наивно оценили трудоемкость в 6 часов вдвоем (у нас вдвоем производительность заметно выше, чем суммарная порознь). Приехал я к напарнику домой в субботу среди дня и впряглись. Что в ночь ушли я отметил. Когда результат нас удовлетворил я посмотрел на часы на стене и сказал: почти 6, уже метро работает. Он заметил - шесть вечера. 28 часов плотной работы "в потоке". И нам уже было за 40...
Теперь я уже на стороне тех, кто про "не больше чем 4 часа" твердит.
Как будто мы были мудрее... Я в 1981 году изобрел сортировку слиянием. Очень изумлялся, что получилось быстрее n-квадрат. Потом конечно нашел в книжке. Но ведь чукча не читатель....
Большинство "новых прогрессивных идей" в ИТ это хорошо забытые не такие уж старые. Примерно раз в 5-8 лет большинство подходов переоткрываются под новыми именами.
Хороших служб поддержки не бывает. Потому что целью организации службы поддержки является замена дорогих квалифицированных специалистов на дешевых сотрудников, которые будут зачитывать клиенту инструкцию.
Это полезно, если предполагаются неквалифицированные пользователи, которые инструкцию не читали и не собираются.
Если же продукт достаточно сложный и требует на стороне клиента квалифицированного персонала, то "первая линия поддержки" лишняя. Тем более "нулевая". Если уж я звоню разработчикам и говорю, что обнаружил ошибку, то не надо зачитывать мне страницы описания программы. И "ставить в очередь на рассмотрение" мою заявку не нужно.
Хорошо, что часто я могу позвонить техническому директору и сказать: "в форме 14 поля 3 и 4 перепутаны, пожалуйста прямо сейчас подойди к соответствующему программисту и пусть при тебе исправит". И у меня через пару часов появляется новая сборка. Но если клиент лично с разработчиками не знаком?
То есть я должен был сначала объявить, что мой опыт программирования перевалил за полвека, а уже потом комментировать? Перечислять языки и архитектуры компьютеров надо?
Вы написали 42 функции умеющие работать с 7-ю разными типами данных.
Через 12 лет в ваш код потребовалось добавить 8-й тип данных.
Ваш "потомок" благополучно модифицировал 40 функций. Еще 2 он не обнаружил.
Клиенты обрадовались новым возможностям и обновили программу, но через месяц посыпались рекламации.
Думаете это умозрительный пример? Вот только что закончил возиться с подобной проблемой. Чтобы разобраться с задачей которая развивалась более 49 лет пришлось переписать ее на другой язык.
Крупные программистские проекты потому и ПРОЕКТЫ, что нуждаются в предварительном проектировании. Перечисленные недостатки ООП являются недостатками при отсутствии предварительного проектирования. Человек, который опишет развитие продукта на десяток лет вперед, может вообще не знать языка программирования, на котором будет вестись разработка.
Функциональное программирование более гибкое, соглашусь. Податливо, как пластилин. Очень удобно для научных задачек и сольного программирования. НО ЗАВОДЫ ИЗ ПЛАСТИЛИНА НА СТРОЯТ.
У реляционных баз данных есть важнейшее преимущество: за ними стоит строгая математическая дисциплина - реляционная алгебра. Альтернативные варианты основаны на идеях, представлениях и рассуждениях, что ставит под сомнение надежность результатов.
Оказалось проще всего заставить пользователя расставить пожелания строго по ранжиру.
Если среди пожеланий к сменному расписанию для цеха есть:1_выпустить пару дополнительных деталей А24117; 2_выделить время на профилактику оборудования STO-4; 3_отпустить Михалыча на полчаса раньше, то пусть начальник определит, в каком порядке будем их отбрасывать. Это и ему понятнее и алгоритм получается быстрым.
Беда в том, что множество вариантов "удовлетворяющих всем ограничениям" как правило пусто. Потому что кроме ограничений физических накидывают кучу пожеланий. И решение сводится как раз к определению, от каких требований придется отказаться, чтобы расписание составилось.
До чего дошел прогресс. Там же экспоненциальная сложность. Значит не такая уж большая размерность задачи у вас была.
Мы эту задачу решали в конце 70х на СМ-1. Пришлось придумывать очень хитрый алгоритм. Даже не так: пришлось придумывать очень хитрую постановку задачи, чтобы составить расписание для вуза. А потом для цеха. А потом для Центра подготовки космонавтов. И еще для управления полетами в зоне аэропорта.
А потом все это было сдано в утиль вместе с "устаревшей вычислительной техникой".
Про коррупцию я ни слова не написал. Мы совсем про разное.
В начале 90-х в Ленинграде проводилась деловая игра с участием представителей власти, бизнеса и научного сообщества. Там один бизнесмен очень хорошо сформулировал: "Мы будем работать при любом законодательстве. При любом законодательстве мы будем получать прибыль. А вот будет ли от нашей деятельности польза стране, городу, населению и т.д. - зависит от законодательства. Но это не наш вопрос."
Так что претензии не к кооперативам, а к законодателям.
Если кооперативам дали больше экономической свободы, чем государственным предприятиям, именно эта РАЗНИЦА стала основным источником прибыли кооперативов. И самой важной деятельностью. Кооперативы стали прежде всего механизмом превращения безналичных рублей в наличные. Лишая госпредприятия оборотных средств и выбрасывая необеспеченные деньги на потребительский рынок. Это была "дыра ниже ватерлинии" из-за которой СССР и затонул..
Ну разумеется, Тарасов не выдавал лицензии на внешнюю торговлю, как и другие кооператоры не выдавали лицензии на превращение безналичных денег в наличные.
Но кооперативы имели права, которых у госпредприятий не было. И превращали эти права в деньги. Вот такая "торговля правами" была выгоднее, чем любое производство.
В результате, вместо того, чтобы заполнить рынок дополнительными товарами, они залили его дополнительными деньгами. Превратив хронический дефицит в тотальный.
Тарасов сам неоднократно рассказывал, что через Исток вели внешнеэкономическую деятельность целые отрасли. Просто потому, что это требовало на порядок меньше согласований и экономило время.
Артем Тарасов в годы Перестройки был вице-президентом Союза объединённых кооперативов СССР и одновременно генеральным директором внешнеэкономической ассоциации «Исток».
Тарасов приобрёл известность в СССР и за рубежом как легальный советский миллионер, которому по решению возглавляемого им кооператива «Техника» за январь 1989 года была выписана заработная плата в 3 миллиона рублей
Вы видимо имели в виду Вадима Туманова, но он умудрялся вести негосударственный бизнес задолго до перестройки.
Тридцать лет назад мне приходилось писать ассемблерные вставки в код на Паскале, чтобы повысить производительность в 15 раз. Но уже следующая версия компилятора генерировала код, аналогичный моему.
Если имеет место заметная разница в производительности, то это означает недоработку авторов компилятора. Это не головная боль прикладного программиста. Его дело выбрать эффективный АЛГОРИТМ и реализовать его максимально прозрачным образом.
Кооперативы должны были наполнить потребительский рынок дополнительными товарами, а они наполнили его дополнительными деньгами. Это была "дыра ниже ватерлинии" окончательно утопившая экономику СССР. Торговать правами оказалось много выгоднее, чем что-то производить. Артем Тарасов торговал правом внешней торговли. Большинство же правом преобразования безналичных денег в наличные.
Речь не просто о диалоге. Вы говорите о научном споре, где цель обеих сторон прежде всего корректировать собственное мнение на основе новых данных. Но научное мышление для человека неестественно и потому трудозатратно. Оно требует крайней дисциплины мышления.
Большинство людей (и даже профессиональные ученые за пределами своей области) пользуются бытовым мышлением. И соответственно их споры имеют целью "доказать этому идиоту, что он дурак". Какую платформу и методику им не предлагай, все равно получим либо бесконечную собачью свалку, либо объединение единомышленников, доводящих друг друга до фанатизма.
"Интерполируем" в лучшем случае. В худшем экстраполируем. Тогда ИИ начинает галлюцинировать. Беда в том, что мы можем отличить интерполяцию от экстраполяции только в простейших случаях, поскольку даже не знаем размерностей "пространства задач" и "пространства решений".
Люди, работающие в командах, организациях и корпорациях - это разные люди, независимо от квалификации. По вашему комментарию ясно, что в корпорацию вам не надо. Пользы не будет ни вам, ни им. Так за тем там HR и сидят, чтобы таких как мы не пускать: любите волю - ищите соучастников и творите в свое удовольствие. "Это АРМИЯ, сынок". Если не готов красить траву и драить плац, то чего приперся? Ответить "как положено" - простейший тест на пригодность к ходьбе строем.
Тем не менее вы, насколько я понял, утверждаете, что есть фирмы, где работает "квалифицированный и ответственный персонал", соблюдающий технологию разработки и где дурацкие ошибки в продукте не встречаются. Увы, я не встречал. А я побывал на всех сторонах всех баррикад в этом бизнесе.
И все же говорил я не о том. А о том, что не встречал разумно устроенной службы поддержки. А это прежде всего персонализация. Если это новичок, который ищет, где галочку поставить, то ему может ответить новичок, умеющий искать ответы в инструкции. А то и ИИ. А если это квалифицированный пользователь со стажем в несколько лет, то его обращение нет смысла перехватывать службе поддержки. Сообщение типа: "Результаты расчета на вот таких данных противоречат физическому смыслу задачи" не нужно рассматривать в службе поддержки. Оно предназначено вообще не программистам.
Нужно было срочно доделать один проект. Мы как всегда наивно оценили трудоемкость в 6 часов вдвоем (у нас вдвоем производительность заметно выше, чем суммарная порознь). Приехал я к напарнику домой в субботу среди дня и впряглись. Что в ночь ушли я отметил. Когда результат нас удовлетворил я посмотрел на часы на стене и сказал: почти 6, уже метро работает. Он заметил - шесть вечера. 28 часов плотной работы "в потоке". И нам уже было за 40...
Теперь я уже на стороне тех, кто про "не больше чем 4 часа" твердит.
Мы говорим о реальности или идеальном мире?
Мы ждали исправления тривиальной ошибки в Автокаде 3 года!
Они просто перепутали в одном из режимов масштаб чертежа и масштаб экрана.
Сколько тысяч сообщений об этой ошибке поступило в службу поддержки? Но очередь в списке необходимых изменений подошла только три версии спустя.
Корпорации со всеми своими системами менеджмента качества выдают код ни сколько не лучше кустаря-одиночки.
Как будто мы были мудрее... Я в 1981 году изобрел сортировку слиянием. Очень изумлялся, что получилось быстрее n-квадрат. Потом конечно нашел в книжке. Но ведь чукча не читатель....
Большинство "новых прогрессивных идей" в ИТ это хорошо забытые не такие уж старые. Примерно раз в 5-8 лет большинство подходов переоткрываются под новыми именами.
Хороших служб поддержки не бывает. Потому что целью организации службы поддержки является замена дорогих квалифицированных специалистов на дешевых сотрудников, которые будут зачитывать клиенту инструкцию.
Это полезно, если предполагаются неквалифицированные пользователи, которые инструкцию не читали и не собираются.
Если же продукт достаточно сложный и требует на стороне клиента квалифицированного персонала, то "первая линия поддержки" лишняя. Тем более "нулевая". Если уж я звоню разработчикам и говорю, что обнаружил ошибку, то не надо зачитывать мне страницы описания программы. И "ставить в очередь на рассмотрение" мою заявку не нужно.
Хорошо, что часто я могу позвонить техническому директору и сказать: "в форме 14 поля 3 и 4 перепутаны, пожалуйста прямо сейчас подойди к соответствующему программисту и пусть при тебе исправит". И у меня через пару часов появляется новая сборка. Но если клиент лично с разработчиками не знаком?
То есть я должен был сначала объявить, что мой опыт программирования перевалил за полвека, а уже потом комментировать? Перечислять языки и архитектуры компьютеров надо?
Вы написали 42 функции умеющие работать с 7-ю разными типами данных.
Через 12 лет в ваш код потребовалось добавить 8-й тип данных.
Ваш "потомок" благополучно модифицировал 40 функций. Еще 2 он не обнаружил.
Клиенты обрадовались новым возможностям и обновили программу, но через месяц посыпались рекламации.
Думаете это умозрительный пример? Вот только что закончил возиться с подобной проблемой. Чтобы разобраться с задачей которая развивалась более 49 лет пришлось переписать ее на другой язык.
Крупные программистские проекты потому и ПРОЕКТЫ, что нуждаются в предварительном проектировании. Перечисленные недостатки ООП являются недостатками при отсутствии предварительного проектирования. Человек, который опишет развитие продукта на десяток лет вперед, может вообще не знать языка программирования, на котором будет вестись разработка.
Функциональное программирование более гибкое, соглашусь. Податливо, как пластилин. Очень удобно для научных задачек и сольного программирования. НО ЗАВОДЫ ИЗ ПЛАСТИЛИНА НА СТРОЯТ.
У реляционных баз данных есть важнейшее преимущество: за ними стоит строгая математическая дисциплина - реляционная алгебра. Альтернативные варианты основаны на идеях, представлениях и рассуждениях, что ставит под сомнение надежность результатов.
Оказалось проще всего заставить пользователя расставить пожелания строго по ранжиру.
Если среди пожеланий к сменному расписанию для цеха есть:1_выпустить пару дополнительных деталей А24117; 2_выделить время на профилактику оборудования STO-4; 3_отпустить Михалыча на полчаса раньше, то пусть начальник определит, в каком порядке будем их отбрасывать. Это и ему понятнее и алгоритм получается быстрым.
Беда в том, что множество вариантов "удовлетворяющих всем ограничениям" как правило пусто. Потому что кроме ограничений физических накидывают кучу пожеланий. И решение сводится как раз к определению, от каких требований придется отказаться, чтобы расписание составилось.
"Брутфорсом его можно было взять за час."
До чего дошел прогресс. Там же экспоненциальная сложность. Значит не такая уж большая размерность задачи у вас была.
Мы эту задачу решали в конце 70х на СМ-1. Пришлось придумывать очень хитрый алгоритм. Даже не так: пришлось придумывать очень хитрую постановку задачи, чтобы составить расписание для вуза. А потом для цеха. А потом для Центра подготовки космонавтов. И еще для управления полетами в зоне аэропорта.
А потом все это было сдано в утиль вместе с "устаревшей вычислительной техникой".
Про коррупцию я ни слова не написал. Мы совсем про разное.
В начале 90-х в Ленинграде проводилась деловая игра с участием представителей власти, бизнеса и научного сообщества. Там один бизнесмен очень хорошо сформулировал: "Мы будем работать при любом законодательстве. При любом законодательстве мы будем получать прибыль. А вот будет ли от нашей деятельности польза стране, городу, населению и т.д. - зависит от законодательства. Но это не наш вопрос."
Так что претензии не к кооперативам, а к законодателям.
Если кооперативам дали больше экономической свободы, чем государственным предприятиям, именно эта РАЗНИЦА стала основным источником прибыли кооперативов. И самой важной деятельностью. Кооперативы стали прежде всего механизмом превращения безналичных рублей в наличные. Лишая госпредприятия оборотных средств и выбрасывая необеспеченные деньги на потребительский рынок. Это была "дыра ниже ватерлинии" из-за которой СССР и затонул..
Ну разумеется, Тарасов не выдавал лицензии на внешнюю торговлю, как и другие кооператоры не выдавали лицензии на превращение безналичных денег в наличные.
Но кооперативы имели права, которых у госпредприятий не было. И превращали эти права в деньги. Вот такая "торговля правами" была выгоднее, чем любое производство.
В результате, вместо того, чтобы заполнить рынок дополнительными товарами, они залили его дополнительными деньгами. Превратив хронический дефицит в тотальный.
Тарасов сам неоднократно рассказывал, что через Исток вели внешнеэкономическую деятельность целые отрасли. Просто потому, что это требовало на порядок меньше согласований и экономило время.
Артем Тарасов в годы Перестройки был вице-президентом Союза объединённых кооперативов СССР и одновременно генеральным директором внешнеэкономической ассоциации «Исток».
Тарасов приобрёл известность в СССР и за рубежом как легальный советский миллионер, которому по решению возглавляемого им кооператива «Техника» за январь 1989 года была выписана заработная плата в 3 миллиона рублей
Вы видимо имели в виду Вадима Туманова, но он умудрялся вести негосударственный бизнес задолго до перестройки.
Тридцать лет назад мне приходилось писать ассемблерные вставки в код на Паскале, чтобы повысить производительность в 15 раз. Но уже следующая версия компилятора генерировала код, аналогичный моему.
Если имеет место заметная разница в производительности, то это означает недоработку авторов компилятора. Это не головная боль прикладного программиста. Его дело выбрать эффективный АЛГОРИТМ и реализовать его максимально прозрачным образом.
Кооперативы должны были наполнить потребительский рынок дополнительными товарами, а они наполнили его дополнительными деньгами. Это была "дыра ниже ватерлинии" окончательно утопившая экономику СССР. Торговать правами оказалось много выгоднее, чем что-то производить. Артем Тарасов торговал правом внешней торговли. Большинство же правом преобразования безналичных денег в наличные.
Речь не просто о диалоге. Вы говорите о научном споре, где цель обеих сторон прежде всего корректировать собственное мнение на основе новых данных. Но научное мышление для человека неестественно и потому трудозатратно. Оно требует крайней дисциплины мышления.
Большинство людей (и даже профессиональные ученые за пределами своей области) пользуются бытовым мышлением. И соответственно их споры имеют целью "доказать этому идиоту, что он дурак". Какую платформу и методику им не предлагай, все равно получим либо бесконечную собачью свалку, либо объединение единомышленников, доводящих друг друга до фанатизма.