Pull to refresh

Comments 156

Главное — продолжайте, не забрасывайте.
Хотелось бы видеть не огромные статьи с кучей мелочей, а темы и важные для обучения с нуля моменты.
А также ссылки и список полезных книг по теме.

Первая статья понравилась.
Так держать! :)
UFO just landed and posted this here
По крайней мере, прекратились статьи «как заработать гугильён бубильёнов за полчаса», «какие таблетки пить, чтобы стать умнее Ландау» и «как завоёвывать друзей и оказывать влияние на людей».

Воды и копи-паст туториалов и не надо.
Хотелось бы заметок, как лучше изучать ту или иную технологию, какие качественные статьи и книги стоит посмотреть и т. п.

Потому как заходишь в магазин, смотришь на полки с компьютерной литературой и обомлеваешь от разнообразия.
Но ведь точно знаешь, что большая часть пособий — не лучший выбор.
А вот, что купить, что посмотреть?
Вот и хочется услышать мнение профессионалов/опытных в этой сфере людей.
По книгам сделаю небольшой обзор в следущий раз.
Я сразу заявил, что не я автор, но и это не копи-паст. Я облажился книгами и выявлял самые важные, по моему, аспекты. Немного здесь, немного там.
«облажился» — это все-таки от слова «лажа» :)
а еще уже который раз вижу «планирую серию статей, планирую стартап, планирую открыть интернет-магазин»
столько планов у всех, не упасть бы
вообще не понимаю, зачем ими делиться? чтоб заплюсовали?
ну хочешь что-то сделать — сделай, а потом говори
«Я Вас понимаю! Да ничего Вы не понимаете!» (с) Реклама на ТВ =)
Для многих это хорошая мотивация — дать публичное обещание.
Мне одному кажется, что Microsoft выбрала для массированной рекламной кампании Habrahabr, или это только кажется?
Могу про Java подобное сделать. Хотите?
Здорово. Вы молодец. Разве что и Вашу статью, и эту объединяет краткость (на мой взгляд, чрезмерная, за один раз я бы прочитал и побольше :)) и отсылки на следующие статьи (интрига!).

Отличный блог получился, этот ваш стартап «Программист».
Не надо. Вас могут обвинить в массированной рекламе продуктов Apache, IBM, Oracle, Red Hat и Sun.
Я лично не использую Oracle'овские или IBM'овские технологии — апач да, это святое.
как это? у Вас Linux стоит на Мак-буке? :)
А что, апач и на Linux тоже ставится? :)
Спалили… У меня стоит Ubuntu, но на компе с Core2Duo.
P.S. Если что, iZENfire имел в виду IBM java-машину. :)
хорошо спланированная PR кампания — это когда восторженные ДЕВЕЛОПЕРЫ пишут обо всем самостоятельно. хотя, разумеется, без заказных статей тут дело не обошлось. весь девелоперский инет кишит такими восторженными текстами.

у меня предложение Микрософту: давайте сделаем еще одну прослойку, теперь между .NET и программой. назовем это типа .DA, чтобы ползьователь не мог запустить свою «Hello World» без скачивания полутора гигабайт ненужного и закрытого кода. и никаких линкеров! пусть все юзеры скачивают и ставят себе .DA (сперва установив, разумеется, .NET)! а то понимаешь…

не даром же маркетологи работали над столь гениальной идеей столько лет. все для ДЕВЕЛОПЕРА.

Не забудте сказать про mono. Недавно вышла версия 2.2, она существует и в сборке для windows. Самая сладкая для меня её часть интерактивный shell, так же известный как REPL — для обучения самый раз.
UFO just landed and posted this here
Да конечно. Моно развивается очень быстро. Когда сидел на убунте, писал на моно. Для моих задач хватало, а на стадии обучения тем более хватит.
Отлично, тогда, надеюсь, вы напишете про такие инструменты как nunit и nant. Сам когда сидел в дебиане ими пользовался, да и сейчас под виндой продолжаю. А новичкам будет полезно компилить проги из консоли а не студии, что бы лучше понять, что происходит.
Бассейн уже ждет водички ;)
Так держать!
Отличное начало. Интересно будет почитать!
Все же я бы сказал, что метод Main — это дверь не для компилятора, а для среды выполнения. Я, конечно, понял, что вы хотели сказать этим, но ведь помимо исполняемых приложений, есть еще и библиотеки (class library), в которых такому методу быть совершенно не обязательно. Получается, что в библиотеках для компилятора дверь не прорублена)
Более того точек входа может быть несколько :)
Жду следующих статей. А к этой у меня два мелких замечания. Первое — в примере не хватает общего пространства имен, в которое он заключен. Нужно было уточнить, что метод WriteLine() — статический, т. е. это метод класса, а экземпляр этого класса не создается, так как там все методы такие. Ну и про CLR можно было по-подробнее, что она очень дотошно «вычитывает» код на предмет наличия ошибок безопасности типов и таким образом можно многие ошибки обнаружить еще до компиляции, а не на этапе выполнения.
Checked Exceptions в C# не поддерживаются. А это значит, что в любой момент приложение может рухнуть, если попытается неправильно использовать сторонний библиотечный класс. И вы это узнаете только на этапе выполнения приложения!

Checked Exceptions нужны на этапе статичекого связывания компилятором исходного кода. Вызовы, которые потенциально могут бросить исключение, отслеживаются компилятором. Программист может вовремя заметить необработанную ошибку и написать обработчик. Но в C# такого нет — приходится полагаться на другие технологии отслеживания ошибок.
В Java Checked Exceptions поддерживаются, но все-равно в любой момент приложение может рухнуть=)

