Гхм, давно вроде как придумали табы, не? В любом адекватном редакторе можно их заменить на пробелы автоматически, если религия просит.
Да
Я искренне вам сочувствую, раз для вас автоматизация превращает работу в боль.
Имелось в виду, что большая часть IDE умеет во время написания кода это делать. Хочется лишь сказать, что то, что этого нет — минус, но не повод выкидывать что-либо на помойку. Плюсов там изрядно больше, чем мелких, но досадных минусов. Написать хорошую IDE силами 5-6 человек, и поддерживать ее с учетом выхода новых возможностей, как минимум, очень сложно. Особенно учитывая некоммерческую суть проекта.
Указатели — есть. async/await — в разработке, насколько мне известно. Паттерн-матчинг — недавно появился. Динамическая типизация — нет, это базовый параметр языка, да и зачем? По моему, она — лишний повод стрелять себе в ногу, но это уже религия и дело вкуса. List comprehensions — нет, но их аналоги легко реализуются на LINQ, с похожей логикой мысли. Зачем два раза одно и то же писать, если оно уже есть?
Пардон, эти элементы языка (ну, кроме указателей) далеко за пределами уровня школьника или студента 1-2 курса (вспоминаем, что я говорил об аудитории).
Да. И когда мне выпадает необходимость пописать где-нибудь вроде Atom или Notepad++, я эти табы с пробелами ставлю сам, причем, не «напрягаясь», и не «задумываясь». Это ж столько мыслительной деятельности занимает — кнопки на клавиатуре нажимать.
Извиняюсь, с «крупными проектами» я тут переборщил — здесь этого не было. Было в Википедии :) Впрочем, из «попрограммировал на PABC.NET, стал разработчиком среднего уровня, среда жить не дает», оно планомерно вытекает…
Не оправдываю разработчиков в плане периодически отваливающегся парсера для автоформатирования… Слегка оффтоп, на деле. Придерусь к одному моменту, ибо в недоумении.
Кому оно вообще нужно? Форматирование какбэ для удобства не только чтения, но и написания служит… Если не делаешь это на автомате руками, работа превращается слегка в боль, не? Если сначала код писать, а потом форматировать, то в чем цель? Сдать преподу, чтоб два не поставил за корявый вид, который читать противно?.. Форматирование кода — базовый скилл вроде, должен быть встроен в любого программиста на уровне коры мозга.
Нет, один юзкейс есть — вставить код из стековерфлоу. А еще?
Какая, однако, активная темка тут на Хабре нашлась! Лол, да это же победа.
По факту, не так давно этот человек начал активно заливать г#$%ом страницу Википедии проекта — размещать там ссылки на Issue на гитхабе, рассказывать о том, насколько же «нельзя» этим Паскалем пользоваться… Теперь вот дошел до того, что целый пост на Хабр написал с той же целью. Интересно только, в чем мотивация.
По части того, насколько активно в обучении используются те или иные фичи — расскажу свою историю. Закончил я мехмат ЮФУ в 2016 году (магистратуру — начинал, соответственно, в 2010). В качестве первого языка для курса «Основы программирования» (продуктивной работы и хороших студентов Вам, Станислав Станиславович!) на первом году обучения был поставлен именно он. Поначалу (я пришел с крайне неплохим бэкграундом в плане опыта программирования на фоне остальных однокурсников) действительно возникала куча вопросов. В основном, связанных с тем, что в продакшене этот язык не используется, и возможность не предвидится. Курс, однако, закончился, а потом…
На втором году обучения вся группа «подтянула» свои знания по C#, Java, C++, Python буквально за две-три недели за язык (ну ладно, на С++ целый год потратили, да, но писать простенькие программы смогли очень быстро), а сложность освоения новых языков свелась практически к нулю. Почему? Потому, что буквально на каждую конструкцию, которая в них встречалась, находилась та, которую мы уже выучили, и знали принципы работы с ней на языке PascalABC.NET. Спрашиваете, зачем все эти фичи, которые реализуют разработчики? Именно по этой причине — обеспечить плавный и легкий переход на практически любой язык, любую среду программирования. То, что не является стабильным (т.е. экспериментальные, разрабатываемые фичи), мною за время обучения не было увидено ни разу — разве что, сам накопаешь кровно-потными трудами, если есть желание что-то «поломать». К моменту, когда пришла пора рассказывать об этих самых фичах на курсах по ЯП, они уже протестированы и стабильны.
То, что человек тут пишет о использовании PascalABC.NET в крупных проектах и промышленной разработке (и о том, что этого нужно избегать), явно говорит о том, что он еще школьник (ну, максимум, первый-второй курс) — зайдите интереса ради на форум мехмата — там таких добрый десяток, с «крупными» проектами вроде «напишем свой тридэ движок на пацкалях, и будем игры писать». Людям, которые имеют работу в нашей области, не нужно объяснять, почему язык не ставит себе целью эту самую промышленность. На это же намекают и орфографические ошибки вроде «по чему». Опять же, юношеский максимализм и абсолютизм, с которым эта «критика» преподносится, указывает на то же самое. Школьники, пожалуй, порой и умные вещи говорят, но в таких случаях их редко можно от взрослого человека отличить.
То, что там есть баги, вполне объяснимо малым размером команды, которая, к слову, не только этим занимается — проект некоммерческий, надо еще и кушать что-то. Там, где максимальный охват аудитории (школа, первокурсники), 99,9% функциональности работает на отлично.
Вопрос к автору у меня только один. Откуда столько хейта? Двойку поставили?
Обидно просто. Учитывая объем работ команды разработчиков, усилия приложены титанические. И обучающий эффект мощнейший, по крайней мере, в руках хорошего преподавателя. А тут появляется п#$%#к, который на весь интернет орет о том, как этот ЯП нужно чуть ли не через Роскомнадзор запретить.
Ну, все было бы неплохо, если бы общение между пользователем и этими вашими NLP не напоминало бы Равшана, Джамшута, и насяльника… Что-то пока подвижек не видно.
Однако, теперь интерфейс, работа с программами на пару с оборудованием чем-то от Линукса к Линуксу отличаются? Или тут рассматривались варианты вроде «поставить с полпинка, ни в чем не разбираться, предустановлены калькулятор, пасьянс, и опенофис»? На самом деле, большая часть современных дистрибутивов так или иначе представляют из себя одно и то же, за исключением дефолтной DE и пакетного менеджера.
Спойлер
А DE, кстати, можно менять, тысячи их!
К тому же, неиллюзорно горит от того, что с названием «Windows -> Linux(а не минт)» рядом с консольными командами не написано «команды специфичны для Debian-based дистрибутивов, для остальных гуглите свои». А «юзеру» может быть не совсем очевидно, что в Минте есть apt-get, а в Manjaro, к примеру, нет.
До кучи — а с каких пор такие статьи вообще на хабре пишут? Позор.
Сейчас, наверное, заминусуете… Однако, хотелось бы услышать долю инсайда от человека, который близок к MS. Вопрос только один. Как заставить разработчиков это использовать? Нет, API хорошее, но на сказке о порочном круге «нет пользователей — нет разработчиков» уже не одну собаку съели. А сама мысль тач-подобных приложений на десктопе меня в ужас приводит :)
Пытался, честно, использовать самые разные приложения — почта, календарь, тот же калькулятор, Skype, Twitter, и т.д. — все это попросту неудобно на мыши и клавиатуре. Превращение приложений из многофункциональных в однокнопочные — бабушке полезно, но не мне.
Вчера попробовал поставить себе другую тему Windows из магазина. Скачалась как приложение, оказалась в Пуске, не запустилась, окошки остались прежними. Ну вот кто будет пользоваться таким магазином?
У меня четвертый год Windows Phone — с 520 до 930. По последнему опыту готов сказать, что, несмотря на все потуги Майкрософта в области UWP, эту технологию попросту некому использовать — старые мобилки выброшены из сопровождения, новых не появляется. Мобильный мир, судя по feature2(кто знает — поймет), заморожен и убит, а десктопный — мертворожденно.
Мне вот упорно кажется, что хостингу VPS/VDS есть о чем рассказать, помимо «лайфхак-гайдов», 100% которых гуглится в интернете, и достойных школьника, случайно прорвавшегося на хабр.
Спасибо за интересную статью! Получил истинное удовольствие, сходил на сайт GIMPS и установил Prime95:) Возник тут сразу вопрос. А есть какое-нибудь более-менее активное применение этим числам? В криптографии, например.
Если уж статья рассчитана на людей, которые не в курсе, что же такое рекурсия, зачем же давать им столь ядовитые примеры? Сугубо из математического представления? Факториал — еще ладно, хрен с ним(хотя бы не создает извратной сложности алгоритма, но так писать тоже нельзя), но вот вычисление чисел Фибоначчи должно выглядеть исключительно как пример, показывающий, к чему приводит рекурсия, если ее применять бездумно(с расчетом количества операций и объяснением, к чему это может привести), не как пример применения рекурсии. А я вот во всем тексте увидел только невнятное «большое дерево вызовов», которое этот новичок скорее всего пролистает…
Согласен с данным замечанием. Но в таком случае все такие моменты должны быть строго описаны в ТЗ(вместо просто указания версии ОС), а иначе все это смотрится как аккуратно поставленные грабли перед лбом разработчика, причем неочевидные и ни разу не необходимые. Человек, к примеру, занимающийся разработкой прошивок для устройств под проект, или каких-либо конкретных программ, не обязан знать юридические подробности и тонкости сертификации используемой ОС, и узнает об этом он, только прочитав ТЗ либо сопутствующую документацию (если там, конечно, что-то по этому поводу имеется). Вообще, данное знание находится на пару-тройку уровней иерархии выше. Узнать о подобных граблях за три месяца до сдачи двухгодового проекта - то еще удовольствие. Почему за три месяца? Гхм, я во втором своем посте в начале об этом написал :)
И если первые грабли скорее назойливы(скорее, даже придирка с моей стороны), то вторые представили реальную проблему, которую без излишнего костылирования и отказа от части функциональности решить так и не удалось.
P.S. Нет, я не знаю, где здесь конкретные претензии непосредственно к Astra Linux SE. Претензии скорее направлены на организацию работы как таковой.
В закупке я непосредственно не участвовал, но отчетливо помню, что от момента «надо закупать дистр» до «оп, у меня в руке диск» прошло не менее полугода, а от людей, которые этим занимались, я регулярно слушал отборный мат — то документы с той стороны не согласовали, то, гхм, в письме печать/подпись поставить забыли, то прыщи на ж*…
Что касается непосредственно работы с софтом, две проблемы.
Одна — простой и быстро решаемый, но сходу удивляющий геморрой, который выражается в отсутствии gcc и make не только в базовой установке, но и на диске с ОС. Компилятор надо покупать на втором диске, который продается отдельно :) А если вдруг купил первый, но не купил второй, то после установки получишь систему, на которой даже VirtualBox's Guest Additions не запустить. Интересно, а они сами когда-либо пробовали работать с ОС Linux без компилятора?
Вторая очень специфическая. Возникла необходимость пересобрать ядро с определенными ключами — увеличить максимальный размер выделяемой непрерывной физической памяти(kmalloc), т.к. требовался большой DMA-буфер, а переписывать железяку для работы со scatter-gather соисполнителям было лень. Решается сие добавлением одного-единственного параметра компиляции к ядру(FORCE_MAX_ZONEORDER вроде). Попытка самостоятельной пересборки обвалилась - новое ядро отказывалось грузиться дальше логин менеджера, и все тут. Позвонили в техподдержку, а они нам сообщили, что у них Своя(тм) система сборки ядра, и без нее ничего не заработает, и попросили 10 миллионов рублей (sic!) для разработки персонализированной версии Astra Linux…
Добавлю тут же, что если средняя офисная работница вдруг вместо красивой десяточки увидит богомерзкий интерфейс Fly, который выедает глаза подчистую, делаю ставку, что убежит и спотыкаться на бегу будет. Вот почему, почему не использовать те же XFCE/LXDE/MATE/...? NIH?
Смотрится, честно говоря, как Болгенос на компьютере Попова.
А если серьезно, довелось мне как-то раз вплотную пообщаться со Astra Linux Special Edition, и это был, наверное, худший опыт общения с Linux за все время работы. На всех уровнях — от закупок лицензий до компиляции софта. Если у кого-то есть возможность — БЕГИТЕ, ГЛУПЦЫ!
По теме, конечно, Вы правы — решения подобного рода создают некоторые проблемы. Конечно, в случае простого воспроизведения видео перечисленные стандартные инструменты достаточно просто решают эту проблему. В конкретно этом случае, помимо воспроизведения на это видео была наложена достаточно сложная обработка в трех различных потоках, и освобождение всех ресурсов(хотя бы для того, чтобы вернуться в состояние «мы ничего не воспроизводим и не обрабатываем, можем подключаться к другой камере») было возможным только после завершения таймаута — т.к. потоки должны завершить работу, а один из них висит в блокирующем вызове и держит пару других в блокировках — ждут следующего кадра. Можно было перейти на сигналы/слоты Qt, другие способы асинхронной передачи, только вот для того, чтобы прийти в вышеупомянутое состояние, так или иначе работу всего включенного нужно завершить. Если задача не в том, чтобы "написать красиво, идеально, по всем стандартам", а "сделать так, чтобы успеть по графику, получить простой в обращении и модифицируемый код" — а именно так обычно и нужно в продакшене — порой проще сделать некорректно.
Конечно, ситуацию можно назвать ошибкой проектирования, или некорректным выбором способа захвата видеопотока, или же отсутствием опыта программистов, ответственных за задачу, безусловно, но статья не несет в себе цели принести этот способ в массы — скорее, обратить внимание на проблему. Что, фактически, мешает разработчикам добавить в класс VideoCapture пару методов вроде setOpenTimeout/setReadTimeout? Гвоздями забитые #define TIMEOUT 30000? Мы за такое у себя на работе морду бьем. Пытался связаться с разрабами — безрезультатно. Вот и статья.
Имеется в виду, что если конкретный редактор этого не поддерживает, это не вызывает проблем. Ну, у меня, по крайней мере.
Имелось в виду, что большая часть IDE умеет во время написания кода это делать. Хочется лишь сказать, что то, что этого нет — минус, но не повод выкидывать что-либо на помойку. Плюсов там изрядно больше, чем мелких, но досадных минусов. Написать хорошую IDE силами 5-6 человек, и поддерживать ее с учетом выхода новых возможностей, как минимум, очень сложно. Особенно учитывая некоммерческую суть проекта.
Пардон, эти элементы языка (ну, кроме указателей) далеко за пределами уровня школьника или студента 1-2 курса (вспоминаем, что я говорил об аудитории).
Не оправдываю разработчиков в плане периодически отваливающегся парсера для автоформатирования… Слегка оффтоп, на деле. Придерусь к одному моменту, ибо в недоумении.
Кому оно вообще нужно? Форматирование какбэ для удобства не только чтения, но и написания служит… Если не делаешь это на автомате руками, работа превращается слегка в боль, не? Если сначала код писать, а потом форматировать, то в чем цель? Сдать преподу, чтоб два не поставил за корявый вид, который читать противно?.. Форматирование кода — базовый скилл вроде, должен быть встроен в любого программиста на уровне коры мозга.
Нет, один юзкейс есть — вставить код из стековерфлоу. А еще?
По факту, не так давно этот человек начал активно заливать г#$%ом страницу Википедии проекта — размещать там ссылки на Issue на гитхабе, рассказывать о том, насколько же «нельзя» этим Паскалем пользоваться… Теперь вот дошел до того, что целый пост на Хабр написал с той же целью. Интересно только, в чем мотивация.
По части того, насколько активно в обучении используются те или иные фичи — расскажу свою историю. Закончил я мехмат ЮФУ в 2016 году (магистратуру — начинал, соответственно, в 2010). В качестве первого языка для курса «Основы программирования» (продуктивной работы и хороших студентов Вам, Станислав Станиславович!) на первом году обучения был поставлен именно он. Поначалу (я пришел с крайне неплохим бэкграундом в плане опыта программирования на фоне остальных однокурсников) действительно возникала куча вопросов. В основном, связанных с тем, что в продакшене этот язык не используется, и возможность не предвидится. Курс, однако, закончился, а потом…
На втором году обучения вся группа «подтянула» свои знания по C#, Java, C++, Python буквально за две-три недели за язык (ну ладно, на С++ целый год потратили, да, но писать простенькие программы смогли очень быстро), а сложность освоения новых языков свелась практически к нулю. Почему? Потому, что буквально на каждую конструкцию, которая в них встречалась, находилась та, которую мы уже выучили, и знали принципы работы с ней на языке PascalABC.NET. Спрашиваете, зачем все эти фичи, которые реализуют разработчики? Именно по этой причине — обеспечить плавный и легкий переход на практически любой язык, любую среду программирования. То, что не является стабильным (т.е. экспериментальные, разрабатываемые фичи), мною за время обучения не было увидено ни разу — разве что, сам накопаешь кровно-потными трудами, если есть желание что-то «поломать». К моменту, когда пришла пора рассказывать об этих самых фичах на курсах по ЯП, они уже протестированы и стабильны.
То, что человек тут пишет о использовании PascalABC.NET в крупных проектах и промышленной разработке (и о том, что этого нужно избегать), явно говорит о том, что он еще школьник (ну, максимум, первый-второй курс) — зайдите интереса ради на форум мехмата — там таких добрый десяток, с «крупными» проектами вроде «напишем свой тридэ движок на пацкалях, и будем игры писать». Людям, которые имеют работу в нашей области, не нужно объяснять, почему язык не ставит себе целью эту самую промышленность. На это же намекают и орфографические ошибки вроде «по чему». Опять же, юношеский максимализм и абсолютизм, с которым эта «критика» преподносится, указывает на то же самое. Школьники, пожалуй, порой и умные вещи говорят, но в таких случаях их редко можно от взрослого человека отличить.
То, что там есть баги, вполне объяснимо малым размером команды, которая, к слову, не только этим занимается — проект некоммерческий, надо еще и кушать что-то. Там, где максимальный охват аудитории (школа, первокурсники), 99,9% функциональности работает на отлично.
Вопрос к автору у меня только один. Откуда столько хейта? Двойку поставили?
Обидно просто. Учитывая объем работ команды разработчиков, усилия приложены титанические. И обучающий эффект мощнейший, по крайней мере, в руках хорошего преподавателя. А тут появляется п#$%#к, который на весь интернет орет о том, как этот ЯП нужно чуть ли не через Роскомнадзор запретить.
К тому же, неиллюзорно горит от того, что с названием «Windows -> Linux(а не минт)» рядом с консольными командами не написано «команды специфичны для Debian-based дистрибутивов, для остальных гуглите свои». А «юзеру» может быть не совсем очевидно, что в Минте есть apt-get, а в Manjaro, к примеру, нет.
До кучи — а с каких пор такие статьи вообще на хабре пишут? Позор.
Пытался, честно, использовать самые разные приложения — почта, календарь, тот же калькулятор, Skype, Twitter, и т.д. — все это попросту неудобно на мыши и клавиатуре. Превращение приложений из многофункциональных в однокнопочные — бабушке полезно, но не мне.
Вчера попробовал поставить себе другую тему Windows из магазина. Скачалась как приложение, оказалась в Пуске, не запустилась, окошки остались прежними. Ну вот кто будет пользоваться таким магазином?
У меня четвертый год Windows Phone — с 520 до 930. По последнему опыту готов сказать, что, несмотря на все потуги Майкрософта в области UWP, эту технологию попросту некому использовать — старые мобилки выброшены из сопровождения, новых не появляется. Мобильный мир, судя по feature2(кто знает — поймет), заморожен и убит, а десктопный — мертворожденно.
И если первые грабли скорее назойливы(скорее, даже придирка с моей стороны), то вторые представили реальную проблему, которую без излишнего костылирования и отказа от части функциональности решить так и не удалось.
P.S. Нет, я не знаю, где здесь конкретные претензии непосредственно к Astra Linux SE. Претензии скорее направлены на организацию работы как таковой.
Что касается непосредственно работы с софтом, две проблемы.
Одна — простой и быстро решаемый, но сходу удивляющий геморрой, который выражается в отсутствии gcc и make не только в базовой установке, но и на диске с ОС. Компилятор надо покупать на втором диске, который продается отдельно :) А если вдруг купил первый, но не купил второй, то после установки получишь систему, на которой даже VirtualBox's Guest Additions не запустить. Интересно, а они сами когда-либо пробовали работать с ОС Linux без компилятора?
Вторая очень специфическая. Возникла необходимость пересобрать ядро с определенными ключами — увеличить максимальный размер выделяемой непрерывной физической памяти(kmalloc), т.к. требовался большой DMA-буфер, а переписывать железяку для работы со scatter-gather соисполнителям было лень. Решается сие добавлением одного-единственного параметра компиляции к ядру(FORCE_MAX_ZONEORDER вроде). Попытка самостоятельной пересборки обвалилась - новое ядро отказывалось грузиться дальше логин менеджера, и все тут. Позвонили в техподдержку, а они нам сообщили, что у них Своя(тм) система сборки ядра, и без нее ничего не заработает, и попросили 10 миллионов рублей (sic!) для разработки персонализированной версии Astra Linux…
Добавлю тут же, что если средняя офисная работница вдруг вместо красивой десяточки увидит богомерзкий интерфейс Fly, который выедает глаза подчистую, делаю ставку, что убежит и спотыкаться на бегу будет. Вот почему, почему не использовать те же XFCE/LXDE/MATE/...? NIH?
А если серьезно, довелось мне как-то раз вплотную пообщаться со Astra Linux Special Edition, и это был, наверное, худший опыт общения с Linux за все время работы. На всех уровнях — от закупок лицензий до компиляции софта. Если у кого-то есть возможность — БЕГИТЕ, ГЛУПЦЫ!
По теме, конечно, Вы правы — решения подобного рода создают некоторые проблемы. Конечно, в случае простого воспроизведения видео перечисленные стандартные инструменты достаточно просто решают эту проблему. В конкретно этом случае, помимо воспроизведения на это видео была наложена достаточно сложная обработка в трех различных потоках, и освобождение всех ресурсов(хотя бы для того, чтобы вернуться в состояние «мы ничего не воспроизводим и не обрабатываем, можем подключаться к другой камере») было возможным только после завершения таймаута — т.к. потоки должны завершить работу, а один из них висит в блокирующем вызове и держит пару других в блокировках — ждут следующего кадра. Можно было перейти на сигналы/слоты Qt, другие способы асинхронной передачи, только вот для того, чтобы прийти в вышеупомянутое состояние, так или иначе работу всего включенного нужно завершить. Если задача не в том, чтобы "написать красиво, идеально, по всем стандартам", а "сделать так, чтобы успеть по графику, получить простой в обращении и модифицируемый код" — а именно так обычно и нужно в продакшене — порой проще сделать некорректно.
Конечно, ситуацию можно назвать ошибкой проектирования, или некорректным выбором способа захвата видеопотока, или же отсутствием опыта программистов, ответственных за задачу, безусловно, но статья не несет в себе цели принести этот способ в массы — скорее, обратить внимание на проблему. Что, фактически, мешает разработчикам добавить в класс VideoCapture пару методов вроде setOpenTimeout/setReadTimeout? Гвоздями забитые #define TIMEOUT 30000? Мы за такое у себя на работе морду бьем. Пытался связаться с разрабами — безрезультатно. Вот и статья.