Для начинающих? Если так, то начинать лучше с прочтения книжки Thinking In Java Кента Бека.
Для профессионалов? Профессионалы знают английский на нужном уровне. Хотя я, хоть и не считаю себя новичком, не достаточно бегло читаю на английском языке. Поэтому часто мне жаль тратить времени на чтение документации без серьёзной необходимости, так как за чтение не платят. (Например, без крайней необходимости я бы не стал изучать документацию по виртуальной машине, не смотря на то, что мне это интересно. ) Если бы было больше документации на русском, я бы сэкономил себе кучу времени.
Человеку, который выдаёт такой код, нужно наполировать зад пряжкой от ремня и отправить назад в школу изучать какой-нибудь компилируемый язык программирования. Можно начать с Pascal. И через пару лет ему можно будет доверить интерпретатор.
Есть гаечный ключ на 19, а пневмотический шуруповёрт. (В гонках F1 таким колёса прикручивают) И то и другое ручной инструмент для откручивания болтов. Каждый из этих инструментов хорош по-своему: один можно возить в богажнике, вторым можно открутить все 4 болта за 0.7 секунды.
Что является расширением чего каждый решает для себя.
Я специализируюсь на более продвинутой технике. (Это не значит, что на людей, которые виртуозно владеют низкоуровневыми инструментами я смотрю свысока. Это значит, что я не можу жить без stl и boost)
Вы, я полагаю, не видите огромной пропасти между этими языками вследствии малого опыта работы хотябы с одним из них.
Код написаный на C можно скомпилировать компилятором C++.
На этом сходства заканчиваются. С и C++ языки разного уровня абстракции, следовательно на каждом из них решаются совершенно специфические задачи совершенно специфичными способами. Люди которые пишут на языке C думают совсем иначе, нежели люди пишущие на C++ — они говорят не так, как C++ разработчики, одеваются не так как C++ разработчики, есть даже мнение что они спят подвесив себя к потолку вниз головой.
Встретить в природе живого C разработчика теперь не так-то просто, потому что даже микроконтроллеры теперь программируют на C++.
А вот ядро линукс написано на языке C… И это, лично меня, здорово угнетает. Я могу понять даже некоторые части библиотеки boost, но вот ядро линукс осилить, боюсь, не смогу никогда.
А где я намекнул на то, что не знаю, как это работает?
У меня было время и до сих пор есть квалификация, чтобы разобраться в тонкостях взаимодействия фронт-энда и бэк-энда. В исходный код GWT Compiler-а я пока не лазил. Каюсь (не было необходимости, и надеюсь, что она не возникнет. Он работает отлично.).
Но я так же, признаюсь, никогда не смотрел исходники компиляторов, например, C/C++, хотя написал не один мегабайт кода на этих языках. Так же, я до сих не изучил исходные коды Firefox, хотя регулярно пользуюсь этим браузером. И более того, я не считаю, что это постыдным.
Я очень-очень-крайне расстроен намёками на отказ от поддержки Ext GWT. Как человек попробовавший на вкус нормальную разработку в нормальной IDE (Eclicse) с нормальным дебагером, боюсь я не смогу вернуться на примитивный JS-редактор и Firebug (пусть даже они выпустят свою консоль для отладки). А ведь когда я впервый раз запустил примеры из коробки (это было пол года назад), я Java вообще не знал… Но я имел несокрушимую веру в то, что должно быть что-то лучше Firebug.
Надеюсь, что до отказа поддержки Ext GWT не дойдёт, и разработчики приложений на ExtJS со временем начнут понимать всю прелесть GWT. И начнут покупать лицензии на этот продукт.
Автор, прислушайтесь к этому комментарию. Использование сокращенной версии открывающих тэгов php считаю безобразием. Если вы используете xml/xslt, то вы должны знать, что там тоже есть тэги <?
Я думаю, потому что когда-нибудь web-разработчики станут достаточно квалифицированными для того, чтобы оценить достоинства этой технологии. А пока, остаётся использовать этот дар w3c только в своих разработках.
Я поверхностно знаком с ExtJS и многие вещи для меня стали открытием. Напрмер: «возможностям класса Array добавлены методы определения индекса по значению элемента». Это, интересно, ещё для чего?
Вопрос к вам, как к профессионалу. Я люблю ExtJS именно за все эти гриды, асинхронные деревья, динамические комбо-боксы. На сколько тяжело будет какой-то конкретный компонент прикрутить к Ext Core? (И чтобы не тащить за собой всю библиотеку целиком.) Хочу использовать, например, Grid в публичной части сайта (потому что в админке он уже реализован), но боюсь напугать пользователя временем загрузки страницы.
Я в шоке. Я помню, что вы заранее оговорились, что картинки специально не используете, но я, наверное, погиб бы от оргазма мозга, если бы маркер раскрывающегося списка был через list-style-image.
Я с вами отчасти согласен. На текущий момент Си предназначен исключительно для системного программирования. Большая часть десктопных приложений создаётся как минимум на C++. Enterprise системы больше на C# или Java.
Форум изначально хотели вести о "системном программировании под *nix", а в названии решили отразить просто «программирование под *nix». Само по себе «программирование под *nix» без привязки к языку, это какая-то очень размытая тема. На C++ я стараюсь использовать кросс-платформенные библиотеки (stl, boost и т.д.), а Java и C# платформонезависимы по своей природе. В итоге, никаких различий в разработке, которые тут собираются обсуждать просто нет. Серьёзные различия возникают при разработке системных приложений на Си.
P.S. Небольшой, но быстрый вэб-сервер я бы как раз писал на C. А большой и функциональный вэб-сервер, наверное, всё же на C++. А вэб-сервер, который умеет пересобирать KDE под FreeBSD наверное на Java. И opensource-сообщество тут ни причём. Средство реализации определяет задача, но никак не наоборот.
… но я едва ли когда-нибудь буду обрабатывать JSON «вручную». Скорее, я воспользуюсь услугами какого-нибудь JS-фрэймворка. Например, JQuery. Так что если разработчики JQuery ещё не реализовали поддержку нативного JSON парсера, то я уверен, что они будут рады коммиту этого wrapper-а.
На ozone.ru я нашел только одну вменяемую книжку по запросу «boost» — это C++ Boost Graph Library. Но я бы хотел ознакомиться со всей библиотекой целиком поверхностно, а не только с библиотекой по построению графов. Я бы хотел знать в общем, какие типовые задачи можно решать при помощи boost, с очень краткими примерами. Без углубления в суть.
Если мне потребуется решить какую-либо задачу с применением конкретной библиотеки я изучу документацию на официальном сайте для последней стабильной версии.
Для начинающих? Если так, то начинать лучше с прочтения книжки Thinking In Java Кента Бека.
Для профессионалов? Профессионалы знают английский на нужном уровне. Хотя я, хоть и не считаю себя новичком, не достаточно бегло читаю на английском языке. Поэтому часто мне жаль тратить времени на чтение документации без серьёзной необходимости, так как за чтение не платят. (Например, без крайней необходимости я бы не стал изучать документацию по виртуальной машине, не смотря на то, что мне это интересно. ) Если бы было больше документации на русском, я бы сэкономил себе кучу времени.
Что является расширением чего каждый решает для себя.
Я специализируюсь на более продвинутой технике. (Это не значит, что на людей, которые виртуозно владеют низкоуровневыми инструментами я смотрю свысока. Это значит, что я не можу жить без stl и boost)
Вы, я полагаю, не видите огромной пропасти между этими языками вследствии малого опыта работы хотябы с одним из них.
На этом сходства заканчиваются. С и C++ языки разного уровня абстракции, следовательно на каждом из них решаются совершенно специфические задачи совершенно специфичными способами. Люди которые пишут на языке C думают совсем иначе, нежели люди пишущие на C++ — они говорят не так, как C++ разработчики, одеваются не так как C++ разработчики, есть даже мнение что они спят подвесив себя к потолку вниз головой.
Встретить в природе живого C разработчика теперь не так-то просто, потому что даже микроконтроллеры теперь программируют на C++.
А вот ядро линукс написано на языке C… И это, лично меня, здорово угнетает. Я могу понять даже некоторые части библиотеки boost, но вот ядро линукс осилить, боюсь, не смогу никогда.
У меня было время и до сих пор есть квалификация, чтобы разобраться в тонкостях взаимодействия фронт-энда и бэк-энда. В исходный код GWT Compiler-а я пока не лазил. Каюсь (не было необходимости, и надеюсь, что она не возникнет. Он работает отлично.).
Но я так же, признаюсь, никогда не смотрел исходники компиляторов, например, C/C++, хотя написал не один мегабайт кода на этих языках. Так же, я до сих не изучил исходные коды Firefox, хотя регулярно пользуюсь этим браузером. И более того, я не считаю, что это постыдным.
Надеюсь, что до отказа поддержки Ext GWT не дойдёт, и разработчики приложений на ExtJS со временем начнут понимать всю прелесть GWT. И начнут покупать лицензии на этот продукт.
Вопрос к вам, как к профессионалу. Я люблю ExtJS именно за все эти гриды, асинхронные деревья, динамические комбо-боксы. На сколько тяжело будет какой-то конкретный компонент прикрутить к Ext Core? (И чтобы не тащить за собой всю библиотеку целиком.) Хочу использовать, например, Grid в публичной части сайта (потому что в админке он уже реализован), но боюсь напугать пользователя временем загрузки страницы.
Форум изначально хотели вести о "системном программировании под *nix", а в названии решили отразить просто «программирование под *nix». Само по себе «программирование под *nix» без привязки к языку, это какая-то очень размытая тема. На C++ я стараюсь использовать кросс-платформенные библиотеки (stl, boost и т.д.), а Java и C# платформонезависимы по своей природе. В итоге, никаких различий в разработке, которые тут собираются обсуждать просто нет. Серьёзные различия возникают при разработке системных приложений на Си.
P.S. Небольшой, но быстрый вэб-сервер я бы как раз писал на C. А большой и функциональный вэб-сервер, наверное, всё же на C++. А вэб-сервер, который умеет пересобирать KDE под FreeBSD наверное на Java. И opensource-сообщество тут ни причём. Средство реализации определяет задача, но никак не наоборот.
… но я едва ли когда-нибудь буду обрабатывать JSON «вручную». Скорее, я воспользуюсь услугами какого-нибудь JS-фрэймворка. Например, JQuery. Так что если разработчики JQuery ещё не реализовали поддержку нативного JSON парсера, то я уверен, что они будут рады коммиту этого wrapper-а.
Если мне потребуется решить какую-либо задачу с применением конкретной библиотеки я изучу документацию на официальном сайте для последней стабильной версии.