Из-за того, что Checked Exceptions часть сигнатуры метода возникают проблемы при перегрузке метода.
1) Приложение может рухнуть из-за ошибки в виртуальной машине или из-за неперехваченного исключения Unchecked Exceptions (RuntimeException в java), которые так «популярны» в C#.

2) Опишите, какие проблемы могут возникнуть при перегрузке метода, если Checked Exceptions — часть сигнатуры метода. Мне такие случаи за десять лет не встречались. Это может быть либо неудачный дизайн, когда бросается исключение не того и не на том уровне абстракции, нарушающее инкапсуляцию, либо… Продолжите мысль.
Я не экстрасенс, поэтому в начале ответьте на вопрос почему нужны Checked Exceptions и почему их нельзя обрабатывать тут же, а принято откладывать на потом. Мой ответ про проблемы при перегрузке будет операться на ваш ответ.
Checked Exceptions нужны на этапе компиляции для раннего обнаружения ошибок неверного использования чужого/незадокументировоанного бинарного кода.
Checked Exception, как и Unchecked-исключение, во время работы приложения можно/нужно обрабатывать на том уровне, где известна причина исключения, либо передавать его вверх по стеку вызовов в вызывающий код, для подробного изучения/логирования, чтобы составить правильную картину возникновения неисправности в программе и оповестить об этом пользователя/разработчика.

Если исключение нельзя обработать, то программа может завершиться с внятным сообщением об ошибке.
Извените, что заставил вас это написать, на самом деле я вспомнил пример из-за которого я возмутился при работе с Java и, кажется, он говорит о корявости Checked Exception вне зависимости от интерпретации Checked Exceptions.

Два или три года назад я писал транстлятор языка Java и для преобразования Java исходник -> AST использовал библиотеки eclipse. Мне понадобилось кастомизировать их поведение и я унаследовал класс библиотеки и переопределил в нем пару методов. Проблема в том, что в теле новых методов я что-то использовал, что могло кинуть Checked Exception, кинуть это исключение дальше, что бы я мог обработать его в своей программе я не мог, так как мне не позволяла сигнатура метода, который я переопределил. Обработать его на месте тоже не мог (представте, что все исключения IO будут обрабатываться внутри стандартной библиотеки), что бы решить эту проблему мне пришлось заводить глобальную переменную (сингелтон) и писать туда, что за исплючение произошло и после вызова метода eclipse проверять эту переменную.
Библиотечные классы, бросающие Checked Exceptions, тоже не застрахованы от ошибок дизайна.

Здесь существует по крайней мере два решения:
либо изменить дизайн переопределённого класса (не использовать прямое наследование, а сделать свой класс фасадом к библиотечному);
либо использовать «оборачивание» сгенерированого исключения в объект сигнатурного исключения и бросать «матрёшечное» исключение наверх для обработки.
Это верно, только в первом решении, мы заменяем глобальную переменную (singelton) на локальную — состояние объекта класса. Второе решение не работало в моем случае, так как метод в который я передавал свой объект кидал не те же самые исключения, которые кидал переопределенный метод, а как то их обрабатывал внутри и кидал уже другой-свой exception.

По мне так, отстутствие Checked Exceptions в C# это благо. Потому что в описанной ситуации Checked Exceptions не помечали вычисления меткой, что они «грязные», а способствовали тому, что кривой дизайн библиотеки передавался на дизайн моего кода, делая его тоже плохим:)
Второе решение не работало в моем случае, так как метод в который я передавал свой объект кидал не те же самые исключения, которые кидал переопределенный метод, а как то их обрабатывал внутри и кидал уже другой-свой exception.

И всё же изучите nested exceptions, прежде чем делать окончательные выводы о вреде Checked Exceptions.
Тот мой код давно умер и я не могу это проверить, но язык Java не обязыкает создателей библиотек использовать nested exceptions, в отличии от Checked Exceptions, поэтому нет гарантии, что исключение которое я кину, и которое содержит необходимое мне исключение в виде nested exception не будет проигноровано в дебрях библиотеки eclipse, а будет помещено в nested exception своего исключения и я смогу найти нужный мне exception после вызова метода библиотеки.
поэтому хорошим тоном является написание xml-комментов с вылетающими исключениями в открытых да и защищенных методах.
К сожалению, эта информация теряется, если сторонний разработчик предоставляет только бинарный код в составе какого-то своего приложения и не намерен делится документацией по использованию этого бинарного кода.

Java-компилятор, как вы правильно заметили, анализирует сигнатуру метода на этапе компиляции. И, обнаружив в нём неперехваченные в вызывающем коде проверяемые исключения, указывает на ошибку компиляции.
Для C# в аналогичном случае придётся писать Test Case, чтобы проверить все методы вызываемого бинарного кода на наличие бросаемых (unchecked) исключений. На это тратиться просто больше усилий, чем в Java.
Я не говорю, что после проверки ошибки в принципе возникнуть не могут. Но тем не менее от многих ошибок можно таким образом застраховаться. Если не ошибаюсь, это была одна из целей разработчиков языка и платформы в целом.
Я дал ссылки для тех, кто хочет подробнее. Вот что сказал в своё время мой учитель.
«Был такой случай, когда програмист на C в условии вместо сравнения ( == ) поставил присваивание ( = ). Программист писал програму для ракет и из-за этой маленькой ошибки ракета разнесла что-то (уже не помню что он сказал.»
Так вот суть в том, чтоне надо надеятся на компьютер, а надо всегда несколько раз проверить и протестировать. =)
заголовок понравился :)
для полноты коллекции осталось дождаться туториал по брэйнфаку — «Брейнфак — первая поллитра!» :D
Хм. Боюсь, что если C# дозируется вёдрами, то Брейнфак пойдёт не пол-литрами, а цистернами… :-)
Будьте аккуратны при скачивании Visual C# Express! Если выбрать русский язык, то начнется скачивание Web Developer Studio почему-то, а не C#
Я не помню где, но у меня была ссылка — можно бесплатно заказать DVD со всем нужным инструментарием. Уже раза три заказывал =) присылали. Там и весь Visual Studio и SP'ки и куча нужного софта, который мне очень понравился. Недавно подсел на Blend.

