Автор фантазер. Представим развитие этой фантазии. Есть джун и модель недоИИ. У джуна нет навыков ни добиться от модели толкового результата, ни оценить этот результат. Так же нет и возможности получить для этого опыт т.к. использование недоИИ подобную возможность практически исключает.
Управлять системами недоИИ с толком способен сеньор или способный мидл. Но откуда им будет взяться в будущем? ИТ начнёт превращаться в магию. И то при условии что недоИИ допилят до соответствующего уровня безглючности.
Хороший пример это IBM, которая сначала уволила толпу народа из-за недоИИ, а потом была вынуждена нанять ещё больше чтобы этим самым недоИИ рулить.
Хард-скиллы по-прежнему важны т.к. без них не возможно рулить этим самым недоИИ с положительным результатом. Без экспертизы толку не будет.
НедоИИ лишь позволяет заглянуть в ИТ. Как когда то Борланд дала RAD системы и появились "специалисты" по формошлепству, которые к профессиональному программированию и разработке имели весьма условное отношение. Просто образовалась ниша по созданию чего-нибудь простенького быстро и без геморроя.
Научившись рулить тем же Midjourney художником все равно не стану. И называть себя специалистом в этой области тоже не получится, но это дает мне возможность заглянуть в этот мир и при необходимости получить какой-то результат при полном отсутствии хужественных навыков. Благо, эта область не требует экспертизы, чтобы получить в принципе годный результат, т.к. по сути любой результат будет иметь право на существование. В отличие от разработки всяких систем с помощью недоИИ, где важна точность и корректность результата, что может обеспечить только специалист соответствующего уровня уже имеющий достаточно опыта и практики.
Почитал комментарии и очень рад что они не коррелируют со статьёй.
Молодой разработчик умеет в кубики, он не понимает как все устроено под капотом. Он не способен решить проблему требующую чуть большего погружения в тему.
Сейчас как раз с интересом наблюдаю как одна вполне известная российская компания разработчик одноименной ERP системы пишет продукт под конкретного заказчика. То что там в организационном смысле полный трындец это фигня. Но там адские проблемы с производительностью. Потому что разрабы увлекаются фреймворками. При том что имеющейся толпой, но нормальных разрабов, могли все что нужно написать с нуля и работало бы это гораздо быстрее.
Кто-то скажет сроки. Но торопыжество всегда выходит потом боком. Спешка актуальна, если это стартап, где надо срочно запускаться и бежать опережая возможных конкурентов. Но когда у тебя есть проект с четкими ТЗ подобная схема это путь к катастрофе.
И да, в упомянутом примере ещё и эпический глюкодром. Ну не может же быть так, что в одном месте собрались все балбесы от разработки. Значит, корни проблемы в другом. В походах. Тех самых, про которые так радостно пишет автор. Поэтому сам уже не боюсь будущего. НедоИИ принял как вспомогательный инструмент. А за счёт молодых и успешных разрабов у меня работа точно будет. Ведь кто-то же должен все это приводить в порядок. А молодые уже такими не станут. Просто окружение изменилось и развиваться вглубь станет сложнее.
С одной стороны автор прав. НедоИИ уже прочно вошли в нашу жизнь. И теперь вместо гуглежа можно чатить почти готовое решение. А при использовании специализированных средств скармливать исходники и получать ещё больше пользы.
Только это приведёт не к безработице, а к деградации и катастрофе. Т.к. новым спецам взяться будет неоткуда, а старые будут нужны чтобы поддерживать кучу нагенерированного недоИИ кода. Т.е. меняется уровень абстракции. Либо придётся лезть в код и разбираться с нуля, либо уповать на недоИИ и лезть в промты чтобы перегенерить нужное.
Всё это приведёт к утрате компетенций, навыков и экспертизы. Спецы работу не потеряют. Хоть и не хочется, но придётся дружить с недоИИ. А вот у вкатунов и новичков шансов на будущее нет. Можно въехать на вау-эффекте и нагенерить сферического коня в вакууме. А дальше что? Чтобы контролировать процесс откуда взять компетенции без самостоятельного обучения разработке? Неоткуда. Занавес. С интересом буду смотреть куда нас все это заведёт.
Если отсутствие FK может превратить ваши данные в желе, то ваши архитекторы БД и не только зря получают зарплату.
Ни разу не сталкивались с ситуацией, когда надо что-то поправить уже каким либо способом накосясенное, а эти самые FK люто мешают?
Поэтому давно пришёл к мысли, что FK не только бесполезны, но и вредны.
Про индексы это же явное утрирование. Но есть ещё одна вещь из теории баз данных, которую тоже можно предать анафеме как и FK. Это нормальные формы. Они порой добавляют лютых тормозов путем создания узких мест, если слепо им следовать.
А я вот котам не могу объяснить что "на работе" и потому им придётся терпеть голод до вечера. Ведь я же тут рядом, мой запах, слышен шум издаваемый мною. Под дверью был бы постоянный мяу-мяу. Ведь коты ещё и терпеть не могут закрытых дверей.
Потому, у меня свой формат удаленки. Но до этого человечеству в массе ещё очень далеко. График свободный, главное - результат. Иначе бы удаленка стала адом. Ведь жена тоже на удаленке, рядом :)
Очень странно такое читать. При том что любому ИТшнику должно быть очевидно, что без ИТ сейчас просто никак.
За всю свою карьеру 20+ лет лучшее ИТ встречал у одного логистического оператора. И уходя оттуда спустя несколько лет оставалось ещё достаточно всякого разного неизученного. Такого масштаба была инфраструктура.
Уходил в компанию, где разработка софта это основной бизнес, но меня ждало разочарование. В плане организации процессов, да и сами проекты были далеко не вершиной технической мысли.
В итоге сейчас сам в одной не большой компании строю свое ИТ. Как техдир. Устал от всяких менеджеров и прочих РП.
Так вот без моих усилий развиваться было бы просто не возможно. Excel - не вариант. Как и готовые решения, потому что они деревянные, а нам нужна гибкость. Да ещё и чужое всегда стоит хороших денег. Свое обходится в итоге дешевле, если уметь его готовить :)
Сейчас ИТ есть у всех. При чем хорошее ИТ может быть там, про что большинство даже не слышало. То что на слуху, вроде Яндекса и прочих, это не большой процент.
Ну что же. Начиная читать статью уже предвкушал, как размажу все аргументы в лепешку, но оказалось иначе. Статья это по сути ошибка выжившего. Ведь вряд ли кто-то на полном серьёзе будет ставить крест на всём поколении. Это не так. Вот автор и рассказывает про тех, кто попал в сандартные ситуации, которые никак не связаны именно с поколением.
При этом есть фундаментальные основы почему в целом поколение зумеров более худшие работники чем те же миллениалы. Были такие статьи. Банально отличалось время и условия. Те же миллениалы жили в условиях постоянных перемен к которым приходилось адаптироваться. И мы не только собственно адаптировалась получая соответствующие навыки и опыт, но и привыкли к тому что приходится адаптироваться и так же получили соответствующий опыт.
В моем случае солидные навыки и умение разбираться в чем либо были получены во времена, когда с теми же компьютерами приходилось возиться. Сейчас такой необходимости просто нет.
Вот у зумеров и нет причин адаптироваться и соответственно прокачивать навыки адаптации и получать опыт перемен. Тут хорошим примером было отображение эволюции телефонов. У миллениалов от кнопочных до смартов, а у зумеров лишь разные вариации смарта, который в общем то никак уже не менялся.
Это как ныне обезьяны, которые не эволюцилнируют в человека потому что нет причин и условий :)
В итоге зуммеры хотят тепличных условий и прочих удобств. Совершенно не готовы к реальности. Что усугубляется культурой пропагандируемой в инфопространстве.
Режим работы в принципе сейчас меняется и сидеть на одном месте уже давно не норма. К тому же есть вариант, что ты таки едешь по работе, но нужно провести неожиданный разговор или вообще что-то сделать срочно.
После перехода на личности это с тобой разговаривать не о чем. Ты ведь про себя написал то. Именно из тебя и полезло всякое стоило чуток вывести тебя из зоны комфорта. Но мне часто приходится иметь дело с перечисленными субстанциями после очередного "гения" программирования. НедоИИ же изрядно способствует увеличению авгиевых конюшен. Все это еще аукнется в очень недалеком будущем.
P.S.: Не имею привычки комментировать то что не читал.
Меня вот зацепило другое. Это 6 лет и зоопарк технологий. Очень сомневаюсь что все перечисленное автор может эффективно использовать и достаточно глубоко знает. Т.к. за 6 лет в принципе этот зоопарк освоить не получится разве то мимо пробежать. И это точно не синьор.
Ну и формулировка про решение на встрече с руководителем получить дальнейший рост и развитие на рынке звучит ну очень подозрительно и вызывает кучу вопросов. Если коротко, то автор сам решил уволиться и если да, то почему? Или автора банально сократили и опять же за что и почему...
В чем развитие и поддержка будет отличаться от чего-либо написанного на другом языке? Java или C# сразу что ли наделяют разраба скилами написания идеального кода? Нет. Бардак есть везде. Зависит от разработчиков и организации процессов. В моем случае все ключевые моменты давно допилены напильником, а грабли найдены и обезврежены. Расширять функционал по образу и подобию не сложно. Максимум можно с веб-частью заморочиться.
Сейчас найти толковых спецов в принципе проблема по любому стэку. Все толковые сидят при деле. Рынок же наполнен вкатунами алчущими бабла. Так что и тут отличий нет. Хотя будет даже проще, т.к. не придется рыться в сортах вкатунов, ведь их на текущий момент не учат Delphi :)
Что такого в Windows? Это что ли какая то редкость? Нет. К тому же IIS есть абсолютно в любой редакции форточек. Так что проблема опять надумана. Зато в случае IIS есть плюс - производительность, т.к. сайт представляет собой по сути часть IIS и потому работает шустрее других вариантов.
Киллер-фича есть. Это кросплатформенность. Т.е. на одной кодовой базе можно собирать приложения для различных платформ. Это как минимум удобно, особенно если проект новый. Не нужен зоопарк всяких средств разработки.
Вот честно, прочитав все это в голове засветился баннер "плохому танцору..."
Мне ничто не мешает в данный момент писать на Delphi 7 современную информационную систему с современным же веб интерфейсом в виде isapi расширения под IIS. И за 20+ лет разработки могу сказать что Delphi прекрасен. При этом работал и на Java и на Net Core разрабатывая всякое большое и сложное. Delphi точно так же может все что нужно, а Java/C# ничем особенным не зацепили.
Полностью согласен. И чем больше читал статью, тем больше вертелось только одно - чушь. Проблема в том, что такие люди пишут, другие их слушают и читают, а потом делают выводы и принимают решения. Мир ещё даже не понял в какую ловушку угодил. И нет, ничего общего с луддитами и прочими борцами с прогресс ом в этом видеть не стоит. Это скорее взгляд на атомную энергию из которой тут же сделали оружие.
Пальцы тоже при желании можно сунуть в розетку, только вот зачем?
В случае с булями есть нюанс. Это ну очень абстрактный тип, который базируется все равно на другом типе хранения. Можно использовать тот же чар с ограничениями, а можно бит, если есть такая возможность.
В MySQL это TinyBit, который по сути байт, где 0 - false, а все остальное true. При этом запихать можно что угодно в диапазоне -128/127. Чем хуже вариант с чаром, где '0' - false, а все остальное true? Т.е. ничто не мешает убрать слой абстракции и работать со значением напрямую.
В MS SQL Server буль вроде вообще отсутствует, а вместо него используется как раз тип Bit, который принимает значения 0, 1 и NULL.
И типизация тут не причем. Типизация нужна чтобы компу не приходилось пытаться преобразовать теплое в мягкое потому что кодер балбес, который пихает что ни попадя, ведь типо "значит может" :) В случае с чар вместо буля это просто альтернатива с потенциальным расширением и заложенной гибкостью. Например, для некоего списка выбора можно использовать набор смысловых значений, а можно использовать числовой идентификатор. Здесь тоже самое. В случае с заменой буля это просто удобнее и читаемость не страдает.
Но я, конечно, ни на чем не настаиваю. То что выбрал для себя это мой выбор, который никому не навязываю. Мне так удобно. И ничего лишнего передано там не будет никогда, потому что сам этого не сделаю, т.к. это лишено смысла. А если с этим кодом будет работать другой разработчик, который не умеет читать описание к используемой функции, то придется его научить читать :)
Что в данном случае нужно отлаживать и в чем проблема? Работоспособность или скорость? При чем тут беззнаковость и прочее? В любом случае цифирь это набор бит. То что старший бит учитывается как знак это не более чем условность. Тот же буль хранится как чар, а можно хранить как первый бит или еще как. Сбрасывать один бит надо "уметь"? Серьезно? Меня пугают такие заявления. Это же детский сад. И работать с битами просто. Один раз написал пару функций и пользуешься. В постгресе не приходилось битовую маску держать, но в текущей СУБД (Firebird) с индексами по этой части нет никаких проблем. Специально проверил. Индекс цепляется.
Если там может прийти что угодно, то это бардак в разработке. При нормальном подходе ничего лишнего прийти не может. Плюс есть описание механизма, где все расписано. Если же кто-то пихает куда попало что попало, то гнать в шею таких разрабов. Таким никакая типизация не поможет. Ведь никто не гарантирует что они правильное значение true/false отправляют :) Зачем такие случаи рассматривать вообще...
И не надо ничего обрабатывать. В базовом случае вообще достаточно одного сравнения, допустим с 0, который будет обозначать false, а все остальное считать true. При необходимости такой код легко доработать и расширить функционал. Сколько использую такой подход ни разу проблем не было.
P.S.: Вот за это и "люблю" публику Хабра, на ровном месте минусов навтыкать. Конструктивно. Демократично. Интеллектуально.
P.P.S.: Например, в PostgreSQL логический тип данных boolean (BOOLEAN) хранится в виде одного байта. В SQL-запросах могут представляться ключевыми словами SQL: TRUE, FALSE и NULL. Также можно использовать строковые представления: для TRUE - «true», «yes», «on», «1», для FALSE - «false», «no», «off», «0». Также принимаются уникальные префиксы этих строк, например «t» или «n».
И чем это отличается от того что использую сам? Всего лишь упростил и сократил до простого 0/1, что понятно всем и гораздо удобнее, чем все эти true/false. А, например, в Python они еще и регистрозависимые. Вообще "прекрасно" :)
Не касаясь рассуждений на тему архитектуры скажу именно про були. Давно уже пришёл к мысли, что гораздо удобнее использовать банальный char с значениями 0/1. Ещё и запись сократится, т.к вместо =false будет ='0' или вообще =0. Да и запас на вырост есть.
А там где нужен именно буль, то проще взять целое и превратить его в набор битовых тумблеров.
Автор фантазер. Представим развитие этой фантазии. Есть джун и модель недоИИ. У джуна нет навыков ни добиться от модели толкового результата, ни оценить этот результат. Так же нет и возможности получить для этого опыт т.к. использование недоИИ подобную возможность практически исключает.
Управлять системами недоИИ с толком способен сеньор или способный мидл. Но откуда им будет взяться в будущем? ИТ начнёт превращаться в магию. И то при условии что недоИИ допилят до соответствующего уровня безглючности.
Хороший пример это IBM, которая сначала уволила толпу народа из-за недоИИ, а потом была вынуждена нанять ещё больше чтобы этим самым недоИИ рулить.
Хард-скиллы по-прежнему важны т.к. без них не возможно рулить этим самым недоИИ с положительным результатом. Без экспертизы толку не будет.
НедоИИ лишь позволяет заглянуть в ИТ. Как когда то Борланд дала RAD системы и появились "специалисты" по формошлепству, которые к профессиональному программированию и разработке имели весьма условное отношение. Просто образовалась ниша по созданию чего-нибудь простенького быстро и без геморроя.
Научившись рулить тем же Midjourney художником все равно не стану. И называть себя специалистом в этой области тоже не получится, но это дает мне возможность заглянуть в этот мир и при необходимости получить какой-то результат при полном отсутствии хужественных навыков. Благо, эта область не требует экспертизы, чтобы получить в принципе годный результат, т.к. по сути любой результат будет иметь право на существование. В отличие от разработки всяких систем с помощью недоИИ, где важна точность и корректность результата, что может обеспечить только специалист соответствующего уровня уже имеющий достаточно опыта и практики.
Почитал комментарии и очень рад что они не коррелируют со статьёй.
Молодой разработчик умеет в кубики, он не понимает как все устроено под капотом. Он не способен решить проблему требующую чуть большего погружения в тему.
Сейчас как раз с интересом наблюдаю как одна вполне известная российская компания разработчик одноименной ERP системы пишет продукт под конкретного заказчика. То что там в организационном смысле полный трындец это фигня. Но там адские проблемы с производительностью. Потому что разрабы увлекаются фреймворками. При том что имеющейся толпой, но нормальных разрабов, могли все что нужно написать с нуля и работало бы это гораздо быстрее.
Кто-то скажет сроки. Но торопыжество всегда выходит потом боком. Спешка актуальна, если это стартап, где надо срочно запускаться и бежать опережая возможных конкурентов. Но когда у тебя есть проект с четкими ТЗ подобная схема это путь к катастрофе.
И да, в упомянутом примере ещё и эпический глюкодром. Ну не может же быть так, что в одном месте собрались все балбесы от разработки. Значит, корни проблемы в другом. В походах. Тех самых, про которые так радостно пишет автор. Поэтому сам уже не боюсь будущего. НедоИИ принял как вспомогательный инструмент. А за счёт молодых и успешных разрабов у меня работа точно будет. Ведь кто-то же должен все это приводить в порядок. А молодые уже такими не станут. Просто окружение изменилось и развиваться вглубь станет сложнее.
С одной стороны автор прав. НедоИИ уже прочно вошли в нашу жизнь. И теперь вместо гуглежа можно чатить почти готовое решение. А при использовании специализированных средств скармливать исходники и получать ещё больше пользы.
Только это приведёт не к безработице, а к деградации и катастрофе. Т.к. новым спецам взяться будет неоткуда, а старые будут нужны чтобы поддерживать кучу нагенерированного недоИИ кода. Т.е. меняется уровень абстракции. Либо придётся лезть в код и разбираться с нуля, либо уповать на недоИИ и лезть в промты чтобы перегенерить нужное.
Всё это приведёт к утрате компетенций, навыков и экспертизы. Спецы работу не потеряют. Хоть и не хочется, но придётся дружить с недоИИ. А вот у вкатунов и новичков шансов на будущее нет. Можно въехать на вау-эффекте и нагенерить сферического коня в вакууме. А дальше что? Чтобы контролировать процесс откуда взять компетенции без самостоятельного обучения разработке? Неоткуда. Занавес. С интересом буду смотреть куда нас все это заведёт.
Если отсутствие FK может превратить ваши данные в желе, то ваши архитекторы БД и не только зря получают зарплату.
Ни разу не сталкивались с ситуацией, когда надо что-то поправить уже каким либо способом накосясенное, а эти самые FK люто мешают?
Поэтому давно пришёл к мысли, что FK не только бесполезны, но и вредны.
Про индексы это же явное утрирование. Но есть ещё одна вещь из теории баз данных, которую тоже можно предать анафеме как и FK. Это нормальные формы. Они порой добавляют лютых тормозов путем создания узких мест, если слепо им следовать.
А я вот котам не могу объяснить что "на работе" и потому им придётся терпеть голод до вечера. Ведь я же тут рядом, мой запах, слышен шум издаваемый мною. Под дверью был бы постоянный мяу-мяу. Ведь коты ещё и терпеть не могут закрытых дверей.
Потому, у меня свой формат удаленки. Но до этого человечеству в массе ещё очень далеко. График свободный, главное - результат. Иначе бы удаленка стала адом. Ведь жена тоже на удаленке, рядом :)
Очень странно такое читать. При том что любому ИТшнику должно быть очевидно, что без ИТ сейчас просто никак.
За всю свою карьеру 20+ лет лучшее ИТ встречал у одного логистического оператора. И уходя оттуда спустя несколько лет оставалось ещё достаточно всякого разного неизученного. Такого масштаба была инфраструктура.
Уходил в компанию, где разработка софта это основной бизнес, но меня ждало разочарование. В плане организации процессов, да и сами проекты были далеко не вершиной технической мысли.
В итоге сейчас сам в одной не большой компании строю свое ИТ. Как техдир. Устал от всяких менеджеров и прочих РП.
Так вот без моих усилий развиваться было бы просто не возможно. Excel - не вариант. Как и готовые решения, потому что они деревянные, а нам нужна гибкость. Да ещё и чужое всегда стоит хороших денег. Свое обходится в итоге дешевле, если уметь его готовить :)
Сейчас ИТ есть у всех. При чем хорошее ИТ может быть там, про что большинство даже не слышало. То что на слуху, вроде Яндекса и прочих, это не большой процент.
Ну что же. Начиная читать статью уже предвкушал, как размажу все аргументы в лепешку, но оказалось иначе. Статья это по сути ошибка выжившего. Ведь вряд ли кто-то на полном серьёзе будет ставить крест на всём поколении. Это не так. Вот автор и рассказывает про тех, кто попал в сандартные ситуации, которые никак не связаны именно с поколением.
При этом есть фундаментальные основы почему в целом поколение зумеров более худшие работники чем те же миллениалы. Были такие статьи. Банально отличалось время и условия. Те же миллениалы жили в условиях постоянных перемен к которым приходилось адаптироваться. И мы не только собственно адаптировалась получая соответствующие навыки и опыт, но и привыкли к тому что приходится адаптироваться и так же получили соответствующий опыт.
В моем случае солидные навыки и умение разбираться в чем либо были получены во времена, когда с теми же компьютерами приходилось возиться. Сейчас такой необходимости просто нет.
Вот у зумеров и нет причин адаптироваться и соответственно прокачивать навыки адаптации и получать опыт перемен. Тут хорошим примером было отображение эволюции телефонов. У миллениалов от кнопочных до смартов, а у зумеров лишь разные вариации смарта, который в общем то никак уже не менялся.
Это как ныне обезьяны, которые не эволюцилнируют в человека потому что нет причин и условий :)
В итоге зуммеры хотят тепличных условий и прочих удобств. Совершенно не готовы к реальности. Что усугубляется культурой пропагандируемой в инфопространстве.
Странная упертая категоричгость :)
Режим работы в принципе сейчас меняется и сидеть на одном месте уже давно не норма. К тому же есть вариант, что ты таки едешь по работе, но нужно провести неожиданный разговор или вообще что-то сделать срочно.
После перехода на личности это с тобой разговаривать не о чем. Ты ведь про себя написал то. Именно из тебя и полезло всякое стоило чуток вывести тебя из зоны комфорта. Но мне часто приходится иметь дело с перечисленными субстанциями после очередного "гения" программирования. НедоИИ же изрядно способствует увеличению авгиевых конюшен. Все это еще аукнется в очень недалеком будущем.
P.S.: Не имею привычки комментировать то что не читал.
Меня вот зацепило другое. Это 6 лет и зоопарк технологий. Очень сомневаюсь что все перечисленное автор может эффективно использовать и достаточно глубоко знает. Т.к. за 6 лет в принципе этот зоопарк освоить не получится разве то мимо пробежать. И это точно не синьор.
Ну и формулировка про решение на встрече с руководителем получить дальнейший рост и развитие на рынке звучит ну очень подозрительно и вызывает кучу вопросов. Если коротко, то автор сам решил уволиться и если да, то почему? Или автора банально сократили и опять же за что и почему...
Странные вопросы.
В чем развитие и поддержка будет отличаться от чего-либо написанного на другом языке? Java или C# сразу что ли наделяют разраба скилами написания идеального кода? Нет. Бардак есть везде. Зависит от разработчиков и организации процессов. В моем случае все ключевые моменты давно допилены напильником, а грабли найдены и обезврежены. Расширять функционал по образу и подобию не сложно. Максимум можно с веб-частью заморочиться.
Сейчас найти толковых спецов в принципе проблема по любому стэку. Все толковые сидят при деле. Рынок же наполнен вкатунами алчущими бабла. Так что и тут отличий нет. Хотя будет даже проще, т.к. не придется рыться в сортах вкатунов, ведь их на текущий момент не учат Delphi :)
Что такого в Windows? Это что ли какая то редкость? Нет. К тому же IIS есть абсолютно в любой редакции форточек. Так что проблема опять надумана. Зато в случае IIS есть плюс - производительность, т.к. сайт представляет собой по сути часть IIS и потому работает шустрее других вариантов.
Киллер-фича есть. Это кросплатформенность. Т.е. на одной кодовой базе можно собирать приложения для различных платформ. Это как минимум удобно, особенно если проект новый. Не нужен зоопарк всяких средств разработки.
Вот честно, прочитав все это в голове засветился баннер "плохому танцору..."
Мне ничто не мешает в данный момент писать на Delphi 7 современную информационную систему с современным же веб интерфейсом в виде isapi расширения под IIS. И за 20+ лет разработки могу сказать что Delphi прекрасен. При этом работал и на Java и на Net Core разрабатывая всякое большое и сложное. Delphi точно так же может все что нужно, а Java/C# ничем особенным не зацепили.
Полностью согласен. И чем больше читал статью, тем больше вертелось только одно - чушь. Проблема в том, что такие люди пишут, другие их слушают и читают, а потом делают выводы и принимают решения. Мир ещё даже не понял в какую ловушку угодил. И нет, ничего общего с луддитами и прочими борцами с прогресс ом в этом видеть не стоит. Это скорее взгляд на атомную энергию из которой тут же сделали оружие.
Пальцы тоже при желании можно сунуть в розетку, только вот зачем?
В случае с булями есть нюанс. Это ну очень абстрактный тип, который базируется все равно на другом типе хранения. Можно использовать тот же чар с ограничениями, а можно бит, если есть такая возможность.
В MySQL это TinyBit, который по сути байт, где 0 - false, а все остальное true. При этом запихать можно что угодно в диапазоне -128/127. Чем хуже вариант с чаром, где '0' - false, а все остальное true? Т.е. ничто не мешает убрать слой абстракции и работать со значением напрямую.
В MS SQL Server буль вроде вообще отсутствует, а вместо него используется как раз тип Bit, который принимает значения 0, 1 и NULL.
И типизация тут не причем. Типизация нужна чтобы компу не приходилось пытаться преобразовать теплое в мягкое потому что кодер балбес, который пихает что ни попадя, ведь типо "значит может" :) В случае с чар вместо буля это просто альтернатива с потенциальным расширением и заложенной гибкостью. Например, для некоего списка выбора можно использовать набор смысловых значений, а можно использовать числовой идентификатор. Здесь тоже самое. В случае с заменой буля это просто удобнее и читаемость не страдает.
Но я, конечно, ни на чем не настаиваю. То что выбрал для себя это мой выбор, который никому не навязываю. Мне так удобно. И ничего лишнего передано там не будет никогда, потому что сам этого не сделаю, т.к. это лишено смысла. А если с этим кодом будет работать другой разработчик, который не умеет читать описание к используемой функции, то придется его научить читать :)
Сообщением выше про java ничего нет. Сложилось мнение что скорее это про php речь.
Хотя ниже упоминается как раз java. Странно...
Что в данном случае нужно отлаживать и в чем проблема? Работоспособность или скорость?
При чем тут беззнаковость и прочее? В любом случае цифирь это набор бит. То что старший бит учитывается как знак это не более чем условность. Тот же буль хранится как чар, а можно хранить как первый бит или еще как.
Сбрасывать один бит надо "уметь"? Серьезно? Меня пугают такие заявления. Это же детский сад. И работать с битами просто. Один раз написал пару функций и пользуешься.
В постгресе не приходилось битовую маску держать, но в текущей СУБД (Firebird) с индексами по этой части нет никаких проблем. Специально проверил. Индекс цепляется.
Если там может прийти что угодно, то это бардак в разработке. При нормальном подходе ничего лишнего прийти не может. Плюс есть описание механизма, где все расписано. Если же кто-то пихает куда попало что попало, то гнать в шею таких разрабов. Таким никакая типизация не поможет. Ведь никто не гарантирует что они правильное значение true/false отправляют :) Зачем такие случаи рассматривать вообще...
С чего вдруг должно прийти какое-то 'В'?
И не надо ничего обрабатывать. В базовом случае вообще достаточно одного сравнения, допустим с 0, который будет обозначать false, а все остальное считать true. При необходимости такой код легко доработать и расширить функционал. Сколько использую такой подход ни разу проблем не было.
P.S.: Вот за это и "люблю" публику Хабра, на ровном месте минусов навтыкать. Конструктивно. Демократично. Интеллектуально.
P.P.S.: Например, в PostgreSQL логический тип данных boolean (BOOLEAN) хранится в виде одного байта. В SQL-запросах могут представляться ключевыми словами SQL: TRUE, FALSE и NULL. Также можно использовать строковые представления: для TRUE - «true», «yes», «on», «1», для FALSE - «false», «no», «off», «0». Также принимаются уникальные префиксы этих строк, например «t» или «n».
И чем это отличается от того что использую сам? Всего лишь упростил и сократил до простого 0/1, что понятно всем и гораздо удобнее, чем все эти true/false. А, например, в Python они еще и регистрозависимые. Вообще "прекрасно" :)
Не касаясь рассуждений на тему архитектуры скажу именно про були. Давно уже пришёл к мысли, что гораздо удобнее использовать банальный char с значениями 0/1. Ещё и запись сократится, т.к вместо =false будет ='0' или вообще =0. Да и запас на вырост есть.
А там где нужен именно буль, то проще взять целое и превратить его в набор битовых тумблеров.