В реальности, у него могут быть и такие взгляды. Это лишь гадание на кофейной гуще, могут быть, а могут не быть. Ты решил, что для тебя это показуха, кто-то решил иначе. В обоих случаях манипуляция удалася, если она имела место быть. Не надо везде искать мировых заговоров. ;)
Что бы наука не тыкала пальцем в небо, должен быть теоретический фундамент. Так же можно сказать и про математику, блаблабла, абстрактные вещи, но куда же без нее? Кстати такая проблема была в прошлом веке, когда физики и математики враждовали на этой же почве, что вы говорите. Потому не надо таких обвинений, философия важная часть процесса и без нее никуда. Во всем нужен баланс.
Так же замечу, что в Xamarin можно строить интерфейс родными стредствами (iOS Interface Builder), а для Дроида есть встроенный редактор в саму Xamarin Studio. Так же есть plugin для Visual Studio, в том числе и для iOS(но в случае с iOS build server должен быть все еще на маке).
Тут по поводу Xamarin вспомнили, вставлю и свои 5 копеек, так как имею честь с ним работать в последнее время. Хороший фреймворк, в целом багов особо не заметил(если несколько неудобных моментов, которые впринципе автоматизируются). Но для работы с ним нужно знать, как минимум азы разработки под конкретную платформу. Если пишешь под iOS, нужно изучить разработку под iOS, тоже самое с Android. Хотя и Xamarin делает библиотеку Monotouch.Dialog, Monodroid.Dialog для унификации работы с интерфейсами, в целом все же надо знать как работать с конкретной платформой.
Но Xamarin дает возможность выносить работу с бизнес-логикой, с датой, с сервисами в отдельные Portable Library, остается только писать интерфейс. Ну и в ООП хватает стратегий и паттернов, что бы унифицировать ядро приложение, главное им уметь правильно следовать.
Резюмируя вышесказнное могу сказать, что порог вхождения в Xamarin довольно высок, с виду он решает меньше проблем, чем тот же Titanium, да и шаблоны проектирования нужно подтягивать. Но с другой стороны, Xamarin надежней того же Titanium и имеет высокую производительность, а так же доступ к более менее богатой инфраструктуре Mono(.Net). Так например я спокойно использую в проекте библиотеки по работе с Rest (RestSharp), работа с json (Newton json.net) и другие. Применяю Linq, generics и другие прелести C#. К тому же вся бизнес логика вынесена в отдельную библиотеку, а работа с ресурами(картинки, звуки и т.п.) решаются с помощью build скрипта.
Зачем? Так же можно похвастатся, какой ты офигенный, что неделями программил на перфокарты, а нынче «молодеж» вообще разбалованная.
Хотя учить стоит имхо с консоли в том числе, потому что встречаю повсеместно например Android девов, которые не могут сбилдить программу с консоли и не знают, что такое maven/ant/gradle. В большинстве случаев мб это и не надо, ведь IDE автоматизирует процедуру построения, но бывают случаи, когда бы это знать не помешало бы.
Вы знаете, я тоже не 1-й год в разработке и меня ваш комментарий удивляет. Ну что ж, невозможно, видимо мы в паралельных мирах живем, в моем возможно. Более того, пугает ваша категоричность, потому конструктивный разговор с вами строить, вижу, не получится. Peace.
Не нужно так спешить, реализовать функционал «Find All Refernces» в emacs вполне возможно, мне кажется это и в VIM возможно, не берусь судить, я его не использую. И это сделать не так уж сложно.
chess.com дает пробный 14 дневный акк и там проходишь уроки очень быстро, учат как ставить мат, тактическим приемам(типа связывание, вилки, двойная атака и прочее).
Например то, что я не уберу сам весь город, не починю сам все дороги, при всем желании, даже будь у меня ресурсы, мне элементарно никто этого не даст сделать. :) Я уже молчу о том, что вести бизнес в Украине опасно.
А с себя я уже начал, в моем подъезде и на моей лестничной клетке чисто и лампочки вкручены.
Кстати вот я заметил, что для видео и аудио есть протоколы транспортного уровня, а для игр как-то все слабо. Я понимаю что игры стандартизировать довольно сложно, ведь всякие бывают и у них разные требования к сети.
Но вот стало интересно даже и нашел в сети статью от корейских исследователей на тему ММО(ну а кто ж еще, как не корейцы этим будут заниматся :)).
В общем кому интересно читайте:
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.98.7687&rep=rep1&type=pdf
Но Xamarin дает возможность выносить работу с бизнес-логикой, с датой, с сервисами в отдельные Portable Library, остается только писать интерфейс. Ну и в ООП хватает стратегий и паттернов, что бы унифицировать ядро приложение, главное им уметь правильно следовать.
Резюмируя вышесказнное могу сказать, что порог вхождения в Xamarin довольно высок, с виду он решает меньше проблем, чем тот же Titanium, да и шаблоны проектирования нужно подтягивать. Но с другой стороны, Xamarin надежней того же Titanium и имеет высокую производительность, а так же доступ к более менее богатой инфраструктуре Mono(.Net). Так например я спокойно использую в проекте библиотеки по работе с Rest (RestSharp), работа с json (Newton json.net) и другие. Применяю Linq, generics и другие прелести C#. К тому же вся бизнес логика вынесена в отдельную библиотеку, а работа с ресурами(картинки, звуки и т.п.) решаются с помощью build скрипта.
Хотя учить стоит имхо с консоли в том числе, потому что встречаю повсеместно например Android девов, которые не могут сбилдить программу с консоли и не знают, что такое maven/ant/gradle. В большинстве случаев мб это и не надо, ведь IDE автоматизирует процедуру построения, но бывают случаи, когда бы это знать не помешало бы.
А с себя я уже начал, в моем подъезде и на моей лестничной клетке чисто и лампочки вкручены.
Но вот стало интересно даже и нашел в сети статью от корейских исследователей на тему ММО(ну а кто ж еще, как не корейцы этим будут заниматся :)).
В общем кому интересно читайте:
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.98.7687&rep=rep1&type=pdf