Если кто знает/видел эту ссылку, то напишите.
А у меня вообще C++ качаться начал :(
Эхх… кармы не хватает. Мог бы параллельно начать серию по основам программирования в общем — алгоритмизация и прочие основы, с привязкой к Бейсику и Паскалю, но с упором на Дельфи.
А почему примеры на уже не используемых языках? Бейсик (и Pascal для многих задач обучения) гораздо лучше заменить на Python или Ruby.
Ну неиспользуемых это громко сказано, имхо. Не «модные» они — да, есть такое (хотя по простым примерам не вижу принципиальной разницы между VB .Net и C# .Net, хоть find & replace используй для «трансляции» одного в другое), но не используемые… Используется даже Cobol и Fortran ;)

хотя ради расширения кругозора было бы и про Python почитать :)
А я разве писал про C# или Java? ;) В том-то и дело, что Ruby и Python сильно отличаются от Pascal и Basic. И не динамической типизацией, а именно подходом. Активное применение анонимной функции (с лямбда-замыканием), делегаты (типа [1, 2].map { |i| i + 1 } #=> [2, 3]), ООП модель из Smalltalk (у Ruby) — всё это сильно меняет стиль программирования.

Плюс и Ruby легко создавать DSL (как бы мини-языки для конкретной задачи) — это очень полезно для обучения, так как можно создать API с помощью которого скрыть некоторые ньюансы (чтобы рассказать обо всём последовательно, конечно же). Например, библиотека RSpec позволяет писать тесты в Ruby, как:
var.should == 1
array.should include(1)
object.should have(3).commands # аналогично object.commands.length.should == 3
>В том-то и дело, что Ruby и Python сильно отличаются от Pascal и Basic. И не динамической типизацией, а именно подходом.

Вот потому то, имхо, и не стоит их использовать для основ программирования и алгоритмизации. Разве что в C-style виде, без использования отличного от других подхода, то есть просто как процедурные языки с элементами ООП, таким-то синтаксисом ветвления, таким-то цикла, таким-то определения класса и т. п. Но, во-первых, в таком случае у них не будет преимуществ (для этого годится любой «Си-подобный» язык, например, PHP ;) ) во-вторых за использование руби (и, вероятно, питона) в таком стиле автора просто заминусуют :)
Но в этом и проблема современного IT-образования — проподают только императивный подход. ОО только в стиле C++. Надо ли говорить, что это в итоге просто ужасно. Многие даже не знают, что проблемы параллельных вычислений можно решить в том числе функциональным программированием или «актёрами» (асинхронной передачей сообщений). Что интерфейсы и абстрактные классы не нужны в модели Smalltalk. А делегата позволяет вам описывать, какой цикл вам нужен, а не как его реализовать:
loop { 'аналог while true' }
5.times { 'аналог for (i = 0; i < 5; i++)' }
10.downto(3) { }
Может быть просто декларативный подход не востребован массовым рынком? Может быть десятки тысяч «функциональных программистов» в год (по России, наверное :) ), специализирующихся на параллельных вычислениях средствами Smalltalk просто не найдут себе работу? Я не спорю, что такой курс(ы) должен быть обязательным при получении диплома программиста, но далеко не основным, имхо, на настоящем этапе развития рынка ИТ. Массовое образование ориентировано прежде всего на нужды экономики (не важно рыночной или плановой), нравится нам это или нет
Проблема востребованности — это вопрос курицы и яйца. Многие бы перешли с PHP на Rails или Django, если бы были предложения о работе. А заказчиков сдерживает нехватка кадров :).

Но проблема не в выбор функциональный/императивный. А именно в ограниченности языков. При любой подготовке изучаются хотя бы несколько языков. Так почему оба языка — классического подхода? Изучая Ruby мы заодно и показывает и классический подход и нетрадиционный :).
В принципе согласен. если речь идет об одновременном использовании двух «традиционных» языков в качестве примеров, то, вероятно, это избыточно и можно было бы использовать какую-нибудь «экзотику» в качестве второго примера :)
Для понимания основ алгоритмизации и выработки навыков решения задач достаточно и Бейсика с Паскалем. Насчет же «не использования»: Бейсик — VB, VBA, Lotus Script, 1C-script, Паскаль — Delphi. Первые еще может быть и узконаправленные языки по применению, но вот насчет Дельфи и ее популярности — навряд ли можно оспорить. Хотя если большинство — закоренелые «сишники», то мой аргумент окажется бесполезным.
Но и Ruby и Python тоже достаточно. Т. е. преимущества Basic и Pascal — это подмножество преимущества Ruby и Python ;)
все-таки, мое ИМХО (основанное на опыте) — для изучения основ алгоритмизации удобнее всего Бейсик и Паскаль. Ограничится можно и Паскалем, но изучать базовые алгоритмы с целыми числами, массивами и прочим удобнее всего на семантически структурированном процедурном языке. А на чем потом программировать — это уже сам человек пусть выбирает, основы они будут везде основы, только синтаксис записи операторов и функций изменится
Под опытом имеется в виду сравнение опыта преподавания на Python\Ruby с опытом на Pascal? Или опыт — это просто, нам всю жизнь и Pascal хватало? :)
Опыт сравнения преподавания основ алгоритмизации на простых языках и сложных. Питон и Руби — веб-ориентированные языки, с мощной моделью объектов. Тем же кто только начинает — им вы вообще понять что такое программирование. А не лезть в дебри классов, наследований и прочего.
Python и Ruby не ориентированы на веб, в отличии от PHP. Это общие языки. Для веб там вообще используют framework’и — Django и Rails.
Так же ООП модель не является для них обязательной в отличии от Java и C#. Можно использовать процедурный стиль. Так же и ООП модель у них гораздо проще, чем у Java и C# (нет интерфейсов, абстрактных классов), потому что они используют модель Smalltalk, а не C++.
Тем не менее 90% десктопных приложений на них не пишутся. И наоборот, процент веб приложений на этих языках (с использованием фреймворков) растет. Всегда используют тот инструмент, который более подходящ для решения той или иной задачи. Мы можем с вами спорить очень долго, и все равно останемся при своих мнениях =)
Вы не правы — очень большое количество десктопных приложений в Linux написаны на Python. Например, довольно популярный jabber-клиент Gajim. Ruby действительно снискал популярность в вебе — но не за счёт языка — сам язык тут не причём.
С другой стороны, наоборот можно избежать много сложностей — например, циклов for:

