@Kelbon Восторг, у меня на собесах в Y не было ничего с leetcode, это больше было похоже на задачи с yandex.code.
История 1 в 1 - тоже не решил последнюю хард-задачу на последнем собеседовании. Очень знакомо, поэтому вызывает отклик. Успехов тебе с твоим кирпичом!)
Цена на камни серии Эльбрус — это абсолютно не естественная, высосанная непонятно с какого места цифра. Особенно учитывая количество схожих по производительности камней, коих можно накупить на эти деньги, еще и на всем понятных x86 или ARM.
С малым бизнесом собственно МЦСТ вообще не работают, если я верно трактую их действия. Мы пытались с ними сконтактировать, разрабатываем системы телемеханики и централизации, в т.ч. аппаратные решения для РЖД СКЖД и КБШ. Возможно письмо затерялось в спаме, ну вы знаете, как это бывает)
Далее, что по сопутствующему ПО (компиляторы, системы сборки, языки программирования, и т.д. и т.п.)?
Как итог: разрабатываем на камнях КОМДИВ производства НИИСИ РАН. Там и к цене претензий меньше, и поддержка есть. Понятная известная MIPS64 архитектура, да там тоже не все гладко. Есть болячки с TDP, вопросы к графической производительности, особенно на ранних версиях вроде 8й. Но под MIPS хотя бы понятно как разрабатывать, есть готовые тулчейны, возьми и делай. Что тут — бизнесу надо сначала разобраться, будет ли в экосистеме Эльбрус'а нужные тулы, когда они понадобятся?
Вот и решайте, стоит ли «оно» своих денег. Мое частное мнение: удел Эльбруса — быть камнем для решений государственного уровня ближе к военке. Особенно с таким подходом к ретейлу. Для частного пользования из отечественных наработок даже серия Байкал на ARM выглядит перспективнее, хотя там тоже есть вопросы к ценнику.
Такие проблемы с читаемостью вылазиют, когда проект масштабируется и разрастается. Будь это единственная функция в проекте — и так сойдет. Как вы предлагаете мне запомнить все магические числа для всех возможных вариантов во всем коде, где, ну скажем, хотя бы 100к строк?
Замечательная статья от Антона. От себя, я бы добавил еще правило:
Вместо использования множественных флагов — используйте enum'чики или классы флагов на их основе. В Qt есть замечательный класс QFlags, который как раз для таких дел.
Решается проблема:
1) Аргументы внезапно получают имена
2) Внезапно сокращается количество аргументов-флагов в прототипе функции
Вы забыли упомянуть подкаст "Мысли и методы" (бывш. Хекслет). Субьективно — это лучший подкаст про информатику и технологии, в формате монолога, который я прослушал ОТ и ДО.
С посылом я согласен, кто выслуживается и наушничает чаще получают повышение, чем простые ребята, просто хорошо выполняющие свои обязанности.
Посыл изложен достаточно ясно, чего нельзя сазать про манеру изложения: сленг, сокращения, несвязное повествование.
Т.е. Вы вполне нормально относитесть к тому, что отрасль наводняется низковалифицированным планктоном? Теми, кто готов выслуживаться и лизоблюдничать перед руководством, ради "ничего не делать и получать больше $$$"
Я и сам не против "горящих" кадров, у кого на лице написано "дай мне работу, я буду изо всех сил стараться внести свой вклад", но, по-моему, в статье как раз говорилось про первый тип людей.
IT-комьюнити и без того достаточно токсичная среда, и она остро нуждается как раз в кадрах с Качественными целями и стремлениями.
Одно меня радует — исключительно денежная мотивация без должного количества наглости не защитит человека от риска быть проглоченным и выплюнутым на обочину по причине выгорания, не мешки ворочать ведь пришел.
Я разработчик на Qt/C++, разрабатываю ПО для железных дорог, работаю с embedded, с высоконагруженными сервисами, что может пойти не так? И как-то раз стучится мне в личку барышня с одного всем Вам известного московского вуза, просит решить ее лабы по Qt за ПЕРВЫЙ КУРС. Ну я такой: "Ладно, помогу что-ли". Я никогда таких лабораторных не видел.
К слову, эти лабы даже меня заставили попотеть, хотя казалось бы. Например, задание "Отрисовка датасета в виде 3D графа с возможностью перемещения камеры на голом виджете в функциональной парадигме используя Афинную геометрию, из Qt доступно только QPainter, полный запрет на ООП". Такие задания из разряда "Изобретите вселенную с нуля левой задней". Если бы мне на первом курсе дали такую лабу, то, наверное, я бы разочаровался в программировании и бесповоротно закрепил бы в своей голове фразу "Это не для тебя".
Указатель — такая же область памяти как и любая другая переменная. У него есть стандартный размер — машинное слово — соответствующий разрядности адресной шины. Обычно, ширина адресной шины определяет размер машинного слова, например если ширина 64бит то и размер машинного слова будет 64бита, т.е. 8 байт.
Массив или список это способ хранения каких-либо данных одного размера, а не какая-то фича конкретного языка.
В случае массива, указатели будут лежать согласно Array Padding для вашего ЯП. В зависимости от реализации, они могут иметь выравнивание по наибольшему или по размеру машинного слова.
Со списком вы имеете разбросанные по памяти ноды из указателей, каждый из которых указывает на соседей и хранимое значение.
Массив — непрерывная область памяти, отсюда и название. Элементы списка могут лежать вообще где угодно, но элементы знают о своих соседях (как — зависит от направленности списка).
Если хотя бы чуть чуть в С могете, то поймете, почему в массив добавить элемент дороже чем в список. И почему доступ к злементу списка дороже чем, из массива. Причем в обоих случаях стоимость прямо пропорциональна размеру.
Логика такого списка контр-интуитивна.
1) зачем в списке членом хранить итератор (или что у вас там?) на какой-то элемент? В первом примере вы с таким же успехом могли вызвать last.
2) такой список не выглядит консистентным. Вместо такого «дубового» подхода логичнее использовать отдельный итератор, с методами next, prev и т.д.
3) методы insert и insertFirst семантически не соответствуют, у вас должно быть тогда insert i, pushFront, pushBack
Но этот способ конечно же придумал не я, я его сам вычитал из книги когда-то. И так https и http. Чтобы это сделать, нужно создать интерфейс. И к этому интерфейсу присваивать нужный класс, в зависимости от типа протокола. Я точно не помню, но вроде я где-то читал, что ООП вправляет мозги. Что это позволяет писать грамотный красивый код. Возможно так.
Вся статья выглядит как один большой несвязный кусок текста. Нет никакой структуры, никакого «газетного» стиля. После прочтения я понял только то, какой беспорядок происходил у автора в голове на момент написания этого «сочинения».
Первое, что мне интересно:
Как Вы собираетесь сохранять стейтмент дерайвед класса во внешнем контексте?
Условимся, что LBC умеет динамически «кастить» не связанные классическим наследованием классы, но как будет вести себя класс-наследник, после выхода из текущего контекста?
В случае, если целью LBC является расширение типов, Вы рискуете получить ту же историю, которая есть сейчас в Ruby, когда Вы открываете код, и не можете на сто процентов доверять ему, потому что не знаете наверняка, какая функциональность включена в тот или иной класс. Так в Ruby пытались решить проблему выражения.
Второе:
Как Вы технически собираетесь реализовать динамическую расширяемость типов при строгой типизации в языке со статической проверкой типов? У Вас есть готовое решение? Очевидно, что Extends это «красивый» прототип.
Иначе, если LBC не призвано расширять типы, а только приводить их к каким-то определенным трейтам (назовем это по Rust'амански), то для чего нужен LBC, если можно реализовать трейт для этого класса? Разница лишь в том, когда выполнять проверку на совместимость (при компиляции в случае трейтов, либо в рантайме, потому как Вы оговариваете возможность LBC работать с Base-классом, которого еще не существует).
В случае с LBC, трейтом якобы выступает публичный интерфейс Base-класса? Но что тогда должна возвращать Extends, в случае несоответствия интерфейсов? Мне не ясно, как это реализовать в рамках Java, я уже не говорю про C++.
Это очень похоже на дополнение к сочинению одного известного автора про «трушное» ООП — альтернативой существующему и работающему предлагаете сомнительные решения.
Все вышесказанное верно, если я правильно понял, что Вы хотели донести в статье.
В этой статье прекрасно все. Не знал, что можно выучить ООП)
Хотя все же стоит заметить, что кроме литературного суецида, парень не побоялся и заявил о себе.
Только топик не верно указан, эта статься должна быть либо в «GTD» либо в «учебном процессе».
В Java принято называть интерфейсы прилагательными, например Drawable, Writeable и т.д. В С++ я часто пишу префикс Abstract для нечисто-виртуальных классов, когда нужно дать понять, что это именно абстрактный класс с необходимостью переопределения некоторых методов. Либо для чисто-виртуальных классов что-то очень общее, например Transmitter, с реализациями TcpTransmitter, SerialTransmitter, UnblockingSerialTransmitter и т.д. Impl в этом случае только засоряет лаконичное имя класса, который, к слову, можно использовать и без применения полиморфизма. Объективно — использование префикса I объясняется языковыми особенностями. Например, в С++ в принципе такого понятия интерфейса, как в Java, не существует, поэтому было бы странно видеть «открывающую» I в имени класса)
Это не статья, а какой-то крик души)
Справедливости ради хочется сказать, что программиста-казуала видно издалека, отношение к ним в коллективе далеко не самое лучшее, так что не все потеряно. Своим отношением к профессии, которую мы все так любим, они сами же порождают ненависть у доброй части айтишников. Программированию свойственен дух исследования, пытливости, упорства, мечтательства. Эти качества обязательны для программиста. Думаю, тут автор скорее режет по-живому и знает что будет больно, с ним трудно не согласиться.
Вообще выражаю автору огромное «Спасибо» — великолепная отдушина, которой порой не хватает, приятно было читать.
Если у автора стояла цель показать пример антипаттерна, то у него это получилось.
Я искренне честно прочитал эту статью два раза, чтобы исключить свою предвзятость. Рассуждения автора мягко говоря перекликаются с книгой Elegant Objects. Возможно такие «паттерны» берутся от слабого понимания промышленного кода и требований к нему. Ведь ни один не приводит примеры такого реально работающего кода в больших проектах на миллион (или в этом случае «на миллиард») строчек. У автора прекрасно получилось обмазать простой до глухого щелчка код абстракциями и паттернами, растянуть его примерно в 10 раз. Вы поймите меня правильно, этот высосанный непонятно из какого места пример очень пахнет оверхедом, вот и все, это такой же «запах» в коде как дублирование или глупые комментарии.
Порой я думаю, что такие статьи пишутся ради статьи.
typo
@Kelbon Восторг, у меня на собесах в Y не было ничего с leetcode, это больше было похоже на задачи с yandex.code.
История 1 в 1 - тоже не решил последнюю хард-задачу на последнем собеседовании. Очень знакомо, поэтому вызывает отклик. Успехов тебе с твоим кирпичом!)
Боюсь ошибиться, но вроде лицензия ARM запрещает правки микроархитектуры.
С малым бизнесом собственно МЦСТ вообще не работают, если я верно трактую их действия. Мы пытались с ними сконтактировать, разрабатываем системы телемеханики и централизации, в т.ч. аппаратные решения для РЖД СКЖД и КБШ. Возможно письмо затерялось в спаме, ну вы знаете, как это бывает)
Далее, что по сопутствующему ПО (компиляторы, системы сборки, языки программирования, и т.д. и т.п.)?
Как итог: разрабатываем на камнях КОМДИВ производства НИИСИ РАН. Там и к цене претензий меньше, и поддержка есть. Понятная известная MIPS64 архитектура, да там тоже не все гладко. Есть болячки с TDP, вопросы к графической производительности, особенно на ранних версиях вроде 8й. Но под MIPS хотя бы понятно как разрабатывать, есть готовые тулчейны, возьми и делай. Что тут — бизнесу надо сначала разобраться, будет ли в экосистеме Эльбрус'а нужные тулы, когда они понадобятся?
Вот и решайте, стоит ли «оно» своих денег. Мое частное мнение: удел Эльбруса — быть камнем для решений государственного уровня ближе к военке. Особенно с таким подходом к ретейлу. Для частного пользования из отечественных наработок даже серия Байкал на ARM выглядит перспективнее, хотя там тоже есть вопросы к ценнику.
Замечательная статья от Антона. От себя, я бы добавил еще правило:
Вместо использования множественных флагов — используйте enum
'чикиили классы флагов на их основе. В Qt есть замечательный класс QFlags, который как раз для таких дел.Решается проблема:
1) Аргументы внезапно получают имена
2) Внезапно сокращается количество аргументов-флагов в прототипе функции
Вы забыли упомянуть подкаст "Мысли и методы" (бывш. Хекслет). Субьективно — это лучший подкаст про информатику и технологии, в формате монолога, который я прослушал ОТ и ДО.
С посылом я согласен, кто выслуживается и наушничает чаще получают повышение, чем простые ребята, просто хорошо выполняющие свои обязанности.
Посыл изложен достаточно ясно, чего нельзя сазать про манеру изложения: сленг, сокращения, несвязное повествование.
Т.е. Вы вполне нормально относитесть к тому, что отрасль наводняется низковалифицированным планктоном? Теми, кто готов выслуживаться и лизоблюдничать перед руководством, ради "ничего не делать и получать больше $$$"
Я и сам не против "горящих" кадров, у кого на лице написано "дай мне работу, я буду изо всех сил стараться внести свой вклад", но, по-моему, в статье как раз говорилось про первый тип людей.
IT-комьюнити и без того достаточно токсичная среда, и она остро нуждается как раз в кадрах с Качественными целями и стремлениями.
Одно меня радует — исключительно денежная мотивация без должного количества наглости не защитит человека от риска быть проглоченным и выплюнутым на обочину по причине выгорания, не мешки ворочать ведь пришел.
Лабы бывают разные, друзья.
Я разработчик на Qt/C++, разрабатываю ПО для железных дорог, работаю с embedded, с высоконагруженными сервисами, что может пойти не так? И как-то раз стучится мне в личку барышня с одного всем Вам известного московского вуза, просит решить ее лабы по Qt за ПЕРВЫЙ КУРС. Ну я такой: "Ладно, помогу что-ли". Я никогда таких лабораторных не видел.
К слову, эти лабы даже меня заставили попотеть, хотя казалось бы. Например, задание "Отрисовка датасета в виде 3D графа с возможностью перемещения камеры на голом виджете в функциональной парадигме используя Афинную геометрию, из Qt доступно только QPainter, полный запрет на ООП". Такие задания из разряда "Изобретите вселенную с нуля левой задней". Если бы мне на первом курсе дали такую лабу, то, наверное, я бы разочаровался в программировании и бесповоротно закрепил бы в своей голове фразу "Это не для тебя".
Так что лабы действительно бывают разные)
Указатель — такая же область памяти как и любая другая переменная. У него есть стандартный размер — машинное слово — соответствующий разрядности адресной шины. Обычно, ширина адресной шины определяет размер машинного слова, например если ширина 64бит то и размер машинного слова будет 64бита, т.е. 8 байт.
Массив или список это способ хранения каких-либо данных одного размера, а не какая-то фича конкретного языка.
В случае массива, указатели будут лежать согласно Array Padding для вашего ЯП. В зависимости от реализации, они могут иметь выравнивание по наибольшему или по размеру машинного слова.
Со списком вы имеете разбросанные по памяти ноды из указателей, каждый из которых указывает на соседей и хранимое значение.
Если хотя бы чуть чуть в С могете, то поймете, почему в массив добавить элемент дороже чем в список. И почему доступ к злементу списка дороже чем, из массива. Причем в обоих случаях стоимость прямо пропорциональна размеру.
1) зачем в списке членом хранить итератор (или что у вас там?) на какой-то элемент? В первом примере вы с таким же успехом могли вызвать last.
2) такой список не выглядит консистентным. Вместо такого «дубового» подхода логичнее использовать отдельный итератор, с методами next, prev и т.д.
3) методы insert и insertFirst семантически не соответствуют, у вас должно быть тогда insert i, pushFront, pushBack
Вся статья выглядит как один большой несвязный кусок текста. Нет никакой структуры, никакого «газетного» стиля. После прочтения я понял только то, какой беспорядок происходил у автора в голове на момент написания этого «сочинения».
Как Вы собираетесь сохранять стейтмент дерайвед класса во внешнем контексте?
Условимся, что LBC умеет динамически «кастить» не связанные классическим наследованием классы, но как будет вести себя класс-наследник, после выхода из текущего контекста?
В случае, если целью LBC является расширение типов, Вы рискуете получить ту же историю, которая есть сейчас в Ruby, когда Вы открываете код, и не можете на сто процентов доверять ему, потому что не знаете наверняка, какая функциональность включена в тот или иной класс. Так в Ruby пытались решить проблему выражения.
Второе:
Как Вы технически собираетесь реализовать динамическую расширяемость типов при строгой типизации в языке со статической проверкой типов? У Вас есть готовое решение? Очевидно, что Extends это «красивый» прототип.
Иначе, если LBC не призвано расширять типы, а только приводить их к каким-то определенным трейтам (назовем это по Rust'амански), то для чего нужен LBC, если можно реализовать трейт для этого класса? Разница лишь в том, когда выполнять проверку на совместимость (при компиляции в случае трейтов, либо в рантайме, потому как Вы оговариваете возможность LBC работать с Base-классом, которого еще не существует).
В случае с LBC, трейтом якобы выступает публичный интерфейс Base-класса? Но что тогда должна возвращать Extends, в случае несоответствия интерфейсов? Мне не ясно, как это реализовать в рамках Java, я уже не говорю про C++.
Это очень похоже на дополнение к сочинению одного известного автора про «трушное» ООП — альтернативой существующему и работающему предлагаете сомнительные решения.
Все вышесказанное верно, если я правильно понял, что Вы хотели донести в статье.
Хотя все же стоит заметить, что кроме литературного суецида, парень не побоялся и заявил о себе.
Только топик не верно указан, эта статься должна быть либо в «GTD» либо в «учебном процессе».
Справедливости ради хочется сказать, что программиста-казуала видно издалека, отношение к ним в коллективе далеко не самое лучшее, так что не все потеряно. Своим отношением к профессии, которую мы все так любим, они сами же порождают ненависть у доброй части айтишников. Программированию свойственен дух исследования, пытливости, упорства, мечтательства. Эти качества обязательны для программиста. Думаю, тут автор скорее режет по-живому и знает что будет больно, с ним трудно не согласиться.
Вообще выражаю автору огромное «Спасибо» — великолепная отдушина, которой порой не хватает, приятно было читать.
Я искренне честно прочитал эту статью два раза, чтобы исключить свою предвзятость. Рассуждения автора мягко говоря перекликаются с книгой Elegant Objects. Возможно такие «паттерны» берутся от слабого понимания промышленного кода и требований к нему. Ведь ни один не приводит примеры такого реально работающего кода в больших проектах на миллион (или в этом случае «на миллиард») строчек. У автора прекрасно получилось обмазать простой до глухого щелчка код абстракциями и паттернами, растянуть его примерно в 10 раз. Вы поймите меня правильно, этот высосанный непонятно из какого места пример очень пахнет оверхедом, вот и все, это такой же «запах» в коде как дублирование или глупые комментарии.
Порой я думаю, что такие статьи пишутся ради статьи.