Согласен с разбором по нишам, но не согласен с начальными тезисами
1. Да, это замена Obj-C, но весьма существенная. Т.к. если раньше убогий Obj-C вызвал лишь усмешку у народа с других платформ, то теперь данный язык вполне может оказаться поприятнее базовых инструментов на других платформах. А это существенно меняет расклад.
2. Не понял как это у вас из логичного «десктоп-приложения под iOS и OS X» (с чем я согласен в общем то) вышло " разработки UI под iOS" — это как бы совсем разные вещи.
3. Область «большая часть приложений под OS X и iOS» — это мягко говоря не маленький кусочек рынка. О таких объёмах код для ядра ос/драйверов или даже серверный код может только мечтать.
А с итогом опять же согласен — лично я тоже просто прохожу мимо.
Очень странный комментарий. Как впрочем и сама статья. Создаётся такое впечатление, что вышла новая версия Objective-C, в то время как на самом деле родился принципиально новый язык.
По набору фич, позиционированию и т.п. он больше всего напоминает язык D, из которого выпилили метапрограммирование (одна из главных фич D кстати), исключения и поддержку многопоточности. Ну и плюс добавили несколько мелких вкусностей типа pattern matching и extensions. И всё это в оригинальном и довольно лаконичном синтаксисе.
Естественно это далеко не идеал, но в любом случае вышел отличный язык, поинтереснее тех же Java и C#. А уж на фоне такого дикого ужаса, как Objective-C, Swift должен казаться просто манной небесной.
P.S. Я сам мягко говоря не поклонники компании Apple. Но в данном случае нельзя не признать, что у них вышел очень интересный и нужный продукт.
А в чём смысл шифрования диска в данном случае? От сотрудников дата-центра оно всё равно не сможет защитить (при таком исполнение), а против внешних злоумышленников и вообще не работает (там вся защита в owncloud).
Замечание насчёт экономической взаимосвязи между странами абсолютно справедливое. Но вот конкретные примеры насчёт потребительских товаров и особенно еды весьма сомнительные.
Например по пшенице Россия является одним из ведущих экспортёров. Помнится даже что многие эксперты связывали начало событий в Египте с запретом экспорта пшеницы в тот год из России (у нас засуха была и чтобы не поднялись цены на хлеб, запретили экспорт). Ну и потребительские товары очень очень многие давно производятся в России, хотя и иностранными компаниями. Это и бытовая техника и автомобили и ещё очень много всего.
Но есть области где у нас действительно полная Ж. Например в области производства чипов, некоторых видов химии и лекарств, станков. Плюс горы всякой мелочи, которые сейчас штампуются в Китае на весь мир (это легко может делать любая страна, но в Китае просто дешевле). Да и ещё много чего думаю, что с ходу не вспоминается. Так что связи с другими странами действительно очень важны. Только надо понимать в каких областях это действительно так, а в каких просто мифы. )
Да, и насчёт помощи… Помогать мог СССР. Россия сейчас классическое капиталистическое государство, так что скорее использует проблемы других стран, чтобы получать нужное по дешёвке, загонять «партнёров» в кредиты или вообще забирать производство себе. У нас в 90-ые были хорошие учителя по таким делам… )
Список стран, которые вообще в курсе подобных технологий, можно увидеть в конце это страницы. Но Россия там впереди с солидным отрывом.
Собственно в случае успешной постройки БН-1200 Россия станет единственной в мире страной, предоставляющей услугу постройки подобных реакторов. А замкнутый цикл — это будущее обычной ядерной энергетики, т.к. урана тоже не безгранично на планете.
Ближайшее будущее энергетики однозначно за ядерной (кстати, догадываетесь какие страны имеют наиболее передовую технологию, замкнутого цикла, в рабочем состояние?), а отдалённое за термоядерной. Плюс безусловно будут процветать гидроэлектростанции и возможно геотермальные, но эти два типа возможны только в очень небольшой области планеты.
А все остальные варианты (с исчерпанием углеводородов) не имеют особого смысла на промышленном уровне (естественно для страны обладающей ресурсами и современными технологиями) и имеют смысл только для обеспечения скажем личного домика посередине тайги. Ну или же для стран не имеющих достаточных технологий или возможностей добычи урана — они и станут жить в будущем на соответствующем уровне…
Кстати, с учётом мирового прохода пика добычи по нефти и скоро по газу, и того факта, что сейчас от энергетики полностью зависит вообще всё (в том числе и такие вещи как например еда), этот вопрос становится определяющим в геополитике. Так что ближайшее десятилетие будет очень не скучным и совсем не мирным… Правда нам (в России) это всё можно будет разглядывать в основном с позиции «схожу ещё за попкорном». )
EROEI для Испании озвучьте тогда уж, если говорите про эффективность. А то ведь на выбитых дотациях (которые кстати в Европе собираются в виде налога с обычной энергетики) под так называемую зелёную энергетику можно много чего наделать… )))
Куда он денется то? ))) Компилятор (gcc) умеет, редактор (Eclipse) умеет… ) А CoIDE — это по сути набор скриптов вокруг Eclipse, так что без проблем его заставить. Основная ценность там скорее в наборе информации о конкретных MK и удобном её представление. Кстати, как раз поэтому если не требуется подобное удобство, то действительно проще взять одну из обычных IDE и всё.
Это было естественно про большие приложения, а не про микроконтроллёры. С последними ситуация другая, т.к.тут ещё становятся важные именно функции их поддержки, а не просто работа с кодом. )
Мы пробовали очень много различных инструментов (и не только IDE, т.к. по сути от IDE нам нужен только редактор — остальное мы реализуем отдельными, более эффективными инструментами) для работы с кодом на C++. По итогам вышло, что полноценно парсить C++ код (т.е. со всеми шаблонами, макросами и прочими прелестями) сейчас умеют всего 3 инструмента и наверное не особо удивительно, что это оказались главные «мостро-ide»: Netbeans, Eclipse и VisualStudio+VisualAssist.
Насколько я знаю, ещё Kdevelop имеет полноценный парсер, но это только под Linux'ом. Плюс Jetbrains обещали этой осенью выпустить полноценную C++ IDE и возможно (судя по показанным отрывкам), что она станет лучше C++ IDE. Однако пока её нет, так что выбор сводится к одному из 3-ёх вышеуказанных монстриков.
Если же выбирать из этих трёх вариантов, то тут уже начинают играть роль всякие мелочи. Типа количества сущностей для подсветки синтаксиса, нюансов в форматирование кода, возможностей подсказки/навигации, рефакторинга. Самый богатый набор всего этого у Eclipse'a. Самый бедный у VS (даже с VA, а без него вообще мрак). Но у Eclipsa нам не понравились некоторые архитектурные нюансы самого приложения, не связанные с C++, плюс общая перегруженность интерфейса и настроек. Поэтому мы предпочли Netbeans — у него набор функций практически такой же как у Eclipse, но при этом более простая архитектура и удобный интерфейс. Это так, если вкратце. )
Да, надо много чего настроить, чтобы получить полноценную среду, но всё кроме отладчика делается тривиально. Причём опять же проблема только с отладчиком для ситуации с кросскомпиляцией и удалённой отладкой (т.е. как раз случай stm32), т.к. там железо выдаёт именно gdb интерфейс.
Насчёт сравнения с CooCox… Вообще то Eclipse и Netbeans даже посильнее чем VS по работе с кодом на C++. A CoIDE основан на Eclipse, но при этом каком-то обрезанном. При этом имеет сильную поддержку именно работы с микроконтроллёрами. В общем по сумме параметров не вижу особого смысла в VS.
Мы уже давно ушли с VS (причём при этом продолжили использовать их компилятор и вот только недавно ушли и с него), т.к. её возможности (даже вместе с VA) по работе с кодом уступают конкурентам (Eclipse и Netbeans). Причём это речь даже не про микроконтроллёры, а про большие десктопные приложения.
Однако я могу без проблем описать как настроить VS для работы скажем с MinGW (gcc для windows приложений).
Что касается VS и stm32, то вот прямо с такой парой я дел не имел, так что с ходу не скажу. Но очевидно, что единственное отличие от варианта выше, будет в настройке процесса отладки. Для варианта выше можно взять просто обычный конвертер в формат pdb (типа cv2pdb) и использовать прямо отладчик из VS. Для embedded программирования это конечно не пойдёт, так там обычно просто выставляется интерфейс удалённого gdb. Соответственно тогда надо или какой-то другой откладчик (а тогда какой смысл в VS вообще?) или же ставить некого посредника между ними (типа решения в данной статье или например WinGDB).
1. А оно работает с Express студией или только с полноценной?
2. Вообще то не вижу вообще никаких проблем настроить себе буквально тоже самое и без всяких плагинов. Т.е. использование gcc (и не только для кросскомпиляции под arm, но и например вообще с MinGW) в VS вполне настраиваемо. Собственно там вообще единственная проблема в интеграции с отладчиком, а всё остальное делается за пару минут.
3. Если вы хотите полноценное автодополнение, подсветку и рефакторинг C++ в студии, то обязательно ставьте VisualAssist — только он даёт что-то более менее приемлемое. Хотя на мой взгляд аналогичные возможности в Netbeans и Eclipse всё равно сильнее.
Очень позитивно. А тогда ещё несколько вопросов:
1. Планируете ли в дальнейшем увеличение скорости или нет? Т.е. стоит ли такой вектор в разработке?
2. Я там глянул у вас в контактах Швеция стоит… Это вы реально там или же только формальности для бизнеса, а сами здесь где-то? Это может иметь значения при некоторых применениях…
3. У вас указано, что есть вариант подключение по ethernet и плюс ещё другие (usb?). Так вот как дела с драйверами (linux, windows) во втором случае?
4. А можно какие-то приблизительные цены на конкретные платы уже сейчас назвать или пока нет?
Не очень понятны следующие вопросы:
1. Находится ли радиочастота вашего решения в диапазоне не требующем лицензирования в России.
2. Мощность передатчика (чтобы соответственно тоже не требовалось лицензирование).
3. Дальность связи при этом (в идеале график зависимости скорости от дальности).
А так в принципе ваше решение конечно весьма интересует. Хотя скорость 2 Мбит/с — это конечно всё же маловато пока… Если хотя бы 10, то уже совсем другой расклад был. Но для начала и это не плохо.
Боюсь что не будет какого-то приемлемого потока воды от естественной конвекции. Кстати, в моём варианте естественная конвекция тоже используется — на радиаторе снаружи. )))
А помпа да, движущаяся… И это меня конечно чуть напрягает, но совсем не потому что от неё что-то слышно (она даже на руках бесшумно работает, а внутри закрытого системного блока вообще без шансов), а потому что это единственная движущаяся часть в компьютере. Т.е. по сути единственная, с потенциально приличными шансами на поломку. Так что я бы тоже с удовольствием избавился от неё, но не представляю какой ещё вариант возможен. Т.е. я в курсе конечно про монстроидальные решения в стиле «системного блока — огромного радиатора», но мне такое не подходит.
Ммм, понимаете ли, на практике как раз в бывших «совковых» организациях (типа тех, что в Зеленограде например) что-то реальное ещё и происходит. А вот в новейших модных гос. организациях, типа Сколково, на практике всё очень мрачно, а успехи есть только на бумаге. Это я говорю как человек не со стороны…
Хотя я всё равно стараюсь быть оптимистом и надеяться вот как раз тут всё пойдёт совсем по другому.
1. Да, это замена Obj-C, но весьма существенная. Т.к. если раньше убогий Obj-C вызвал лишь усмешку у народа с других платформ, то теперь данный язык вполне может оказаться поприятнее базовых инструментов на других платформах. А это существенно меняет расклад.
2. Не понял как это у вас из логичного «десктоп-приложения под iOS и OS X» (с чем я согласен в общем то) вышло " разработки UI под iOS" — это как бы совсем разные вещи.
3. Область «большая часть приложений под OS X и iOS» — это мягко говоря не маленький кусочек рынка. О таких объёмах код для ядра ос/драйверов или даже серверный код может только мечтать.
А с итогом опять же согласен — лично я тоже просто прохожу мимо.
По набору фич, позиционированию и т.п. он больше всего напоминает язык D, из которого выпилили метапрограммирование (одна из главных фич D кстати), исключения и поддержку многопоточности. Ну и плюс добавили несколько мелких вкусностей типа pattern matching и extensions. И всё это в оригинальном и довольно лаконичном синтаксисе.
Естественно это далеко не идеал, но в любом случае вышел отличный язык, поинтереснее тех же Java и C#. А уж на фоне такого дикого ужаса, как Objective-C, Swift должен казаться просто манной небесной.
P.S. Я сам мягко говоря не поклонники компании Apple. Но в данном случае нельзя не признать, что у них вышел очень интересный и нужный продукт.
Например по пшенице Россия является одним из ведущих экспортёров. Помнится даже что многие эксперты связывали начало событий в Египте с запретом экспорта пшеницы в тот год из России (у нас засуха была и чтобы не поднялись цены на хлеб, запретили экспорт). Ну и потребительские товары очень очень многие давно производятся в России, хотя и иностранными компаниями. Это и бытовая техника и автомобили и ещё очень много всего.
Но есть области где у нас действительно полная Ж. Например в области производства чипов, некоторых видов химии и лекарств, станков. Плюс горы всякой мелочи, которые сейчас штампуются в Китае на весь мир (это легко может делать любая страна, но в Китае просто дешевле). Да и ещё много чего думаю, что с ходу не вспоминается. Так что связи с другими странами действительно очень важны. Только надо понимать в каких областях это действительно так, а в каких просто мифы. )
Да, и насчёт помощи… Помогать мог СССР. Россия сейчас классическое капиталистическое государство, так что скорее использует проблемы других стран, чтобы получать нужное по дешёвке, загонять «партнёров» в кредиты или вообще забирать производство себе. У нас в 90-ые были хорошие учителя по таким делам… )
Собственно в случае успешной постройки БН-1200 Россия станет единственной в мире страной, предоставляющей услугу постройки подобных реакторов. А замкнутый цикл — это будущее обычной ядерной энергетики, т.к. урана тоже не безгранично на планете.
А все остальные варианты (с исчерпанием углеводородов) не имеют особого смысла на промышленном уровне (естественно для страны обладающей ресурсами и современными технологиями) и имеют смысл только для обеспечения скажем личного домика посередине тайги. Ну или же для стран не имеющих достаточных технологий или возможностей добычи урана — они и станут жить в будущем на соответствующем уровне…
Кстати, с учётом мирового прохода пика добычи по нефти и скоро по газу, и того факта, что сейчас от энергетики полностью зависит вообще всё (в том числе и такие вещи как например еда), этот вопрос становится определяющим в геополитике. Так что ближайшее десятилетие будет очень не скучным и совсем не мирным… Правда нам (в России) это всё можно будет разглядывать в основном с позиции «схожу ещё за попкорном». )
Для США например у нас картинка такого рода
Насколько я знаю, ещё Kdevelop имеет полноценный парсер, но это только под Linux'ом. Плюс Jetbrains обещали этой осенью выпустить полноценную C++ IDE и возможно (судя по показанным отрывкам), что она станет лучше C++ IDE. Однако пока её нет, так что выбор сводится к одному из 3-ёх вышеуказанных монстриков.
Если же выбирать из этих трёх вариантов, то тут уже начинают играть роль всякие мелочи. Типа количества сущностей для подсветки синтаксиса, нюансов в форматирование кода, возможностей подсказки/навигации, рефакторинга. Самый богатый набор всего этого у Eclipse'a. Самый бедный у VS (даже с VA, а без него вообще мрак). Но у Eclipsa нам не понравились некоторые архитектурные нюансы самого приложения, не связанные с C++, плюс общая перегруженность интерфейса и настроек. Поэтому мы предпочли Netbeans — у него набор функций практически такой же как у Eclipse, но при этом более простая архитектура и удобный интерфейс. Это так, если вкратце. )
Насчёт сравнения с CooCox… Вообще то Eclipse и Netbeans даже посильнее чем VS по работе с кодом на C++. A CoIDE основан на Eclipse, но при этом каком-то обрезанном. При этом имеет сильную поддержку именно работы с микроконтроллёрами. В общем по сумме параметров не вижу особого смысла в VS.
Однако я могу без проблем описать как настроить VS для работы скажем с MinGW (gcc для windows приложений).
Что касается VS и stm32, то вот прямо с такой парой я дел не имел, так что с ходу не скажу. Но очевидно, что единственное отличие от варианта выше, будет в настройке процесса отладки. Для варианта выше можно взять просто обычный конвертер в формат pdb (типа cv2pdb) и использовать прямо отладчик из VS. Для embedded программирования это конечно не пойдёт, так там обычно просто выставляется интерфейс удалённого gdb. Соответственно тогда надо или какой-то другой откладчик (а тогда какой смысл в VS вообще?) или же ставить некого посредника между ними (типа решения в данной статье или например WinGDB).
2. Вообще то не вижу вообще никаких проблем настроить себе буквально тоже самое и без всяких плагинов. Т.е. использование gcc (и не только для кросскомпиляции под arm, но и например вообще с MinGW) в VS вполне настраиваемо. Собственно там вообще единственная проблема в интеграции с отладчиком, а всё остальное делается за пару минут.
3. Если вы хотите полноценное автодополнение, подсветку и рефакторинг C++ в студии, то обязательно ставьте VisualAssist — только он даёт что-то более менее приемлемое. Хотя на мой взгляд аналогичные возможности в Netbeans и Eclipse всё равно сильнее.
1. Планируете ли в дальнейшем увеличение скорости или нет? Т.е. стоит ли такой вектор в разработке?
2. Я там глянул у вас в контактах Швеция стоит… Это вы реально там или же только формальности для бизнеса, а сами здесь где-то? Это может иметь значения при некоторых применениях…
3. У вас указано, что есть вариант подключение по ethernet и плюс ещё другие (usb?). Так вот как дела с драйверами (linux, windows) во втором случае?
4. А можно какие-то приблизительные цены на конкретные платы уже сейчас назвать или пока нет?
Да, для обычных вещей вполне достаточная скорость. Просто нам актуально ещё и видео в реальном времени…
1. Находится ли радиочастота вашего решения в диапазоне не требующем лицензирования в России.
2. Мощность передатчика (чтобы соответственно тоже не требовалось лицензирование).
3. Дальность связи при этом (в идеале график зависимости скорости от дальности).
А так в принципе ваше решение конечно весьма интересует. Хотя скорость 2 Мбит/с — это конечно всё же маловато пока… Если хотя бы 10, то уже совсем другой расклад был. Но для начала и это не плохо.
А помпа да, движущаяся… И это меня конечно чуть напрягает, но совсем не потому что от неё что-то слышно (она даже на руках бесшумно работает, а внутри закрытого системного блока вообще без шансов), а потому что это единственная движущаяся часть в компьютере. Т.е. по сути единственная, с потенциально приличными шансами на поломку. Так что я бы тоже с удовольствием избавился от неё, но не представляю какой ещё вариант возможен. Т.е. я в курсе конечно про монстроидальные решения в стиле «системного блока — огромного радиатора», но мне такое не подходит.
Хотя я всё равно стараюсь быть оптимистом и надеяться вот как раз тут всё пойдёт совсем по другому.