count = 10
count.times do |i|
  puts i
end

array = [1, 2, 3]
array.each do |i|
  puts i
end

loop do
  # бесконечный цикл
end


В Pascal это были бы сложные операции, которые нужно удерживать в голове (сколько раз были мелкие ошибки, так как забывал >= вместо > в for).

Заметьте, никаких объектов или веба, а текст программы больше похож на английский язык.
вы путаете немного Паскаль и Си =)
в паскале for i:=0 to n do… трудно допустить ошибку, в отличие от синтаксиса си: for {i=1,++,n) (явно написал неверно, ибо си не знаю — на уровне понимания). А понятие цикла так вообще легко объяснить на Бейсике — For Next — чего уж проще. А в вашем примере уже используются «пережитки» классов =) count.times — объект.свойство. Насчет же «англоязычности» — тут все языки практически одинаковы. Изучив например оператор writeln в Паскале, новичок легко поймет, например и шарп-ское Console.WriteLine. Я не спорю, возможно ваш постулат об обучении на базе Питона имеет под собой основания. Но пока я не встречал курсов основ программирования именно на этих языках. А преподавание основ на Бейсике и Паскале — закреплено временем. Я сам начал с Бейсика и Паскаля, и впоследствии легко освоил и VB, и VBA, и даже такую редкую вещь как Lotus Script. Аналогично, переход от Pascal к Delphi вообще произошел незаметно. Изучив Питон и Руби перейти к Си, будет сложнее, не говоря уже о Ява и проч. А вот, изучив Си, обратный переход к РНР, Питону, Яве и т.д. С-based языкам очень и очень просто пойдет.
По поводу перехода — а почему бы не рассказать об алгоритмах на Ruby/Python (как замена Basic), а вторым языком рассказать о Java/C# (вместо Pascal)? ;)
Для этого мне надо их знать. Я же предпочитаю говорить только о том что знаю досконально.
Кстати, ещё один колосальный плюс Python и Ruby для обучения — интерактивная консоль. Вы просто пишете в неё команды и она тут же выполняет, давай возможность вам двигаться по шагам.

Например, выбрать нечётные элементы из массива:
~$ irb
>> a = [1, 2, 3, 4]
=> [1, 2, 3, 4]
>> a.reject { |i| i % 2 == 0 }
=> [1, 3]
>> 


В результате не надо объяснять процесс компиляции, какой-то инструментарий. И возможность увидеть результат сразу после каждого шага.

Кстати, есть даже интерактивная консоль в Вебе — в результате ученикам даже ПО не надо ставить.
Как раз таки Бейсик — интерпретатор =) Можно и пошагово выполнять.
Спасибо за статью. Хотелось бы продолжения. Особенно интересны примеры web-программирования на C#, т.к. часто с ним приходится сталкиваться в работе.
Знаете, я никак не пойму зачем же нужны эти циклы статей. Сначала капли про Руби, теперь ведра C#, скоро, вероятно, будут прудики с жабами…
Точнее, так. Я в чем-то понимаю авторов — интересно писать; в процессе начинаешь лучше понимать то, о чем, пишешь; самооценка, в конце концов, растет.
Но читатели… вы почему так рады этим циклам? Неужели вы рассчитываете, что люди, сами недавно освоившие эту область, могут последовательно и безошибочно все изложить? Суметь расставить акценты, дать хорошие примеры?
Вместо этого, если вы действительно хотите выучить язык, то почему не взять за основу хорошую книгу, написанную человеком, стопроцентно разбирающимся в теме? Многие из таких книг переведены на русский (пусть и не лучшим образом), так что даже плохое владение английским не должно остановить. Кстати, если говорить про C#, то советую читать Трэя Неша и не советую Либерти.
Уверен, автор сам эти книги уже освоил, и думаю, будет активно пользоваться ими при написании своего цикла статей, что, безусловно, положительный момент. Но у меня тогда вопрос — почему не обратиться сразу к первоисточнику? Какова ценность этого пережевывания…

