Ходил во дворец в этот компас, с 6 класса 3 года занимался на бейсике, делфи и курсах 3д макса, мне это с детства интересно. Си там не было. Занятия типа пол занятия учимся, другую играем. Ходили даже большие парни, чтобы только поиграть по сети Большая половина моей группы разработка ПО в радике ходила на курсы в ГШП(Городская школа программирования кажется,это которая в радике), плавают в самых элементарных лабах... не все конечно, но большинство. Их туда потащили родители, чтобы зря дома не сидели. По-моему даже в радике небольшой путь самосовершенствования в этой области, сижу на лекциях книги по C# читаю, а то даже си появится очень не скоро... Хотелось бы найти какую-нибудь фирму даже для бесплатной стажировки, было бы очень полезно и интересно. Единственные интересные и полезные лекции нам читает преподаватель-программист из какой-то местной фирмы якобы по истории специальности, но читает про разработку приложений, работу команды программистов, этапы разработки и тп
sp0_of, прошу прощения за переход на личности, но в таком нежном возрасте уже трудился давно. А по поводу курсов, может вопрос во 2-м высшем?
sp0_of, Почему меня далеко не программиста еще в школе насабачили делать все с помощью алгоритмов, без привязки к языкам... также в радике товарищ Макаров учил тому же... хоть и довольно своеобразно... Но алгоритмы это в первую очередь склад ума... можно учиться на типовых решениях, но когда свое работет - намного лучше... а синтаксис... хм... даже обезьяну можно научить музыке... По ООП можно почитать книжки, синтаксис - хелп и дебаггер... Самое интересное в программировании - это ассемблер или кодинг на машинных кодах... когда по алгоритму, разложить кучу подпрограмм, основываясь на архитектуре камня... по структурной схеме можно написать прогу даже... хочется мозг позабивать - поразбирайтесь с этим (а лучше когда есть доступ к железке), и не ищите курсы, их в рязани просто нет... ГШП это вообще жесть... в былое время ворду учили с помощью рисования картинок на доске... PS а рязанские программисты сидят по своим рабочим местам, кодят в пхп сайты на московские конторы (засев гденить системным администратором), или дрова пишут под системы РЛС на заводах... или от скуки игры пишут... обраование хорошо когда оно прибыль приносит, а тут ее особо нет.
А ты когда-нибудь писал архитектурно-зависимый код? Были ли задачи, даже реализация которых на ассемблере конкретной железки не укладывалась в отведенное время? Болела ли голова от того, как распараллелить задачу на N микропроцессоров? Попробуй, вдруг понравится А писать копи-пастом в среде разработки, которая больше половины функций делает сама, как раз могут научить в институте. Вот только в такой системе программист превращается в секретаршу. Поэтому и негде в Рязани поговорить программистам, что хороших программистов мало и у каждого свои интересы. А задать вопрос и на глобальных форумах можно.
Нет. Просто программисты разные бывают. Кому-то нравится кодить на низком уровне, а кто-то считает себя крутым, научившись кидать кнопки на форму. К сожалению, в Рязани последних намного больше, поэтому общаться между собой им не о чем, следовательно, и негде.
Как говорится, хорошие программисты пишут не на чем умеют, а на чем им скажут. Поэтому на первом курсе программистов я бы обучал исключительно типичным алгоритмам (прям все книжки Кнута дать под запись) плюс основам программирования на уровне схем (условия, циклы, подпрограммы...) без привязки к какому-то синтаксису. Естественно необходим обзор технологий: что и на чем сейчас пишут. Я считаю, что выбор языка программирования должен исходить из поставленной задачи, а не наоборот. А те буковки, что ты написал, я и сам не все знаю А коммьюнити в Рязани искать бесполезно, да и зачем, если в интернете форумов по любой теме полно.
Какой толк знать синтаксис не зная алгоритмизации, т.е. не зная зачем это все надо... следовательно не зная типовых алгоритмов и не расскажешь о особенностях ЯП... алгоритм это и есть программа, синтаксис лишь способ реализации... PS дрова на си не напишешь... микроконтроллер не прошьешь по-человечески... не говоря уже о толковой многопоточности... тем более в средах вижуал... особенно любимыми и распространенными, повседневyet писание в них делать можно, но как правильно сказано, есть гуишники, а есть те кто за этих гуишников все остальное делает...
2 sp0_of опыт дровописания есть на мк? не для виндов, не для осей, а для мк, с аппаратным вводом-выводом? типа обработки сигнала для цифровой связи... на си напишешь, но сравнив по скорости (которая ооочень важна) поймешь почему я так сказал... и если все привыкли что вам среда программирования все разложит на понятный железке язык, то увы не так все просто... я давно не программирую на хлеб, но то что написано на си, потом сидится и правится вручную на асемблере...(ныне это зовется оптимизацией) до маразма микрокоманд не доходит... а можно былобы еще быстрее делать софт И опять пошло поехало знание буковок, я например немецкий и китайский по словам знаю, а предложение составить не могу... так что уделяйте больше внимание изучению языков... а алгоритмы papenkin, я прекрасно понимаю что драйверами большинство зовет то через что мы дружим с аппаратной частью... а то что драйвер бывает как ключевой элемент, построенный на примитивной "логике" мы все забываем... и привыкли кодить под винду или юникс, работать с библиотеками... только вот на мк их нет... там и винды нет, там ручками-ручками... низкоуровневыми языками все... или вообще микрокомандами... Так что когда так говорите, вспоминайте то, что те, кто заставляет работать биосы итп на компах, тоже программисты...
Viktor_62, я 6 лет программировал микропроцессоры Analog Devices, причем в основном многопроцессорные системы с соответствующим распараллеливанием задач. Первое время, естественно, писалось все в основном на С, но последние года 2 моей работы, мне было проще сделать все на ассемблере. Во-первых, потому что ставились задачи в реальном времени (цикл обработки 1-1.5 мс), где С все равно не успевал, а во-вторых, потому что за время работы уже написалось много библиотек на низком уровне. И в этом плане знание какого-то языка не приносит никакой пользы, потому что сегодня ты пишешь для одного процессора, а завтра тебе дают другой, мало того, что с другой системой команд, так еще и с другой архитектурой. То что ты говоришь про языки как раз важно для програмистов, работающих на прикладном уровне, а не для железячников. А вот как раз знание алгоритмизации поможет реализовать программу (на любом языке) более эффективно, с меньшими затратами. К тому же работающие рядом алгоритмисты частенько не понимают, как оно вообще будет в итоге работать, и уж тем более им не известно, как именно задачу можно разбить на параллельные участки, если есть в этом такая необходимость, потому что для этого они должны хотя бы представлять себе, как работает процессор. Так что опять же на низком уровне хороший программист должен быть еще и хорошим алгоритмистом. Все взаимосвязано, и выделять что-то тяжело.
Не совсем понял в чем ты меня пытаешься убедить... Я и не говорил, что под мк надо писать на языке высокого уровня используя гигантские либы. Я лишь сказал, что драйвер на сях написать можно, а во многих случаях _нужно_. Вот конкретный пример: есть линейка продуктов из 6 различных девайсов, во всех девайсах стоят разные процы. Задача - написать USB драйвер, работающий как в хост-режиме, так и режиме девайса. Вот какой смысл писать (а самое главное - отлаживать) на асме 6 различных драйверов, когда можно написать 1, а остальную работу переложить на кросскомпилер? К тому же по личному опыту скажу, что нынешние компилеры очень "поумнели" и соревноваться с ними в оптимизации ассемблерного кода под распространенную архитектуру - моветон.
2 papenkin Я говорю не про прикладные задачи под какую-то ось, а под задачи решаемые на аппаратном уровне... под архитектуру DSP или мк любого уровня... а не про софтовый программизм, там да когда пишешь софт, то конкурентов распространенным языкам просто нет... тем паче асм 2 sp0_of выше твоего топика есть внятный ответ, не мой, зачем нам нужен асм и почему си не катит, я после подобной задачи к этому и пришел... распараллелить обрабоотку сигнала, дабы несколько камней делали преобразование фурье, ДПФ камень может делать сам (в DSP это встроенно) а вот распараллеливание и складывание решения си не сделает... Просто спор зашел железячников и софтовиков... для каждого свои языки и методы подходят... Флуд не флуд, но разговор о необходимости подробного изучения способов алгоритмизации любого процесса или задачи...
Разве никто из вас не знает о существовании языка System_C ??? Что вы всё одно и то же толкуете? Может уже хватит спорить?