Мне нравится тем, что в один дистрибутив включены все или почти все среды рабочего стола, и также много софта, который не нужно качать из интернета. Привычка такая «иметь все на одном диске» осталась еще со старых добрых времен, когда в подземных переходах продавали пиратские супер-сборники:)))
Ну и кроме того, это полезно там, где нужно установить линукс, а интернета нет физически.
Открываем любой мейкфайл — и видим if, else, case и т.д. Это не декларативность.
Одна из причин, по которой мне нравится декларативность — как раз макимальная интеграция с IDE. Можно открыть опции в каком-нибудь редакторе свойств, список файлов доступен визуально и т.д.
Да, в сложных проектах вероятно действительно нужен именно язык сборки, и скорее всего чисто декларативным проектом не обойтись. Я это прекрасно понимаю. Скажу честно — я не знаю как разрешить это противоречие. Но вероятно, нужно идти в сторону некоего структурированного файла, в котором информация по максимуму представлена в декларативном виде (и полностью доступна из IDE), а императивные фрагменты изолированы и написаны на чем-то более современном, чем то на чем написаны makefiles. Я не знаю, может быть javascript подойдет на эту роль и Qt Build System?
либо журналисты просто поиграли на публику в традициях голливудских фильмов про хакеров. Чтобы публика обратила внимание на проблему.
Программное стирание данных с жесткого диска не так интерсно и зрелищно для обывателей, как распиливание компьютера болгаркой.
Make-файлы действительно ужасны. Код на бейсике и тот лучше выглядит:)
Я вообще за декларативный подход к описаню проектов вместо императивного, т.е. это должен быть не скрипт типа make-файла, а иерархический файл на базе xml или чего-то подобного, внутри которого в определенных узлах дерева содержатся имена файлов проекта, зависимости, опции компиляции и т.п. Более того, я склоняюсь к мысли, что базовый формат файла проекта должен включаться в стандарт языка программирования, чтобы любой компилятор и любая среда разработки могли открыть и скомпилировать любой проект (созданный в другой IDE и для другого компилятора) целиком. Разумеется, каждая IDE может иметь свои «расширения» формата, не влияющие на суть проекта, но в том же xml можно спокойно это организовать.
Что касается сред разработки — в них главное действительно то, что они должны работать. Дебаггеры обязательно нужны — иногда проще один раз пройти по шагам в отладчике, чтобы понять что неправильно в алгоритме, чем что-то там компилировать в уме. Ну и конечно, среды разработки должны быть легкими. И в смысле простоты использования, и в смысле потребляемых ресурсов компьютера. Много функций не надо — но те что есть, должны работать безупречно, не тормозить и не глючить ни при каких обстоятельствах.
Писать же код в блокнотах, вимах и т.п. — если люди привыкли то почему-бы и нет, но приятнее все-же пользоваться специальными инструментами.
Людям будет понятнее о чем речь:) Для гугления опять же больше подходит. Мне тоже пришла в голову мысль о скрещивании Objective C и D (что тоже кстати было бы интересно).
То что вы сделали — уже очень круто. А если вы сделаете полноценную реализацию такого языка для LLVM, это будет уже не просто круто, а войдет в историю.
Даже не знаю что сказать:)
С одной стороны, очень познавательно и объяснено понятным языком, за что спасибо.
С другой… это-ж сколько людей делают деньги из воздуха (и там ведь не только торговцы, но и огромная индустрия IT). Эти бы усилия, да направить на микробиологию или квантовую физику…
Вся эта статья выглядит как фрикерство в чистом виде, и не более того. Один деятель тут помнится таблицу Менделеева пытался переоткрыть… вот это примерно то же самое.
Печально что на Хабре время от времени появляются такие личности…
Пост ни о чем.
Таких схем (причем отличающихся друг от друга) можно нарисовать тысячи, и все они будут в общем и целом выглядеть как «правильные», и общих рассуждений такого рода можно нагенерировать столько, что на несколько книг хватит, но при этом все это будет ни о чем. Не знаю что там было в предыдущих постах, но если то же самое — правильно что заминусовали.
Провод толстоват и явно не на месте. Его бы надо сделать на конце дужки, за ухом, там бы он не мешал. И отключаемым конечно — кому-то удобнее провод, кому-то — аккумуляторы на очках таскать,
В том-то и дело, что «свой кастомный внутренний бинарный формат хранения данных». Я тоже такой могу придумать и придумывал неоднократно.
А хочется, чтобы был некий универсальный и повсеместно распространенный формат, библиотеки для работы с ним в большинстве языков программирования, софт для просмотра и редактирования этих данных и т.д. Как с XML.
Хорошо. Про текстовые форматы (типа xml и json) знают все, а бинарные к сожалению не так широко известны (я например знал лишь то что они существуют, но ни разу с ними не сталкивался ни как программист, ни как пользователь).
Почему-то вспомнились стародавние времена.
Во времена dial-up'а такое было — то-ли шутка, то-ли на самом деле, какая-то программа с базой телефонов модемных пулов и паролей бесплатного доступа к инету; пользователь ее ставил — а через некоторое время и его купленные у провайдера логины и пароли появляются в этой базе:)
Возможно, лампочки накаливания слишком дешевы и с них слишком маленькая прибыль, и сами производители ламп лоббируют такие законы, чтобы продавать только дорогие галогенные и светодиодные лампы, и чтобы ни у кого не было даже возможности продавать дешевые?
Эх, были же девайсы в старые добрые времена!
qwerty-клавиатура, радиоканал, пиринговая сеть по радио, рация, гениальная идея знакомств через сопоставление анкет близлежащих устройств…
Когда-же появится какая-нибудь фирма, которая начнет делать такие вот замечательные оригинальные устройства с современной начинкой и современной мобильной ОС? Одинаковые смартфоны-кирпичи уже надоели.
А вот на собеседовании каком-нибудь обязательно про эти «шаблоны в шаблонах в шаблонах» спросят:)
В реальном кодинге я использую шаблоны именно так, как предполагалось изначально — для универсальных по отношению к какому-то типу функций и классов. Шаблоны в шаблонах, SFINAE и прочие абстракции ни разу не понадобились. Зато очень часто возникает необходимость в рефлексии, в функциональном программировании (лямбда-функции, замыкания и т.д.), в модулях (система инклудов — это самая большая беда С/С++), и еще пожалуй в каких-то простых мелочах, которые почему-то упустили.
Если посмотреть на boost, то многие из бустовских библиотек могут быть отличным примером того, что должно быть продумано и реализовано на языковом уровне, но не реализовано. Но потребность в этих фичах есть, и в результате сделали такие хитроумные реализации этих возможностей (которые по сути есть костыли для языка программирования, и к тому же не всегда работают корректно). А программисты, компилируя каждый раз буст, по сути вынуждены компилировать каждый раз «внутренности» самого компилятора:)
Ну и кроме того, это полезно там, где нужно установить линукс, а интернета нет физически.
Одна из причин, по которой мне нравится декларативность — как раз макимальная интеграция с IDE. Можно открыть опции в каком-нибудь редакторе свойств, список файлов доступен визуально и т.д.
Да, в сложных проектах вероятно действительно нужен именно язык сборки, и скорее всего чисто декларативным проектом не обойтись. Я это прекрасно понимаю. Скажу честно — я не знаю как разрешить это противоречие. Но вероятно, нужно идти в сторону некоего структурированного файла, в котором информация по максимуму представлена в декларативном виде (и полностью доступна из IDE), а императивные фрагменты изолированы и написаны на чем-то более современном, чем то на чем написаны makefiles. Я не знаю, может быть javascript подойдет на эту роль и Qt Build System?
Программное стирание данных с жесткого диска не так интерсно и зрелищно для обывателей, как распиливание компьютера болгаркой.
Я вообще за декларативный подход к описаню проектов вместо императивного, т.е. это должен быть не скрипт типа make-файла, а иерархический файл на базе xml или чего-то подобного, внутри которого в определенных узлах дерева содержатся имена файлов проекта, зависимости, опции компиляции и т.п. Более того, я склоняюсь к мысли, что базовый формат файла проекта должен включаться в стандарт языка программирования, чтобы любой компилятор и любая среда разработки могли открыть и скомпилировать любой проект (созданный в другой IDE и для другого компилятора) целиком. Разумеется, каждая IDE может иметь свои «расширения» формата, не влияющие на суть проекта, но в том же xml можно спокойно это организовать.
Что касается сред разработки — в них главное действительно то, что они должны работать. Дебаггеры обязательно нужны — иногда проще один раз пройти по шагам в отладчике, чтобы понять что неправильно в алгоритме, чем что-то там компилировать в уме. Ну и конечно, среды разработки должны быть легкими. И в смысле простоты использования, и в смысле потребляемых ресурсов компьютера. Много функций не надо — но те что есть, должны работать безупречно, не тормозить и не глючить ни при каких обстоятельствах.
Писать же код в блокнотах, вимах и т.п. — если люди привыкли то почему-бы и нет, но приятнее все-же пользоваться специальными инструментами.
То что вы сделали — уже очень круто. А если вы сделаете полноценную реализацию такого языка для LLVM, это будет уже не просто круто, а войдет в историю.
С одной стороны, очень познавательно и объяснено понятным языком, за что спасибо.
С другой… это-ж сколько людей делают деньги из воздуха (и там ведь не только торговцы, но и огромная индустрия IT). Эти бы усилия, да направить на микробиологию или квантовую физику…
Печально что на Хабре время от времени появляются такие личности…
Таких схем (причем отличающихся друг от друга) можно нарисовать тысячи, и все они будут в общем и целом выглядеть как «правильные», и общих рассуждений такого рода можно нагенерировать столько, что на несколько книг хватит, но при этом все это будет ни о чем. Не знаю что там было в предыдущих постах, но если то же самое — правильно что заминусовали.
А хочется, чтобы был некий универсальный и повсеместно распространенный формат, библиотеки для работы с ним в большинстве языков программирования, софт для просмотра и редактирования этих данных и т.д. Как с XML.
Во времена dial-up'а такое было — то-ли шутка, то-ли на самом деле, какая-то программа с базой телефонов модемных пулов и паролей бесплатного доступа к инету; пользователь ее ставил — а через некоторое время и его купленные у провайдера логины и пароли появляются в этой базе:)
qwerty-клавиатура, радиоканал, пиринговая сеть по радио, рация, гениальная идея знакомств через сопоставление анкет близлежащих устройств…
Когда-же появится какая-нибудь фирма, которая начнет делать такие вот замечательные оригинальные устройства с современной начинкой и современной мобильной ОС? Одинаковые смартфоны-кирпичи уже надоели.
В реальном кодинге я использую шаблоны именно так, как предполагалось изначально — для универсальных по отношению к какому-то типу функций и классов. Шаблоны в шаблонах, SFINAE и прочие абстракции ни разу не понадобились. Зато очень часто возникает необходимость в рефлексии, в функциональном программировании (лямбда-функции, замыкания и т.д.), в модулях (система инклудов — это самая большая беда С/С++), и еще пожалуй в каких-то простых мелочах, которые почему-то упустили.
Если посмотреть на boost, то многие из бустовских библиотек могут быть отличным примером того, что должно быть продумано и реализовано на языковом уровне, но не реализовано. Но потребность в этих фичах есть, и в результате сделали такие хитроумные реализации этих возможностей (которые по сути есть костыли для языка программирования, и к тому же не всегда работают корректно). А программисты, компилируя каждый раз буст, по сути вынуждены компилировать каждый раз «внутренности» самого компилятора:)