Прошу автора не воспринимать комментарий как личную критику. Это всего лишь мое мнение о такого рода циклах в целом. Просто так получилось, что сегодня мне очень захотелось высказаться на этот счет.
Я понимаю, но я не «недавно» освоил это. Преподавал в университете C#. Да, может быть из меня плохой программист, но преподавать я думаю смогу.
Моё ИМХО — эти статьи не столько для того, чтоб научить, сколько для того, чтоб дать толчок людям, которы «хотели, но стеснялись спросить об это» =)
На всякий случай, прошу прощения, я ни в коем случае не хотел сказать что конкретно вы не разбираетесь в том, о чем рассказываете и что новичок в этом.
Мне кажется, что толчком должны служить как раз сложные примеры. Тоесть человек посмотрел, что можно сделать, какие возможности у технологии, и подумал «круто, надо разобраться в этом». И пошел читать книгу.
Потому что ведь все равно циклом «о языке в целом» не заменишь толстую книгу. Как и курсом лекций, кстати.
В этом и проблема. Преподавать я умею, но в оффлайне. А очень хочется понять как лучше будет в онлайне.
В универе что? все рядом (группа), есть доска. К каждому я могу заглянуть через плечо.
Сейчас как раз все мои силы идут на то, что бы найти оптимальный и интересный метод обучения в интернете. Ищу инструментарий.
Я представляю это как что-то среднее между скринкастом, webinar, чат и т.д.
если у кого есть мысли по этому поводу — прошу писать!
Это несложно, покажите элегантное решение нетривиальной проблемы, а потом разберите пример по косточкам. Обучить через интернет кого-то, думаю, трудно — нет обратной связи, заглянуть через плечо не получится. Поэтому, главное — заинтересовать и предоставить максимум информации. Я бы сделал такой цикл статей: «Вот что мы сделали!», «Как мы это делали», «Какие проблемы у нас возникли и как мы их решили», «Как мы это наконец сделали и что ещё можем сделать».
>Сейчас как раз все мои силы идут на то, что бы найти оптимальный и интересный метод обучения в интернете. Ищу инструментарий.

Jбучение кого? Насколько я знаю инструментарий сильно различается при обучении «всего интернета» или при обучение конкретной группы (по предварительной записи, возможно с предварительным тестированием и т. п.).

При первой ЦА упор делается, обычно, на «дидактические материалы» (вроде так это называется у профессионалов :) ), в общем статьи-лекции, возможно скрин/подкасты, задания для самостоятельной работы, «анкетное» тестирование и т. п. Характерная особенность — мало обратной связи, особенно для человека не следящего за публикацией материалов в «реал-тайм». Самый известный пример, наверное, intuit.ru

При второй ЦА обучение, напротив, строится на тесной обратной связи, вплоть до полного отсутствия теоретической (вернее «лекционной») и «домашней» частей — «делай как я и задавай вопросы, если что-то непонятно», «теперь делай то-то, что значит не знаешь, а почему 5 минут назад не переспросил». Кто-то использует групповое обучение, кто-то парное, кто-то индивидуальное, главное тесная обратная связь студента и преподавателя. технологии самые разные, от систем видеоконференций до «примитивной» IRC или даже аськи
Мне кажется, что книга не всегда может быть оптимальным средством для обучения, порой цикл статей со ссылками на сайт с документацией вполне может заменить книгу, даже очень хорошую.
Советую почитать одну статью Евгения Матюшкина — там описано, как хорошо научиться языку программирования. Мне лично, запомнилась такая цитата: "… читать литературу стоит лишь тогда, когда есть вопросы, на которые она даст ответ. Если читать книгу, не имея к ней вопросов, то информация выветрится через неделю. ".
Думаю, это не только к учебникам относится :)
Полностью согласен
По-моему таки статьи куда лучше подходят в качестве толчка. Сложный пример, с использованием всех возможностей языка, мощных библиотек классов, фреймвоков и т. п. чаще провоцируют, по-моему, мысли вида «круто, надо бы разобраться в этом, но разбираться, наверное, год, так что как-нибудь потом», чем «круто, надо разобраться в этом, где бы книгу надыбать»

Плюс очень многие книги (не все) часто подразумевают какие-то базовые концепции, которыми далеко не факт, что владеешь (самый частый пример лично для меня — консоль *nix и стандартное дерево ФС в этих же никсах, или регэкспы), или их авторы уделяют недостаточно внимание «разрыву рекурсии» частой в современном мире, когда одно понятие сложно или невозможно объяснить без второго, а второе без первого.

Да и ниже цитировали «Если читать книгу, не имея к ней вопросов, то информация выветрится через неделю.» с чем я полностью согласен. Вот я сейчас начал читать книгу по Ruby, толчком послужили соседние «капли»

