Абсолютно согласен. Именно из-за лютого ручного make, адского autotools или чудного cmake на C писать не особо комфортно. Все те же проблемы ассемблера, только теперь кроссплатформенные.
Лично для себя я пишу утилиты на node.js, а для production, учитывая специфику embedded, т.е. когда требуется быстродействие и компактность, пишу на си. И иной раз без подключения стандартной библиотеки. :)
В windows писать для консоли вообще не принято. Из-за чего приходится лепить окошки и тратить время на свистелки. Но окошки там красивее :)
Они выпустили новую версию приложения с материальным дизайном, где у всех списков очень большая высота строк. В итоге на экране телефона помещается только три строчки.
Купил своему ребенку микроник. Всё хорошо, но вот детали в макетке очень плохо держатся и контакт плохой. Чтоб схема запустилась надо все детальки пошевелить. А в целом очень клёво.
Ну, если вспомнить Turbo Pascal… Там тоже заголовок модуля прекомпилирован. Но, как правильно замечено в следующем комментарии, шаблоны C++, некий аналог макросов, очень сложно прекомпилировать.
Но самой главное препятствие — препроцессор. Модули возможно ввести только когда отказаться от него, а это полная перестройка всех исходников. Это будет другой язык.
Я про модули не понял. Он же по сути состоит из двух частей: объявления и непосредственно кода. Объявления подгружаются с помощью include ибо они не должны быть большими(у разумных людей). А код уже скомпилированный в виде архива/объектника/библиотеки.
В объявлениях могут быть макросы коие никак не представляются в коде. Т.е. заголовки модулей не могут обладать всей мощью include. Следовательно модуль придётся упростить до набора внешних функций, переменных или констант.
Где-то в исходнике модуля надо ввести аттрибут 'extern' из которого в неявном виде будет выделяться объявление(такой уже есть).
Текстовые include вы не хотите, но всё равно придётся вводить директиву подключения модуля. Что-то вроде #import <stdio>. Оно чем-то принципиально лучше #include?
И реально никто не сделал такого для C? Там ведь тоже можно сделать что-то вроде package.json и придумать общую схему для подсасывания зависимостей и сбора include папки из пакетов.
У grub реально есть свой CLI. Так что всё логично. :)
Внедряя JSON везде вы усложняете жизнь простым программам. Для хранения разобранного дерева надо использовать динамическую память, хеш таблицы, списки и пр. Это типичный подход прикладника. Зафигачить всё с помощью толстых библиотек, лишь бы не думать. :) Без обид. Но именно прикладники заблуждаются про стоимость printf и strcmp.
Для большинства маленьких утилит как раз достаточно пробежаться по строчкам и выделяя ключи распихать значения по статическим переменным. И никаких лишних зависимостей и динамических структур.
Большие и жирные программы могут и в JSON хранить, если им так удобнее. Но ведь не хранят. Почему? Может простые форматы эффективнее для их решения?
Кто-то там сверху писал про строки. В C++ std::string это кромешный ад и обман. За как будто ясным API скрывается ужас реализации с колоссальным дублированием кода и потреблением ресурсов. Я в 90-ых годах фанател от C++ и думал, что ООП очень помогает эффективности. Но когда познакомился с реальностью был в ужасе. Люди не умеют пользоваться ООП.
Лично мне в C не хватает строгой типизации и объявления функций в функциях с доступом к локальным переменным. Но даже имеющийся С годен. Достаточно просто делать продуманные API.
И кстати, про C 2.0 согласен. Можно было бы сделать :) Просто чуточку выправить. Но как грузить модули динамически со статической типизацией без извратов?
В целом спор бесполезен пока мы не договоримся о целях и приоритетах. Кто-то пишет компактно и эффективно, а кто-то пишет без оглядки на ресурсы, но с как бы комфортом. Отсюда и вкусы разные.
Как сейчас модно говорить, у автора разорвало пукан!
Когда я только перешёл работать на linux (лет 10 назад) с windows у меня тоже было подобное настроение. Всё было неудобно, нелогично и убого. Вони было побольше, чем у автора. Но спустя пару лет я вдруг понял насколько проще работать и разрабатывать под Linux. На венду меня теперь не загнать. 25 лет пишу софт. Уж поверьте. :)
Так вот. Текстовые конфиги в большинстве своём имеют настолько примитивный формат, что парсятся на раз. И это огромная сила unix. В итоге, для настройки системы достаточно текстового редактора и интеллекта!
JSON и XML не годятся для человека. Они требуют сложного парсинга, трудно читаемы и их структуру легче поломать.
Для бинарных форматов вообще будут нужны специальные утилиты. И, если их форматы универсальны, так же требуют парсинга. В обратном случае хранимые бинарные структуры будут платформо-зависимы и требовать регулярного обновления при добавлении новых полей.
По поводу языка C тоже скажу. По сути это кроссплатформенный ассемблер. Он должен обеспечивать полный контроль над аппаратурой. Разве что он оффициально не подпускает к регистру состояния процессора со всякими там битами переноса, но во всём остальном он хорош. И если бы вы попробовали написать синтаксический парсер этого языка, то больше бы не докапывались до него. Я вообще считаю, что он во много просто гениален. Очень простой и при этом мощный.
По поводу модульности в C. Разве sudo apt-get install libevent не похоже на npm i libevent?
Язык Shell. Не стоит на нём писать что-то большое. Разбейте задачу на отдельные функции и сделайте их на подходящем для этого языке и только затем совместите их функционал в одном sh-сценарии. Это я пишу потому, что есть некоторые личности, которые пишут JSON парсеры/генераторы на Sh и потом жалуются.
Про printf вообще смешно. Если вы не понимаете как работает эта функция, то согласитесь, что проблема не в ней.
Ну и так далее...
И кстати, я не говорю, что unix идеальна. Очень много бардака. Особенно там, где разработку вело много народа. И на мой взгляд, историческое наследие в виндовс на много тяжелее и буквально жирнее.
Очевидно, что автор уже на… игрался в настройки устройств и уже хочет чтобы всё просто нормально работало и не отнимало его времени. Очень его понимаю.
Вы молодцы. И действовали как профессионалы. А мы, любители, обожаем всё делать своими руками. Но чаще всего мы просто не в курсе существования имеющихся инструментов. Хуже того, мы даже их не ищем, а сразу с щенячим восторгом велосипедим. :)
Лет 12 назад, когда руссифицировал китайские DECT телефоны будучи в командировке на фабрике наблюдал подобный подход у китайцев. Местный программист в excel рисовал клетки знакомест, печатал их на принтере, карандашиком заполнял пиксели букв и далее как у вас. А мне приходилось ждать результата и от скуки за пару часов в том же excel(я тогда был виндоузятником) сделал ему таблицу и генератор исходника. На пробел назначил горячую клавишу переключения значения пикселя (просто менялся цвет фона ячейки). Он так этим и не воспользовался. А уж ошибок наделал, вообще печаль. Но тогда удалось забрать у них исходники и мой труд не пропал даром.
Вкусовщина. Лично для меня горбатый стиль остался в далёком прошлом, там же где пылятся всякие паскали, си++ и виндовсы. И именно идентификаторы через подчёркивание читаются легче, так как подчёркивание больше походит на пробел и соответственно облегчает чтение. А вот слитная запись для чтения трудна.
Сами сравните: ГорбатоПлотноеИмя или простое_для_чтения_обозначение.
Z: в начале пути к файлам немного отпугивает, хотя разделитель — нормальный /. А в целом, независимость драйверов от версии ядра выглядит киллер-фичей.
Не совсем понятна цель статьи. Покупайте наших слонов? Так как тема программирования скорее закрыта, чем открыта.
P.S. Но сам процессор заинтересовал.
IMHO, до реального применения далеко, как до Пекина. Так что продолжаем волноваться!
Абсолютно согласен. Именно из-за лютого ручного make, адского autotools или чудного cmake на C писать не особо комфортно. Все те же проблемы ассемблера, только теперь кроссплатформенные.
Лично для себя я пишу утилиты на node.js, а для production, учитывая специфику embedded, т.е. когда требуется быстродействие и компактность, пишу на си. И иной раз без подключения стандартной библиотеки. :)
В windows писать для консоли вообще не принято. Из-за чего приходится лепить окошки и тратить время на свистелки. Но окошки там красивее :)
Они выпустили новую версию приложения с материальным дизайном, где у всех списков очень большая высота строк. В итоге на экране телефона помещается только три строчки.
Купил своему ребенку микроник. Всё хорошо, но вот детали в макетке очень плохо держатся и контакт плохой. Чтоб схема запустилась надо все детальки пошевелить. А в целом очень клёво.
Сбербанк тоже сменил дизайн своего приложения на какой-то пустой
В итоге это будут не модули, а нечто жутко не простое. С++ уже сам по себе перегруженный язык и с такими модулями он вообще станет сложнее windows. ;)
Честно скажу, мне нравятся простые и лаконичные языки. C хорош своей простотой. А C++… — Бьёрна явно слишком занесло.
Ну, если вспомнить Turbo Pascal… Там тоже заголовок модуля прекомпилирован. Но, как правильно замечено в следующем комментарии, шаблоны C++, некий аналог макросов, очень сложно прекомпилировать.
Но самой главное препятствие — препроцессор. Модули возможно ввести только когда отказаться от него, а это полная перестройка всех исходников. Это будет другой язык.
Я про модули не понял. Он же по сути состоит из двух частей: объявления и непосредственно кода. Объявления подгружаются с помощью include ибо они не должны быть большими(у разумных людей). А код уже скомпилированный в виде архива/объектника/библиотеки.
В объявлениях могут быть макросы коие никак не представляются в коде. Т.е. заголовки модулей не могут обладать всей мощью include. Следовательно модуль придётся упростить до набора внешних функций, переменных или констант.
Где-то в исходнике модуля надо ввести аттрибут 'extern' из которого в неявном виде будет выделяться объявление(такой уже есть).
Текстовые include вы не хотите, но всё равно придётся вводить директиву подключения модуля. Что-то вроде
#import <stdio>. Оно чем-то принципиально лучше#include?И реально никто не сделал такого для C? Там ведь тоже можно сделать что-то вроде package.json и придумать общую схему для подсасывания зависимостей и сбора include папки из пакетов.
У grub реально есть свой CLI. Так что всё логично. :)
Внедряя JSON везде вы усложняете жизнь простым программам. Для хранения разобранного дерева надо использовать динамическую память, хеш таблицы, списки и пр. Это типичный подход прикладника. Зафигачить всё с помощью толстых библиотек, лишь бы не думать. :) Без обид. Но именно прикладники заблуждаются про стоимость printf и strcmp.
Для большинства маленьких утилит как раз достаточно пробежаться по строчкам и выделяя ключи распихать значения по статическим переменным. И никаких лишних зависимостей и динамических структур.
Большие и жирные программы могут и в JSON хранить, если им так удобнее. Но ведь не хранят. Почему? Может простые форматы эффективнее для их решения?
Кто-то там сверху писал про строки. В C++ std::string это кромешный ад и обман. За как будто ясным API скрывается ужас реализации с колоссальным дублированием кода и потреблением ресурсов. Я в 90-ых годах фанател от C++ и думал, что ООП очень помогает эффективности. Но когда познакомился с реальностью был в ужасе. Люди не умеют пользоваться ООП.
Лично мне в C не хватает строгой типизации и объявления функций в функциях с доступом к локальным переменным. Но даже имеющийся С годен. Достаточно просто делать продуманные API.
И кстати, про C 2.0 согласен. Можно было бы сделать :) Просто чуточку выправить. Но как грузить модули динамически со статической типизацией без извратов?
В целом спор бесполезен пока мы не договоримся о целях и приоритетах. Кто-то пишет компактно и эффективно, а кто-то пишет без оглядки на ресурсы, но с как бы комфортом. Отсюда и вкусы разные.
Как сейчас модно говорить, у автора разорвало пукан!
Когда я только перешёл работать на linux (лет 10 назад) с windows у меня тоже было подобное настроение. Всё было неудобно, нелогично и убого. Вони было побольше, чем у автора. Но спустя пару лет я вдруг понял насколько проще работать и разрабатывать под Linux. На венду меня теперь не загнать. 25 лет пишу софт. Уж поверьте. :)
Так вот. Текстовые конфиги в большинстве своём имеют настолько примитивный формат, что парсятся на раз. И это огромная сила unix. В итоге, для настройки системы достаточно текстового редактора и интеллекта!
JSON и XML не годятся для человека. Они требуют сложного парсинга, трудно читаемы и их структуру легче поломать.
Для бинарных форматов вообще будут нужны специальные утилиты. И, если их форматы универсальны, так же требуют парсинга. В обратном случае хранимые бинарные структуры будут платформо-зависимы и требовать регулярного обновления при добавлении новых полей.
По поводу языка C тоже скажу. По сути это кроссплатформенный ассемблер. Он должен обеспечивать полный контроль над аппаратурой. Разве что он оффициально не подпускает к регистру состояния процессора со всякими там битами переноса, но во всём остальном он хорош. И если бы вы попробовали написать синтаксический парсер этого языка, то больше бы не докапывались до него. Я вообще считаю, что он во много просто гениален. Очень простой и при этом мощный.
По поводу модульности в C. Разве
sudo apt-get install libeventне похоже наnpm i libevent?Язык Shell. Не стоит на нём писать что-то большое. Разбейте задачу на отдельные функции и сделайте их на подходящем для этого языке и только затем совместите их функционал в одном sh-сценарии. Это я пишу потому, что есть некоторые личности, которые пишут JSON парсеры/генераторы на Sh и потом жалуются.
Про
printfвообще смешно. Если вы не понимаете как работает эта функция, то согласитесь, что проблема не в ней.Ну и так далее...
И кстати, я не говорю, что unix идеальна. Очень много бардака. Особенно там, где разработку вело много народа. И на мой взгляд, историческое наследие в виндовс на много тяжелее и буквально жирнее.
Избегайте необдуманного следования правилам моды. Сегодня они помогут, а завтра подведут.
Очевидно, что автор уже на… игрался в настройки устройств и уже хочет чтобы всё просто нормально работало и не отнимало его времени. Очень его понимаю.
Вы молодцы. И действовали как профессионалы. А мы, любители, обожаем всё делать своими руками. Но чаще всего мы просто не в курсе существования имеющихся инструментов. Хуже того, мы даже их не ищем, а сразу с щенячим восторгом велосипедим. :)
Автор же написал, что это велосипед. Когда много времени очень приятно для практики поизобретать велики.
Лет 12 назад, когда руссифицировал китайские DECT телефоны будучи в командировке на фабрике наблюдал подобный подход у китайцев. Местный программист в excel рисовал клетки знакомест, печатал их на принтере, карандашиком заполнял пиксели букв и далее как у вас. А мне приходилось ждать результата и от скуки за пару часов в том же excel(я тогда был виндоузятником) сделал ему таблицу и генератор исходника. На пробел назначил горячую клавишу переключения значения пикселя (просто менялся цвет фона ячейки). Он так этим и не воспользовался. А уж ошибок наделал, вообще печаль. Но тогда удалось забрать у них исходники и мой труд не пропал даром.
Вкусовщина. Лично для меня горбатый стиль остался в далёком прошлом, там же где пылятся всякие паскали, си++ и виндовсы. И именно идентификаторы через подчёркивание читаются легче, так как подчёркивание больше походит на пробел и соответственно облегчает чтение. А вот слитная запись для чтения трудна.
Сами сравните: ГорбатоПлотноеИмя или простое_для_чтения_обозначение.
Z:в начале пути к файлам немного отпугивает, хотя разделитель — нормальный/. А в целом, независимость драйверов от версии ядра выглядит киллер-фичей.Я вообще считаю, что последний JS это ES5. Всё что потом, это JS++. Очень уж его усложнили.