Ну и не маловажный фактор — обратная связь, что не понятно тут же переспросил, может автор ответит, может еще кто. А когда вопросы возникают в процессе чтения книги, то:
— не знаешь где и у кого собственно спрашивать (особенно если книг на английском, а ты владеешь им достаточно чтобы «читать техническую документацию со словарем», но недостаточно чтобы сказать что-то сложнее «май нэйм из ...»)
— если даже нашел форум, гуглгруппу и т.п. русскоязычные. то даже на корректно сформулированный вопрос можно получить ответ «RTFM» или «юзай поиск», а учитывая, что часто в таких комьюнити общение идет на сленге, которого вы не знаете, то шансы что-либо найти минимальны (мне, например, не приходило в голову вбивать в поиск «юзать вьюшку», а по «использовать отображение» ничего не мог найти
— возможность корректировать содержание статей по ходу изложения, тоже немаловажна, автор видит, что много вопросов по какой-то вскользь освещенной им теме (не самый хороший, но пример — регэкспы) и посвящает часть или всю следующую статью этой теме.
Слишком уж мало написали. Только успел заинтересоваться, а уже P.P.S.
мне одному кажется, что здесь нет ни слова про C#, а только пара слов про то, что такое метод и его сигнатура?..
наверное, все-таки стоит рассчитывать на аудиторию, знакомую хотя бы с процедурным программированием, или даже ООП. ну или, как вариант, назвать цикл «ООП на примере C#. шаг первый — что такое метод».
ну и для hello world на .Net наверное не стоит использовать кальку c++ — метод, возвращающий интовый ноль…
возможно, я чего-то не понимаю (в C# новичёк) — но почему Main возвращает 0 (без смысловой нагрузки), ведь он может быть void?
Там же написанно, что раз стоит возвращаемый тип int, то нам надо вернуть этот int и поэтому будет return 0;
Если будет стоять void, тогда возвращать ничего не надо.
ну так я это и имею в виду — если по логике ничего возвращать не надо, то зачем просто так указывать int вместо void, а потом озвращать 0?
Ооо! Это старая история идущая со времен С и первых С++ :)

Нет на самом деле все просто, во времена MS-DOS возвращенное из main значение обрабатывалось осью и на его значении основывалось что произошло, в простейшем случае 0 — приложение завершилось корректно, !0 — приложение завершилось аварийно. А еще можно было вроде как в *.bat файлах это значение отлавливать и на его основе разные штуки писать, типа ветвления и последовательности запуска других команд.

Вот, как то так.

Кстати как сейчас с этим не знаю, но по-моему ничего не изменилось и ось также может получить возвращенное значение, дело только в том что зачем это сейчас надо? Во всяком случае в Win-системах.
Если копнуть еще глубже, то история старее MS DOS :) Как минимум традиция это пошла от первых компиляторов Си и первых Юниксов (что было раньше яйцо или курица я затрудняюсь ответить без гугления :) ) и до сих пор в них успешно используется, да и в Win-системах никто не отменял анализ возвращаемого значения в тех-же «батниках»(«кээмдешниках»), а с недавних пор и PowerShell. Да и вообще, программа для Windows тождественно не равна программе с GUI, возьмите любой системный сервис — это все CLI приложения, как раз и возвращающие эти значения. Именно по ним ядро винды судит успешно запустился тот или иной сервис

Самое прикольное видеть этот int main на AVR или PIC :)
возвращаемое значение в вин-системах (да и в любых других) также используется в фабриках процессов чтобы понять где все хорошо просчиталось, а где надо повторить
К слову, и сейчас эти возвращаемые значения весьма удобны. Например, в «Назначенных заданиях» винды есть графа с «Результатами прошлого запуска».
И сразу видно, какая задача была выполнена с ошибкой. Ибо тогда там результат отличен от нуля.
Думаю, пусть даже и сейчас можно обойтись void'ом, но возвращаемый нуль — это признак хорошего тона, что ли.
У меня вопрос, немного не по теме: как, где и в чем скомпилировать проект созданный в visual C++ express (с использованием .NET) под linux?
Посмотрите в сторону nano Но все конечно зависит от сложности проекта
тьфу ты блин, mono конечно, ниже ссылку дали, полночи просто в nano сижу :)
А почему вы сразу подразумеваете, что у пользователя Windows? Почему нет инструкций по установке .Net на Linux и Mac OS X?
не переживайте, скоро и под Linux будут эту проприетарную бадью втюхивать.

хотя, если отвечать непосредственно на вопрос (я, понимая вашу иронию, пишу, скорее, остальной публике), то ответ будет очень простым. Просто под *NIX системы этот аппендикс ненужен. он там как мертвому припарка. там и так все просто. А ведь есть еще вовсю набирающая обороты Inferno, где и сетевые ресурсы все представлены в виде файлововой системы. интересно, куда денется Микрософт со своей непомерно раздутой и завзнич закрытой Windows лет через пяток :). только на Девелоперах и держется.
Честно говоря, я говорю без всякой иронии. В Linux уже давно и активно используется Mono, при этом разработчики стараются найти свой взгляд (Gtk#). Многие .Net программисты хорошо оценивают Mono.

Ирония тут если и есть, так только в том, что автор забыл о кроссплатформенности — а ведь на Хабре доля «других» ОС весьма велика.
Приложений на Mono наберётся, наверное, с десяток. Я говорю про те, которые есть в общедоступных репозиториях Linux.
Правда в Linux, конечно же, доля Mono мала и сферу .Net прекрасно занимает Python (надеюсь, что Ruby тоже будет активно использоваться для desktop-приложений).
Ну основное назначение Mono по-моему все же кроссплатформееные приложения (с упором на разработчиков .net), нет?
Не совсем. Например, Novell (которая и финансирует Mono) часто использует Mono для разработки чисто Linux-приложений (максимум, POSIX). Часто используется Gtk# или привязки к GNOME.
.Net мало шансов стать кросс-платформенной из-за привязки к Windows (ASP.Net заточен под IIS, WinForms в Mono приходится эмулировать нативными средствами).
чем ASP.NET заточен под IIS?

SWT на каждой платформе тоже эмулируется нанивными средствами
чем ASP.NET заточен под IIS?

Попробуйте инсталлировать ASP.Net без IIS на Windows.
SWT на каждой платформе тоже эмулируется нанивными средствами


А причём здесь SWT? Она не входит в JavaSE.
SWT не эмулируется, а использует JNI-вызовы к библиотекам нативных элементов управления ComCtl3D.dll в Windows и к Gtk-библиотеке на Unix. На Mac OS X используются JNI-вызовы к виджетам Cocoa, если не ошибаюсь в названии.
Пробывал. Запускал через XSP (mono), работало.

В чем смысл фразы: «WinForms в Mono приходится эмулировать нативными средствами»?
Mono это считается кросс-платформенным средством, которое хронически отстаёт от текущей версии .Net на одну-две версии — в зависимости от типа операционки, на которую портировали.

WinForms в других операционках работают через Gtk#? Gtk# не что иное как аналог SWT для Java, но Gtk Look&Feel отличается от Windows-контролов, значит происходит эмуляция поведения WinForms, а не реальное поведение .Net-контролов.
В чем-то отстает, в чем то опережает. Например, пока в MS только думают написать managed компилятор C#'а к пятой версии, в mono мы имеем его уже сейчас. Пока в MS только думают написать RELP, он в mono уже есть.

Если реализация WinForms под windows завязана на системные вызовы windows, то ясно, что реализацию под linux напишут по другому. В Java с Look'n'Feel под MacOS тоже не все хорошо=)
Ну в любом случае в .Net изначально не заложена кроссплатформенность.
Если судить по этой статье, то заложена, по идее платформозависим только один компонент — VES (насколько я понял аналог JRE). Да и на заре появления .Net вроде как MS заявляла о кроссплатформенности.

Другое дело, что наверняка код его закрыт, защищен юридически как только можно и т. п. и независимому от MS разработчику сложно реализовать всю документированную (а ведь и недокументированная наверняка есть) функциональность
Спасибо, правда не знаю получится ли следить постоянно, тут и Ruby, и С#, и Java, все давно интерсовало, но «боялся спросить» :)
Спасибо!
Главное продолжайте, пожалуйста.
Я лично как раз начал изучать C#. Конечно, я купил книгу и прохожу ее главу за главой, но тем читать еще один взгляд интересней!
Надеюсь, что я когда-то подумаю «ага, а вот оно как на самом деле!», читая ваши статьи :)
Товарищи у меня вопрос!

Прежде чем узнать вопрос следует знать цель моего вопроса (говорю это для неадекватных людей): лично для себя хочу узнать мнение людей, которые собираются программить на C#

Итак:

Почему вы выбрали С#, если
— работает только под Win
— требует намного больше затрат (покупка лицензий на Win)
— тот же LAMP бесплатный (ну почти бесплатный)
— все таки С# не такой уж и производительный ЯП (ВНИМАНИЕ: если вы так не считаете, не обращайте внимания. Скажем ХолиВару НЕТ!)
Буду рад услышать объективную точку зрения.

Спасибо

1,3: Я пишу на C# мелкие аппликейшны под Win, которые нельзя написать с участием LAMP.

2: Затраты у меня пока что нулевые — свободный MS C# Studio Express, свободный .NET Framework, свободный SQLite как БД.

4: Почему? Меня вполне устраивает) Если, например, брать Qt c С++, то простецкая отрисовка формы, где будет 1 текстбокс с датой текущей, займёт в памяти в 2 раза больше пространства, нежели то же самое на C#.
А почему вы не используете Python и Ruby на которых также можно писать не веб, а обычные приложения под Windows? ;)
Потому что в VS всё интуитивно понятно — гуи для формочки, куча подсказок и прочее) Даже не читая мануалы, можно наваять что-то простое)
Неверно говорить, что C# только под Windows. Mono — довольно хороший проект и активно используется в Linux.
По поводу производительности. Сейчас скорость Java\C# считается более, чем приемлемой — просмотрите на Python/Ruby :).
Сравнивать LAMP и C# нельзя — это разные вещи. Формально, вопросы о кроссплатформенности, цене и сравнение с LAMP имеет отношение только к ASP.Net.

Лично я не любитель C# (я использую Java, которая практически тоже самое), но по мне Java/C# хороший способ написать ресурсоёмкий код в 2 раза быстрее, чем на C\C++, потеряв всего 10 % производительности.

Лично я считаю, что Java прекрасно подходит для ресурсоёмких вставок в JRuby и Jython коде :).
1. Мне не нравятся другие платформы, хотя Mono и существуют для любителей альтернативы.
2. Затраты один раз, и то не факт, win шла вместе с ноутом, среды для разработки на этапе обучения есть бесплатные, а потом не грех и заплатить за инструмент с помощью которого ты зарабатываешь деньги.
3. Desktop приложения на PHP? Я вас правильно понял? :).
4. Действительно не такой, хотя смотря с чем сравнивать, но на текущем этапе (стоимость железа и стоимость работы программиста), затраты на проиводительность, вполне окупаются скоростью разработки.
десктоп-приложения на пыхе существуют кстати… их правда очень мало, но они есть;)
Ни кто не отрицает их существование :).
Просто посмотрим на пример PHP-GTK, стандартный Hello World :http://gtk.php.net/manual1/ru/tutorials.hellow.php и сравним с тем же самым решением на C#. После этого можно представить танцы с бубном при написании чего либо более сложного.

В конечном счете все упирается в три постулата разработки:
1. Быстро
2. Качественно
3. Недорого

При разработке можно выбрать только два параметра, и подобрать нужный инструмент. На текущий момент меня целиком устраивает в качестве инструмента C#
У меня задача такая: нужно писать несложные тулзы и хотелось бы использовать XNA для прототипирования игр.

— я работаю под Win.
— работа предоставляет лицензию.
— понятия не имею, что такое LAMP.

Может есть какие-то лучшие средства для моих целей? Спрашиваю совершенно искренне, так как исследований особых не проводил, а вцепился сразу в C#.
1. у конторы профиль — разработка под win
2. существует несколько вариантов msdn подписки — там и win, и sql-сервер, и VS, и куча прочих полезностей
3. а кто это?
4. еще ни разу (к счастью?) не приходилось сталкиваться с задачами, для которых производительности C# было бы недостаточно
Наверное стоит отделить С# и платформу .net

Сначала про платформу:
— не буду приводить цифр, но подавляющее число десктопов (а по некоторым оценкам и компов вообще) работает под win, плюс еще есть mono
— если работать в нормальной фирме, то мои затраты на лицензии равны нулю, максимум цена самой ОС, без которой мне все равно никуда не деться (в настоящий момент юзаю винду бесплатно, бета тест и все такое :), если же «для себя», то для разработки .Net SDK и даже IDE есть бесплатные, а для серверных приложений — win-hosting или vds, ну а БД можно прикрутить любую, тот же MySQL
— вопрос производительности (в разумных пределах) в большой части проектов не стоит остро, и приносится в жертву скорости и качеству разработки и, наверное, стоит говорить о производительности .Net независимо от языка

Теперь про С# как язык разработки для .Net
— программы на С# .Net компактнее, да и красивее, имхо, чем на VB .Net, плюс привычный знакомый синтаксис (С/С++/PHP)
— программы на С# .Net компактнее и имеют более высокий уровень абстракции чем на С++ .Net
— спрос на C# программистов на рынке труда есть, как на «фриланс», так и «в офисе» и, по-моему, больше чем на VB .Net и VС++ .Net

Всё имхо и не тема для холиваров :)
Но, кстати, на IronPython код гораздо компактнее, чем на C# ;)
хм… начало пользоваться популярностью step-by-step обучение. Внимание, вопрос: нужно ли начинать цикл статей по WPF? Если да, — то сделаю. Если будут желающие помочь — пишите в личку, скоординируемся.
Очень хотелось бы увидеть. Так что бесспорно нужно :)
тогда попрошу немного поднять мне карму, и я опубликую вводную :)
Надо. Из таких статей интересно узнавать о новых или прошедших мимо тебя языках и технологиях или отдельных аспектах в них, вообще не напрягаясь (как в случае с целенаправленным чтением документации :)).
Может начать цикл статей по кросс-платформенному программированию на С++/Qt? А то Питоновская версия что-то загнулась;) Вы скажите есть извращенцы которым это интересно? Если есть, то поделюсь опытом
есть, очень интересно!
ну значит как закончится сессия ждите;) особенно если накопится хотя бы человек пять желающих…
пока хотелось бы узнать какие темы стоит освещать… с нуля с++ рассказывать я вряд ли буду, так что наверно стоит зафиксировать какой-нить минимальный уровень знаний и примерный список тем, которые стоит осветить
Знания – С++ без объяснений (так как из программистов, думаю, его здесь знают все), а рассказывать наверное надо именно о Qt :)
ок, но все же хотелось бы примерный список топиков чтобы можно было подобрать какой-нить учебный проект, который будем писать шаг за шагом;) потому что просто обзор возможностей Qt (с разъяснениями и примерами) это статей на 40 наверно;)
Какой-нибудь анализатор выдачи (например проверка позиций своего сайта и конкурентов) гугла (а может списка поисковиков) с накоплением результатов в БД и экспортом/импортом в файл?

Вроде все основные технологии будут задеты — тут и работа (многопоточная) с удаленными серверами, сокетами и т. п., и работа с БД, и с файлом, и разбор HTML/XML, ну и, естественно, GUI, возможно с элементами HTML рендеринга (да и консольные какие-нибудь команды можно придумать, типа пакетных заданий)

Правда, наверное, это тоже статей на 40 потянет наверное :)

и чо тут всех на веб тянет?;) без веба уже не думается?;) ладно как сессия закончится напишу вводную статью, а там посмотрим как да что;)
Ну а как без веба в наше время? :)

А если серьезно, то такие приложения, имхо, охватывают большую часть реальных задач встающих перед разработчиком.
Есть, очень интересно, вроде даже в комментах к питоновской писал об этом, но заминусовали кажется :)
Жжжесть. :)
Ruby — капля первая… десятая;
Java — чашка первая;
C# — ведро первое… :)))) Разодрало просто…
Так и поддмывает написать про какой-нибудь язык. Жаль, что читать про php, javascript, Visual Basic никому будет не интересно.
Про JavaScript думаю было бы интересно, при условии, что там не простейшая валидация форм в onsubmit и не «тупое» (в стиле копи-паст) использование JQuery и компании, а что-то вроде полноценной (для учебных целей, конечно) реализации «веб-десктопа» с нуля
CSS + Internet Explorer 6.0 — бутылка водки первая… ;)
>>> Для извращенцев :) можно попробовать использовать csc.exe — это компилятор C#

Быдло, такое быдло…
А я щитаю, надо начинать с конпеляции в командной строке и мейк файлов, чтоб в башке хоть осталось как это все работает. Ато разведется потом быдла, которое без IDE ниче сделать немогут.
тру-вэй — использование msbuild для билда csproj-проектов :)
Большое спасибо, как раз то, что мне нужно:)
UFO just landed and posted this here
Ещё пять минут и вылоу. Дописывал и ошибки исправлял =)
Вы знаете, статья очень сильно логически не закончена. Вы даёте введение в .Net но делаете это по принципу AS IS, не объясняя что/зачем/почему. Как например вот здесь:
Одной из основных идей .NET является совместимость различных служб, написанных на разных языках. Например, служба, написанная на C++ для .NET, может обратиться к методу класса из библиотеки, написанной на Delphi; на C# можно написать класс, наследованный от класса, написанного на Visual Basic .NET, а исключение, созданное методом, написанным на C#, может быть перехвачено и обработано в Delphi.
Всё совместимо, и всё может вызывать(ся), но вы не ступили ещё ниже и не упомянули про IL.
Притом есть в тексте логические неточности, всё вроде бы правильно, но ухо немного режет.
Вобщем статья не сильно, посему "-" за неё, но начинание хорошее, поэтому в карму "+" ;).
Спасибо учту. Я привык словами объяснять и на доске рисовать ))
Вот переучиваюсь, а вернее учусь новому методу обучения!
Sign up to leave a comment.

Articles