Комментарии 346
Важно не упустить «введение» (биты, байты, слова, системы счисления и т.п.). Тут как нельзя кстати подходит ассемблер (у вас он почему-то оказался в середине), а уже после него можно плавно и вдумчиво переходить на С.
Ну для того, чтобы разобраться в «битах, байтах, словах, системах счисления» ассемблер в общем-то необязателен. Он как раз выступит естественным продолжением после С, углубляя знания студента. Но начинать с C я бы не стал.
Зачем учить мертвые языки вроде Smalltalk и Ada мне вообще непонятно.
Зачем учить мертвые языки вроде Smalltalk и Ada мне вообще непонятно.
мертвые языкилишь в вашем воображении. ;-) Я ясно написал, где они используются. А изучть их можно затем, чтов них много лет назад было реализовано то, чего и сейчас нет в широко распространённых языках. Зная разные языки, вы сможете более или менее легко эмулировать недостающие возможности в вашем языке.
Написали, но живее они от этого не становятся. Почти нет сообщества, на stackoverflow ответов, я думаю, не найти, применить особо негде, скорость изучения из-за этого будет ниже. И что потом с этими знаниями делать? Для общего развития? Для изучения обширной темы «какими разными бывают языки программирования» не имеет смысла прыгать по всем языкам какие есть, лучше глубоко изучить два-три языка, реализующих различные парадигмы и теоретическую часть.
Кстати, а сколько времени вы отводите на изучение 8 (!) языков программирования? Отмечу, что среди них нет большинства самых востребованных из КДПВ — Java, C#, PHP, Python. Их потом дополнительно учить?
Кстати, а сколько времени вы отводите на изучение 8 (!) языков программирования? Отмечу, что среди них нет большинства самых востребованных из КДПВ — Java, C#, PHP, Python. Их потом дополнительно учить?
Вы думали или проверяли? Smalltalk on stackoverflow.com Ну и проверьте списки рассылки Squeak.
Кстати, учить Кобол хоть, наверно, и скучно, зато прибыльно. Софта на нём написано немерянно, и его нужно сопровождать/расширять, а знающих этот ЯП всё меньше и меньше.
Зачем учить мертвые языки вроде Smalltalk и Ada мне вообще непонятно.
Это как латынь. Никто не говорит, но все лингвисты учат:)
Ну что вы, латынь же учат далеко не только лингвисты же и даже как-то используют.
Ну если вы собираетесь разработывать новый язык, то посмотреть на Smalltalk может быть полезно. Но если вы хотите что-то такое запрограммировать — то вряд ли…
Но позвольте — http://www.cincomsmalltalk.com/main/successes, причём это не legacy, а новые программы, запущенные менее 10 лет назад.
На латыни говорят врачи и биологи
Биты, байты, слова, системы счисления, арифметика указателей — всё это и есть C. А вот ИМХО после — если еще останется желание залезть глубже в кроличью нору — asm.
Во введении имхо более важно понимать как работает парсер. Что такое блок ворожение оператор и тд. У меня товарищ у себя в городе делал интернет магазины на заказ, я ему минут 30 объяснял что доллар в jquery это просто функция.
Согласен с автором, чтобы всецело понимать процесс, которым занимаешься, нужно знать его основы. Другое дело, что, в частных случаях нет необходимости в понимании той, или иной, основы, наверное. Для того и есть программисты, которые знают, преимущественно один язык высокого уровня.
Для меня ВМКашная последовательность изучения канонична: Паскаль, Ассемблер, Си, Си++, Лисп, Пролог. Т.е. сначала нужно просто понять, что такое алгоритм. А потом идти от самых глубин. Потому что, нужно знать, как работает процессор. А изучая Си, нужно понимать, что это платформонезависимый Ассемблер. А дальше нужно ознакомиться с различными парадигмами. При этом Си++, мне кажется, знать необходимо.
Полностью C++ знать невозможно. Для его знания на более-менее приемлемом уровне необходимо не менее 2 лет практики.
Честно говоря, я не понимаю всего этого хейтерства вокруг Си++. Есть такая замечательная книга «С++ за 21 день». Не думаю, что мои знания выходят за рамки этой книги, даже с учетом года изучения в университете. При этом мне не попадалось реального кода, который был бы непонятен. Где же используется весь тот сложный Си++, о котором так много пишут на Хабре? Наверное, у меня мало опыта, но тот опыт, что есть, считаю весьма полезным. И он мне говорит, что Си++ не такой уж сложный.
Всё дело в том, что между «писать на C++» и «эффективно писать на C++» — огромная пропасть.
Ничто не мешает писать на C++ как на C с классами — но в этом случае я бы порекомендовал Java или C# — это уменьшило бы время разработки.
C++ сложен кучей нюансов, которые непременно вылезут в процессе разработки (привет, stackoverflow). Есть ещё C++11 и C++14, которые внесли много нового, в т.ч. и принципиально нового.
Ничто не мешает писать на C++ как на C с классами — но в этом случае я бы порекомендовал Java или C# — это уменьшило бы время разработки.
C++ сложен кучей нюансов, которые непременно вылезут в процессе разработки (привет, stackoverflow). Есть ещё C++11 и C++14, которые внесли много нового, в т.ч. и принципиально нового.
Вы библиотеками из Boost много пользовались или ограничились STL?
Буст настолько запутан?
Да, буст очень запутан. Если внутренности STL ещё можно худо-бедно читать, то в Boost лучше вообще не залезать, и вот почему:
1. Boost кроссплатформенен — мы увидим мешанину из директив препроцессора.
2. Boost позволяет эмулировать возможности новых стандартов C++ на старых компиляторах: например, лямбды, functional, move semantics, variadic templates. Какими костылями и какой ценой это было достигнуто, лучше не смотреть.
3. Время компиляции программы с Boost на порядок выше, чем на STL. У меня есть простой проект с Boost, который делает простую фильтрацию изображений, который компилируется 30 секунд, и аналогичный без Boost, который компилируется за секунду. Если есть возможность отказаться от буста — лучше отказаться.
Но в целом Boost не так плох. Boost можно рассматривать как передний край развития C++. Именно благодаря Boost C++ эволюционирует: вещи из Boost переходят в стандарт C++ и становятся частью STL.
1. Boost кроссплатформенен — мы увидим мешанину из директив препроцессора.
2. Boost позволяет эмулировать возможности новых стандартов C++ на старых компиляторах: например, лямбды, functional, move semantics, variadic templates. Какими костылями и какой ценой это было достигнуто, лучше не смотреть.
3. Время компиляции программы с Boost на порядок выше, чем на STL. У меня есть простой проект с Boost, который делает простую фильтрацию изображений, который компилируется 30 секунд, и аналогичный без Boost, который компилируется за секунду. Если есть возможность отказаться от буста — лучше отказаться.
Но в целом Boost не так плох. Boost можно рассматривать как передний край развития C++. Именно благодаря Boost C++ эволюционирует: вещи из Boost переходят в стандарт C++ и становятся частью STL.
Например вот
https://github.com/boostorg/dynamic_bitset/blob/develop/include/boost/dynamic_bitset/dynamic_bitset.hpp
В принципе все прочитать можно. Но местами оно переусложнено для портабельности и полноты API.
https://github.com/boostorg/dynamic_bitset/blob/develop/include/boost/dynamic_bitset/dynamic_bitset.hpp
В принципе все прочитать можно. Но местами оно переусложнено для портабельности и полноты API.
Приятно читать, однако.
А теперь взгляните вот сюда (отдельная библиотека boost.preprocessor):
https://github.com/boostorg/preprocessor/tree/develop/include/boost/preprocessor/tuple
Ну или сюда (кусок из boost.mpl):
https://github.com/boostorg/mpl/blob/develop/include/boost/mpl/aux_/preprocessed/msvc70/map.hpp
А теперь взгляните вот сюда (отдельная библиотека boost.preprocessor):
https://github.com/boostorg/preprocessor/tree/develop/include/boost/preprocessor/tuple
Ну или сюда (кусок из boost.mpl):
https://github.com/boostorg/mpl/blob/develop/include/boost/mpl/aux_/preprocessed/msvc70/map.hpp
Проблема C++ в том, что написать непонятный код на нем очень легко. Сделать непонятным код, который был понятным, добавив пару условий (и пару багов) — еще проще. А вот понять потом этот код и провести рефакторинг должным образом — задача другого порядка. В итоге без твердой руки в управлении проектом качества кода постепенно падает, особенно если «нужно быстрее».
Также вам передают привет простыни в описании ошибки при использовании шаблонов, проблемы с поддержкой современных фич в современных компиляторах, segmentation fault, толпы ifdef'ов, неявное приведение типов, heap/stack corruption и все прочее, что вы должны по долгу службы держать в голове, но не можете.
В итоге в каком-нибудь лохматом громоздком проекте, где многое писалось без использования STL просто потому, что тогда в нем были баги, это многое проще просто переписывать с нуля. Проблему, конечно, решает строгое следование гайдлайнам, но код, который попадает к вам в руки, часто про них не слышал.
Также вам передают привет простыни в описании ошибки при использовании шаблонов, проблемы с поддержкой современных фич в современных компиляторах, segmentation fault, толпы ifdef'ов, неявное приведение типов, heap/stack corruption и все прочее, что вы должны по долгу службы держать в голове, но не можете.
В итоге в каком-нибудь лохматом громоздком проекте, где многое писалось без использования STL просто потому, что тогда в нем были баги, это многое проще просто переписывать с нуля. Проблему, конечно, решает строгое следование гайдлайнам, но код, который попадает к вам в руки, часто про них не слышал.
А вы смотрели, например, во внутренности Boost'a?
«Научиться программировать за 21 день очень легко. Это как перевести стрелки часов. Солнечных. Через дорогу. На португальский.»
C++ очень похож на естественный язык. Сказать:«Я знаю полностью язык c++», — могут немногие, но это не беда, ведь в каждой «социальной группе» используется только его часть.Это эквивалентно правилу 2500 слов в английском языке. Если вы хотите не только «разговаривать» на языке, но и писать хорошие произведения, то нужно изучать С++ глубже. В культурном обществе употребление мата разрешается только спонтанно, а когда за речью не следят, матом разговаривают. Аналогично на с++ — одна и та же задача решается различными способами. Можно написть красиво и понятно, а можно ******(много мата). Однажды из-за проектной ошибки, один и тот же код писали разные програмисты разного уровня. Спектр решений на с++ меня шокировал, от чистого С до шаблонов.
Три года практики? Если кто-то говорит вам, что он знает С++ и у него нет очков и бороды, то он либо врет, либо просто не читал Александреску.
Это не то что бы ВМКашная последовательность, это каноничная. У нас единственно Ассемблер изучали после С++, до Лиспа с Прологом, как раз перед изучением «Организации ЭВМ».
Золотые слова: последовательность «сначала машинная арифметика, потом Ассемблер, а уж потом что-нибудь еще» не работает. Человеку надо сначала влезть на ступеньку, с любым языком — будь то хоть Паскаль, хоть, прости господи, Бейсик. Почувствовать, попробовать программирование на вкус, а уж потом нырять.
Т.е. сначала нужно просто понять, что такое алгоритм. А потом идти от самых глубин
Золотые слова: последовательность «сначала машинная арифметика, потом Ассемблер, а уж потом что-нибудь еще» не работает. Человеку надо сначала влезть на ступеньку, с любым языком — будь то хоть Паскаль, хоть, прости господи, Бейсик. Почувствовать, попробовать программирование на вкус, а уж потом нырять.
А вот я приверженец стратегии программирования, нацеленной на результат. Сначала ставим задачу, а затем с интересом её решаем, попутно изучая язык программирования. Переписывать через месяц код с новыми значениями — это нормально, это не трата времени, а естественный процесс обучения. А вот накапливать в течении года теорию и только потом приступить к практическую программированию — нереально.
Также я считаю, что не нужно смешивать следующие моменты:
1. Изучение архитектуры, логики и парадигм и технологий программирования.
2. Изучение синтаксиса языков.
3. Изучение алгоритмов и структур данных.
Мне становится грустно, когда я вижу студентов, которые без уверенного знания архитектуры и синтаксиса языка сразу лезут в алгоритмы.
Роль учебников для каждого индивидуальна. Я считаю чтение учебников скучным, для меня это пустая трата времени, т.к. теория без практики не откладывается. А если и использую учебники, то исключительно как документацию и справочный материал — впрочем, сейчас всё то же самое есть в интернете.
Многие, например, очень настойчиво советуют всякие модные книги по написанию совершенного кода и паттернам. Новичку эти книги будут вредны. Например, паттерн — это просто способ оформления кода с определённой логикой, а не готовое решение, которое обязательно нужно куда-нибудь воткнуть.
Ещё крайне важно знать английский язык. Потому что документация и обучающие примеры в подавляющем большинстве будут на английском.
Также я считаю, что не нужно смешивать следующие моменты:
1. Изучение архитектуры, логики и парадигм и технологий программирования.
2. Изучение синтаксиса языков.
3. Изучение алгоритмов и структур данных.
Мне становится грустно, когда я вижу студентов, которые без уверенного знания архитектуры и синтаксиса языка сразу лезут в алгоритмы.
Роль учебников для каждого индивидуальна. Я считаю чтение учебников скучным, для меня это пустая трата времени, т.к. теория без практики не откладывается. А если и использую учебники, то исключительно как документацию и справочный материал — впрочем, сейчас всё то же самое есть в интернете.
Многие, например, очень настойчиво советуют всякие модные книги по написанию совершенного кода и паттернам. Новичку эти книги будут вредны. Например, паттерн — это просто способ оформления кода с определённой логикой, а не готовое решение, которое обязательно нужно куда-нибудь воткнуть.
Ещё крайне важно знать английский язык. Потому что документация и обучающие примеры в подавляющем большинстве будут на английском.
Вы не поверите, но и мне в первую очередь важен результат. При условии, что вы уже профессионал. Но я против алчного желания мгновенного результата, когда человек лишь начал учёбу. В первое время изучения программирования результатом должно являться усвоение знаний. Начните уже воспринимать программирование как инженерное искусство и науку, а не как набор магических заклинаний.
Программирование — это никак не наука. Программист не производит знание, он производит код. Есть специальный термин «компьютерные науки», но это не программирование само по себе.
Искусство тоже мимо, только если код не экспонат. Но мы все к этому стремимся, да.
Программирование — это инженерное дело, то есть ремесло. А в ремесле очень важен практический опыт и умение соотнести затраты и результат, которое с ним приходит.
Искусство тоже мимо, только если код не экспонат. Но мы все к этому стремимся, да.
Программирование — это инженерное дело, то есть ремесло. А в ремесле очень важен практический опыт и умение соотнести затраты и результат, которое с ним приходит.
Вы путаете программирование и кодинг. Кодеры производят код, а программисты также как и физики, матиматики и тд ищут решение проблемм.
Какие хорошие слова!
Нет слова «кодинг» в русском языке. Есть программирование — создание программ, и кодирование — процесс написания программного кода. Соотносятся они примерно как постройка дома и перекладывание кирпичей. Мы все-таки говорим о первом.
Физики и математики создают научное знание, программисты создают программы.
Решением проблем занимается человек абсолютно любой профессии, не было бы проблемы — его бы не звали.
Физики и математики создают научное знание, программисты создают программы.
Решением проблем занимается человек абсолютно любой профессии, не было бы проблемы — его бы не звали.
Можете привести примеры работы «кодера»? Например, в типичной компании, разрабатывающей свой продукт. Что будут делать кодеры, и что будут делать программисты? Как этим понятиям соответсвуют Junior/Middle/Senior Developer из типичных вакансий?
Пока что я не уверен, что профессия «кодер» существует в 2016 году за пределами интернет форумов.
Пока что я не уверен, что профессия «кодер» существует в 2016 году за пределами интернет форумов.
Лично я «кодерами» называю программистов, способных писать код, но не обладющих развитым аналитическим мышлением.
Кодер не способен осилить Кнута или Кормена. Кодер не может оценивать эффективность алгоритмов, в результате чего программа может начать тормозить на пустом месте. Кодер не способен решать задачи, где требуется применение математических методов. Кодер не способен придумать или реализовать какой-нибудь алгоритм, и т.д. Идея, надеюсь, понятна.
Например, была у меня пара студентов: с одной стороны, уже подрабатывали разработчиками, с другой — не могли решить элементарные задачи. Одна студентка-разработчица под iOS вообще убила: за год не смогла написать свёртку изображений (функция-велосипед пишется за 5 минут), потому что не понимала, как. Искала готовые решения, пытаясь разобраться с OpenCV, но так и смогла этого сделать. Пришлось в итоге её выгнать.
Кодер не способен осилить Кнута или Кормена. Кодер не может оценивать эффективность алгоритмов, в результате чего программа может начать тормозить на пустом месте. Кодер не способен решать задачи, где требуется применение математических методов. Кодер не способен придумать или реализовать какой-нибудь алгоритм, и т.д. Идея, надеюсь, понятна.
Например, была у меня пара студентов: с одной стороны, уже подрабатывали разработчиками, с другой — не могли решить элементарные задачи. Одна студентка-разработчица под iOS вообще убила: за год не смогла написать свёртку изображений (функция-велосипед пишется за 5 минут), потому что не понимала, как. Искала готовые решения, пытаясь разобраться с OpenCV, но так и смогла этого сделать. Пришлось в итоге её выгнать.
Ну по вашей версии это тот же программист, просто хуже.
Мне больше интересна версия, где кодер и программист каким-то образом кардинально отличаются.
В англоязычных местах сегодня coder и programmer используются вполне себе взаимозаменяемо, и серьёзно топовые люди могут быть названы кодерами без всякой задней мысли.
Но в русскоязычных, почему-то, некотые (большинству пофиг, по-моему, они используют так же, как и англоязычные коллеги) умудрённые люди, программисты, любят это разграничение и используют, несмотря на отсутствие хоть какого-то чёткого определения и общепринятого понимания того, в чём всё-таки разница.
Возможно, это просто мой pet peeve, но такая двойственность (с одной стороны, говорят о том, как важно быть логичным и прочее, а с другой, без оглядки используют такое расплывчатое понятие) выглядит очень странно.
Напомнило TDD, почему-то. Часто сталкиваюсь, что в последнее время под «TDD» понимается тупо «пишите ли вы какие-нибудь тесты?».
Мне больше интересна версия, где кодер и программист каким-то образом кардинально отличаются.
В англоязычных местах сегодня coder и programmer используются вполне себе взаимозаменяемо, и серьёзно топовые люди могут быть названы кодерами без всякой задней мысли.
Но в русскоязычных, почему-то, некотые (большинству пофиг, по-моему, они используют так же, как и англоязычные коллеги) умудрённые люди, программисты, любят это разграничение и используют, несмотря на отсутствие хоть какого-то чёткого определения и общепринятого понимания того, в чём всё-таки разница.
Возможно, это просто мой pet peeve, но такая двойственность (с одной стороны, говорят о том, как важно быть логичным и прочее, а с другой, без оглядки используют такое расплывчатое понятие) выглядит очень странно.
Напомнило TDD, почему-то. Часто сталкиваюсь, что в последнее время под «TDD» понимается тупо «пишите ли вы какие-нибудь тесты?».
В русском и английском многие слова имеют разный смысл. Так, слова «менеджер» и «manager» имеют разный смысл, «девелопер» и «developer» — тоже и т.д. Это вполне естественная эволюция значений слов при заимствовании.
А для философов даже слова «детерминированный» и «определённый» имеют разный смысл.
А для философов даже слова «детерминированный» и «определённый» имеют разный смысл.
Мне больше интересна версия, где кодер и программист каким-то образом кардинально отличаются.Вы действительно не видите разницы? По-моему отличие между «кодером» и «программистом» — это всё то же самое различие между наукой и псевдонаукой, скажем алхимией и химией.
Алхимики ведь много интересных вещей изобрели. Больше того, многие учёные, заложившие фундамент современной науки ей увлекались. Тот же Ньютон вообще считал, что это — его самое главное дело в жизни, а Начала — это так, фигня, сочинение, которое Галлей его буквально заставил написать, блажь какая-то.
Но, тем не менее, это не помешало алхимикам толочься буквально на одном месте сотни лет! Просто потому что у тебя нет плана и объективного способа оценки результатов, то можно ходить кругами на одном месте годами.
Вот и описанная студентка-разработчица, судя по описанию, была занята поисками «философского камня». Что, глаз бешенного койота не подходит? Ну давай мочу доископаемого бизона попробуем. Вдруг да сработает…
И, к сожалению, очень часто современные курсы приводят вот именно к такому результату: человек не воспринимает компьютер как тупую числодробилку, которую он сам (при наличии достаточного времени, понятно) может разобрать на части снизу доверху и собрать обратно.
Для него выделение памяти — магия, сборка мусора — ещё большая магия, как хранятся и обрабатываются данные в используемых библиотеках — его не просто не интересует, он даже не догадывается, что ему может быть полезно этим поинтересоваться. Соответственно когда что-то не срабатывает — это не повод разобраться в том, что пошло не так, а повод отправиться на поиски бивней мамонта, которые магическим образом улучшат работу карбюратора.
К сожалению использование высокоуровневых языков поощряет формирование именно такого видение мира — потому их и опасно использовать для обучения программированию. При всём их практическом удобстве. Хорошие учителя могут эту проблему сделать не такой острой, но есть более простой способ: просто начать с какого-нибудь более низкоуровневого языка. Pascal, при всей своей архаичности, вполне годится: в нём нет никакой магии! Вы не поверите, но в Turbo Pascal User's Guide были не только подробно описаны функции Mark/Release но и было подробно описано — как устроена «куча» внутри, чем отличаются реализации «кучи» в версиях 5 и 6 и прочее.
Возможно, это просто мой pet peeve, но такая двойственность (с одной стороны, говорят о том, как важно быть логичным и прочее, а с другой, без оглядки используют такое расплывчатое понятие) выглядит очень странно.Не вижу ничего странного. Отличить науку от лженауки зачастую не так-то просто — но, тем не менее, одно — приносит нам новые, улучшенные процессоры, увеличивает «удои» и прочее, а второе — приводит примерно вот к такому.
> Вы действительно не видите разницы?
Разницу между чем и чем? Посмотрите сверху, там ещё один мой пост есть (над постом от DistortNeo) — я там как раз и попросил примеры кодера/программиста, чтобы понять, кто под ними подразумевался в данном конкретном случае, и разницу между ними.
Разницу между чем и чем? Посмотрите сверху, там ещё один мой пост есть (над постом от DistortNeo) — я там как раз и попросил примеры кодера/программиста, чтобы понять, кто под ними подразумевался в данном конкретном случае, и разницу между ними.
Я сталкиваюсь (на собеседованиях) с кодерами постоянно, но так как моя задача — их отсеять, то я понятия не имею чем они занимаются там, куда их берут на работу.
Но разница между программистом и кодером — довольно простая: задача кодера — написать код, задача программиста — создать программу. Кажется, что это одно и то же? Нет, нифига.
Написать код — это как в известной притче: «Если достаточно долго месить чан с перловой кашей, в синтаксическом мусоре можно рано или поздно узреть лик Ларри Уолла». Есть задача, мы её решаем и если всё сделано «как написано», то… «я лично пришиваю пуговицы — к пуговицам претензии есть?»
А написать программу — это другое. У тебя есть задача и заказчику пофигу что у тебя там не работает — IndexDB, OpenCV или ASP.NET. По-фи-гу. Ему нужно чтобы программа работала.
Бич программирования — это пресловутые протекающие абстракции. В проекте, над которым я сейчас работаю — сотни миллионов строк. Я работаю над маленьким компонентом (где-то с полмиллиона строк), но баги, которые у нас «выстреливают» (в смысле — нам на них жалуются)… примерно в половине случаев — на самом деле они не у нас, а где-то в другом месте — и мне нужно понять (хотя бы примерно) — где (и кто за эту часть отвечает). Потому что багов быть не должно, а то, что они не у нас — не означает, что нам на них можно «забить».
Так вот без хотя бы примерного понимания того, как все эти бесконечные слои абстракций работают — я этого сделать не могу. А люди, освоившие «на специальных курсах visual, научившиеся расставлять формочки и прочее» — даже не предствляют что делать если у них возникла проблема из-за того, что где-то в огромном стеке технологий, которые они используют, случилась очередная «протечка» и «что-то пошло не так». Вернее «представляют» и «делают» — «месят чан с перловой кашей». При этом одна и та же ошибка «загоняться вглубь» множеством разных способов — но будет неизменно «всплывать», так как люди, которые с ней борются не понимают не только откуда она проистикает, но и не имеют представления о том, что ответ на этот вопрос вообще существует!
«Почему сервер иногда отвечает за две минуты вместо двух сукунд?» «А фиг его знает — но мы watchdog поставили и перезапускаем его, когда он начинает подтомаживать».
Какое-то время это работает, но когда количество костылей переваливает за критическую массу… про историю с Windows Longhorn — слышали? А ведь там кодеров участвовало не так и много в процессе. Большинство разработчиков в Microsoft — неплохие профессионалы.
Но разница между программистом и кодером — довольно простая: задача кодера — написать код, задача программиста — создать программу. Кажется, что это одно и то же? Нет, нифига.
Написать код — это как в известной притче: «Если достаточно долго месить чан с перловой кашей, в синтаксическом мусоре можно рано или поздно узреть лик Ларри Уолла». Есть задача, мы её решаем и если всё сделано «как написано», то… «я лично пришиваю пуговицы — к пуговицам претензии есть?»
А написать программу — это другое. У тебя есть задача и заказчику пофигу что у тебя там не работает — IndexDB, OpenCV или ASP.NET. По-фи-гу. Ему нужно чтобы программа работала.
Бич программирования — это пресловутые протекающие абстракции. В проекте, над которым я сейчас работаю — сотни миллионов строк. Я работаю над маленьким компонентом (где-то с полмиллиона строк), но баги, которые у нас «выстреливают» (в смысле — нам на них жалуются)… примерно в половине случаев — на самом деле они не у нас, а где-то в другом месте — и мне нужно понять (хотя бы примерно) — где (и кто за эту часть отвечает). Потому что багов быть не должно, а то, что они не у нас — не означает, что нам на них можно «забить».
Так вот без хотя бы примерного понимания того, как все эти бесконечные слои абстракций работают — я этого сделать не могу. А люди, освоившие «на специальных курсах visual, научившиеся расставлять формочки и прочее» — даже не предствляют что делать если у них возникла проблема из-за того, что где-то в огромном стеке технологий, которые они используют, случилась очередная «протечка» и «что-то пошло не так». Вернее «представляют» и «делают» — «месят чан с перловой кашей». При этом одна и та же ошибка «загоняться вглубь» множеством разных способов — но будет неизменно «всплывать», так как люди, которые с ней борются не понимают не только откуда она проистикает, но и не имеют представления о том, что ответ на этот вопрос вообще существует!
«Почему сервер иногда отвечает за две минуты вместо двух сукунд?» «А фиг его знает — но мы watchdog поставили и перезапускаем его, когда он начинает подтомаживать».
Какое-то время это работает, но когда количество костылей переваливает за критическую массу… про историю с Windows Longhorn — слышали? А ведь там кодеров участвовало не так и много в процессе. Большинство разработчиков в Microsoft — неплохие профессионалы.
Вот так много слов и совсем нету смысла. Знаете что вы сказали? Что есть профессионалы и есть шарлатаны. Вот смысл вашего многословия.
Хотя я даже с этим не соглашусь — очень многие наработки алхимии легли в основу химии. Нет, ну правда. Люди накопили опыт, который потом удалось систематизировать. Не было бы опыта — и что бы химики систематизировали? Да если ещё и без помощи физиков?
Что там ваша бедная девочка с картинками — она хоть раз работала с таким классом задач? Ей помогали? Была ли достаточно дружелюбной атмосфера, чтобы она могла спросить сама? Нам ничего этого не известно. Интересно было бы уточнить у DistortNeo этот момент. Просто если «девочка студентка» впервые видит этот класс задач, а на её вопросы её посылают лесом — то она вполне естественно ничего не сделает. Это ж джун зелёнейший!
И вдруг появляются такие странные утверждения… джун имеет право не знать ни про выделение памяти ни про сборку мусора… первые полгода-год погружения в практические задачи. Вот чтобы вырасти из джуна (самое близкое к описываемому «кодеру») — да, требуется погружение, понимание и много чего ещё.
Использование высокоуровневых языков позволяет на стадии изучения алгоритмов игнорировать некоторые особенности реализации этих алгоритмов на исполняющей машине. А то, что после этого почему-то забывают людям дать остальные знания — язык-то точно не виноват. А низкоуровневые просто работают этаким «фильтром» — справится с концепциями и алгоритмами разом или нет… ну нет — значит «не программист».
PS иногда видел разделения программист/кодер в виде, присваивающем программисту менеджерские/аналитические/архитектурные задачи… видел даже экономические задачи реализации алгорима! Хотя программист, по большому счёту, менеджерскими и большей частью аналитических задач заниматься не должен. Т.е. проанализировать прикладную область, проанализировать инструментально-библиотечные возможности, безусловно, должен программист, а вот пообщаться с заказчиком и выяснить, а что же он хочет — это всё-таки задача аналитиков/менеджеров. Но некоторые почему-то накладывают на программиста умение договариваться с заказчиком…
PPS а вообще разделение программист/кодер появляется когда ну очень хочется почешить ЧСВ и под программиста закладывается то, чем пишущий по факту занимается.
Хотя я даже с этим не соглашусь — очень многие наработки алхимии легли в основу химии. Нет, ну правда. Люди накопили опыт, который потом удалось систематизировать. Не было бы опыта — и что бы химики систематизировали? Да если ещё и без помощи физиков?
Что там ваша бедная девочка с картинками — она хоть раз работала с таким классом задач? Ей помогали? Была ли достаточно дружелюбной атмосфера, чтобы она могла спросить сама? Нам ничего этого не известно. Интересно было бы уточнить у DistortNeo этот момент. Просто если «девочка студентка» впервые видит этот класс задач, а на её вопросы её посылают лесом — то она вполне естественно ничего не сделает. Это ж джун зелёнейший!
И вдруг появляются такие странные утверждения… джун имеет право не знать ни про выделение памяти ни про сборку мусора… первые полгода-год погружения в практические задачи. Вот чтобы вырасти из джуна (самое близкое к описываемому «кодеру») — да, требуется погружение, понимание и много чего ещё.
Использование высокоуровневых языков позволяет на стадии изучения алгоритмов игнорировать некоторые особенности реализации этих алгоритмов на исполняющей машине. А то, что после этого почему-то забывают людям дать остальные знания — язык-то точно не виноват. А низкоуровневые просто работают этаким «фильтром» — справится с концепциями и алгоритмами разом или нет… ну нет — значит «не программист».
PS иногда видел разделения программист/кодер в виде, присваивающем программисту менеджерские/аналитические/архитектурные задачи… видел даже экономические задачи реализации алгорима! Хотя программист, по большому счёту, менеджерскими и большей частью аналитических задач заниматься не должен. Т.е. проанализировать прикладную область, проанализировать инструментально-библиотечные возможности, безусловно, должен программист, а вот пообщаться с заказчиком и выяснить, а что же он хочет — это всё-таки задача аналитиков/менеджеров. Но некоторые почему-то накладывают на программиста умение договариваться с заказчиком…
PPS а вообще разделение программист/кодер появляется когда ну очень хочется почешить ЧСВ и под программиста закладывается то, чем пишущий по факту занимается.
джун имеет право не знать ни про выделение памяти ни про сборку мусора…
Серьезно? Можно мне другой глобус, пожалуйста?
Серьёзно. Другой глобус — это к Маску.
Вы забываете, что помимо языков с прямым управлением памяти бывают «managed» языки (java, javascript) и сессионные языки (php как минимум 4ая версия, более поздние не смотрел). Сессионным языкам, как можно логично предположить — болт положить на утечки, т.к. создать утечку, которая в пределах одной сессии сожрёт всю память — это надо очень постараться. Чуть ли не специально так писать придётся. В «managed» языках так же сложно писать так, что будут серьёзные утечки… Хотя на StackOverflow действительно реалистичная ситуация. Ну так она классическая «учебная».
В итоге получаем — знать по факту — не обязательно. Но только совсем-совсем зелёному (да не троллю! джуну!).
При дальнейшем развитии — ему придётся писать более сложные алгоритмы/обращаться к внешним ресурсам — вот здесь уже потребуется реальное понимание (а не то, что он вынес из ВУЗа/курсов), как это всё работает… он с этим должен будет разобраться (хотя и будет по прежнему джуном).
Вы забываете, что помимо языков с прямым управлением памяти бывают «managed» языки (java, javascript) и сессионные языки (php как минимум 4ая версия, более поздние не смотрел). Сессионным языкам, как можно логично предположить — болт положить на утечки, т.к. создать утечку, которая в пределах одной сессии сожрёт всю память — это надо очень постараться. Чуть ли не специально так писать придётся. В «managed» языках так же сложно писать так, что будут серьёзные утечки… Хотя на StackOverflow действительно реалистичная ситуация. Ну так она классическая «учебная».
В итоге получаем — знать по факту — не обязательно. Но только совсем-совсем зелёному (да не троллю! джуну!).
При дальнейшем развитии — ему придётся писать более сложные алгоритмы/обращаться к внешним ресурсам — вот здесь уже потребуется реальное понимание (а не то, что он вынес из ВУЗа/курсов), как это всё работает… он с этим должен будет разобраться (хотя и будет по прежнему джуном).
При чем здесь «есть другие языки»? Джун — это уровень квалификации — «начальный», т.е. человек без опыта, но с базовым набором знаний. Выделение памяти — в пределах первого курса любого ВУЗа. Если человек закончил ВУЗ по профилю и не знает про выделение памяти, то ему стоит выкинуть свой диплом. Если не учился и не знает, то он просто не обладает достаточной квалификацией, чтобы быть «джуном».
А если забыл, ввиду того что не пользовался этим C/C++ с того самого первого курса?.. Возьмём тот же JS — там ведь вообще выделять по сути не требуется (точнее это легко можно упустить, т.к. язык не требует каких-либо действий кроме присвоения).
Ну и знает хоть что-то о выделении памяти (в рамках того самого первого курса) и сколько-нибудь достаточно понимает — вещи очень разные. Я имел ввиду больше 2ое.
Ну и знает хоть что-то о выделении памяти (в рамках того самого первого курса) и сколько-нибудь достаточно понимает — вещи очень разные. Я имел ввиду больше 2ое.
А если забыл, ввиду того что не пользовался этим C/C++ с того самого первого курса?..
Это субъективно, конечно, но на мой взгляд, это некое базовое знание, примитив к тому же. Если отложить в сторону JS, то даже в той же Java понятно, что объект создается не из «пустоты». Более того, вопросы работы с памятью входят в экзамен на самый начальный сертификат.
Язык, которым мы пользуемся — это только инструмент, принцип работы кучи (условно) — это знание, которое не зависит от инструмента.
Ну и знает хоть что-то о выделении памяти (в рамках того самого первого курса) и сколько-нибудь достаточно понимает — вещи очень разные. Я имел ввиду больше 2ое.
Не знаю… нам давали это на первом курсе, в упрощенном виде (список свободных блоков, дробление, фрагментация и т.п.), но общее представление это дает всем — проще быть не может.
точнее это легко можно упустить, т.к. язык не требует каких-либо действий кроме присвоенияВ этом и проблема — легко упустить, а потому нужно постоянно об этом помнить. И тот факт, что явно освобождать память не требует не делает задачу проще — наоборот, это загоняет проблему «вглубь». Вам по прежнему нужно думать о том, чтобы все ссылки на более ненужные объекты обнулились, однако при этом у вас в коде даже нет «реперных точек», которые отмечают момент, где это происходит.
Ну и знает хоть что-то о выделении памяти (в рамках того самого первого курса) и сколько-нибудь достаточно понимает — вещи очень разные.Конечно. Проблема в том что «практический подход» призывает к тому, чтобы просто не думать о том, что память — это вообще ограниченный ресурс. А результат — у меня телефон, которые в 1000 раз мощнее чем компьютер, на котором я впервые увидел электронную почту, не всегда позволяет мне написать письмо в 100 килобайт размером (нет, я всё понимаю: Unicode и всё такое… но тексты подобного размера я редактировал на компьютере MSX-2 с памятью, на минуточку, 128K и процессором 3.58MHz, а мой телефон с памятью в гиг и процессором в 2GHz этого не может — это вообще в какие ворота?).
Ага, еще забавно было видеть примеры в учебниках по программированию вида «создадим простейший редактор текста. Вот у нас строковая переменная, читаем в нее файл...». И возникает внезапный прикол, что во-первых эта программа отожрет памяти по размеру файла, при том, что мы видим в каждый момент времени только «окно», а во-вторых, будет доооолго открывать этот файл. При этом какой-нибудь Volkov Commander откроет и отредактирует тот же 1Гб файл в реальном режиме.
При этом какой-нибудь Volkov Commander откроет и отредактирует тот же 1Гб файл в реальном режиме.Не откроет — это вам не МироМир.
Но, кстати, прообраз того самого Volkov Commander'а очень хорошо показывает к чему приводит бездумное применение модных технологий.
Кокретнее — в его 5й версии. Правда началось это с 4'й (где появился NCZIP), но апофигей — это 5я.
Она в 20 раз больше (притом что новых фич появилась горстка), но вот как раз NCEDIT объёмом почти в 200K — это финиш.
Дело в том, что как и в предыдущих версиях редактор показывает надпись во время загрузки текста — ну чтобы пользователь понимал что происходит.
Однако в версии 5.0 этот редактор — отдельный файл почти в 200K размером. При этом файлы, которые он может редактировать — по прежнему не могут быть больше 64K (тогда это считалось нормальным… Turbo Pascal 5.x тоже не умеет файлы больше 64K редактировать, к примеру).
Вот кем надо быть, чтобы задизайнить систему, которая не сообщает о загрузке с диска файла в 200K, но потом показывает процесс загрузки файла размером не более 64K? С прогресс-баром и прочими прелестями?
Не откроет
Значит, я путаю с каким-то другим файловым менеджером, но не суть, я думаю, довод понятен: окно против целого блока.
Кокретнее — в его 5й версии. Правда началось это с 4'й (где появился NCZIP), но апофигей — это 5я.
Ага, это было печально, когда он перестал влезать на дискету. ЕМНИП, 5ю версию переписали на другом языке, поэтому она такая пухлая.
Отвечаю про девочку-студентку. Цель заданий — избавиться от типичных ошибок джунов при работе с изображениями: они забывают про диапазон 0-255 и выход из него, иногда выходят за границы массива, в неправильном порядке обходят изображения (из-за чего падает скорость). Только после этого студентам можно ставить более-менее приличные задачи, имеющие хоть и небольшую, но практическую ценность.
Все студенты перед заданием получают теорию (что такое свёртка и как её считать), программу-болванку для работы с изображениями (загрузка и сохранение). Консультируем студентов с удовольствием. Дополнительных материалов (учебники, интернет) навалом. В чём проблема решить простую задачу? Но если человек не может хоть как-то решить даже простую задачу, то такой человек нам не нужен, и тратить своё время на него мы не видим смысла.
Все студенты перед заданием получают теорию (что такое свёртка и как её считать), программу-болванку для работы с изображениями (загрузка и сохранение). Консультируем студентов с удовольствием. Дополнительных материалов (учебники, интернет) навалом. В чём проблема решить простую задачу? Но если человек не может хоть как-то решить даже простую задачу, то такой человек нам не нужен, и тратить своё время на него мы не видим смысла.
DistortNeo в такой ситуации проблема, скорее всего, в том, что девочка по сути не программист. Согласно тому, что вы описали здесь идёт простейшее непонимание принципов работы компьютерных систем. Т.е. это равносильно ситуации «гуманитарий поизучал курсы программирования». Отсутствие базовых знаний и понимания.
Это НЕ кодер. Это неспециалист.
И у неё выбор простой — или стать-таки специалистом (вполне возможно, что она это может), или отказаться от этой специальности и заняться чем-то более релевантным её знаниям/умениям. В виду калечности её знаний — пусть становления специалистом её будет крайне затруднён. Т.е. «кодера» мы тут не нашли.
vlad72 Вопрос не в уровне. Есть специалисты, есть неспециалисты. В текущей дискусси кодеры не появлись. И от методики может зависеть качество специалиста и процент выхода годного продукта (специалистов). Я не знаком с методиками, которые из любого человека сделают специалиста. Есть методики которые неспособны сделать специалистом.
PS возьмём простой пример (действительно простой, если знать как работает компьютер и как работает js… единственное но — нахождение проблемы требует некоторой усидчивости): есть проблема — после нажатия shift+а (русская) в некотором поле поле перестаёт принимать символы.
Можете описать примерный процесс поиска?
Уточню — библиотек и js-кода много и всё это свалено в кучу (там ещё и говнокод местами… в общем-то проблема как раз в куске такого «щастя» и нашлась). Я (плохо знакомый с кодом — 3ый месяц в проекте) потратил чуть больше 5 часов на эту (в общем-то простую, но нудную) задачу, джуны-мидлы более-мене знакомые с проектом не знали с какой стороны к ней подступиться. Впрочем и здесь надо уточнить — у меня, судя по всему, самый сильный скилл по вебу (хотя я себя позиционирую больше как бекэндера, хотя и умею фуллстек)
Это НЕ кодер. Это неспециалист.
И у неё выбор простой — или стать-таки специалистом (вполне возможно, что она это может), или отказаться от этой специальности и заняться чем-то более релевантным её знаниям/умениям. В виду калечности её знаний — пусть становления специалистом её будет крайне затруднён. Т.е. «кодера» мы тут не нашли.
vlad72 Вопрос не в уровне. Есть специалисты, есть неспециалисты. В текущей дискусси кодеры не появлись. И от методики может зависеть качество специалиста и процент выхода годного продукта (специалистов). Я не знаком с методиками, которые из любого человека сделают специалиста. Есть методики которые неспособны сделать специалистом.
PS возьмём простой пример (действительно простой, если знать как работает компьютер и как работает js… единственное но — нахождение проблемы требует некоторой усидчивости): есть проблема — после нажатия shift+а (русская) в некотором поле поле перестаёт принимать символы.
Можете описать примерный процесс поиска?
Уточню — библиотек и js-кода много и всё это свалено в кучу (там ещё и говнокод местами… в общем-то проблема как раз в куске такого «щастя» и нашлась). Я (плохо знакомый с кодом — 3ый месяц в проекте) потратил чуть больше 5 часов на эту (в общем-то простую, но нудную) задачу, джуны-мидлы более-мене знакомые с проектом не знали с какой стороны к ней подступиться. Впрочем и здесь надо уточнить — у меня, судя по всему, самый сильный скилл по вебу (хотя я себя позиционирую больше как бекэндера, хотя и умею фуллстек)
> Я не знаком с методиками, которые из любого человека сделают специалиста.
Но зато есть методики, как из потенциального специалиста сделать законченного неспециалиста ))
Но зато есть методики, как из потенциального специалиста сделать законченного неспециалиста ))
В такой ситуации проблема, скорее всего, в том, что девочка по сути не программист. Согласно тому, что вы описали здесь идёт простейшее непонимание принципов работы компьютерных систем. Т.е. это равносильно ситуации «гуманитарий поизучал курсы программирования». Отсутствие базовых знаний и понимания.Почему не специалист? Это — уровень 90% «разработчиков на 1С» и где-то половины «натягивателей шкурок на CMS». Они сами — считают себя программистами. Ну потому что программы-то они пишут :-)
Это НЕ кодер. Это неспециалист.
Есть специалисты, есть неспециалисты. В текущей дискусси кодеры не появлись.А кто тогда появился? Как этих людей назвать? Они «что-то знают» про CSS, JS, HTML, пишут какой-то код, получают за это зарплату, некоторые работодатели, надо полагать, довольны (иначе они не приходили бы к нам на собеседования, а либо научились бы программировать, либо «переквалифицировались бы в управдомы»). Кто они? Как их назвать?
Можете описать примерный процесс поиска?Ну как я могу описать то, чего я не делал? Понятно что чудес в мире не бывает, значит нажатие этого самого shift+а изменило что-то в документе. Либо DOM, либо состояние какой-нибудь JS переменной. То есть вначале нужно сравнить DOM «до» и «после» нажатия. Если он поменялся (скажем поле поменяло аттрибуты), то нужно смотреть — кто и когда и поменял, если нет — значит у нас где-то кто-то перехватывает event'ы и нужно искать — кто и где. Если вы за 5 часов проблему нашли, то, надо полагать в внутренности браузера не лазили, так что можно считать, что ошибок в реализации браузера нету и, скорее всего, кто-то где-то неправильно обрабатывает сообщения и, получив, «чужое» сообщение блокирует не то поле, которое хотел. Может страничка пытается сама поиск реализовать (чтобы по Ctrl+F не открывалось окошко поиска — это, конечно, перепутать Ctrl+F и Shift-А непросто… но я ещё и не то видел) или ещё чего-нибудь в этом же духе.
В общем не очень понятно — чего вы хотели увидеть… и не очень понятно почему джуниор должен в подобных местах «в ступор» впадать…
>Знаете что вы сказали? Что есть профессионалы и есть шарлатаны. Вот смысл вашего многословия.
Вопрос состоит не в уровне развивающего программиста, а в том, что одна методика обучения готовит людей, готовых к развитию, а другая просто информированных на некоем уровне и теряющихся при новых для него проблемах.
Вопрос состоит не в уровне развивающего программиста, а в том, что одна методика обучения готовит людей, готовых к развитию, а другая просто информированных на некоем уровне и теряющихся при новых для него проблемах.
Я придерживаюсь версии, что «кодер» — это сленговое название техника-программиста по классификаторам профессий (выпускник техникума или колледжа), а «программист» — инженер-программист (выпускник вуза). Понятно, что некоторые выпускники вузов даже кодером работать не смогут, а кто-то и без формального образования как инженер большинство выпускников за пояс заткнёт, но в целом по квалификационным требованиям можно посмотреть чем отличается «кодер» от «программиста». Базовое же различие, по-моему, «кодер» решает технические задачи, а «программист» — производственные техническими средствами.
А что именно (какой ньюанс) не понимала студентка и какими подходами Вы пользовались для объяснений?
Обожэмой, кодеросрач, ўсё пропало…
Программист рисует UML и задаёт алгоритмы которые используются конкретными методами. Кодер переносит это всё в код.
А если от UML тошнит, да и вообще графика не особо воспринимается?
Что простите? попросили привести пример что делают кодеры и программисты
UML как правило рисует не программист. Это задача или архитектора или технического писателя. Программиста обычно заставить рисовать эти штуки можно разве что под угрозой расстрела или хотя бы пыток.
Собственно правда заключается в том, что программист и кодер — разные профессии. То есть совсем.
Грубо говоря там, где у вас создание программ поставлено на поток (как выпечка пирожков или Биг Маков) — там у вас есть архитекторы и кодеры. Там, где делаются штучные изделия (как в любом, пусть даже маленьком, ресторанчике) — им делать нечего.
И тут, также как с поварами: хороший повар может «дорасти» до создателя новых рецептов очередных гамбургеров (хотя немногим это понравится), но человек, засовывающий картошку во фритюрницу — поваром никогда не станет. Хотя может стать менеджером…
P.S. И тут также, как с фастфудом — вопрос о том, нужен ли он вообще, в принципе — будет, наверное, обсуждаться вечно, но на практике — он существует, а потому существуют и кодеры.
Грубо говоря там, где у вас создание программ поставлено на поток (как выпечка пирожков или Биг Маков) — там у вас есть архитекторы и кодеры. Там, где делаются штучные изделия (как в любом, пусть даже маленьком, ресторанчике) — им делать нечего.
И тут, также как с поварами: хороший повар может «дорасти» до создателя новых рецептов очередных гамбургеров (хотя немногим это понравится), но человек, засовывающий картошку во фритюрницу — поваром никогда не станет. Хотя может стать менеджером…
P.S. И тут также, как с фастфудом — вопрос о том, нужен ли он вообще, в принципе — будет, наверное, обсуждаться вечно, но на практике — он существует, а потому существуют и кодеры.
Думаю, на этом обсуждение можно закончить ))
Собственно правда заключается в том, что программист и кодер — разные профессии. То есть совсем.
но на практике — он существует, а потому существуют и кодеры.
Из ваших описаний я по-прежнему склонен считать, что вы просто называете кодером плохого/безответственного/начинающего программиста, который плохо знает теорию, не разбирается в системе и не очень умеет/стремится работать самостоятельно и брать инициативу:
А люди, освоившие «на специальных курсах visual, научившиеся расставлять формочки и прочее» — даже не предствляют что делать если у них возникла проблема из-за того, что где-то в огромном стеке технологий, которые они используют, случилась очередная «протечка» и «что-то пошло не так».
…
«Почему сервер иногда отвечает за две минуты вместо двух сукунд?» «А фиг его знает — но мы watchdog поставили и перезапускаем его, когда он начинает подтомаживать».
…
А ведь там кодеров участвовало не так и много в процессе. Большинство разработчиков в Microsoft — неплохие профессионалы.
Если я не прав, то можете сказать, в чём разница между плохим программистом и кодером?
Если я не прав, то можете сказать, в чём разница между плохим программистом и кодером?В требованиях.
Как было написано на самом верху:
Кодеры производят код, а пирограммисты также как и физики, матиматики и тд ищут решение проблемм.Если у вас производство программ поставлено на поток и рисуются все эти UML-схемы и прочее, то у вас появляется в цепочке ниша для «условного индуса», которые «кодит». Ему снаружи приходит список фукций — и он их реализует. К каждой функции приложены граничные условия — и от успешно преобразует текстовое представление в набор тестов для JUnit или gTest.
Собственно UML-диаграммы — это как лакмусовая бумажка: если они у вас являются частью производственного процесса и рисуются для всех частей системы (и не как что-то высокоуровневое для презентации уже после того, как система написана) — то и кодеры у вас, почти наверняка, есть тоже. Обратное, впрочем, не совсем верно, так как кроме UML есть несколько других способов донести эту информацию от «архитектора» до «кодера».
Кодера совершенно не интересует и не волнует существование в природе таких вещей как алгоритмы, кеши и прочее — и от него этого не требуют. Вообще. Его задача — перевести набор «картинок» в код. Всё. Если полученный код тормозит или неправильно работает — это ошибка «архитектора», в слудующий раз будет ставить задачу детальнее…
Java, в частности, очень сильно заточена под эту категорию — и осторожность во введении новых фич, во-многом, связана с тем, что возрастут затраты на кодинг, так как не все кодеры смогут освоить все эти новомодные лямбды и навставляют
var где только смогут, так что потом в этом коде сам чёрт ногу сломит.Да, наверное, даже «плохой» программист может справиться с обязанностями кодера. Зависит от того, насколько он «плох», конечно, но может. Обратное — неверно.
> Кодера совершенно не интересует и не волнует существование в природе таких вещей как алгоритмы, кеши и прочее
Неужели на UML прорисовывают все детали алгоритмов, вплоть до последнего бита в кэшах??
Неужели на UML прорисовывают все детали алгоритмов, вплоть до последнего бита в кэшах??
Не прорисовывают. Потому созданные таким образом приложения часто безбожно тормозят. Но если заказчика это устраивает…
Ну вот видите, вы тоже приходите к тому, что ваш образ «кодера» — это всего лишь программист, у которого проблемы с качеством кода.
А человек на стойке в Макдональдсе — просто плохой повар, ага.
Кодер — это человек, умеющий перерабатывать тексты в код и всё. Большо от него — ничего не требуется. Соответственно дизайн приложения должен быть таков, чтобы накосячить было нельзя. Обычно это обозначает что приложение будет тормозить потому что в нём будет много «лишних» слоёв, но каждый слой будет «покрыт тестами» настолько, что даже при условии что его писал «индус» — вся конструкция вместе — будет работать.
Та же самая ситуация, что и гамбургерами, собственно: дизайн приводится к такому виду, чтобы даже если человек ничего не знающий о кулинарии породил что-то, что можно есть. То, что там ну будет места импровизации и что это никтогда не будет заслуживать эпитета «вау» — неважно. Важно, чтобы никто не отравился.
Кодер — это человек, умеющий перерабатывать тексты в код и всё. Большо от него — ничего не требуется. Соответственно дизайн приложения должен быть таков, чтобы накосячить было нельзя. Обычно это обозначает что приложение будет тормозить потому что в нём будет много «лишних» слоёв, но каждый слой будет «покрыт тестами» настолько, что даже при условии что его писал «индус» — вся конструкция вместе — будет работать.
Та же самая ситуация, что и гамбургерами, собственно: дизайн приводится к такому виду, чтобы даже если человек ничего не знающий о кулинарии породил что-то, что можно есть. То, что там ну будет места импровизации и что это никтогда не будет заслуживать эпитета «вау» — неважно. Важно, чтобы никто не отравился.
Вот вы пишете, что кодер переводит набор картинок в код. Так или иначе, какие-то решения по написанию кода он в процессе этой деятельности принимать неизбежно будет (иначе «набор картинок» или любая другая спецификация, по которой он работает, не оставляя никакой свободы интерпретации, должна быть полной, непротиворечивой и исчерпывающей и, как следствие, функционально эквивалентной готовой программе, зачем тогда «кодер» — бери да запускай). Например, решения какого уровня кодер принимает, а какого — не принимает?
Любые решения, требующие знания чего-то, кроме, собственно, языка программирования — принимает дизайнер. Если нужна сортировка пузырьком — ссылка на описание этой сортировки в википедии. Нужна база данных? Описание этой базы данных — картинка со списком таблиц и связями.
Названия переменных — да, оставляются на усмотрение разработчика. Тех, которые
То, что во многих случаях дизайн будет неоптимален (ну не может дизайнер многие вещи правильно спроектировать без экспериментов и замеров производительности!) — никого не волнует, главное, чтобы патологических случаев не было с с замедлением (или там портеблением памяти) не в 10-20-100 раз по сравнению с тем, что реально нужно, а в произвольное, сколь угодно большое число раз (а вот тут — уже всякие кеши учитывать необязательно).
Потому что задача — не сделать «лучше, чем у других», а «сделать, потратив на это XX часов дизайнера и YY часов кодера». Предсказуемость — важнее качества результата.
Вы не поверите — сколько такого говнософта в мире создаётся в самых разных областях…
Названия переменных — да, оставляются на усмотрение разработчика. Тех, которые
private, конечно.То, что во многих случаях дизайн будет неоптимален (ну не может дизайнер многие вещи правильно спроектировать без экспериментов и замеров производительности!) — никого не волнует, главное, чтобы патологических случаев не было с с замедлением (или там портеблением памяти) не в 10-20-100 раз по сравнению с тем, что реально нужно, а в произвольное, сколь угодно большое число раз (а вот тут — уже всякие кеши учитывать необязательно).
Потому что задача — не сделать «лучше, чем у других», а «сделать, потратив на это XX часов дизайнера и YY часов кодера». Предсказуемость — важнее качества результата.
Вы не поверите — сколько такого говнософта в мире создаётся в самых разных областях…
> Любые решения, требующие знания чего-то, кроме, собственно, языка программирования — принимает дизайнер.
> Если нужна сортировка пузырьком — ссылка на описание этой сортировки в википедии.
Тогда кодеров согласно вашему пониманию вообще практически не существует в природе. В любой, даже самой забюрократизированной конторе, где разработчик не в курсе, что за программу он пишет (такие реально существуют, впрочем, вы наверняка знаете), устройство внутренней логики остаётся на откуп разработчику. Дизайнер даёт общую спецификацию, что на входе, что на выходе, а уж как оно там должно быть внутри реализовано, решает сам разработчик.
И вот именно по этой причине и появляется говнософт. Если бы было как вы пишите, чтобы при разработке программ всё вплоть до алгоритмов сортировки задавалось бы проектировщиками, говнософта было бы намного меньше :)
> Если нужна сортировка пузырьком — ссылка на описание этой сортировки в википедии.
Тогда кодеров согласно вашему пониманию вообще практически не существует в природе. В любой, даже самой забюрократизированной конторе, где разработчик не в курсе, что за программу он пишет (такие реально существуют, впрочем, вы наверняка знаете), устройство внутренней логики остаётся на откуп разработчику. Дизайнер даёт общую спецификацию, что на входе, что на выходе, а уж как оно там должно быть внутри реализовано, решает сам разработчик.
И вот именно по этой причине и появляется говнософт. Если бы было как вы пишите, чтобы при разработке программ всё вплоть до алгоритмов сортировки задавалось бы проектировщиками, говнософта было бы намного меньше :)
Почему «дизайнер»? Design != дизайн.
To design = разрабатывать, designer в этом контексте = разработчик. Инженер в конце концов.
[англ. design — проектировать, конструировать] — художественное конструирование предметов, изделий; создание эстетического облика среды.
To design = разрабатывать, designer в этом контексте = разработчик. Инженер в конце концов.
> Почему «дизайнер»
Потому что митап, колл, кастомер и т.д. Мода такая.
Потому что митап, колл, кастомер и т.д. Мода такая.
Неа, мимо. «Митап», «колл» — правильные американизмы, англицизмы. «Дизайн» в данном контексте — неверно используемое слово. Примерно как «мы продаем нашу экспертизу». Т.е. слово-калька уже используется в языке, и имеет иной смысл.
> «Митап», «колл» — правильные американизмы, англицизмы.
А по-моему, и то, и другое — барахло, которое тянется в язык лишь потому, что фраза «Мы проводим митап» кажется солиднее, чем «Мы проводим встречу». На этом фоне назвать дизайнером проектировщика ничуть не хуже. Слово «дизайн» в его классическом понимании в русский язык было притянуто тоже не слишком давно, в конце 1980-х.
А по-моему, и то, и другое — барахло, которое тянется в язык лишь потому, что фраза «Мы проводим митап» кажется солиднее, чем «Мы проводим встречу». На этом фоне назвать дизайнером проектировщика ничуть не хуже. Слово «дизайн» в его классическом понимании в русский язык было притянуто тоже не слишком давно, в конце 1980-х.
На этом фоне назвать дизайнером проектировщика ничуть не хуже.
Хуже. Вы не понимаете сути претензии.
Слово «дизайн» в его классическом понимании в русский язык было притянуто тоже не слишком давно, в конце 1980-х.
Тем не менее, слово «дизайн» уже вошло в язык. Нравится вам это или нет. И имеет оно определенный смысл, как и слово «экспертиза», например. Употреблять «дизайнер» в значении «разработчик» или «экспертиза» вместо «опыт, мастерство, знания» — неверно, это ошибка. Такая же, как если назвать табуретку арбузом. Употребление «колл» — просто пижонство, но не ошибка.
> Употреблять «дизайнер» в значении «разработчик» или «экспертиза» вместо «опыт, мастерство, знания» — неверно, это ошибка.
Вы уж извините, но я все равно еще немного позанудствую :) В язык можно привлекать как новые слова, так и новые значения для существующих слов. Не существуют какие-либо правила, которые одобряют первое и запрещают второе. Всё это субъективно. Поэтому никакой ошибки тут нет. Тем более что «дизайнер» уже достаточно давно в русском языке встречается и в значении «конструктор». До «разработчика» уже немного осталось.
Вы уж извините, но я все равно еще немного позанудствую :) В язык можно привлекать как новые слова, так и новые значения для существующих слов. Не существуют какие-либо правила, которые одобряют первое и запрещают второе. Всё это субъективно. Поэтому никакой ошибки тут нет. Тем более что «дизайнер» уже достаточно давно в русском языке встречается и в значении «конструктор». До «разработчика» уже немного осталось.
Ну во-первых митап это != «встреча». Это слово привносит дополнительный смысл — встреча по проекту/обсуждение текущих наработок/… Т.е. в вашем случае «мы проводим встречу по проекту» будет верной расшифровкой вашей первой фразы, а вот ваша расшифровка — не корректна. Аналогично с коллом — он привносит некоторые дополнительные смыслы. Вполне возможно, отсутствующие в оригинальном языке. Ваше же употребление дизайн пытается сменить устоявшееся значение у существующих слов — это более сложный я тяжёлый процесс… и эффектинов происходить он может только в условиях обозначившегося несоответствия изначального смысла. Т.е. технически-то оно возможно, но будет восприниматься более «в штыки», чем привлечение новых слов.
> Это слово привносит дополнительный смысл — встреча по проекту/обсуждение текущих наработок
А ещё есть такое слово как «собрание» :)
> Аналогично с коллом — он привносит некоторые дополнительные смыслы.
А тут соглашусь с MacIn, это слово привносит дополнительный вкус пижонства.
Помню лет двадцать назад преподавателя по экономике, она так любила выражаться, у неё вместо «задач» были «таски», а вместо определений «дефиниции». Это и тогда смотрелось пижонством, и в общем-то и сейчас.
А ещё есть такое слово как «собрание» :)
> Аналогично с коллом — он привносит некоторые дополнительные смыслы.
А тут соглашусь с MacIn, это слово привносит дополнительный вкус пижонства.
Помню лет двадцать назад преподавателя по экономике, она так любила выражаться, у неё вместо «задач» были «таски», а вместо определений «дефиниции». Это и тогда смотрелось пижонством, и в общем-то и сейчас.
> Вы не поверите — сколько такого говнософта в мире создаётся в самых разных областях…
Почему не поверю, я сам так часто пишу, только вместо «дизайнера» обычно собственная богатая фантазия, а вместо «кодера» — интерпретатор Питона с библиотеками. Нужна сортировка — вызвать функцию sort/sorted, даже не заботясь, что там внутри, пузырёк или квиксорт. Нужна база данных — прикрутить левой ногой какой-нибудь ORM, даже не факт, что подходящий под задачу, а тот, который первый в голову придёт. Об оптимальности и речи не идёт — работать такое поделие будет в 10-20-100 раз медленнее даже наивного кода на С++. Ни до какого продакшена, правда, оно и близко не доживает — после нескольких итераций либо выкидывается за ненадобностью, либо перепиливается уже более-менее по-уму.
Почему не поверю, я сам так часто пишу, только вместо «дизайнера» обычно собственная богатая фантазия, а вместо «кодера» — интерпретатор Питона с библиотеками. Нужна сортировка — вызвать функцию sort/sorted, даже не заботясь, что там внутри, пузырёк или квиксорт. Нужна база данных — прикрутить левой ногой какой-нибудь ORM, даже не факт, что подходящий под задачу, а тот, который первый в голову придёт. Об оптимальности и речи не идёт — работать такое поделие будет в 10-20-100 раз медленнее даже наивного кода на С++. Ни до какого продакшена, правда, оно и близко не доживает — после нескольких итераций либо выкидывается за ненадобностью, либо перепиливается уже более-менее по-уму.
В принципе государственные российские классификаторы разделяют инженера-программиста (выпускник вуза в общем случае), техника-программиста (выпускник техникума-колледжа) и просто программиста (выпускник пту-лицея, а то и просто средней школы). По образовательным стандартам теоретических знаний больше, конечно, у инженера.
> Собственно правда заключается в том, что программист и кодер — разные профессии. То есть совсем.
Я вам возражу :) Нет такой профессии «кодер». В принципе нет. Это просто обидное словечко, которое придумали те программисты, которые имеют творческую составляющую в своей работе, чтобы обозначать тех программистов, которые этой творческой составляющей не имеют (либо в силу умственных неспособностей, либо в силу унылых должностных обязанностей).
Я вам возражу :) Нет такой профессии «кодер». В принципе нет. Это просто обидное словечко, которое придумали те программисты, которые имеют творческую составляющую в своей работе, чтобы обозначать тех программистов, которые этой творческой составляющей не имеют (либо в силу умственных неспособностей, либо в силу унылых должностных обязанностей).
> Собственно правда заключается в том, что программист и кодер — разные профессии
И то и другое не является профессией, это описание рабочей деятельности людей.
И то и другое не является профессией, это описание рабочей деятельности людей.
Ремесло — Это написание отчётов в 1C, а создание системы управления грузовыми перевозками, авиарейсами или производством — сложная инженерная работа в которой иной раз изобретаются новые концепции и парадигмы программирования.
Ремесло — Это...Вы так говорите, будто это что-то плохое. Между тем, хороших ремесленников куда как меньше, чем требуется.
Написание отчётов в 1C вполне может потребовать труд нескольких человек, если отчет строится неприлично долго и нужно оптимизировать обработку данных. Управления грузовыми перевозками/производством некоторые умельцы решают таблицей и парой формочек в каком-нибудь Oracle Forms. Вопрос масштаба и конкретной задачи. И то, и другое — это программирование.
Что вы пытаетесь доказать? Что есть программисты и Программисты? Вы из этих?
Что вы пытаетесь доказать? Что есть программисты и Программисты? Вы из этих?
Вообще, я с вами не соглашусь. Ремесло от творчества в программировании отличается не сутью задачи, а тем, сколько раз вы её уже решали. Делая свой первый отчет в 1С, вы точно так же первопроходец. Делая стопятидесятый, вы ремесленник. Делая свою первую систему логистики, вы тоже изучаете для себя новую отрасль, собираете материалы по автоматизации (если вам повезло работать «самостоятельным» программистом, а не винтиком большой девелоперской машины) и т.д.
А для следующего клиента вы уже будете идти знакомым путем, и это уже тоже будет ремесло.
А для следующего клиента вы уже будете идти знакомым путем, и это уже тоже будет ремесло.
Не путайте инженерное дело и ремесло. А инженерное дело — отрасль научно-технической деятельности.
Совсем не обязательно ставить целью результат, имеющий какую-то практическую ценность. Плюс к этому теория без применения на практике очень тяжело запоминается, а если и запоминается, то быстро улетучивается. А вот если в качестве «результата» поставить, например, решалку квадратных уравнений (с комплексными числами и вырожденными случаями), крестики-нолики или морской бой (возможно, с последующим добавлением сетевой игры), то по идее обучение должно стать проще и эффективнее, ибо теория сразу применяется на практике. А в связи с отсутствием практической ценности (кроме собственно обучения) и относительной простотой задачек всё выкинуть и переписать с нуля, набравшись опыта, будет совсем не жалко. И я сам так изучаю новые языки и технологии)
Ну да, у меня сначала был тетрис, потом домино (компьютер меня даже обыгрывал), потом творческий подход к решению задач по обработке изображений в университете (дано задание, решать можно любыми средствами), затем — полноценный бот для онлайн-игры, имеющий сервер обновления и около 50-100 пользователей, ну и потом просто работа.
Для новичков как раз нужны книги для новичков («за 21 день», «на примерах» и т.д.).
Сложно представить, что кто-то может научиться программировать по толстому учебнику, приправив его ещё чтением стандарта и справочника по библиотеке.
Имхо, так можно учить 3-й, 4-й язык (я сам так C# когда-то давно изучал по 2 книгам Шилдта + стандарт), но не первый.
Сложно представить, что кто-то может научиться программировать по толстому учебнику, приправив его ещё чтением стандарта и справочника по библиотеке.
Имхо, так можно учить 3-й, 4-й язык (я сам так C# когда-то давно изучал по 2 книгам Шилдта + стандарт), но не первый.
С толстыми книгами есть другая проблема — они могут пытаться быть настолько всеобъемлющими, что хорошая их часть — банальщина и «из пустого в порожнее».
Мне вот понравилась книга «Core Java for the Impatient», например. Я не могу адекватно оценить т.к. много не работал (пока) с Java и многого не знаю, но подобное выглядит гораздо лучше, чем несколько книг от того же автора, где всё разжёвывают с самых нулей.
Мне вот понравилась книга «Core Java for the Impatient», например. Я не могу адекватно оценить т.к. много не работал (пока) с Java и многого не знаю, но подобное выглядит гораздо лучше, чем несколько книг от того же автора, где всё разжёвывают с самых нулей.
Это тоже. Когда уже знаешь несколько языков, наступает момент, когда читать в очередной раз про float vs double или про видимость методов и т.д. становится невыносимо скучно )
Серия «для нетерпеливых» уже лучше, но если оценивать «Scala for the Impatient», которую я недавно читал, то там тоже банальщины выше крыши.
Впрочем, есть и более хардкорные способы изучения, например: Learn X in Y minutes + документация по стандартной библиотеке (читать не целиком, а по мере необходимости).
Серия «для нетерпеливых» уже лучше, но если оценивать «Scala for the Impatient», которую я недавно читал, то там тоже банальщины выше крыши.
Впрочем, есть и более хардкорные способы изучения, например: Learn X in Y minutes + документация по стандартной библиотеке (читать не целиком, а по мере необходимости).
Согласна с автором, Си очень удобный язык для изучения азов программирования, правда нам в универе давали сначала функциональный CAML, а потом уже к Си переходили. Мотивировалось это тем, что большинство студентов до универа программированием вообще не занимались и если им сразу дать Си, то ничего компилироваться не будет. Не знаю, насколько верно это утверждение, правда.
Как он может быть удобным, если даже для «Hello, World!»-программы надо написать (а преподавателю объяснять (обычно словами «Так надо. Потом поймёте.»)) кучу неочевидных (а для начинающего — неестественных) вещей?
Так на любом языке для «Hello, World!» нужно программный код писать. А удобство Си в том, что на основе его синтаксиса построен синтаксис огромного количества языков программирования. Плюс, как уже говорилось в статье, в языке достаточно немного основных ключевых слов, но при этом на нем можно написать много чего благодаря множеству уже существующих библиотек и системных функций.
> но при этом на нем можно написать много чего благодаря множеству уже существующих библиотек и системных функций.
Ага, попробуйте на C заменить в строке все вхождения одной подстроки на другую подстроку произвольной длины :)
Ага, попробуйте на C заменить в строке все вхождения одной подстроки на другую подстроку произвольной длины :)
Это не сложнее, чем в любом другом языке. Просто берете что-нибудь вроде https://github.com/stephenmathieson/str-replace.c и пользуетесь.
Неа, в том-то и дело, что «в любом другом языке» (ну, не в любом, конечно, но в подавляющем большинстве используемых ныне) эта типовая задача, и куча других типовых задач решаются стандартными библиотеками. А программист на С вынужден или писать велосипед или искать чужие велосипеды, к тому же тратить время на выяснение, можно ли чужому велосипеду доверять.
Ну, блин. Доверять чему-то придется. На стадии прототипа или учебной задачи можно доверять вообще всему, а нервничать о производительности/корректности опосля.
У меня вот недоверие к пресловутым стандартным библиотекам. Покажите мне, как на этих самых языках с библиотеками решить весьма тривиальную задачу — декомпозиция/нормализация utf-8 строки с выхлопом опять же в utf-8 — чтобы идентично работало, например, в java, c++, as3, js. Т. е. чтобы строки на естественном языке, обработанные в совершенно разных средах, можно было корректно сравнивать, считать хеши от них и тд.
У меня вот недоверие к пресловутым стандартным библиотекам. Покажите мне, как на этих самых языках с библиотеками решить весьма тривиальную задачу — декомпозиция/нормализация utf-8 строки с выхлопом опять же в utf-8 — чтобы идентично работало, например, в java, c++, as3, js. Т. е. чтобы строки на естественном языке, обработанные в совершенно разных средах, можно было корректно сравнивать, считать хеши от них и тд.
> чтобы идентично работало, например, в java, c++, as3, js
Это ж задача совсем другого плана. Примерно как подружить между собой весь мир, и чтобы никто не воевал :) В случае одной платформы стандартным библиотекам всё-таки больше доверия, т.к. они потому и стандартные, что кто-то ответственный, наверняка понимающий, умный, справедливый, мудрый (надеюсь, ребята из Комитетов стандартизации меня сейчас читают) их одобрил.
Это ж задача совсем другого плана. Примерно как подружить между собой весь мир, и чтобы никто не воевал :) В случае одной платформы стандартным библиотекам всё-таки больше доверия, т.к. они потому и стандартные, что кто-то ответственный, наверняка понимающий, умный, справедливый, мудрый (надеюсь, ребята из Комитетов стандартизации меня сейчас читают) их одобрил.
Дак нет, того же плана :) Того плана, что даже библиотеки для работы со строками довольно унылые, и в случае любого чиха приходится садиться на велосипед. Того плана, что нет общего стандарта ни на эти вот самые строки, ни на функционал библиотек — покамест все отдано на реализацию саппортерам конкретных языков.
Ладно, сие не есть проблема, реально требующая обсуждения :)
Ладно, сие не есть проблема, реально требующая обсуждения :)
Ладно, сие не есть проблема, реально требующая обсуждения :)В том-то и дело, что это — и есть центральная проблема, которую мы тут обсуждаем.
Дело в том, что замена в строке на подстроки на подстроку другого размера — это не сложная, а очень сложная задача. Как любая банальность эта — тоже обсосана Джоелем.
Соответственно все языки делятся на два класса:
1. Языки в которых очевидно, что это — сложная задача (C — один из них).
2. Языки в которых прилагаются неимоверные усилия к тому, чтобы сделать вид что это — простая задача.
Так вот: человека, который, этого не понимает, по большому счёту, программистом — назвать нельзя. Ибо он не понимает по какому минному полю он ходит. Он может быть художником, архитектором или даже говнокодером, но это — не программист! У него нет в руках миноискателя, который «звенит» возле проблемых участков кода! Он может реагировать на разрывабщиеся под ногами мины — но только наступая на них.
Означает ли это, что C — обязателен в программе обучения? Нет, конечно, какой-нибудь Pascal демонстрирует это не менее выпукло. А вот в «большинстве используемых ныне» языков — это неочевидно. И это — большая трагедия.
Человек, который этого не осознал и не прочувствовал может сколь угодно хорошо рассуждать на тему всяких алгоритмов, но у него нет понимания того, что с этими чёртовыми O(N), O(N log N) и O(N2) он всречается постоянно, на каждом шагу, при написании почти любой строчки кода!
А без этого понимания — нет хорошего программиста.
Начинающий программист должен писать велосипеды для самообучения.
Понятно, что в продакшене нужно использовать готовые проверенные решения, но нет ничего хуже использования готовых решений без понимания, как они устроены изнутри.
Понятно, что в продакшене нужно использовать готовые проверенные решения, но нет ничего хуже использования готовых решений без понимания, как они устроены изнутри.
Так на любом языке для «Hello, World!» нужно программный код писать
Не, человек сказал «кучу неочевидных вещей», а не «код».
Например, чтобы написать HW на Quick Basic, нужно ввести ровно одну строку:
PRINT «Hello world!»
И все. И объяснить начинающему, что это, несложно: вот оператор вывода, вот текст, который мы выводим.
Возьмем Си:
#include <stdio.h>
int main(){
printf('Hello world!\r\n');
return 0;
};
Здесь уже сложнее: это потом, когда ты продвинулся, ты понимаешь, что инклюд позволяет тебе связать твой код с библиотекой, но изначально, для новичка — это ненужное, вспомогательное действие. Лишнее на этом этапе обучения.
Потом — зачем нам нужна «главная» функция, почему и кому она возвращает результат, почему вывод сделан вот так, и почему перевод строки выглядит вот так…
В общем — много мишуры, которая при росте размера и сложности программы станет просто «погрешностью округления», но для новичка оно совсем лишнее и только путает.
Это я не к холивору, просто пытаюсь на пальцах показать разницу для новичков (ну, раз уж о HW речь зашла).
Выскажусь с позиции такого новичка. На первом курсе мы изучали одновременно C++ и Pascal, до этого я знал только Visual Basic на очень базовом уровне. Не было никаких проблем понять, что include нужен для подключения функции printf(), не только у меня, но и у многих других. Перевод строки в первых программах особо и не нужен, но после объяснения тоже все понятно — курсор в начало / курсор вниз. Писали void main(), главная функция — точка начала программы. У всего есть понятная причина, никаких магических конструкций, которые работают сами по себе.
Да и с Паскалем была прямая аналогия: include — uses, printf — write/writeln. begin/end — {} (только слова набирать дольше и опечатки в них иногда делаешь).
Да и с Паскалем была прямая аналогия: include — uses, printf — write/writeln. begin/end — {} (только слова набирать дольше и опечатки в них иногда делаешь).
до этого я знал только Visual Basic на очень базовом уровне
То-есть та самая начальная подготовка уже была, о чем я и написал.
но после объяснения тоже все понятно — курсор в начало / курсор вниз
Я не говорил, что «перевод строки» — непонятная хрень, я говорил о другом.
Писали void main(), главная функция — точка начала программы
А почему у программы должна быть точка начала, почему начало в виде функции?
Вот в примере на Бейсике все понятно: начался лист — началась программа. И так далее.
Вы идете все по тому же полю: "это можно понять, если приложить немного усилий". Я не говорю о том, что это дико непонятная вещь; я говорю о том, что это лишнее и мешает понять суть.
начался лист — началась программа
А потом в середине листа встречается объявление функции и становится очень непонятно, почему ее операторы не исполняются, ведь мы уже привыкли, что программа это лист.
А почему у программы должна быть точка начала, почему начало в виде функции
Потому что у всего есть начало и конец, программа разделяется на функции, начало и конец программы это главная функция. Я о том, что если есть простая причина почему надо делать какие-то действия, то это более понятно, чем пример и без действий и без объяснений, который просто почему-то работает. Мне кажется, это не лишнее, это и есть та суть, которую нужно понять — как работает программа.
Впрочем, может я и не прав, никогда не обучал программированию новичков.
А потом в середине листа встречается объявление функции и становится очень непонятно, почему ее операторы не исполняются, ведь мы уже привыкли, что программа это лист.
Во-первых, понятно — это отдельная поименованная область. Как текст/статья в рамке/блок в блок-схеме.
Во-вторых, при обучении элементарщине user defined функции не используются, они описываются позже.
В-третьих, отдельный модуль.
Я о том, что если есть простая причина почему надо делать какие-то действия, то это более понятно
А если нет никаких причин делать что-то ради того чтобы делать, еще лучше.
Мне кажется, это не лишнее, это и есть та суть, которую нужно понять — как работает программа.
Мы о разных стадиях говорим. Я имел дело с людьми, которые не знали совсем ничего. Такому ты объясняешь императивный принцип: вот твои действия: первое, второе, третье. Выполняются одно за одним, именно в таком порядке, никак иначе. Вот ветвление, вот цикл.
Потом, потом, уже идет «вот это повторяется, мы выделим это, назовем и вызовем. Это функция/подпрограмма».
Вот представьте, что вы объясняете по блок-схеме: здесь действия в чистом виде, никаких побочных объявлений, описаний, включений и пр. Чем лучше блок-схема отражается на язык, тем лучше для новичка.
Или тот же непопулярный нынче алгоритмический язык/мнемокод — описывает чисто алгоритм, используя базовые конструкции и никакой побочки.
Может скажу банальность, но язык программирования это прежде всего «инструмент», а как известно прежде чем с ним работать (изучать) надо знать как его держать в руках. Моё мнение, начало это Алгоритм! Надо научиться алгоритмически мыслить, строить цепочки связей (команд) и видить цель.
Пусть меня закидают «тапками» но моё мнение алгоритмизацию лучше начинать с Паскаля. Как учебный язык нулевого уровня ему нет равных. Сам преподаю (уже 25 лет) и вижу что мода приходит и уходит, а классика остается.
Пусть меня закидают «тапками» но моё мнение алгоритмизацию лучше начинать с Паскаля. Как учебный язык нулевого уровня ему нет равных. Сам преподаю (уже 25 лет) и вижу что мода приходит и уходит, а классика остается.
Возможно. Вы представляете немного иной подход — начинающийся не с машины, а с алгоритмов. Но тогда, наверное, лучше взять Modula или Oberon того же Никлауса Вирта, как более прогрессивные языки.
Если все же вспомнить слова Вирта (отца Паскаля, Модулы и Оберона ;) ) когда его спросили какой язык программирования он считает наиболее подходящий для обучения, он ответил Паскаль как наиболее приближенный к человеческому :)
Да согласен, для студентов что направление ИТ учить надо с классики, С потом уже все остальное, НО для первоначального (нулевого) обучения (школьники) предпочтителен Паскаль.
Например, первые алгоритмические конструкции циклов (Пока/While, До/Until, Для/For) наиболее понятны именно здесь.
НО опять, на вкус и цвет, все фломастеры разные, сколько людей столько и мнений :)
Ваш покорный слуга основывается своём скромном мнении и опыте (25 лет пед работы ;) ) :)
Да согласен, для студентов что направление ИТ учить надо с классики, С потом уже все остальное, НО для первоначального (нулевого) обучения (школьники) предпочтителен Паскаль.
Например, первые алгоритмические конструкции циклов (Пока/While, До/Until, Для/For) наиболее понятны именно здесь.
НО опять, на вкус и цвет, все фломастеры разные, сколько людей столько и мнений :)
Ваш покорный слуга основывается своём скромном мнении и опыте (25 лет пед работы ;) ) :)
А вы пробовали учить чему-то другому? Не оберону/модуле, а, скажем, Scheme, Python?
На Питоне пробовал.
Но сразу говорю, средние и менее ученики взвыли :) Питон очень не плох для обучения, но (да опять НО ;) ) только в том случае если они понимают уже структуру алгоритма, То есть знают какому блоку (циклу или ветвлению) что принадлежит, а выделения программного блока отступами для них вообще кошмар, в Паскале, Си и прочих, программные скобки физически видны. С этого как раз и начинается практика, учу выделять блоки, что бы знали что кому принадлежит.
Но сразу говорю, средние и менее ученики взвыли :) Питон очень не плох для обучения, но (да опять НО ;) ) только в том случае если они понимают уже структуру алгоритма, То есть знают какому блоку (циклу или ветвлению) что принадлежит, а выделения программного блока отступами для них вообще кошмар, в Паскале, Си и прочих, программные скобки физически видны. С этого как раз и начинается практика, учу выделять блоки, что бы знали что кому принадлежит.
Space — символы как часть синтаксиса языка была на мой взгляд очень глупой идеей. По этой причине его и не люблю.
А не пробовали ли вы объяснять, что выделение отступами логических блоков им, ученикам, прекрасно знакомо на примере многоуровневых списков, которые они легко, не задумываясь, клепают в своих рефератах/курсовых:
А)
Б)
С)
1.
2.
А)
Б)
С)
1.
2.
-
-
3.И вообще, какими теориями и приемами, изобретенными великими педагогами и методистами, преподавателями компьютерной грамотности (Ушинский, Ершов, Макаренко и др.) Вы пользовались в работе?
Отступы в списке выше нормально не отображаются, но идея должна быть ясна...
Если бы мне в школе про списки начали говорить, я бы не понял еще больше.
— Отступы в списке можно сделать любого уровня, а не ровно 4 пробела, длина отступов на смысл не влияет.
— Отступы делаются для визуального разделения, а не для логического. Для логического как раз используются цифры и буквы.
— В списках нет циклов.
Я питон почти не знаю, мы в школе VB изучали, но когда начало и конец блока чем-то обозначены это более понятно.
— Отступы в списке можно сделать любого уровня, а не ровно 4 пробела, длина отступов на смысл не влияет.
— Отступы делаются для визуального разделения, а не для логического. Для логического как раз используются цифры и буквы.
— В списках нет циклов.
Я питон почти не знаю, мы в школе VB изучали, но когда начало и конец блока чем-то обозначены это более понятно.
Не все с вами согласятся. Если бы мне в школе преподавали питон, я бы сразу понял эту абстракцию.
— В питоне тоже не нужно делать ровно 4 пробела, можно и табуляцией это делать.
— Отступы делаются для выделения логического разделения, иначе список может читаться так же как постом выше, где парсер сожрал список — тружно понять где какой уровень и что за чем идет.
— Вы не представляете циклы в списках, а я представляю. Если список является пошаговым набором инструкций, то цикл в нем может быть реализован в таком виде: «Шаги А.4.1 — А.4.8 повторять до получения результата, но не более 8 раз».
В школе изучал QBasic и мне никто не говорил, что надо делать отступы — я их сам машинально начал делать для выделения логических блоков и повышения читаемости кода.
— В питоне тоже не нужно делать ровно 4 пробела, можно и табуляцией это делать.
— Отступы делаются для выделения логического разделения, иначе список может читаться так же как постом выше, где парсер сожрал список — тружно понять где какой уровень и что за чем идет.
— Вы не представляете циклы в списках, а я представляю. Если список является пошаговым набором инструкций, то цикл в нем может быть реализован в таком виде: «Шаги А.4.1 — А.4.8 повторять до получения результата, но не более 8 раз».
В школе изучал QBasic и мне никто не говорил, что надо делать отступы — я их сам машинально начал делать для выделения логических блоков и повышения читаемости кода.
"— В списках нет циклов."
Если использовать ссылки на пункты то циклы появятся: "п. 3567. Заявителю при подаче заявления… повторить последовательно, в порядке возрастания номеров пунктов, 567886543 раз п. 700-3576"; появятся условия — "п. 766544321. ЕСЛИ заявитель соответствует пп. 788765 п. 765 раздела А Критериев, заявитель [исполнитель алгоритма] обязан произвести процедуру сертификации (см. п. 000-8765325799ф, раздела 765-87-у-7654н-123н, приложения 124-987-543-НКАРОЛ- 14986- 14Б:6Э Порядка обязательной сертификации заявителей...), если заявитель не соответствует ...".
На таких списках можно даже ассемблер разъяснить, объяснив, что метка в ассемблере — это аналог такой вот ссылки на нужное место ф формальном документе или списке из этого документа.
Это не цикл, а goto. С пониманием goto проблем обычно и нет. А сама инструкция «перейти наверх на пункт такой-то» — это и есть понятное обозначение конца блока, о чем я и говорил.
Цикл со счетчиком в виде списка на бумаге сделать не получится. Можно записать оператор словами, но если не знать как он работает, то будет непонятно.
Цикл со счетчиком в виде списка на бумаге сделать не получится. Можно записать оператор словами, но если не знать как он работает, то будет непонятно.
Скрытый текст
Мне например сначала казалось, что словом for задается диапазон — «для» значений переменной i от A до B делать то-то (то есть как будто
if (i >= A && i <= B)). При чтении обычного списка с листа оно примерно так и воспринимается, потому что это декларативное описание.Вы говорите больше о программировании на списках, а я говорю о том, что списки вполне нормально соотносятся с логикой визуальных отступов.
Не путайте теплое с мягким.
Не путайте теплое с мягким.
Отступы в списке выше нормально не отображаютсяВот как бы и я о чём.
Милый вы мой :) что вы говорите, 7-8 и даже 9 класс не то что нормальные рефераты сделать и оформить не могут, а об многоуровневых списках вообще молчу :)
Кстати пример не очень удачный. Как раз Паскаль в этом отношении с его Begin и end наиболее понятен.
По теории педагогики ;) это не ко мне :) пед образования не имею :) зато в активе военное (Можайка) и инженерное (программист) :)
А прием очень простой, ты должен объяснить так что бы любой человек смог понять :) ну и конечно армейский принцип «делай как я» :)
Кстати пример не очень удачный. Как раз Паскаль в этом отношении с его Begin и end наиболее понятен.
По теории педагогики ;) это не ко мне :) пед образования не имею :) зато в активе военное (Можайка) и инженерное (программист) :)
А прием очень простой, ты должен объяснить так что бы любой человек смог понять :) ну и конечно армейский принцип «делай как я» :)
Ну я всё же не про школьников писал, а про студентов или образованных самоучек (естественные или инженерные направления). Школьники или 'нулевые' ученики — вообще отдельный разговор, я, например, не очень знаю, как учить человека с полного нуля. На мой взгляд всё же должна сначала стихийно накопиться некая критическая масса знаний, чтобы было общее представление. И у школьников программирование обычно как обязаловка, мало связанная с их желаниями.
Армейский принцип «делай как я»:
Познакомьте из с TeX, LaTex, потом с OMdoc — только осторожно, не залезая в дебри — для этого уже есть книжка "Сверстай диплом красиво: LaTeX за три дня" (http://www.stolyarov.info/books/latex3days). Тем кто не одолеет его — покажите руководства (прямо ткните в страницы по текстовым стилям) по OOWriter, онлайн документацию по MS Word.
Text Encoding Initiative (TEI) — с ним можно познакомить гуманитариев — это их специализированный инструмент.
Разве на Питоне нельзя, при желании, писать, как на Паскале?
(Надо ли на Питоне писать, как на Паскале — другой вопрос.)
(Надо ли на Питоне писать, как на Паскале — другой вопрос.)
Это как? :)
На Питоне нельзя писать как на Паскале. Вот на C — можно, а на Питоне — нет. У него просто нет базовых структур данных со сложность O(1).
Это как заниматься гимнастикой на батуте: тренированный атлет это сделать может, но новичка этому учить — боже упаси. Лучше уж твёрдый пол и устройчиво стоящие на нём снаряды…
Это как заниматься гимнастикой на батуте: тренированный атлет это сделать может, но новичка этому учить — боже упаси. Лучше уж твёрдый пол и устройчиво стоящие на нём снаряды…
> У него просто нет базовых структур данных со сложность O(1).
Эмм… щито?
Эмм… щито?
Нет вообще ничего, что работало бы за константное время. Два числа нельзя за константное время сложить! Или присвоить!
Потому что всё-на-свете хранится в ассоциативных массивах, которые расширяются по мере необходимости. А числа в BigNumы превращаются, если нужно. Это удобно, спору нет — но это же и обозначает, что вы никогда ни в чём можете быть уверены.
Для человека, которые уже имеет представление об алгоритмах — это не проблема, но когда вы пытаетесь рассказать о том что такое «сложность вычислений» и «потребление памяти» — это ужасно. У человека возникает чёткое ощущение, что преподаватель «чего-то недоговаривает».
Потому что всё-на-свете хранится в ассоциативных массивах, которые расширяются по мере необходимости. А числа в BigNumы превращаются, если нужно. Это удобно, спору нет — но это же и обозначает, что вы никогда ни в чём можете быть уверены.
Для человека, которые уже имеет представление об алгоритмах — это не проблема, но когда вы пытаетесь рассказать о том что такое «сложность вычислений» и «потребление памяти» — это ужасно. У человека возникает чёткое ощущение, что преподаватель «чего-то недоговаривает».
Признаться, всё ещё не улавливаю сути вашего педагогического посыла. Вот, например, человек пишет о внутреннем представлении целых чисел в Питоне: http://www.laurentluce.com/posts/python-integer-objects-implementation/
Т. е., может так получиться, что я сложил два числа, и результат сохранится в уже выделенном блоке памяти. А может так, что интерпретатор должен будет выделять новый блок, и это займёт больше времени — вы об этом?
Т. е., может так получиться, что я сложил два числа, и результат сохранится в уже выделенном блоке памяти. А может так, что интерпретатор должен будет выделять новый блок, и это займёт больше времени — вы об этом?
Не только об этом. Там в совокупности много чего набирается: обращение к переменным идёт через хеш (у нас же интерпретируемый язык, причём, в отличие от древноего BASIC'а переменных не фиксированное число, а сколько угодно), для части переменных есть отдельные оптимизации и т.д. и т.п. Простейший пример:
Как? Почему? За что?
Туева хуча «протекающих» абстракций! Да, обычно они вас не беспокоят, а если вдруг что-то случится — вы знаете где и что искать. Но это вы — человек с опытом работы и знающий где что происходит.
А если человек только учится? И только лишь пытается разобраться в том, как работает инструмент, который ему дали?
Скорее всего решит «это магия, иногда она срабатывает, иногда нет, что ж тут такого»… а что будет, если потом в реальной работе магия не сработает?
$ python3 Python 3.4.3 (default, Oct 14 2015, 20:28:29) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> a = 100 >>> b = 100 >>> a is b True >>> a = 1000 >>> b = 1000 >>> a is b False
Как? Почему? За что?
Туева хуча «протекающих» абстракций! Да, обычно они вас не беспокоят, а если вдруг что-то случится — вы знаете где и что искать. Но это вы — человек с опытом работы и знающий где что происходит.
А если человек только учится? И только лишь пытается разобраться в том, как работает инструмент, который ему дали?
Скорее всего решит «это магия, иногда она срабатывает, иногда нет, что ж тут такого»… а что будет, если потом в реальной работе магия не сработает?
Если развить вашу мысль, разве не получится, что магия вообще везде, и иногда работает так, а иногда — иначе? Сложить два числа хоть на Си, хоть на Паскале, хоть на Ассемблере за константное время? Ну разве что в ОС жёсткого реального времени или на голом железе (очень распространённые среды для обучения начинающих программистов, ага). А вот от такой, к примеру, магии и вообще ничего не спасёт: http://stackoverflow.com/questions/11227809/why-is-it-faster-to-process-a-sorted-array-than-an-unsorted-array
> Сложить два числа хоть на Си, хоть на Паскале, хоть на Ассемблере за константное время?
Сложение, это же не обработка строки. В любой ОС это будет константное значение. Процессор не переключит контекст, пока он выполняет по сути атомарную операцию сложения.
> А вот от такой, к примеру, магии и вообще ничего не спасёт
Это ж не магия, а дюже умный современный процессор
Сложение, это же не обработка строки. В любой ОС это будет константное значение. Процессор не переключит контекст, пока он выполняет по сути атомарную операцию сложения.
> А вот от такой, к примеру, магии и вообще ничего не спасёт
Это ж не магия, а дюже умный современный процессор
Процессор не переключит контекст, пока он выполняет по сути атомарную операцию сложения.А кто его остановит? Вопрос в частоте, конечно.
> Процессор не переключит контекст
Пацаны, написавшие InterlockedIncrement и прочие наборы атомарных арифметических функций, опять не знали?
> Это ж не магия, а дюже умный современный процессор
И? В чём принципиальная разница, кто виноват и что делать?
Пацаны, написавшие InterlockedIncrement и прочие наборы атомарных арифметических функций, опять не знали?
> Это ж не магия, а дюже умный современный процессор
И? В чём принципиальная разница, кто виноват и что делать?
И? В чём принципиальная разница, кто виноват и что делать?Принципиальная разница в том, что «магия» — это что-то непознанное и постижимое, а процессор — это что-то, сделанное людьми и людьми же обслуживаемое.
Если уж совсем без магии хочется — возьмите эмулятор Atari 2600. Отличная вещь: без вских OS, но главное — видопамять на одну строку и отсутствие прерываний. То есть вам нужно за время показа одной строки выполнить определённый кусочек программы, который породит вам следующую строку. С точностью до такта!
И никакой магии.
> Пацаны, написавшие InterlockedIncrement
Пацаны знали, но писали его не для тех данных, которые целиком вмещаются в регистр процессора. По крайней мере, если речь идет об x86.
> И? В чём принципиальная разница, кто виноват и что делать?
Принципиальная разница в том, что поведение процессора логично и ожидаемо.
Пацаны знали, но писали его не для тех данных, которые целиком вмещаются в регистр процессора. По крайней мере, если речь идет об x86.
> И? В чём принципиальная разница, кто виноват и что делать?
Принципиальная разница в том, что поведение процессора логично и ожидаемо.
> которые целиком вмещаются в регистр процессора
Лолшто? 32-битный аргумент функции InterlockedIncrement не вмещается целиком в регистр процессора? При том что для х86 эти регистры стали 32-битными начиная, кажется, с i386?
Лолшто? 32-битный аргумент функции InterlockedIncrement не вмещается целиком в регистр процессора? При том что для х86 эти регистры стали 32-битными начиная, кажется, с i386?
Зря лолштокаете. В самой документации по Interlocked-функциям написано, что арифметические операции с 32-битными числами на 32-битных ОС являются атомарными :)
Ссылку, сестра, ссылку!
Ну вот, например:
https://msdn.microsoft.com/en-us/library/ms684122.aspx
А что, у вас есть сомнения, что 32-битный процессор в состоянии атомарно обработать 32-битное число? Ему обязательно дробить на микрооперации действие, которое делается сумматором из полусотни вентилей?
https://msdn.microsoft.com/en-us/library/ms684122.aspx
А что, у вас есть сомнения, что 32-битный процессор в состоянии атомарно обработать 32-битное число? Ему обязательно дробить на микрооперации действие, которое делается сумматором из полусотни вентилей?
Ему обязательно дробить на микрооперации действие, которое делается сумматором из полусотни вентилей?Нет, конечно. Но ему обязательно нужно будет разбить одну инструкцию как минимум на три: чтение из памяти, модификация данных и запись. И тут полусотней вентилей никак не обойтись: сколько блоков участвует в «походе в оперативную память» на современном CPU даже представить себе страшно!
Слуште, ну не надо так пугать меня на старости лет! Вы сами-то пробовали читать, что там написано? «Приложения должны синхронизировать доступ к переменным… Приложения должны обеспечивать атомарность операций...» И далее: «Простые операции чтения и записи на выровненные 32-битные переменные атомарны, т. е. не возникнет ситуации, когда только часть переменной была обновлена, все биты обновляются атомарно. Однако синхронизация доступа не гарантируется. (...)»
> А что, у вас есть сомнения…
Не сомнения у меня есть, а твёрдая уверенность. Вот вам пример из Рихтера. Инкрементируем переменную в одном потоке:
MOV EAX, [g_x]; значение из g_x помещается в регистр
INC EAX; значение регистра увеличивается на 1
MOV [g_x], EAX; значение из регистра помещается обратно в g_x
В двух потоках по-очереди:
MOV EAX, [g_x]; поток 1 в регистр помещается 0
INC EAX; поток 1. значение регистра увеличивается на 1
MOV [g_x], EAX; поток 1. значение 1 помещается в g_x
MOV EAX, [g_x]; поток 2. в регистр помещается 1
INC EAX; поток 2. значение регистра увеличивается до 2
MOV [g_x], EAX; поток 2. значение 2 помещается в g_x
В двух потоках параллельно:
MOV EAX, [g_x]; поток 1. в регистр помещается 0
INC EAX; поток 1. значение регистра увеличивается на 1
MOV EAX, [g_x]; поток 2 в регистр помещается 0
INC EAX; поток 2. значение регистра увеличивается на 1
MOV [g_x], EAX; поток 2. значение 1 помещается в g_x
MOV [g_x], EAX; поток 1. значение 1 помещается в g_x
Это лишь один из многих вариантов, ассемблерные инструкции могут быть перетасованы и любым другим образом. Ну вы чего, в самом деле…
> А что, у вас есть сомнения…
Не сомнения у меня есть, а твёрдая уверенность. Вот вам пример из Рихтера. Инкрементируем переменную в одном потоке:
MOV EAX, [g_x]; значение из g_x помещается в регистр
INC EAX; значение регистра увеличивается на 1
MOV [g_x], EAX; значение из регистра помещается обратно в g_x
В двух потоках по-очереди:
MOV EAX, [g_x]; поток 1 в регистр помещается 0
INC EAX; поток 1. значение регистра увеличивается на 1
MOV [g_x], EAX; поток 1. значение 1 помещается в g_x
MOV EAX, [g_x]; поток 2. в регистр помещается 1
INC EAX; поток 2. значение регистра увеличивается до 2
MOV [g_x], EAX; поток 2. значение 2 помещается в g_x
В двух потоках параллельно:
MOV EAX, [g_x]; поток 1. в регистр помещается 0
INC EAX; поток 1. значение регистра увеличивается на 1
MOV EAX, [g_x]; поток 2 в регистр помещается 0
INC EAX; поток 2. значение регистра увеличивается на 1
MOV [g_x], EAX; поток 2. значение 1 помещается в g_x
MOV [g_x], EAX; поток 1. значение 1 помещается в g_x
Это лишь один из многих вариантов, ассемблерные инструкции могут быть перетасованы и любым другим образом. Ну вы чего, в самом деле…
Не нужно ничего перетасовывать даже. Банальный «inc [g_x]» не гарантирует атомарности если не используется префикс LOCK". А какой, собственно, в этом префиксе был бы смысл, если бы всё и так всегда атомарно работало бы?
Кстати скорость работы инструкций «inc [g_x]» и «lock inc [g_x]» очень заметно отличается. В несколько раз.
Кстати скорость работы инструкций «inc [g_x]» и «lock inc [g_x]» очень заметно отличается. В несколько раз.
Ага, я даже пытался замерить это время: из нескольких потоков инкрементил одну и ту же области памяти и считал сумму за секунду.
У меня получилось 175M инкрементов в секунду при одном потоке и всего 47M при 2 и большем числе потоков. Получается, что при инкременте в 4 потока каждый из потоков выполняет инкремент всего 12M раз. Т.е. когда к памяти имеет доступ один поток, получается около 23 тактов на операцию, а когда несколько (например, 4), то значение увеличивается до 300-350 тактов. Для сравнения: простой инкремент — 1-2 такта.
У меня получилось 175M инкрементов в секунду при одном потоке и всего 47M при 2 и большем числе потоков. Получается, что при инкременте в 4 потока каждый из потоков выполняет инкремент всего 12M раз. Т.е. когда к памяти имеет доступ один поток, получается около 23 тактов на операцию, а когда несколько (например, 4), то значение увеличивается до 300-350 тактов. Для сравнения: простой инкремент — 1-2 такта.
Корни проблем неправильного понимания атомарности растут со старых архитектур. Когда у нас процессор (ядро) был один, то да, любая операция, которая выражалась одной ассемблерной командой, была атомарна. Потому что никто параллельно не мог работать с той же областью памяти. А вот действия, состоящие из несколько команд, могли быть прерваны посередине.
В случае многопроцессорных систем для обеспечения атомарности стало необходимо также блокировать совместный доступ к памяти. Поэтому Interlocked команды используются даже если аргумент влезает в регистр процессора.
В случае многопроцессорных систем для обеспечения атомарности стало необходимо также блокировать совместный доступ к памяти. Поэтому Interlocked команды используются даже если аргумент влезает в регистр процессора.
Корни неправильного понимания атомарности растут из неправильного понимания атомарности. Да, когда у вас система достаточно простая, то всё работает так, как вы описываете. На том же Atari 2600 просто некому «испортить малину». Но уже на первом IBM PC (а это, так, на минуточку, 81й год) есть DMA и 8087й сопроцессор, который, на минуточку, ходит в память параллельно и независимо от основного процессора! И там уже можно испытать все «прелести» неатомарности операции
inc и нарушения правил алиасинга (а вы как думали — откуда они в C/C++ взялись? вот именно отсюда… не конкретно от 8087го, конечно, а в принципе — от архитектур где CPU и FPU независимо ходят в память).Даже i8080 (1974) уже имел в чипсете DMA.
Ну не преувеличивайте :) Ни DMA, ни сопроцессор, не смогут захватить шину независимо от основного процессора у IBM PC. Это «мнимый» параллелизм. Только тогда, когда он её сам готов отдать. В случае DMA — даст контроллеру команду на загрузку данных, в случае сопроцессора — когда он сам выберет из очереди инструкцию Fxxxx. Аппаратные прерывания? Тоже нет, у 8086 перед переходом по вектору прерывания сначала целиком завершается текущая инструкция.
Опять же таки, что касается атомарности, если рассматривать многопоточную работу, да еще когда несколько потоков лезут к общим данным в оперативной памяти, то естественно, вы правы. Но сама операция сложения действительно атомарна :) Более того, если вы попробуете сложить два целых числа в простом примере, вы увидите, что компилятор вам сделает сложение регистр-регистр, а не будет тянуть их из памяти. Так что не всё так сложно, как вы пишите.
Опять же таки, что касается атомарности, если рассматривать многопоточную работу, да еще когда несколько потоков лезут к общим данным в оперативной памяти, то естественно, вы правы. Но сама операция сложения действительно атомарна :) Более того, если вы попробуете сложить два целых числа в простом примере, вы увидите, что компилятор вам сделает сложение регистр-регистр, а не будет тянуть их из памяти. Так что не всё так сложно, как вы пишите.
Только тогда, когда он её сам готов отдать.Проблема в том, что он вполне себе «готов её отдать» посреди одной инструкции — а иначе префикс LOCK смысла бы не имел. А он, напоминаю, в 8086 уже был.
В случае DMA — даст контроллеру команду на загрузку данных, в случае сопроцессора — когда он сам выберет из очереди инструкцию Fxxxx.Записать в память сопроцессор осуществляет не тогда, когда он «выберет из очереди инструкцию», а когда у него данные появятся, что, опять-таки может произойти непонятно когда. Опять-таки: если бы было не так, то команда WAIT была бы не нужна — а она тоже в 8086м появилась.
Описанную вами «сферическую» атомарность невозможно увидеть и ощутить без обращения в память, а как только мы туда начинаем обращаться — у нас начинаются гонки. И, собственно, тот факт что средства для борьбы с ними появились в 8086м процессоре — это очень такой толстый намёк.
Не понимаю с чем вы спорите и зачем.
> если бы было не так, то команда WAIT была бы не нужна
Команда WAIT же не для того, чтобы гарантировать «атомарность» работы операций процессора. Она для того, чтобы корректно обработать результат работы FPU.
> Не понимаю с чем вы спорите и зачем.
Я ни с чем оне спорю, я просто объясняю свою позицию, что неоднозначности с синхронизацией в работе процессора не существенны для обучения на императивных языках, где действительно время и порядок выполнения операций прогнозируемы. С ними можно столкнуться в специальных случаях, а не в работе учебных приложений. А как работает IBM PC, я, в общем-то, знаю. Примерно на таком уровне:
http://zx-pk.ru/threads/22102-pk-poisk-adapter-som-portov.html
Команда WAIT же не для того, чтобы гарантировать «атомарность» работы операций процессора. Она для того, чтобы корректно обработать результат работы FPU.
> Не понимаю с чем вы спорите и зачем.
Я ни с чем оне спорю, я просто объясняю свою позицию, что неоднозначности с синхронизацией в работе процессора не существенны для обучения на императивных языках, где действительно время и порядок выполнения операций прогнозируемы. С ними можно столкнуться в специальных случаях, а не в работе учебных приложений. А как работает IBM PC, я, в общем-то, знаю. Примерно на таком уровне:
http://zx-pk.ru/threads/22102-pk-poisk-adapter-som-portov.html
Команда WAIT же не для того, чтобы гарантировать «атомарность» работы операций процессора. Она для того, чтобы корректно обработать результат работы FPU.Команда WAIT нужна для того, чтобы получить сигнал «всё, я отстрелялся». Так как 8087 сам, независимо ходит в память, то она нужна, в частности, для того, чтобы «иметь право» обратится к памяти, в которую пишет FPU. В частности если вы организуете целочисленные вычисления на FPU (это не дикость: Turbo Pascal имел ажно специальный тип Comp для этих целей), а потом начинаете работать с данными из CPU, то вам нужно использовать либо LOCK, либо WAIT, иначе атомарности может и не получиться.
Я ни с чем оне спорю, я просто объясняю свою позицию, что неоднозначности с синхронизацией в работе процессора не существенны для обучения на императивных языках, где действительно время и порядок выполнения операций прогнозируемы.На однопроцессорной системе, в случае когда не используется сопроцессор и так далее? Да, наверное. Но как-то в ваших предыдущих выступлениях я этого не уловил. Наоборот — там были странные рассуждения про «атомарные арифметические операции» и прочее. Которые нифига не атомарны (если не прилагать специальных усилий) даже при использовании DOS'а. Уже в IBM PC они не были атомарными — и на это легко можно было нарваться если прерывания перехватывать (да, да, в те времена это было нормальным и естественным), 8087й процессор или DMA использовать.
Между «вы, скорее всего, на это не наткнётесь в своих учебных программах» и «процессор не переключит контекст, пока он выполняет по сути атомарную операцию сложения» — дистанция огромного размера.
Современные компьютеры выполняют миллиарды операций в секунду (а скоро могут и до триллионов добраться) — при таких масштабах оказывается, что вещи, случающиеся «очень редко», происходят, скажем, раз в минуту. Вам будет приятно пользоваться программой, которая раз в минуту падает? Вот об этом и речь.
Касаемо 8086: да, прерывание может произойти во время выполнения команды: процессор может считать из памяти операнд и начать выполнять операцию, но не успеть записать результат. С точки зрения программиста это будет выглядеть как если бы команда не выполнялась вообще.
DMA и сопроцессор — отдельные темы. Скорее всего, вам никогда не понадобится лезть в область памяти в тот момент, когда с ней работает сопроцессор или гадит DMA.
DMA и сопроцессор — отдельные темы. Скорее всего, вам никогда не понадобится лезть в область памяти в тот момент, когда с ней работает сопроцессор или гадит DMA.
Скорее всего, вам никогда не понадобится лезть в область памяти в тот момент, когда с ней работает сопроцессор или гадит DMA.Про DMA — не знаю, наверное. А с сопроцессором как раз это постоянная история. Вычислили вы что-нибудь этакое (размер какого-нибудь буфера) с использованием плавучки (типичный пример: «время ожидания» и «частота опроса» заданные как числа с плавающей точкой), а потом — крутитесь в цикле обработки. Забудете WAIT — получите джиттер в лучшем случае (это если вы потеряете только один «цикл обработки», если получите просто «мусор» в этой памяти, то программа просто упадёт, скорее всего).
Тут, правда, вам ещё и прерывания будут подмешаны в кучу… но, в общем, на PC («настоящей PC», модель 5150) это бола та ещё головная боль.
Интеграция сопроцессора в 80486й (и все последующие модели) — одна из вещей, где количество абстракций упало со временем, а не возросло… правда тот же 80486й добавил кеш, так что в целом — «протечек» стало больше… но конкретно «пляски с бубном вокруг сопроцессора» 80486й (и 68040 у «конкурентов» — что интересно тоже одновременно добавивший кеш и сопроцессор на кристал) — оставили в прошлом.
Обычно заботу о вызове WAIT берёт на себя компилятор.
Пикантная ситуация возможна, опять же, при прерываниях, если обработчик прерывания хочет прочитать область памяти, куда может писать сопроцессор. Обработчик прерываний не имеет права вызвать WAIT.
Пикантная ситуация возможна, опять же, при прерываниях, если обработчик прерывания хочет прочитать область памяти, куда может писать сопроцессор. Обработчик прерываний не имеет права вызвать WAIT.
Обычно заботу о вызове WAIT берёт на себя компилятор.Если не используется каламбур типизации.
Обработчик прерываний не имеет права вызвать WAIT.Кто ему вдруг запретит? Я боюсь вы путаете запрет, который налагают многие операционки, (для упрощения написания x87 эмуляторов) с ограничениями железа.
Впрочем всё это ушло уже ооочень далеко от вопроса о том, как изучать языки программирования.
> На однопроцессорной системе, в случае когда не используется сопроцессор и так далее?
На любой. Если вы сами ничего специально для этого не сделаете, вы не получите непрогнозируемый результат. Ни на 8086, ни даже сейчас, т.к. ОС контексты процессов тоже не переключает произвольным образом, а делает это по планировщику.
> Вам будет приятно пользоваться программой, которая раз в минуту падает?
Я, честно говоря, не понял смысла этого замечания. Я вроде бы нигде не писал, что «долой ГМО и синхронизацию потоков в многопоточном приложении». Если был нетрезв и написал, дайте цитату.
На любой. Если вы сами ничего специально для этого не сделаете, вы не получите непрогнозируемый результат. Ни на 8086, ни даже сейчас, т.к. ОС контексты процессов тоже не переключает произвольным образом, а делает это по планировщику.
> Вам будет приятно пользоваться программой, которая раз в минуту падает?
Я, честно говоря, не понял смысла этого замечания. Я вроде бы нигде не писал, что «долой ГМО и синхронизацию потоков в многопоточном приложении». Если был нетрезв и написал, дайте цитату.
Даже если процессор отдаёт память DMA явно, чисто в теории далеко не факт, что он не делает несколько захватов-отдач во время одной команды. Грубо: захватили память, прочитали команду, отдали память, дешифровали команду, поняли что операнд в памяти, захватили память, прочитали операнд, отдали память, выполнили операцию, поняли, что операнд тоже нужно поместить в память, захватили, записали, отдали. Итого минимум одно окно, где может вмешаться тот же DMA.
Если развить вашу мысль, разве не получится, что магия вообще везде, и иногда работает так, а иногда — иначе?Конечно получится. Но не стоит забывать о том, что появилась она — совсем недавно.
Ну разве что в ОС жёсткого реального времени или на голом железе (очень распространённые среды для обучения начинающих программистов, ага).Почему нет? В MS DOS магии было вполне немного. Потому, в частности, за MS DOS держались очень долго. Windows, да — это уже проблема, конечно…
А вот от такой, к примеру, магии и вообще ничего не спасёт: http://stackoverflow.com/questions/11227809/why-is-it-faster-to-process-a-sorted-array-than-an-unsorted-arrayОпять-таки: любая система на базе 80386 «без наворотов» (читай: без кеша).
В целом — вы правы: чем дальше в лес — тем сложнее от магии избавиться. Но это не значит, что это — что-то хорошее. Для обучения — это плохо.
P.S. Принцип примерно тот же, что и на уроках труда. Станки, на которых детей обучают программрованию — это что-то ближе к XIX веку, чем к XXI. И не потому что они дешевле, чем современная супер-пупер наворочанная железка. А потому что его элементарно проще понять и освоить. И не надо говорить, что сегодня от этого никуда не деться: купите Arduino — и всё: нет больше никакой магии. Причём оно же ещё и стоит копейки…
Чего тогда не BASIC? Тоже очень популярный язык у школьных преподавателей. И простой. Но я бы предпочел Python. Легок в освоении, и можно одним языком покрыть практически все основы: от циклов и ветвлений до лямб, рекурсий и ООП.
В начале пед карьеры Бейсик тоже тоже был ;)
Но, сейчас он исключен из олимпиадного набора языков, а в олимпиадах мы участвуем :) И опять же в Бейсике трудно понять программный блок.
Против Питона я не против (он мне нравится), но ко мне приходят школьники разного уровня, одни все схватывают на лету (таких единицы) другие со«скрипом» циклы осваивают. Были классы в которых успевал не только ООП показать но Ассемблер чуток познакомить, сейчас это только в памяти.
Но, сейчас он исключен из олимпиадного набора языков, а в олимпиадах мы участвуем :) И опять же в Бейсике трудно понять программный блок.
Против Питона я не против (он мне нравится), но ко мне приходят школьники разного уровня, одни все схватывают на лету (таких единицы) другие со«скрипом» циклы осваивают. Были классы в которых успевал не только ООП показать но Ассемблер чуток познакомить, сейчас это только в памяти.
BASIC изучали не от хорошей жизни: просто это было единственное, что можно было использовать на допотопных компьютерах.
Навскидку, что использовал в конце 80-х — самом начале 90-х на допотопных компьютерах минимум 4-х разновидностей (клоны Радио-86РК, Спектрума, БК-0010, Yamaha MSX2)
— фокал
— бейсик
— си
— паскаль
— форт
— дбэйс
ну и ассемблеры
— фокал
— бейсик
— си
— паскаль
— форт
— дбэйс
ну и ассемблеры
Даже на любительском Радио-86РК с 32Кб памяти был спектр языков.
Бейсик понятен. Всем. Поэтому и используется(овался).
Бейсик понятен. Всем. Поэтому и используется(овался).
Поддерживаю, начинать надо с Паскаля, от #define, заголовочных файлов, неясного printf у людей которые едва начали сносит мозг.
И при этом в отличии от Ada, Modula, Oberon… Паскаль жив и применяться в коммерческой разработке, что увеличивает полезность занятий.
И при этом в отличии от Ada, Modula, Oberon… Паскаль жив и применяться в коммерческой разработке, что увеличивает полезность занятий.
Для понимания C++ стоило прочитать «Дизайн и эволюция языка C++» Страуструппа. Он там не столько описывает язык, сколько объясняет мотивацию принятия тех или иных решений. После этого многое становится значительно понятнее. Не знаю, есть ли аналогичная по современной редакции языка.
Сам я начинал с МК-52, ассемблеров и паскаля, но серьезно увлекся после изучения C. В конце концов перешел на функциональщину, но путь был довольно длинный.
Я считаю, что в качестве первого языка надо выбирать язык, позволяющий создавать абстракции. Программирование заключается именно в этом — в создании и повторном использовании абстракций. Но C в этом отношении очень плох.
И не надо бояться, что человек не поймет принципов работы компьютера. В том же старом добром SICP разбирают не только устройство памяти, но даже разрабатывают достаточно реалистичную модель процессора. Это лучший учебник, не смотря на то, что сам язык Scheme уже несколько устарел.
Сам я начинал с МК-52, ассемблеров и паскаля, но серьезно увлекся после изучения C. В конце концов перешел на функциональщину, но путь был довольно длинный.
Я считаю, что в качестве первого языка надо выбирать язык, позволяющий создавать абстракции. Программирование заключается именно в этом — в создании и повторном использовании абстракций. Но C в этом отношении очень плох.
И не надо бояться, что человек не поймет принципов работы компьютера. В том же старом добром SICP разбирают не только устройство памяти, но даже разрабатывают достаточно реалистичную модель процессора. Это лучший учебник, не смотря на то, что сам язык Scheme уже несколько устарел.
В принципе согласен с автором, но от себя хочу заметить: я бы рекомендовал после С изучить функциональный язык типа того же Lisp(Sheme) или Haskell. Просто, исходя из личного опыта, пересаживаться с императивщины на функциональщину очень тяжело по причине сложности понимания парадигмы, так что уже лучше «поломать» мозг в начале своего пути разработчика, чем уже не будучи новичком, часами сношать свой мозг, пытаясь уловить принципы функционального программирования.
Паскаль -> С -> Java -> Javascript
Вы в тридцать лет пошли в школу? Это очепятка? :)
Большинство американских университетов начинают с Питона. Он и читабелен и популярен и легко изучается.
Лучше параллельно изучать С и Ассемблер. Это даст представление о том, что лежит за компилируемыми языками. А потом что-то скриптовое, чтобы почувствовать себя человеком и, при этом, понимать чем расплачиваются скриптовые языки за удобство.
Эх, помню как в универе С++ заставил меня возненавидеть программирование, а потом другой язык вернул интерес, и принес понимание, что можно заниматься задачами не закапываясь в ненужные технические детали.
«Знание принципов проектирования программ, алгоритмов». Вот про это все тело ноет. Где оно написано? Утомился от собственного изобретения велосипедов там, где уже давно на ракете летают.
В книгах на английском языке. Например, Code Complete by Steve McConnell по кодированию. И список рекомендаций к ней.
Thomas H. Cormen
Невероятно, но Java вообще изучать не предлагается. Java является промышленным языком #1 последние 10 лет по количеству работы, проектов, и инфраструктуры. Кроме того, Java весьма интересна как язык своим дизайном, например Python и другие языки открыто заимствовали идеи библиотек и фраймворков. С академической точки зрения, JVM это предмет для обязательного изучения любого программиста-теоретика и/или перформансника. Одна JMM чего стоит!
Java рарабатывалась как костыль для неосиливших C++. Она — Smalltalk для нищих, с урезанным… практически всем. Когда Sun внезапно предложила язык с привычным синтаксисом, многие компании, включая IBM спешно переделали свои SVM в JVM. Привычный синтаксис же важнее.
Так Вы имеете в виду «изучение как хобби»? А то можно срачь развести про недостатки С++.
Это так, но в прошлом. В настоящем времени Java — это мощная платформа, явно сильнее чем то, что предлагает Smalltalk и не слабее того, что есть в мире C++
Вы бы на холивор-то не нарывались бы ;)
Если вы не знаете какой-то язык и его экосистему (а Java не просто так хватанула такой кус разработки) — то это не повод пытаться принизить этот язык и возвысить какой-либо другой.
Если вы не знаете какой-то язык и его экосистему (а Java не просто так хватанула такой кус разработки) — то это не повод пытаться принизить этот язык и возвысить какой-либо другой.
С академической точки зрения Java в общем-то не интересна. Синтаксис языка крайне жесткий и для «гимнастики ума» не подходит. Научиться писать код _качественно_ Java тоже не особо стимулирует. Разобраться с анатомией работы компьютера тоже не получится, ибо JVM. ИМХО, Java — это одна из тех платформ, которые надо учить тогда, когда ты сознательно решил работать в этой области. Тогда, когда уже достаточно потратить на изучение самого языка день-два, а остальное время — на те библиотеки и фрейморки, которые нужны для работы.
Если под «гимнастикой ума» понимать то что предлагает например Ruby, то Java конечно не в той категории. Несмотря на ограничения синтаксиса, гибкость Java не подлежит сомнению именно из-за количества паттернов и фраймворков которые ее поддерживают. С академической точки зрения Java (JVM) интересна как первый язык решивший проблему линковки библиотек. Вся та мощь и гибкость которую предоставляют полноценная рефлексия, пост-обработка бутекода, аннотации и класслоадеры никогда не снилась C++ и подобным.
> интересна как первый язык решивший проблему линковки библиотек
Вот не соглашусь. Это важно как раз с _практической_ точки зрения. А платформа для обучения программированию как раз должна иметь минимум автоматики, или хотя бы режим работы без автоматики. Тот же С++ (хотя «на старте» к нему действительно лучше не прикасаться по моему мнению), имеет отличную фичу, в нём вы можете сначала мучиться с ручным управлением жизни объектов, а потом изучить смартпойнтеры, и главное — легко понять, как они устроены. А в Java, если вы новичок в программировании, вы это воспримете как должное, и не будете понимать, что находится «под капотом» у этого механизма. И если с С, Паскаля и С++ вы можете легко перейти на управляемый код, то наоборот это будет весьма болезненно.
Вот не соглашусь. Это важно как раз с _практической_ точки зрения. А платформа для обучения программированию как раз должна иметь минимум автоматики, или хотя бы режим работы без автоматики. Тот же С++ (хотя «на старте» к нему действительно лучше не прикасаться по моему мнению), имеет отличную фичу, в нём вы можете сначала мучиться с ручным управлением жизни объектов, а потом изучить смартпойнтеры, и главное — легко понять, как они устроены. А в Java, если вы новичок в программировании, вы это воспримете как должное, и не будете понимать, что находится «под капотом» у этого механизма. И если с С, Паскаля и С++ вы можете легко перейти на управляемый код, то наоборот это будет весьма болезненно.
Вы хотите сказать что в статье предлагается изучить 8 (!!) языков и все это на стадии «новичок»?
Повторяюсь, я говорил про линковку библиотек, а не управление памятью. Как много людей по Вашему знают что происходит при динамическом подключении .o? Или еще лучше .dll на Windows? Ответ — единицы, остальные «воспринимаю это как данность» (и отлично живут и работают).
Или то-же управление памятью. Кто из C/C++ программистов представляют себе как аллоцируется память? Еще лучше, как она деаллоцируется? А ведь это одна из самых важных характеристик, влияющих на быстродействие программы. Опять же — единицы.
Ну или венец творения — что происходит при ошибках и крашах? В частности при обращении по NULL? Что, «система гарантирует корректность»? Нет, не везде и не всегда. Разные ОС делают это по-разному. И все это необходимо досконально знать чтобы написать минимально-надежную программу.
Простите за прямоту, но мне кажется Вы оперируете какими-то стереотипами что C/C++ сложнее или проще чем Java. В C полно магии на уровне операционки и/или процессора которые нужно хорошо понимать чтобы написать просто корректную программу, я уж не говорю быструю. И наоборот, хорошие Java программисты великолепно разбираются в процессорах, операционках, компиляторах и много в чем другом, что позволяет им выжимать максимум из JVM (те самые случаи когда Java программа быстрее C++ аналога 0_о )
Повторяюсь, я говорил про линковку библиотек, а не управление памятью. Как много людей по Вашему знают что происходит при динамическом подключении .o? Или еще лучше .dll на Windows? Ответ — единицы, остальные «воспринимаю это как данность» (и отлично живут и работают).
Или то-же управление памятью. Кто из C/C++ программистов представляют себе как аллоцируется память? Еще лучше, как она деаллоцируется? А ведь это одна из самых важных характеристик, влияющих на быстродействие программы. Опять же — единицы.
Ну или венец творения — что происходит при ошибках и крашах? В частности при обращении по NULL? Что, «система гарантирует корректность»? Нет, не везде и не всегда. Разные ОС делают это по-разному. И все это необходимо досконально знать чтобы написать минимально-надежную программу.
Простите за прямоту, но мне кажется Вы оперируете какими-то стереотипами что C/C++ сложнее или проще чем Java. В C полно магии на уровне операционки и/или процессора которые нужно хорошо понимать чтобы написать просто корректную программу, я уж не говорю быструю. И наоборот, хорошие Java программисты великолепно разбираются в процессорах, операционках, компиляторах и много в чем другом, что позволяет им выжимать максимум из JVM (те самые случаи когда Java программа быстрее C++ аналога 0_о )
> Как много людей по Вашему знают что происходит при динамическом подключении
Полагаю, большинство программистов, которые пришли в профессию с интересом, а не потому что высокие зарплаты, это знают.
> Кто из C/C++ программистов представляют себе как аллоцируется память?
Из С/С++ программистов также подавляющее большинство. Это один из тех моментов, ради которых их приглашают на работу :) Вот Java-программисты в массе своей не знают, собственно, им оно обычно и не требуется.
> Ну или венец творения — что происходит при ошибках и крашах?
Ничего особенного в фреймах исключений нет. И кстати, С++ программист обычно знает как работает механизм исключений на низком уровне, а для Java-программиста это просто экземпляр класса с информацией об ошибке.
> В C полно магии на уровне операционки и/или процессора
> которые нужно хорошо понимать чтобы написать просто корректную программу
Ну не перегибайте. В С/С++ можно ничего не понимать о работе операционки и процессора, и писать точно такие же программы, как пишут ничего не понимающие программисты на других языках. Единственное, в С надо запомнить одну жизненно важную парадигму — выделил память, не забудь её освободить. Всё остальное уже плюшки.
> мне кажется Вы оперируете какими-то стереотипами что C/C++ сложнее или проще чем Java
Не надо объединять С и С++, это совершенно разные вещи. И да, C++ сложнее чем Java. Значительно сложнее. Это не стереотип. Мне пришлось и Java-программистом не один год поработать, и на С++. Количество абстракций, которыми оперирует программист С++, больше на порядок. Причем я не говорю, что это хорошо, я абсолютно исренне считаю, что это излишняя сложность.
> хорошие Java программисты великолепно разбираются
Хорошие программисты великолепно разбираются во всём. Проблема в том, что они в меньшинстве.
Полагаю, большинство программистов, которые пришли в профессию с интересом, а не потому что высокие зарплаты, это знают.
> Кто из C/C++ программистов представляют себе как аллоцируется память?
Из С/С++ программистов также подавляющее большинство. Это один из тех моментов, ради которых их приглашают на работу :) Вот Java-программисты в массе своей не знают, собственно, им оно обычно и не требуется.
> Ну или венец творения — что происходит при ошибках и крашах?
Ничего особенного в фреймах исключений нет. И кстати, С++ программист обычно знает как работает механизм исключений на низком уровне, а для Java-программиста это просто экземпляр класса с информацией об ошибке.
> В C полно магии на уровне операционки и/или процессора
> которые нужно хорошо понимать чтобы написать просто корректную программу
Ну не перегибайте. В С/С++ можно ничего не понимать о работе операционки и процессора, и писать точно такие же программы, как пишут ничего не понимающие программисты на других языках. Единственное, в С надо запомнить одну жизненно важную парадигму — выделил память, не забудь её освободить. Всё остальное уже плюшки.
> мне кажется Вы оперируете какими-то стереотипами что C/C++ сложнее или проще чем Java
Не надо объединять С и С++, это совершенно разные вещи. И да, C++ сложнее чем Java. Значительно сложнее. Это не стереотип. Мне пришлось и Java-программистом не один год поработать, и на С++. Количество абстракций, которыми оперирует программист С++, больше на порядок. Причем я не говорю, что это хорошо, я абсолютно исренне считаю, что это излишняя сложность.
> хорошие Java программисты великолепно разбираются
Хорошие программисты великолепно разбираются во всём. Проблема в том, что они в меньшинстве.
Ну зачем? В ней предлагаю учить лишь первые 3 по очереди, а после уже выбирать по вкусу. Или, по крайней мере, ознакомиться.
Если Вы от Java в таком восторге, что же будет при знакомстве со Smalltalk, скажем VisualWorks или GemStone?
Ничего не будет. Я уже знаком со Smalltalk.
Вы рассматриваете языки сами по себе, без всего что их окружает. Такой подход совершенно не описывает реальную полезность технологий. Java как язык могла бы спокойно компилироваться в машинный код и это действительно был бы урезанный C++. Я (и некоторые другие) в восторге не от языка, а от JVM-the-platform, и мои комментарии в основном относятся к платформе, а к языку.
Вы рассматриваете языки сами по себе, без всего что их окружает. Такой подход совершенно не описывает реальную полезность технологий. Java как язык могла бы спокойно компилироваться в машинный код и это действительно был бы урезанный C++. Я (и некоторые другие) в восторге не от языка, а от JVM-the-platform, и мои комментарии в основном относятся к платформе, а к языку.
> Научиться писать код _качественно_ Java тоже не особо стимулирует.
Есть минимум две вещи, которым джава способствует.
1. Объектность. Именно потому, что в джаве все есть объект, и под эти объекты практически нет синтаксического сахара, многие принципы ООП более очевидны. Да, тут все манипулируется указателями (кроме примитивов), ни слова ни про стек, ни про кучу, зато можно отлично набить скиллы моделирования иерархий объектов и их взаимодействия.
2. Все же джавой пользуются, как выше верно заметили, в контексте фреймворков, а не голого языка. Фреймворки же — устоявшийся стандарт с собственными жесткими правилами разработки, куда жестче, чем у языка в общем. Что попало куда попало здесь воткнуть уже серьезно сложней.
Есть минимум две вещи, которым джава способствует.
1. Объектность. Именно потому, что в джаве все есть объект, и под эти объекты практически нет синтаксического сахара, многие принципы ООП более очевидны. Да, тут все манипулируется указателями (кроме примитивов), ни слова ни про стек, ни про кучу, зато можно отлично набить скиллы моделирования иерархий объектов и их взаимодействия.
2. Все же джавой пользуются, как выше верно заметили, в контексте фреймворков, а не голого языка. Фреймворки же — устоявшийся стандарт с собственными жесткими правилами разработки, куда жестче, чем у языка в общем. Что попало куда попало здесь воткнуть уже серьезно сложней.
Увеличил Вам карму.
Как начинать изучать языки программирования в школе?
Что касается меня то я не знаю с какого языка начинать но мне кажется, что главным здесь должен быть не язык, а преподаватель который сможет зажечь огонь интереса в глазах ребёнка. А уже на топливе этой страсти и увлечения любой язык пойдёт как по маслу. И наоборот: даже самый «подходящий» язык не переварится если его преподаёт скучный учитель.
Если есть желание можно дать ученикам паяльник в руки и вместе с ними спаять несколько вентилей из транзисторов для демонстрации булевой алгебры. Загоревшимся глазам гораздо интереснее рассказывать о битах и байтах, механике работы процессора, памяти — и им будет чего рассказать на свидании девушке:)
Если создание реального рабочего проекта вызывает восторг у людей — то почему бы и нет. Автор верно упомянул о том как люди ловятся на гуишных приложениях. Обсасывание черствых структур данных — скучное занятие, особенно когда на начальных этапах развития не можешь уловить зачем, для чего, когда эти знания пригодятся и нужно ли тебе вообще это знать в свои -надцать лет. Ведь так хочется «потыкать» кнопочки: они гораздо реальнее и дают мнимую возможность поставить себя рядом с создателями программ с которыми ты работаешь каждый день (помню свои возвышенные чувства и школьную гордость от написания примитивного аудиоплеера на C++Builder:))). Но если работа с абстрактными структурами данных для тебя превращается в захватывающий квест, полон интересных приключений — то я только за.
Мой подход таков — нужно начинать с того, что у тебя зажгёт огонь в глазах и вызовет восторг в душе. А тогда уже в это разгоревшееся пламя понемножку подбрасывать сырые но «правильные» дрова.
Всем побольше интересных увлекательных книг!
Что касается меня то я не знаю с какого языка начинать но мне кажется, что главным здесь должен быть не язык, а преподаватель который сможет зажечь огонь интереса в глазах ребёнка. А уже на топливе этой страсти и увлечения любой язык пойдёт как по маслу. И наоборот: даже самый «подходящий» язык не переварится если его преподаёт скучный учитель.
Если есть желание можно дать ученикам паяльник в руки и вместе с ними спаять несколько вентилей из транзисторов для демонстрации булевой алгебры. Загоревшимся глазам гораздо интереснее рассказывать о битах и байтах, механике работы процессора, памяти — и им будет чего рассказать на свидании девушке:)
Если создание реального рабочего проекта вызывает восторг у людей — то почему бы и нет. Автор верно упомянул о том как люди ловятся на гуишных приложениях. Обсасывание черствых структур данных — скучное занятие, особенно когда на начальных этапах развития не можешь уловить зачем, для чего, когда эти знания пригодятся и нужно ли тебе вообще это знать в свои -надцать лет. Ведь так хочется «потыкать» кнопочки: они гораздо реальнее и дают мнимую возможность поставить себя рядом с создателями программ с которыми ты работаешь каждый день (помню свои возвышенные чувства и школьную гордость от написания примитивного аудиоплеера на C++Builder:))). Но если работа с абстрактными структурами данных для тебя превращается в захватывающий квест, полон интересных приключений — то я только за.
Мой подход таков — нужно начинать с того, что у тебя зажгёт огонь в глазах и вызовет восторг в душе. А тогда уже в это разгоревшееся пламя понемножку подбрасывать сырые но «правильные» дрова.
Всем побольше интересных увлекательных книг!
Так откуда Вы можете знать, что зажгет в Вас огонь, не попробовав? Поэтому начинать надо с Паскаля, потом Си, а потом уже по профессии.
Дело не в том на чём писать, а в том, что писать.
Нужно пробовать)
Я лично пробовал с gwbasic, а потом pascal но не берусь утверждать, что с их нужно начинать потому, что я не проходил иные пути. Мне вот стало интересно если бы я начал двигаться с функциональных языков и алгебраических типов данных.
Я лично пробовал с gwbasic, а потом pascal но не берусь утверждать, что с их нужно начинать потому, что я не проходил иные пути. Мне вот стало интересно если бы я начал двигаться с функциональных языков и алгебраических типов данных.
Правильное обучение это путь от простого к сложному, а не наоборот…
Только вот вопрос простоты — он относительный.
Возьмите какой-нибудь «язык RL». Вот описание:
Это — полное и исчерпывающее описание вполне себе функционального языка программирования. На котором можно писать сортировки и оценивать их сложность, расставлять ферзей и делать многое другое.
Сравните с описанием какого-нибудь С или даже Pascal'я… У нас нет ни указателей, ни «адресной арифметики», ни аллокации памяти — нет вообще ничего кроме символов, термов, выражений и их значений. Куда проще-то?
Возьмите какой-нибудь «язык RL». Вот описание:
Символ — любая последоваьтельность составленная из букв латинского алфавита. При этом большие и маленькие символы мы считаем одинаковыми.
Примеры:
A, B, symbol, AnotherSymbol — символы
НеСимвол, a2, abc-d — не символы
Терм — любой символ, а также любое выражение, заключённое в скобки. При этом выражение — любая последовательность термов (в том числе и пустая), разделённая пробелами.
Примеры:
A B CCC D — выражение из четырёх термов
(A B) — терм, состоящий из одного выражения, которое, в свою очередь, состоит из выражения, состоящего из двух символов в скобках
(()) B CCC — выражение из трёх термов, первый из которых состоит из единственного терма в скобках
Программа на языке RL представляет собой выражение, состоящее из термов специального вида, называемых функциями.
Функция — это выражение следующего вида:
(F (T1… Tn) B)
где
F — символ, называемый именем функции
T1… Tn — символы, называемые аргументами функции
B — терм, называемый телом функции (обязан имать один из представленных ниже видов)
Имена функций, описанных в программе не должны совпадать. Для каждой функции и для каждого набора значений определён результат, вычисляемый по описанным ниже правилам. Результатом работы программы является результат вызова первой функции на аргументах, заданных при запуске программы.
Термы, допустимые в качестве тела функции и их значения:
(abort) — этот терм не имеет параметров и его значением явлется символ undefined
(quote x) — этот терм не имеет параметров и его значением является выражение x
Пусть T1… Tn — термы, Z1… Zn — соответствующие им значения
(first T1) — значением этого терма является первый терм выражения Z1 (если Z1 пусто, то значением является символ undefined)
(bf T1) — значением этого терма является выражение, полученное отбрасыванием первого терма выражения Z1 (если Z1 пусто, то значением является символ undefined)
(expr T1… Tn) — значением этого терма является выражение Z1… Zn
(equal T1 T2) — значением этого терма является символ true если Z1 и Z2 совпадают и символ false, если они различны
(symbol T1) — значением этого терма является символ true если Z1 состоит из одного символа и false — во всех остальных случаях
(if T1 T2 T3) — значением этого терма является символ Z2, если Z1 — это символ true и Z3 — во всех остальных случаях
(br T1) — значением этого терма является Z1 в скобках
(cont T1) — значнием этого терма является выражение X, если Z1 это терм, состоящий из выражения X в скобках, в противном случае значением является символ undefined
(call F T1… Tn) — значением этого терма является значение тела функции F на аргументах Z1… Zn при условии что функция с именем F существует в программе и имеетnаргументов, в противном случае значение этого терма — символ undefined
Это — полное и исчерпывающее описание вполне себе функционального языка программирования. На котором можно писать сортировки и оценивать их сложность, расставлять ферзей и делать многое другое.
Сравните с описанием какого-нибудь С или даже Pascal'я… У нас нет ни указателей, ни «адресной арифметики», ни аллокации памяти — нет вообще ничего кроме символов, термов, выражений и их значений. Куда проще-то?
Так простота в ОБУЧЕНИИ определяется не только количеством ключевых слов, но и понятности их применения для человека, НЕЗНАКОМОГО с программированием. Поэтому сначала императивные ЯП, потом ОО-ЯП, потом Ф-ЯП — именно в таком порядке. Ну или Вы тогда кардинально несогласны со статьей Пола Грэма «Побеждая посредственность», а я с ней согласен ))
Так простота в ОБУЧЕНИИ определяется не только количеством ключевых слов, но и понятности их применения для человека, НЕЗНАКОМОГО с программированием.В этом случае Pascal — оказывается ещё хуже RL'я.
В случае с Pascal'ем у вас появляется куча понятий (память, массивы, изменяемые состояния и прочее, прочее, прочее). Тут же — простейшие понятия, пожалуй даже проще синусов-косинусов. Если вы можете понять что такое квадратный корень или экспонента, то почему для вос возникают сложности с пониманием того, что такое терм?
Ну да, у нас тут аж целая дюжина функций — ну так их не обязательно сразу все вводить. Введя только лишь
first и bf вы уже можете рассказывать про то, как сделать second, а как только у вас появились if и equal — вы можете рассказать как реализовать логические операции. С появлением call — можно уже сделать и арифметику и сортировки (да, собственно, язык становится полным по Тьюрингу), так что больше ничего от языка и не требуется для изучения теории (на практике, конечно, хочется чтобы в языке хотя бы числа были, а в идеале — так даже и строки). А для практики — реализуйте разные варианты вычисления «чисел Фибоначчи» — и уже можно говорить о сложности (экспоненциальная сложность от линейной отличается настолько заметно, что никакие гагагерцы не спасут), кешировании и прочем.Да, в изучении RL'я сразу возникают кучи разных моментов — но это же и хорошо! Тут вот уже обсуждали разницу между «accidental complexity» и «essential complexity». Так вот в RL'е вы с места в карьер сталкиватесь с «essential complexity» (с той самой с которой вам потом придётся бороться столько времени сколько вы будете заниматься программированием) — и научаетесь с ней бороться.
> В случае с Pascal'ем у вас появляется куча понятий…
Да, но все они интуитивно понятны начинающему программисту! Достаточно просто владеть немного математикой.
> Да, в изучении RL'я сразу возникают кучи разных моментов — но это же и хорошо!
Нет, это плохо! Так как это чисто программистские штучки и непонятно ЗАЧЕМ они возникают, с ЧЕМ они борются. То есть Вы предлагаете решения, не обозначив проблемы. Это с точки зрения бритвы Оккама плохо. А если идти путем ИП->ООП->ФП всё очень четко и понятно с точки зрения ОБУЧЕНИЯ, так мы в самой жизни обычно мыслим императивно.
Вы рассматриваете простоту ПРИМЕНЕНИЯ, а речь про ОБУЧЕНИЕ. И это не одно и тоже. Боюсь, что Ваш метод готовит как раз «кодеров» ))
Да, но все они интуитивно понятны начинающему программисту! Достаточно просто владеть немного математикой.
> Да, в изучении RL'я сразу возникают кучи разных моментов — но это же и хорошо!
Нет, это плохо! Так как это чисто программистские штучки и непонятно ЗАЧЕМ они возникают, с ЧЕМ они борются. То есть Вы предлагаете решения, не обозначив проблемы. Это с точки зрения бритвы Оккама плохо. А если идти путем ИП->ООП->ФП всё очень четко и понятно с точки зрения ОБУЧЕНИЯ, так мы в самой жизни обычно мыслим императивно.
Вы рассматриваете простоту ПРИМЕНЕНИЯ, а речь про ОБУЧЕНИЕ. И это не одно и тоже. Боюсь, что Ваш метод готовит как раз «кодеров» ))
Да, но все они интуитивно понятны начинающему программисту!Ой ли? Я видел кучу людей, которые при описании того, что такое «список» (классический, с указателями на элемент до и после) впадали «в ступор» и им требовалось рисовать разные картинки на бумажке, чуть ли не тащить за руку в библиотеку и показывать как там картотека устроена!
Это вам так кажется, что «они все интуитивно понятны», а с RL'ем — у вас есть какие-то проблемы… Потому что понятия Pascal'я вы освоили когда-то давно и уже думаете в этих терминах, а для новичка — вовсе не факт, что Pascal понятнее RL'я.
Контрольный вопрос: вы вообще с Logo когда-нибудь сталкивались? А это, как бы, язык специально созданный для обучения програмированию.
Поиграйтесь с ним, а потом скажите к чему он ближе — к RL'ю или к Pascal'ю…
Так как это чисто программистские штучки и непонятно ЗАЧЕМ они возникают, с ЧЕМ они борются.Они возникают просто потому что у нас такие «правила игры». Вы же не спрашиваете почему конь в шахматах прыгает «буквой Г», а слон ходит «по диагонали»? Вот и тут та же история.
Собственно это вообще главный шаг, через который должен переступить будущий программист: он должен понять, что в компьютере нет ни зверушек, которые мы видим на экране, ни даже текста, который мы редактируем. Всё что представляет из себя компьютер — это нолики и единички (много ноликов и единичек) и некоторые очень странные, но фиксированные (хотя и сложные) правила игры. Игра в бисер этакая. И спрашивать «зачем» во многих случаях бессмысленно — просто потому что нет на этот вопрос ответа. Хотя всегда есть ответ на вопрос «почему» — но во многих случаях ответ на него «ну… потому что так вышло» или, гораздо чаще, «потому что это было нужно для решения задачи, которая сейчас уже не актуальна».
А если идти путем ИП->ООП->ФП всё очень четко и понятно с точки зрения ОБУЧЕНИЯ, так мы в самой жизни обычно мыслим императивно.Если бы мы мыслили императивно, то мы никогда в жизни ложку ко рту бы не поднесли! Тактовая частота «процессора» головного мозга — порядка тысячи герц, время реакции, которое нужно, чтобы не пролить суп — меньше секунды. Так что мыслим мы, вы уж извините, никак не последовательно и не императивно. Мыслим мы как раз функционально. Вот говорим мы императивно, пишем тоже — потому что у нас одна глотка и пара рук.
Вы рассматриваете простоту ПРИМЕНЕНИЯ, а речь про ОБУЧЕНИЕ.Вот как раз применять RL я бы на практике не советовал. Так как в нём нет даже чисел то считать что-нибудь на нём, мянко говоря, небыстро. Это — как раз учебный язык, которые идёт не со стороны того, что в компьютере есть, а со стороны того, что нам от него нужно.
Боюсь, что Ваш метод готовит как раз «кодеров» ))Практика — вещь упрямая. Люди, решившие на RL'е какую-нибудь достаточно сложную задачу, как правило, потом достаточно легко осваивают и Pascal и C++ и любые другие языки. Люди, которые объясняют, что RL — это фигня и учить нужно Visual Basic, которым они уже сейчас отлично владеют — редко когда становятся программистами (хотя часто добиваются успеха в других, смежных, областях).
Ой ли? Я видел кучу людей, которые при описании того, что такое «список»
Мне кажется, подразумевается императивный подход как таковой — он действительно ближе человеку, является прямым аналогом инструкции по выполнению каких-либо действий; вместо списков могут использоваться массивы (на ранней стадии, естественно). Само слово «список» дезориентирует новичка, потому что бытовое «список» аналогично массиву.
Мыслим мы как раз функционально. Вот говорим мы императивно, пишем тоже — потому что у нас одна глотка и пара рук.
Хорошо. Примем на секунду вашу точку зрения; что это меняет? Процессор — императивен, выполняет команды одну за одной. Функциональные языки, как и логические — это абстракция. Протекающая иногда (отсечение в Прологе, например).
Сама жизнь императивна: время течет в одну сторону. Мы не можем сначала пройти в дверь, а потом открыть ее.
Это — как раз учебный язык, которые идёт не со стороны того, что в компьютере есть, а со стороны того, что нам от него нужно.
В таком случае, мы получаем тех же самых людей, которые не понимают ограничений машины. Вот есть у нас функция, вот еще одна, их результат вычисляется условно-мгновенно. Будто бы. А на деле — нет, машина императивна.
как правило, потом достаточно легко осваивают и Pascal и C++ и любые другие языки.
Потому что они ближе и машине, и человеку. Здесь ошибка выжившего: человек, который освоил более абстрактную штуковину, скажем так, «лучше мыслит», поэтому ему легко дадутся императивные языки. Тот, кто мыслит «похуже» (слабо тренирован в обучении), все равно освоит императивную парадигму, а вот на функциональную «мозгов не хватит». Получается иллюзия того, что в первом случае функциональный подход «открыл чакры».
Сама жизнь императивна: время течет в одну сторону.Это у Ньютона время в одну сторону течёт. А вот теория относительности — вносит поправки: там уже далеко не для всех событий можно сказать — что произошло раньше, что позже.
Мы не можем сначала пройти в дверь, а потом открыть ее.Это если мы в гордом одиночестве, да. А вот если у нас открывает дверь Вася, а заходит туда Маша — то она запросто может и «огрести» если Вася зазевается.
Процессор — императивен, выполняет команды одну за одной.Это так в 60е годы было. А сейчас у вас уже в кармане — телефон, где процессор ни разу не исполняет «команды одну за другой» и где «Вася» и «Маша» должны прилагать специальные усилия для того, чтобы в дверях не столкнуться.
Вот есть у нас функция, вот еще одна, их результат вычисляется условно-мгновенно. Будто бы.Пока вы выполняете программы для RL'я на бумажке — да. Но стоит вам запустить реальный интерпретатор — и у вас возникнет совсем другое ощущение. И можно будет поговорить о сложности, затратах памяти и многом другом.
Здесь ошибка выжившего: человек, который освоил более абстрактную штуковину, скажем так, «лучше мыслит», поэтому ему легко дадутся императивные языки.Ошибка выжившего — это как раз у нас сейчас в индустрии. Последние лет 20 разработчики железа вбухивают колоссальные средства в то, чтобы поддерживать иллюзию «императивного железа». На это уходит от 90% и больше «транзисторного бюджета» — и сопоставимое количество энергии. Причём чем дальше в лес — тем сложнее это делать.
Вопрос отказа от императивной парадигмы сегодня — это вопрос времени и денег: пока всё ещё оказывается дешевле эмулировать императивную парадигму (в основном потому что вокруг нас из-за «ошибки выжившего» куча императивного кода), но, как уже было сказано, чем дальше — тем дороже это обходится.
Зачем же учить людей тому, от чего им, рано или поздно, придётся отказываться?
Это у Ньютона время в одну сторону течёт. А вот теория относительности — вносит поправки: там уже далеко не для всех событий можно сказать — что произошло раньше, что позже.
Мы, на секундочку, об обучении программированию и тому, какие концепции легче понимаются за счет присутствия в жизни среднего человека.
Это если мы в гордом одиночестве, да. А вот если у нас открывает дверь Вася, а заходит туда Маша — то она запросто может и «огрести» если Вася зазевается.
Не имеет значения. Это просто два последовательных процесса, выполняемых двумя «ядрами». То, что они действуют параллельно, не отменяет того, что каждый последователен в действиях.
Это так в 60е годы было. А сейчас у вас уже в кармане — телефон, где процессор ни разу не исполняет «команды одну за другой» и где «Вася» и «Маша» должны прилагать специальные усилия для того, чтобы в дверях не столкнуться.
Исполняет так же. Реордеринг, переключение задач — частности. Суть та же — сначала одна команда, затем другая. Деже если это одна команда задачи А, потом одна команда задачи Б. В некоторый промежуток времени, квант, задача последовательна. Переключение — абстракция, каждое ядро исполняет команды императивно.
Как ни крути, объяснить императивный подход на примере двери с 1м человеком, а потом — борьбу двух императивных процессов за разделяемый ресурс на пример двоих проще раз так в 500, чем фнукциональную парадигму. И математика тут не поможет: человек решает задачу(пример, уравнение) последовательно, действиями (это, кстати, контр-пример к вашему «мы мыслим функционально»).
Но стоит вам запустить реальный интерпретатор — и у вас возникнет совсем другое ощущение.
Ощущение, именно ощущение. Запуская Пролог-машину, у меня тоже есть ощущение, что машина выполнила весь вывод, все резолюции за раз. А на деле все тот же императив под капотом. Вот если я спаяю комбинационную схему… то тогда… и то придется иметь дело со скоростью распространения сигнала.
Последние лет 20 разработчики железа вбухивают колоссальные средства в то, чтобы поддерживать иллюзию «императивного железа».
Не императивного железа, а машины. Да, сигнал распространяется параллельно, но мы с ним не работаем. Машина, самый глубокий уровень, который трогают руками — это машинный код (в крайнем случае, микрокод), и здесь все последовательно. У нас есть синхросигнал — аналог того самого времени, которое течет в одну сторону, который обспечивает выполнение шаг за шагом.
Зачем же учить людей тому, от чего им, рано или поздно, придётся отказываться?
Затем что в обозримом (субъективное словечко, алярм) будущем не предвидится массового отказа.
Получается, что ф.п. — это абстракция над императивной машиной, которая является абстракцией над неимперативным железом.
Это пока что еще один уровень абстракции.
Мы, на секундочку, об обучении программированию и тому, какие концепции легче понимаются за счет присутствия в жизни среднего человека.Ни концепций, связанным с функциональным программированием, ни концепций, используемым императивным в жизни обычного человека нет.
Это просто кажется, что какой-нибудь «сборник рецептов» — это «почти программа». Выглядит похоже, но строчка, которая встречается почти в каждом рецепте — перечёркивает всё напрочь. Магическая строчка, выгрядит весьма невинно:
соль, перец — по вкусуНо дело в том, что она неявно вносит в рецепт «здравый смысл», «опыт» и прочие вещи, которых компьютер начисто лишён. И, собственно, будущих «программистов» и «непрограммистов» разделяет именно «принятие» этого факта. Не понимание, а «принятие». Человек может умом понимать, что компьютер — это железяка, гора транзисторов — и больше ничего, но пока он на подсознательном уровне ожидает, что компьютер будет «действовать разумно» — программистом он не станет.
Что самое смешное, так это то, что все эти бесконечные слои абстракций — это попытка сделать-таки компьютер… ну пусть не разумным, но хотя бы не таким патологическим кретином! И обычных людей в обычной жизни часто удаётся обвести вокруг пальца… но задача программиста, собственно, во-многом в том и заключается, чтобы разобраться в тех случаях, когда абстракция «протекает» и иллюзия «разумности» улетучивается!
Потому убедить ученика в этом становится всё сложнее — но это критически важный момент. Вам долго и упорно приходится вдалбливать тот факт, что «машины — это куча транзисторов» в головы ученков.
Либо, как альтернатива — стартовать из точки, где нет ничего лишнего (математические функции и их преобразование в машинные инструкции) и добавить потихоньку всё необходимое.
Практика показывает что результаты — отличаются разительно. Просто потому что наш мозг так устроен, что усвоить что-то ему гораздо проще, чем забыть.
В результате оказывается что при попытке пройтись по цепочке ИП->ООП->ФП слишком многие не доходят до конца.
Это пока что еще один уровень абстракции.В каком-то смысле — да, в каком-то — нет. Сейчас вообще «всё смешалось в доме облонских». Вы про SSA что-нибудь знаете? Почитайте если будет время. Сейчас цепочка во всех современных системах выглядит так: императивный или функциональный язык язык->ФП-временное представление->императивный код->ФП-представление внутри процессора->ФП-железо. Иногда добавляется ещё пара слоёв :-)
В идеале от императивности нужно бы отказаться вообще, но для того, чтобы это реально сделать нужно чтобы цепочка начиналась с ФП-представления. С чем — пока что сложности, но потихоньку процесс идёт: во все современные языки потихоньку-полегоньку идеи ФП добавляются. Десятое правило Гринспена рулит…
Ни концепций, связанным с функциональным программированием, ни концепций, используемым императивным в жизни обычного человека нет.Ох неужели? В любой книге по алгоритмам сказано, что алгоритм — это последовательность действий. В 'Introduction to Algorithms' все примеры императивны. Любой химический или молекулярно-биологический протокол — императивен. Любая инструкция на производстве или в науке — императивна. Прошу прощения, но у Вас религиозный фанатизм.
Прошу прощения, но у Вас религиозный фанатизм.
А у вас то, что называется клиповым мышлением.
Любая инструкция на производстве или в науке — императивна.[Почти любая] инструкция предполагает оперированием понятиями, которые в эту инструкцию не входят. Именно поэтому историки, их читая, проводят годы, чтобы их расшифровать. И потому у китайцев «вдруг» прорыв происходит не когда им удаётся стащить описания техпроцесса, а когда к ним эмигрирует кто-нибудь, кто участвовал в его разработке.
Программирование же — это составление инструкций для абсолютного кретина, который не обладает.
[Почти любая] инструкция предполагает оперированием понятиями, которые в эту инструкцию не входят.
Это не делает ее неимперативной.
Программирование же — это составление инструкций для абсолютного кретина, который не обладает.
Хм… при этом императивного кретина в жизни представить может каждый, а вот функциоанльного — только под ЛСД.
Ни концепций, связанным с функциональным программированием, ни концепций, используемым императивным в жизни обычного человека нет.
Большая часть жизни — императивна, см. пример с дверью. У любого человека. Упомянутый вами фактор субъективизма никакого отношения к обсуждению «императив вс функционал» не имеет. Возьмите не готовку, а кипячение воды в чайнике. Стирку. Совершение покупок. Все императивно, ничего фнукционального нет. Вообще.
Это просто кажется, что какой-нибудь «сборник рецептов» — это «почти программа». Выглядит похоже, но строчка, которая встречается почти в каждом рецепте — перечёркивает всё напрочь. Магическая строчка, выгрядит весьма невинно:
соль, перец — по вкусу
Не просто кажется, а так и есть. Эта строчка применяется императивно: строго после шага n, когда вкус блюда сформирован и его можно ощутить. Не функционально, а строго после шага n.
Потому убедить ученика в этом становится всё сложнее — но это критически важный момент.
На императивном подходе это сделать проще, чем с функциональным. Вот ты показал человеку, что если сначала сделать вывод на экран, а потом спозиционировать курсор, получится лажа, потому что компьютер — тупой исполнитель — и все ясно.
В результате оказывается что при попытке пройтись по цепочке ИП->ООП->ФП слишком многие не доходят до конца.
Разговор немного идет по кругу.
Это, возможно, вызвано тем, что некоторым людям в прицнипе тяжело осилить ФП, в отличие от ИП, которое встречается в жизни, см. пример с дверью. В силу неспособности понимать абстракции (коими является ФП) в принципе.
императивный код->ФП-представление внутри процессора->ФП-железо
Представление внутри процессора императивно, железо функционально тоже только условно: есть скорость распространения сигнала.
В идеале от императивности нужно бы отказаться вообще,
Это невозможно: все вокруг императивно. Комбинационные схемы в ЦП переключаются императивно, что приходится выравнивать тактированием. Даже если вы возьмете аналоговый компьютер, все равно столкнетесь с проблемой выравнивания фаз.
"тащить за руку в библиотеку и показывать как там картотека устроена!"
Лучше показать ученику список ссылок на текст какой ни будь интересной работы — например, подойдет список алфавитного указателя из работы киноведа, посвященной предпоследней версии самого крутого боевика, который идет сейчас в кинотеатрах — там будет понятно, что список страниц со словом "терминатор", "чужой", "клоны", ну, или для девочек — "принцесса Лея" — это последовательный список последовательно (но не рядом стоящих в книге) идущих страниц, где это слово упоминается и страницы различаются по специально предназначенному для этого элементу оформления — номеру страницы.
Чем интереснее и оригинальнее будет Вами придуман пример — тем меньше вам придется вести в библиотеки учеников, только для того, чтобы показать скучнейшую вещь на свете — картотеку, и тем больше времени будет потрачено на программирование и на интереснейшие дискуссии — из области искусств и, опять таки — программирования.
Лучше показать ученику список ссылок на текст какой ни будь интересной работы — например, подойдет список алфавитного указателя из работы киноведа, посвященной предпоследней версии самого крутого боевика, который идет сейчас в кинотеатрах — там будет понятно, что список страниц со словом «терминатор», «чужой», «клоны», ну, или для девочек — «принцесса Лея» — это последовательный список последовательно (но не рядом стоящих в книге) идущих страниц, где это слово упоминается и страницы различаются по специально предназначенному для этого элементу оформления — номеру страницы.Попробуйте — и вы поймёте что половина учащихся решат, что список — это упорядоченное подмножество, а другая половина — осознает, то «это что-то похожее на списк литературы», но будет считать что нет ничего страшного в том, чтобы записать пару ссылок в один элемент типа «Node*» (если мы в C) или "^Node" (если у нас Pascal). И будут обижаться что компилятор какой-нибудь «ну такой простой вещи» не понимает (например что не стоит терять старое значение, если оно нам ещё нужно).
Чем интереснее и оригинальнее будет Вами придуман пример — тем меньше вам придется вести в библиотеки учеников, только для того, чтобы показать скучнейшую вещь на свете — картотеку, и тем больше времени будет потрачено на программирование и на интереснейшие дискуссии — из области искусств и, опять таки — программирования.Дискуссии можно потратить на всякие самые разнообразные темы, но пока обучающийся не поймёт, что компьютер — болван и «не понимает» ничего — успеха не будет.
P.S. Есть такая присказка: хуже дурака может быть только дурак с инициативой. Так вот компьютер — не просто дурак, а законченный кретин. А современные языки не делают его умнее, но дают ему возможность «проявлять инициативу». Чем они и опасны для обучения…
khim
В общем-то Ваш подход понятен и где-то даже оправдан: этакое глобальное научное образование, которое вполне может идти и от сложного к простому. Если ученик в него «вписывается», то все ОК, но дело в том, что далеко не все смогут это сделать (так как это сложней изначально), поэтому отсеятся даже те, кто смог бы кодить на более низком уровне. Например далеко не все нормальные прогеры на ООП любят ФП. Что-ж им уходить с этой работы теперь?
Есть такое распределение в виде пирамиды: внизу кодеры (их много), по-середине программисты (их меньше), на самом верху разработчики языков и парадигм (их мало). И все они полезны. Кто где, становится понятно через время (от года до пяти как минимум) — поэтому обучать лучше снизу вверх.
Как то так…
В общем-то Ваш подход понятен и где-то даже оправдан: этакое глобальное научное образование, которое вполне может идти и от сложного к простому. Если ученик в него «вписывается», то все ОК, но дело в том, что далеко не все смогут это сделать (так как это сложней изначально), поэтому отсеятся даже те, кто смог бы кодить на более низком уровне. Например далеко не все нормальные прогеры на ООП любят ФП. Что-ж им уходить с этой работы теперь?
Есть такое распределение в виде пирамиды: внизу кодеры (их много), по-середине программисты (их меньше), на самом верху разработчики языков и парадигм (их мало). И все они полезны. Кто где, становится понятно через время (от года до пяти как минимум) — поэтому обучать лучше снизу вверх.
Как то так…
Не путайте функциональность мозга с мыслительным процессом.
Мозг — жесткая функциональная асинхронщина.
Человеческое мышление — тотальная императивность.
Мозг — жесткая функциональная асинхронщина.
Человеческое мышление — тотальная императивность.
Переменные и указатели (или как они там называются в Паскале — ссылки?) многие старшеклассники осваивают с большим трудом, если вообще осваивают. Им мешает, как ни странно, знание математики, алгебры. Запись типа x = x + 1 вводит их в ступор.
Именно так. И они же — с лёгостью проходят через RL. Но нет, программисты со стажем будут продолжать рассказывать сказки о том, что ООП — это очень просто, а функциональное программирование — это ужас-ужас… потому что в противном случае встанет вопрос об их собственной профпригодности.
В общем истина, высказанная Планком о физике верна и для программирования: Не следует думать, что новые идеи побеждают путем острых дискуссий, в которых создатели нового переубеждают своих оппонентов. Старые идеи уступают новым таким образом, что носители старого умирают, а новое поколение воспитывается в новых идеях, воспринимая их как нечто само собой разумеющееся.
В общем истина, высказанная Планком о физике верна и для программирования: Не следует думать, что новые идеи побеждают путем острых дискуссий, в которых создатели нового переубеждают своих оппонентов. Старые идеи уступают новым таким образом, что носители старого умирают, а новое поколение воспитывается в новых идеях, воспринимая их как нечто само собой разумеющееся.
У вас, видимо, есть статистически наработанный опыт, чтобы утверждать, что RL более понятен чем императивные конструкции языков программирования? (ООП нужно давать отдельно от программирования и давать по рукам тому, кто даёт их одновременно)
Научных монограмм у меня нет, но так как RL реально использовался для преподавания в школе (я сменил место жительства, так что лет 10 не преподавал — может и до сих пор используется), то могу сказать, что у людей не имеющих опыта программирования RL вообще идёт «в лёгкую» (у них не возникает ненужных вопросов и за один урок они изучают весь RL, а на следующем — уже можно на основе RL'я что-то строить и обсуждать).
У детей с опытом общения с BASIC«ом или, в более новое время, с C# возникают проблемы, но обычно они их быстро преодолевают (очень сильный стимул: им стыдно, когда люди, которых они считают „менее продвинутыми“ их обгоняют).
А вот у профессиональных программистов (на императивных языках, Scheme'ры, понятно, в восторге) — воникает отторжение. Причём не на уровне „ничего не понятно“, а „ну, это слишком сложно, лучше сначала с циклов начать“.
У детей с опытом общения с BASIC«ом или, в более новое время, с C# возникают проблемы, но обычно они их быстро преодолевают (очень сильный стимул: им стыдно, когда люди, которых они считают „менее продвинутыми“ их обгоняют).
А вот у профессиональных программистов (на императивных языках, Scheme'ры, понятно, в восторге) — воникает отторжение. Причём не на уровне „ничего не понятно“, а „ну, это слишком сложно, лучше сначала с циклов начать“.
> А вот у профессиональных программистов (на императивных языках, Scheme'ры, понятно, в восторге) —
> воникает отторжение.
Я вам легко скажу, почему: профессиональный программист знаком с правилом бритвы Оккама. Ребенку-то всё равно. Ему объяснили абстракцию, он её понял и дальше использует. Профессиональный программист же видит _еще одну абстракцию, которая делает всё то же самое каким-то другим путем_, и первая мысль, которая его посещает, звучит как: «Нафига все эти навороты?» Кроме того, профессиональный программист знает, как обычно рождаются многие такие языки: сидит вечером другой скучающий программист, и думает, как бы ему сделать язык, непохожий на С++, чтобы обязательно была новая, интересная, свежая концепция. И начинает творить, для самого себя, чтобы было прикольно. А потом, если pet-проект доживает до стадии готовности, выводит это в свет.
И еще один момент есть: несмотря на обилие функциональных языков, с большей вероятностью обучаемый в жизни столкнется с обычным императивным языком. И поэтому нет смысла что-либо в этом менять. Надо будет что-то функциональное — выучит сам.
> воникает отторжение.
Я вам легко скажу, почему: профессиональный программист знаком с правилом бритвы Оккама. Ребенку-то всё равно. Ему объяснили абстракцию, он её понял и дальше использует. Профессиональный программист же видит _еще одну абстракцию, которая делает всё то же самое каким-то другим путем_, и первая мысль, которая его посещает, звучит как: «Нафига все эти навороты?» Кроме того, профессиональный программист знает, как обычно рождаются многие такие языки: сидит вечером другой скучающий программист, и думает, как бы ему сделать язык, непохожий на С++, чтобы обязательно была новая, интересная, свежая концепция. И начинает творить, для самого себя, чтобы было прикольно. А потом, если pet-проект доживает до стадии готовности, выводит это в свет.
И еще один момент есть: несмотря на обилие функциональных языков, с большей вероятностью обучаемый в жизни столкнется с обычным императивным языком. И поэтому нет смысла что-либо в этом менять. Надо будет что-то функциональное — выучит сам.
> сидит вечером другой скучающий программист, и думает, как бы ему сделать язык, непохожий на С++,
> чтобы обязательно была новая, интересная, свежая концепция
Чтобы избежать недопонимания — собственно, это не камень в огород функциональных языков, а просто фича — так многие языки рождаются :)
> чтобы обязательно была новая, интересная, свежая концепция
Чтобы избежать недопонимания — собственно, это не камень в огород функциональных языков, а просто фича — так многие языки рождаются :)
Надо будет что-то функциональное — выучит сам.
Так в том-то и дело, что обойтись императивным языком можно, наверное, всегда (как и функциональным — они тюринг-полные). Если обучить функциональному, то императивный язык точно понадобится, человек его выучит и будет знать две парадигмы. А если человеку, знающему только императивную попадётся задача, которую эффективнее решить с функциональной парадигмой, то скорее всего он обойдётся императивной, а не будет учить функциональную.
А зачем вообще программирование учить в школе? Откуда этот тренд, что все должны программировать.
> Откуда этот тренд, что все должны программировать.
А нет никакого тренда. В школе не профессиональная подготовка ведется, а дается понимание, что есть, как оно устроено, и что выбирать в дальшейшей жизни.
А нет никакого тренда. В школе не профессиональная подготовка ведется, а дается понимание, что есть, как оно устроено, и что выбирать в дальшейшей жизни.
Соглашусь, НО есть такая гадость как ОГЭ ( 9 классы) и ЕГЭ (11 классы) если в 9 там минимум, то в 11 не зная программирования хорошо не сдать. Это если еще не вспоминать про «школьные олимпиады по информатике», там чистое программирование.
Так что если человек собирается в технические вузы то данное ему необходимо.
Так что если человек собирается в технические вузы то данное ему необходимо.
А зачем вообще биологию учить в школе? Откуда этот тренд, что все должны биоложить?
Я бы скорее с уроками труда сравнил.
Раз такая тема пошла то стоит отметить, что в школе учат кучу всего но редко учат главному: как строить крепкую семью, уметь ладить с людьми: в коллективе на работе и с близкими, развивать своё здоровье, уметь решать задачи, не бояться трудностей, а тему как эффективно обучаться вообще не поднимаем.
> как строить крепкую семью, уметь ладить с людьми: в коллективе на работе и с близкими,
> развивать своё здоровье, уметь решать задачи, не бояться трудностей
А родители ребенку тогда зачем? Кормить его тоже в школе можно :)
> развивать своё здоровье, уметь решать задачи, не бояться трудностей
А родители ребенку тогда зачем? Кормить его тоже в школе можно :)
если в школе не укрепляют здоровье, не учат способствующему жизни знанию, не гибкости и пыту мудрости, не знанию того, что творится под носом, а учат информации об абстрактных вещах то зачем тогда школа?! Ведь потом всему этому они будут обучаться стихийно в курилках, пьянках, семейных скандалах, когда будут нападать на своих родителей и отбиваться потом от своих же детей…
> если в школе не укрепляют здоровье
Не укрепляют. Здоровье укрепляют в санаториях.
> не учат способствующему жизни знанию
Учат, но не как строить семью и как ладить с людьми.
> не гибкости и пыту мудрости
Этому вообще никто не учит. Это человек сам приобретает. Или не приобретает.
> не знанию того, что творится под носом
А что под ним творится?
> зачем тогда школа?
Затем, чтобы ваш ребенок умел читать, писать, считать, и обладал набором базовых знаний, чтобы дальше определить свою профессию и занять место в обществе. Как правильно жениться и какой коньяк лучше пить, эти вопросы находятся вне компетенции школы.
Не укрепляют. Здоровье укрепляют в санаториях.
> не учат способствующему жизни знанию
Учат, но не как строить семью и как ладить с людьми.
> не гибкости и пыту мудрости
Этому вообще никто не учит. Это человек сам приобретает. Или не приобретает.
> не знанию того, что творится под носом
А что под ним творится?
> зачем тогда школа?
Затем, чтобы ваш ребенок умел читать, писать, считать, и обладал набором базовых знаний, чтобы дальше определить свою профессию и занять место в обществе. Как правильно жениться и какой коньяк лучше пить, эти вопросы находятся вне компетенции школы.
как строить крепкую семью, уметь ладить с людьми: в коллективе на работе и с близкими
Это слишком индивидуально, такому не научишь.
развивать своё здоровье
Не только учат, но и непосредственно развивают: внезапно, физкультура.
уметь решать задачи, не бояться трудностей
Частично это делает литература, но она изрядно устарела, поэтому эффект мал.
а тему как эффективно обучаться вообще не поднимаем.
У нас учили разным приемам в рамках уроков психологии.
Каждый программист считает, что программированию должны обучать детей в школе потому, что это вправляет мозги и учит решать конкретные задачи.
Каждый шахматист считает, что шахматам необходимо обучаться в школе так как это структурирует мышление, учит смотреть на ситуацию с разных углов.
Каждый преподаватель боевых искусств считает, что этому должны учить детей в школе не потому, чтобы морды бить людям, а потому, что боевое искусство помогает социализироваться, научиться ладить с людьми, адаптироваться в коллективе.
Список можно продолжить…
Я считаю, что в школе нужно больше учить не знаниям, а навыкам(учиться, ладить в коллективе с людьми, строить крепкую семью и т.д.), которые помогут в жизни: если знания бесполезные то они забудутся, а мастерство, как говорится, не пропьёшь)
Каждый шахматист считает, что шахматам необходимо обучаться в школе так как это структурирует мышление, учит смотреть на ситуацию с разных углов.
Каждый преподаватель боевых искусств считает, что этому должны учить детей в школе не потому, чтобы морды бить людям, а потому, что боевое искусство помогает социализироваться, научиться ладить с людьми, адаптироваться в коллективе.
Список можно продолжить…
Я считаю, что в школе нужно больше учить не знаниям, а навыкам(учиться, ладить в коллективе с людьми, строить крепкую семью и т.д.), которые помогут в жизни: если знания бесполезные то они забудутся, а мастерство, как говорится, не пропьёшь)
Сам изучил и попробовал немало языков, а сейчас в добавок к основной работе преподаю в школе информатику.
Моё мнение: первым нужно учить Си. А вторым мультипарадигменный язык типа Lua или Python. 2 самые лучшие руководства по языкам программирования, которые я брал в руки это Керниган&Ритчи © и Иерусалимски (Lua).
За упоминание С++ или Java сразу бить линейкой по рукам. Школьники, которые не хотят думать, очень падки на сказки про «универсальный язык». Потом превращаются в интеллектуальных инвалидов — остатки умения строить архитектуру программы и алгоритмов рассеиваются и они начинают как обезьяны перетаскивать элементы на формы в VIsual Studio или C++ Builder, вообще не понимая что они делают. Вместо того, чтобы разобраться с GTK а, может быть, даже SDL2.
Моё мнение: первым нужно учить Си. А вторым мультипарадигменный язык типа Lua или Python. 2 самые лучшие руководства по языкам программирования, которые я брал в руки это Керниган&Ритчи © и Иерусалимски (Lua).
За упоминание С++ или Java сразу бить линейкой по рукам. Школьники, которые не хотят думать, очень падки на сказки про «универсальный язык». Потом превращаются в интеллектуальных инвалидов — остатки умения строить архитектуру программы и алгоритмов рассеиваются и они начинают как обезьяны перетаскивать элементы на формы в VIsual Studio или C++ Builder, вообще не понимая что они делают. Вместо того, чтобы разобраться с GTK а, может быть, даже SDL2.
Вот, кстати, да — тоже хотел написать что-то в этом духе. Лучше не начинать обучение программированию с C++/Java/Javascript — эти индус-триальные уродцы появились на свет в результате ректального изнасилования их родителей чуждыми им парадигмами. Рано или поздно освоить, как минимум, один язык из этой троицы таки придётся, но лучше поздно, иначе можно навсегда остаться ментальным инвалидом. Вспоминаю, как сам когда-то пытался понять некую простую концепцию вроде map/reduce/filter — вроде, и понимать-то нечего, да вот беда: объяснение давалось на примере STL-библиотеки, обрабатывающей STL-контейнеры. До сих пор икаю и глаз дёргается.
Начинать, в нынешних реалиях, лучше действительно с С и Питона (по-моему, можно параллельно учить оба сразу) — Питон показывает, как быстро и кратко сделать что-то на высоком уровне, а С — как это всё работает на низком уровне. Потом от С можно пойти в сторону Ассемблера, а от Питона — в сторону Scheme. По-хардкору, можно бы и начать сразу с Ассемблера и Scheme, но они слишком сильно оторваны от повседневной реальности.
Начинать, в нынешних реалиях, лучше действительно с С и Питона (по-моему, можно параллельно учить оба сразу) — Питон показывает, как быстро и кратко сделать что-то на высоком уровне, а С — как это всё работает на низком уровне. Потом от С можно пойти в сторону Ассемблера, а от Питона — в сторону Scheme. По-хардкору, можно бы и начать сразу с Ассемблера и Scheme, но они слишком сильно оторваны от повседневной реальности.
Мне вот всё интересно, чем же вам эти языки-то не угодили?
C++ на базовом уровне — достаточно простоя язык, если не вдаваться в дебри шаблонизаторов и «бить линейком по рукам» за ифдефы — на базовом уровне язык по сложности/эффективности будет мало отличаться от C.
Java — промышленный язык который старательно следует парадигме «написано однажды — запустится везде» (да, не всё так гладко, как хотелось бы, но тем не менее). Чистый несложный язык, пытающийся в важных местах контролировать программиста и дающий при этом максимум свободы (наговнокодить можно… ну так и на C можно так наговнокодить!). Конечно есть вопрос к пониманию работы с памятью… но в конечном счёте и здесь всё не бесплатно, поэтому концепцию управления памятью учить приходится.
JavaScript — мощный быстрый язык позволяющий буквально всё… Такой язык без жёсткого контроля со стороны давать действительно нельзя, но вот чистую алгоритмику на нём изучать — вполне нормальное явление.
В общем, простите, но у меня сложилось впечатление, что «неасилил, потому и ругаю». Я бы тот же C без хорошего преподавателя давать обычным школьникам не решился. Нахрена нам ещё одни говнокодеры кривых драйверов?
C++ на базовом уровне — достаточно простоя язык, если не вдаваться в дебри шаблонизаторов и «бить линейком по рукам» за ифдефы — на базовом уровне язык по сложности/эффективности будет мало отличаться от C.
Java — промышленный язык который старательно следует парадигме «написано однажды — запустится везде» (да, не всё так гладко, как хотелось бы, но тем не менее). Чистый несложный язык, пытающийся в важных местах контролировать программиста и дающий при этом максимум свободы (наговнокодить можно… ну так и на C можно так наговнокодить!). Конечно есть вопрос к пониманию работы с памятью… но в конечном счёте и здесь всё не бесплатно, поэтому концепцию управления памятью учить приходится.
JavaScript — мощный быстрый язык позволяющий буквально всё… Такой язык без жёсткого контроля со стороны давать действительно нельзя, но вот чистую алгоритмику на нём изучать — вполне нормальное явление.
В общем, простите, но у меня сложилось впечатление, что «неасилил, потому и ругаю». Я бы тот же C без хорошего преподавателя давать обычным школьникам не решился. Нахрена нам ещё одни говнокодеры кривых драйверов?
Ну да, если изучать C++ как C с классами — будет просто. Главное, не пытаться потом бить пяткой в грудь, утверждая, что знаешь C++.
> JavaScript — мощный быстрый язык позволяющий буквально всё…
Это вы так пошутили? Это язык без стандартной библиотеки — каждый вынужден использовать сторонние модули. Быстрый — у интерпретируемых языков нет затрат на компиляцию, но скорость выполнения очень низкая. Буквально всё, но только в пределах песочницы, в которой он запущен.
> JavaScript — мощный быстрый язык позволяющий буквально всё…
Это вы так пошутили? Это язык без стандартной библиотеки — каждый вынужден использовать сторонние модули. Быстрый — у интерпретируемых языков нет затрат на компиляцию, но скорость выполнения очень низкая. Буквально всё, но только в пределах песочницы, в которой он запущен.
Если не вдаваться и мало отличаться от С, то это и будет, в сущности, С. Такой нормальный кроссплатформенный высокоуровневый ассемблер. Мне, кстати, не кажется таким уж ужасом использовать С++ как чуть более продвинутый С, хотя, возможно, тут я неправ. А вот использовать С++ для изучения более высокоуровневых концепций — зло. Начнёт студент изучать ООП — он также должен будет изучить всю сиплюсплюсную хрень вроде того, как, когда и в каком порядке вызываются чистые виртуальные приватные конструкторы базовых классов. А так же как, когда и почему они не вызываются. Начнёт студент изучать обработку структур данных — он тут же запутается в угловых скобках, шаблонах, контейнерах, итераторах и компараторах, словно в рукавах смирительной рубашки. Вот скажите, ну зачем, например, для изучения алгоритмов нужно знание того, что ++iterator работает быстрее чем iterator++? Да те же пресловутые указатели, понимание которых считается чуть ли не врождённым дарованием — ну что, казалось бы, сложного: выделил память, попользовался, освободил. А то, что синтаксис С++ в этом отношении запутан и противоречив.
Java — промышленный язык, который старательно держит программиста за идиота, страдающего ООП головного мозга.
Касательно того, что не так с JavaScript… было бы, всё же, некоторым преувеличением ответить «всё!», но по-моему, гораздо быстрее выйдет перечислить не «что не так с JavaScript», а «что так с JavaScript» :)
Что касается «асилил/ниасилил». Я, конечно, не Линус Торвальдс, но более-менее освоил С++ уже довольно давно, на данный момент это мой основной рабочий язык. То, что до сих пор иногда приходится озадаченно чесать репу, потому что не знал, что некая фича С++ работает именно так, как работает — наверное, характеризует негативно до некоторой степени и мои умственные способности тоже, но нам же в программировании нужны не только абсолютные гении, правда?
Может показаться, что я считаю себя сильно умнее создателей С++, Java и JavaScript. Это не так — я понимаю, что у создателей всех трёх этих языков были вполне объективные причины сделать их именно такими, какие они есть. Более того, эти причины мне, в общих чертах, известны. Еще более того, именно по этим причинам данные три языка и стали настолько популярны. Если так, почему не изучать программирование исключительно на них? Я бы воспользовался аналогией из статьи Брукса «No silver bullet»: он использует понятия «essential complexity» и «accidental complexity». Я не уверен, как это красиво перевести на русский, поэтому оставлю, как есть. «Essential complexity» — это сложность, собственно, самой задачи. «Accidental complexity» — это сопутствующие сложности, связанные со средствами, используемыми для решения этой задачи. Перво-наперво надо учиться справляться с essential complexity, а если мы для изучения программирования выбрали C++/Java/JavaScript, получится, скорее, наоборот.
Java — промышленный язык, который старательно держит программиста за идиота, страдающего ООП головного мозга.
Касательно того, что не так с JavaScript… было бы, всё же, некоторым преувеличением ответить «всё!», но по-моему, гораздо быстрее выйдет перечислить не «что не так с JavaScript», а «что так с JavaScript» :)
Что касается «асилил/ниасилил». Я, конечно, не Линус Торвальдс, но более-менее освоил С++ уже довольно давно, на данный момент это мой основной рабочий язык. То, что до сих пор иногда приходится озадаченно чесать репу, потому что не знал, что некая фича С++ работает именно так, как работает — наверное, характеризует негативно до некоторой степени и мои умственные способности тоже, но нам же в программировании нужны не только абсолютные гении, правда?
Может показаться, что я считаю себя сильно умнее создателей С++, Java и JavaScript. Это не так — я понимаю, что у создателей всех трёх этих языков были вполне объективные причины сделать их именно такими, какие они есть. Более того, эти причины мне, в общих чертах, известны. Еще более того, именно по этим причинам данные три языка и стали настолько популярны. Если так, почему не изучать программирование исключительно на них? Я бы воспользовался аналогией из статьи Брукса «No silver bullet»: он использует понятия «essential complexity» и «accidental complexity». Я не уверен, как это красиво перевести на русский, поэтому оставлю, как есть. «Essential complexity» — это сложность, собственно, самой задачи. «Accidental complexity» — это сопутствующие сложности, связанные со средствами, используемыми для решения этой задачи. Перво-наперво надо учиться справляться с essential complexity, а если мы для изучения программирования выбрали C++/Java/JavaScript, получится, скорее, наоборот.
Ну ООП изучать на базе C++, не планируя стать программистом и сделать его своим основным инструментом — это с головой не дружить, согласен. Кстати, описанные проблемы C++ результат того, что единого управляющего развитием центра там нет. Впрочем и бонусы он извлёк из этой же ситуации…
Java — действительно промышленный язык. Который (при незначительном повышении знания) позволяет очень (слишком) многое программисту. Единственное, что он не даёт делать напрямую — управлять памятью. Впрочем да, писать в парадигмах отличных от ООП в Java сложно (хотя процедурный реализуем, да и элементы функционально появились)… Вот только зачем в Java писать в иных парадигмах? Это не минус, это базовый функционал. Хотите функциональщину — берите Scala (только почему-то она не смогла «победить Java»… да и вообще в последнее время некоторое охлаждение к ней идёт). Хотите другую парадигму — ради бога, используйте любой интересный вам язык.
С JavaScript, как с языком для обучения программированию что-то не так? Простите, но это бред. Проблема этого языка — как раз в том что он предельно простой (но с подводными камнями, и уютно разложенными граблями). А из-за того, что он простой к нему лезут те, кто и алгоритмов-то не понимают! В Серьёзной Промышленной Эксплуатации конечно эти все грабли и подводные камни всплывают. Но это ведь уже другая проблема — сперва нужно добиться понимания алгоритмизации от человека. Ну и напоследок отмечу — язык (сам по себе) JavaScript вполне нормальный… мешает ему то же, что и c++ — много плохо совместимых реализаций (впрочем здесь заметны некоторые улучшения) и то, что пишут на нём люди, не понимающие этого языка (порой — от слова «совсем»).
Но речь-то о том, что «Лучше не начинать обучение программированию с C++/Java/Javascript» (окончание этого предложения вообще фееричное...). А начинать, на самом деле, можно на любом языке. Потому что первая задача — познакомить человека с «алгоритмами» и «структурами данных».
В плане обучения программированию «Accidental complexity» — это про сложность написания простых программ (у Java с этим есть небольшие проблемы — всё-таки «хелловорлд» получается достаточно многословный). И для простых программ все обиженные вами языки подходят (равно как и для, собственно, обучения программированию).
А вот дальнейшее обучение (когда человек уже решил стать программистом) должно больше опираться на сферу, в которую хочет войти программист. Просто потому, что это накладывает серьёзные ограничения-фильтры на список выбираемых языков. Ну не получится у вас писать программы для большинства МК на Java/JavaScript (равно как и драйвера устройств). Не получится у вас для веба писать на C/C++ (хотя трансляторы есть… но лучше б их не было). Не разумно писать enterprise-класс приложений на c/c++ (слишком дорогая поддержка и написание). Безусловно я сейчас очень условно поделил ниши и есть «протечки», но в целом ситуация близко к описанной мной ситуации. И тут мы приходим к тому, что если человеку хочется делать веб, то ассемблер ему вообще никуда не упёрся (равно как и C)… ну и зачем их изучать? Может лучше сразу js? Только, так сказать, «на берегу» объяснить, что подводных камней — море. И учить потроха языка придётся глубоко. А помимо языка ещё нужно будет учить либы и фреймворки. При этом в вебе сейчас дикая скорость развития.
Java — действительно промышленный язык. Который (при незначительном повышении знания) позволяет очень (слишком) многое программисту. Единственное, что он не даёт делать напрямую — управлять памятью. Впрочем да, писать в парадигмах отличных от ООП в Java сложно (хотя процедурный реализуем, да и элементы функционально появились)… Вот только зачем в Java писать в иных парадигмах? Это не минус, это базовый функционал. Хотите функциональщину — берите Scala (только почему-то она не смогла «победить Java»… да и вообще в последнее время некоторое охлаждение к ней идёт). Хотите другую парадигму — ради бога, используйте любой интересный вам язык.
С JavaScript, как с языком для обучения программированию что-то не так? Простите, но это бред. Проблема этого языка — как раз в том что он предельно простой (но с подводными камнями, и уютно разложенными граблями). А из-за того, что он простой к нему лезут те, кто и алгоритмов-то не понимают! В Серьёзной Промышленной Эксплуатации конечно эти все грабли и подводные камни всплывают. Но это ведь уже другая проблема — сперва нужно добиться понимания алгоритмизации от человека. Ну и напоследок отмечу — язык (сам по себе) JavaScript вполне нормальный… мешает ему то же, что и c++ — много плохо совместимых реализаций (впрочем здесь заметны некоторые улучшения) и то, что пишут на нём люди, не понимающие этого языка (порой — от слова «совсем»).
Но речь-то о том, что «Лучше не начинать обучение программированию с C++/Java/Javascript» (окончание этого предложения вообще фееричное...). А начинать, на самом деле, можно на любом языке. Потому что первая задача — познакомить человека с «алгоритмами» и «структурами данных».
В плане обучения программированию «Accidental complexity» — это про сложность написания простых программ (у Java с этим есть небольшие проблемы — всё-таки «хелловорлд» получается достаточно многословный). И для простых программ все обиженные вами языки подходят (равно как и для, собственно, обучения программированию).
А вот дальнейшее обучение (когда человек уже решил стать программистом) должно больше опираться на сферу, в которую хочет войти программист. Просто потому, что это накладывает серьёзные ограничения-фильтры на список выбираемых языков. Ну не получится у вас писать программы для большинства МК на Java/JavaScript (равно как и драйвера устройств). Не получится у вас для веба писать на C/C++ (хотя трансляторы есть… но лучше б их не было). Не разумно писать enterprise-класс приложений на c/c++ (слишком дорогая поддержка и написание). Безусловно я сейчас очень условно поделил ниши и есть «протечки», но в целом ситуация близко к описанной мной ситуации. И тут мы приходим к тому, что если человеку хочется делать веб, то ассемблер ему вообще никуда не упёрся (равно как и C)… ну и зачем их изучать? Может лучше сразу js? Только, так сказать, «на берегу» объяснить, что подводных камней — море. И учить потроха языка придётся глубоко. А помимо языка ещё нужно будет учить либы и фреймворки. При этом в вебе сейчас дикая скорость развития.
> Проблема этого языка — как раз в том что он предельно простой
Да нифига он не простой. Он, как бы это точнее назвать, анархический. Когда вы берёте для преподавания обычный императивный язык со строгими правилами, вы рассказываете про типы переменных, про последовательность выполнения кода, и это как раз логично и легко для понимания. В случае JavaScript у вас нет жестких рамок, и многие студенты просто не могут уловить логику в создании программ на нём.
Да нифига он не простой. Он, как бы это точнее назвать, анархический. Когда вы берёте для преподавания обычный императивный язык со строгими правилами, вы рассказываете про типы переменных, про последовательность выполнения кода, и это как раз логично и легко для понимания. В случае JavaScript у вас нет жестких рамок, и многие студенты просто не могут уловить логику в создании программ на нём.
Как раз для веба изучение Си может быть полезно. Вообще придерживаюсь мнения, что хороший программист знает (хотя бы поверхностно) внутреннее устройство используемых инструментов (в частности трансляторов), может, как минимум, залезть в исходники и попытаться понять, почему его программа ведёт себя не так как он ожидает.
== и ===
NaN, которое является числом, но не равно самому себе
И это только первое, что пришло в голову хотя я Js почти не знаю
Я категорически против того, чтобы этим говном пудрить мозги новичкам в программировании.
То, что эта кривая поделка стала так популярна — говорит не о том, что она хороша, а о том, что индустрия часто поощряет не самые лучшие технические решения, а непонятно что.
NaN, которое является числом, но не равно самому себе
И это только первое, что пришло в голову хотя я Js почти не знаю
Я категорически против того, чтобы этим говном пудрить мозги новичкам в программировании.
То, что эта кривая поделка стала так популярна — говорит не о том, что она хороша, а о том, что индустрия часто поощряет не самые лучшие технические решения, а непонятно что.
Я не сомневаюсь, что Брендан Эйк профессионал высокого класса. Но когда он создавал JS, это явно был безответственный поступок. Сделать ЯП за 10 дней на коленке… Похоже, он в тот момент сам всерьёз не относился к этому поделию. Возможно, планировал в скорости заменить его следующей версией. Но кто же знал, что оно так разойдётся.
Отсюда урок: 7 раз отмерь, 1 раз отрежь, особенно если проектируешь систему (т.е. нечто, что будет работать в связке с другими продуктами или использоваться другими людьми). Протоколы взаимодействия, формат файлов, архитектура программы — это самые важные вещи. Всё остальное можно переделать.
Отсюда урок: 7 раз отмерь, 1 раз отрежь, особенно если проектируешь систему (т.е. нечто, что будет работать в связке с другими продуктами или использоваться другими людьми). Протоколы взаимодействия, формат файлов, архитектура программы — это самые важные вещи. Всё остальное можно переделать.
Вроде, NaN есть также и в С++, и в Питоне. И тоже не равен сам себе.
>… единого управляющего развитием центра там нет
Вот сейчас членам «The C++ Standards Committee» обидно было…
Проблемы и бонусы С++ — результат того, что он развивался эволюционно, мучительно пытаясь сохранить обратную совместимость. Был язык С, быстрый, «близкий к металлу», при этом достаточно переносимый. Захотелось объектов. Объекты были уже, допустим, в Смоллтоке — но Смоллток не нужен. И что-то совсем новое, куда объекты хорошо впишутся, мы тоже не хотим. А хотим, чтобы у нас старое на С тоже продолжало работать. Давайте введём объекты в С! К сожалению, физиологическое отверстие, через которое внутрь С можно ввести объекты, только одно — заднепроходное. И вот тут метафора с ректальным изнасилованием мне кажется очень точной. Дальше — больше: хотим обобщённое (или как его там) программирование. Оно уже есть, допустим, в Лиспе — но Лисп не нужен. Давайте введём в С++! К сожалению, физиологическое отверстие для введение осталось всё то же… ну вы понели. Тем не менее, в результате мы и объекты, и обобщённое программирование худо-бедно имеем, язык развивается, программисты не разбегаются кто на Лисп, кто на Смоллток, уже написанный код поддерживается, и вообще жизнь прекрасна. Попытки запилить вместо этого что-то новое, концептуальное и красивое, время от времени предпринимаются, но по степени своей успешности напоминают попытки перевести человечество на язык Эсперанто :)
Вот сейчас членам «The C++ Standards Committee» обидно было…
Проблемы и бонусы С++ — результат того, что он развивался эволюционно, мучительно пытаясь сохранить обратную совместимость. Был язык С, быстрый, «близкий к металлу», при этом достаточно переносимый. Захотелось объектов. Объекты были уже, допустим, в Смоллтоке — но Смоллток не нужен. И что-то совсем новое, куда объекты хорошо впишутся, мы тоже не хотим. А хотим, чтобы у нас старое на С тоже продолжало работать. Давайте введём объекты в С! К сожалению, физиологическое отверстие, через которое внутрь С можно ввести объекты, только одно — заднепроходное. И вот тут метафора с ректальным изнасилованием мне кажется очень точной. Дальше — больше: хотим обобщённое (или как его там) программирование. Оно уже есть, допустим, в Лиспе — но Лисп не нужен. Давайте введём в С++! К сожалению, физиологическое отверстие для введение осталось всё то же… ну вы понели. Тем не менее, в результате мы и объекты, и обобщённое программирование худо-бедно имеем, язык развивается, программисты не разбегаются кто на Лисп, кто на Смоллток, уже написанный код поддерживается, и вообще жизнь прекрасна. Попытки запилить вместо этого что-то новое, концептуальное и красивое, время от времени предпринимаются, но по степени своей успешности напоминают попытки перевести человечество на язык Эсперанто :)
Опять эти сказки про универсальный язык.
Инструмент нужно выбирать под задачу. В программировании есть свои специализации (highload, bigdata, desktop, server backend, server frontent, embedded, machine learning,… ) и если ты посмотришь внимательно на все эти группы технологий, то там давно уже «универсальный» С++ вытеснен или активно вытесняется более совершенными (хоть и узкоспециализированными) инструментами
Инструмент нужно выбирать под задачу. В программировании есть свои специализации (highload, bigdata, desktop, server backend, server frontent, embedded, machine learning,… ) и если ты посмотришь внимательно на все эти группы технологий, то там давно уже «универсальный» С++ вытеснен или активно вытесняется более совершенными (хоть и узкоспециализированными) инструментами
Тем не менее, Java такое развитие пошло на пользу.
Вот так и хочется ответить всем и разом… но у меня лимит, поэтому буду отвечать всем здесь.
Гугл такую структуру не нашёл. Комитет стандартов C++ в ISO — да есть. Здесь две проблемы — очень много Undefined Behavior (оставляется на откуп компиляторам), и вторая — комитет явно имеет проблемы в однородности — раз уж с модульностью прокатило в текущем стандарте. Так что… не на что обижаться-то.
Вот Java действительно развивалась эволюционно. Вероятность того, что код, написанный для java 1.2 сломается в JVM 8ой — весьма невелика. Единственное, что потребуется — притащить с собой классы, которых уже нет в стандартной библиотеке.
Впрочем для меня это не только плюс, но и жирнющий минус — слишком много это за собой тащит проблем.
DrPass «многие студенты просто не могут уловить логику в создании программ на нём» стоит переписать как «многие преподаватели просто не умеют объяснять алгоритмы, поэтому им обязательно требуются костыли строгой типизации». Чтобы вы не думали, что я наговариваю на какой-либо язык — основная моя разработка крутится в Java, но приходится также активно использовать и JS (ибо почти фуллстек с уклоном в бекэнд). И динамическая типизация писать алгоритмы не мешает совершенно. Вот для «писать надёжно» и прочих фишек требуется дополнительные усилия (линтер, статический анализ кода, стайл-гайды, ...). А вот базу (алгоритмы) на JS писать ничто не мешает.
VolCh Изучение C — сомнительно. Веб слишком далёк от железа, чтобы глубоко в железо погружаться для его изучения… Хотя если есть желание писать в том числе VM исполняющую код — тогда действительно нужен. И да, я под вебом подразумеваю только UI (брауезрную) часть. Для этого веба полезней знать принципы работы с памятью в managed VM.
evocatus и с какой вероятностью студент/школьник напорется на проблему с ==/=== или с NaN? Особенно если он _не_планирует_ стать программистом? (Впрочем мне легче понимать разницу в проверках эквивалентности — в Java == и .equals() тоже имеют существенные различия в работе)
PS вообще же, программирование (в школах) лучше давать на визуальных языках типа скретч (https://scratch.mit.edu/).
В институтах на непрофильных специальностях — скриптовой, и только для тех, кто планирует стать разработчиком есть смысл начинать с компилируемых (возможно даже с управлением памятью).
Но перед этим всё-таки создать нормальный курс «ввод в специальность» в котором хоть как-то разъяснить разницу между языками — пусть сразу сами выберут (всё легче будет изучать — мотивация будет эффективней).
И да — паскаля в этом списке нет, т.к. имеет слишком малую распространённость… Да и эффективность современного паскаля под большим вопросом.
Гугл такую структуру не нашёл. Комитет стандартов C++ в ISO — да есть. Здесь две проблемы — очень много Undefined Behavior (оставляется на откуп компиляторам), и вторая — комитет явно имеет проблемы в однородности — раз уж с модульностью прокатило в текущем стандарте. Так что… не на что обижаться-то.
Вот Java действительно развивалась эволюционно. Вероятность того, что код, написанный для java 1.2 сломается в JVM 8ой — весьма невелика. Единственное, что потребуется — притащить с собой классы, которых уже нет в стандартной библиотеке.
Впрочем для меня это не только плюс, но и жирнющий минус — слишком много это за собой тащит проблем.
DrPass «многие студенты просто не могут уловить логику в создании программ на нём» стоит переписать как «многие преподаватели просто не умеют объяснять алгоритмы, поэтому им обязательно требуются костыли строгой типизации». Чтобы вы не думали, что я наговариваю на какой-либо язык — основная моя разработка крутится в Java, но приходится также активно использовать и JS (ибо почти фуллстек с уклоном в бекэнд). И динамическая типизация писать алгоритмы не мешает совершенно. Вот для «писать надёжно» и прочих фишек требуется дополнительные усилия (линтер, статический анализ кода, стайл-гайды, ...). А вот базу (алгоритмы) на JS писать ничто не мешает.
VolCh Изучение C — сомнительно. Веб слишком далёк от железа, чтобы глубоко в железо погружаться для его изучения… Хотя если есть желание писать в том числе VM исполняющую код — тогда действительно нужен. И да, я под вебом подразумеваю только UI (брауезрную) часть. Для этого веба полезней знать принципы работы с памятью в managed VM.
evocatus и с какой вероятностью студент/школьник напорется на проблему с ==/=== или с NaN? Особенно если он _не_планирует_ стать программистом? (Впрочем мне легче понимать разницу в проверках эквивалентности — в Java == и .equals() тоже имеют существенные различия в работе)
PS вообще же, программирование (в школах) лучше давать на визуальных языках типа скретч (https://scratch.mit.edu/).
В институтах на непрофильных специальностях — скриптовой, и только для тех, кто планирует стать разработчиком есть смысл начинать с компилируемых (возможно даже с управлением памятью).
Но перед этим всё-таки создать нормальный курс «ввод в специальность» в котором хоть как-то разъяснить разницу между языками — пусть сразу сами выберут (всё легче будет изучать — мотивация будет эффективней).
И да — паскаля в этом списке нет, т.к. имеет слишком малую распространённость… Да и эффективность современного паскаля под большим вопросом.
Изучение C — сомнительно. Веб слишком далёк от железа, чтобы глубоко в железо погружаться для его изучения… Хотя если есть желание писать в том числе VM исполняющую код — тогда действительно нужен. И да, я под вебом подразумеваю только UI (брауезрную) часть. Для этого веба полезней знать принципы работы с памятью в managed VM.
Я не только (и даже не столько) браузерную часть имею в виду, а, скорее, бэкенд. И не «виртуальный». Если о виртуальной машине речь (Java, .Net и т. п.), то изучать надо её, а не Си.
Что касается «асилил/ниасилил». Я, конечно, не Линус Торвальдс, но более-менее освоил С++ уже довольно давно, на данный момент это мой основной рабочий язык.
Иронично — Линус говорил, что C++ — ужасный язык, а люди, использующие его, лучше бы никогда не подходили к ядру Линукса ;)
Вы уж извините :)
> JavaScript — мощный быстрый язык позволяющий буквально всё… Такой язык без жёсткого контроля со стороны давать действительно нельзя, но вот чистую алгоритмику на нём изучать — вполне нормальное явление.
У Вас ошибка в слове JavaScript. Судя по контексту, Вы имели в виду ассемблер.
> JavaScript — мощный быстрый язык позволяющий буквально всё… Такой язык без жёсткого контроля со стороны давать действительно нельзя, но вот чистую алгоритмику на нём изучать — вполне нормальное явление.
У Вас ошибка в слове JavaScript. Судя по контексту, Вы имели в виду ассемблер.
PS: Никакого жесткого контроля за обучением не нужно — кидаешь, либо выплывает, либо нет. Причем желательно в операционной системе, где нет никаких песочниц, контроля операций с памятью и дисковых операций и тд. Пока человек не ошибется, например, инкрементировав не тот регистр (или переменную, не суть), и не пропишет аккуратно весь диск нулевыми секторами через дорожку вместо того, чтобы заполнить один цилиндр — он ничего не понял. Пока не поиграл сам с собой в памяти приложения в core wars — он ничего не понял. Пока он не прострелил себе ногу — он ничего не понял. Пока он не научился писать классы и имплементировать ООП или иную ООП головного мозга на любом языке, который как бы это все не поддерживает — он ничего не понял. Все это имхо, кмк, etc.
> Судя по контексту, Вы имели в виду ассемблер
Вообще, судя по контексту, это был Паскаль :) Я бы не стал пытаться преподавать чистую алгоритмику на ассемблере, где две трети операций будут связаны не с выполнением алгоритма, а с обеспечением костылей «где и как сохранить данные». Да и мощным я бы его постеснялся назвать. Мощность языка определяет производительность программиста, а не программ.
Вообще, судя по контексту, это был Паскаль :) Я бы не стал пытаться преподавать чистую алгоритмику на ассемблере, где две трети операций будут связаны не с выполнением алгоритма, а с обеспечением костылей «где и как сохранить данные». Да и мощным я бы его постеснялся назвать. Мощность языка определяет производительность программиста, а не программ.
Поясню, раз ввёл в заблуждение общими терминами…
Мощный язык — язык, позволяющий реализацию достаточно широкого спектра алгоритмов. При этом для популярных алгоритмов известны готовые решения.
Быстрый язык — язык, минимально втыкающий палки в колёса при попытке написать небольшую программку (мы ведь про базовое обучение — там нет места крупным проектам).
Надеюсь больше не будет недопонимания в смысле слов, который я вкладывал в фразу.
PS хабр меня таки вынудит написать статью… раз в час комментировать… тяжело…
Мощный язык — язык, позволяющий реализацию достаточно широкого спектра алгоритмов. При этом для популярных алгоритмов известны готовые решения.
Быстрый язык — язык, минимально втыкающий палки в колёса при попытке написать небольшую программку (мы ведь про базовое обучение — там нет места крупным проектам).
Надеюсь больше не будет недопонимания в смысле слов, который я вкладывал в фразу.
PS хабр меня таки вынудит написать статью… раз в час комментировать… тяжело…
> Мощный язык — язык, позволяющий реализацию достаточно широкого спектра алгоритмов
Дык, любой Тьюринг-полный язык позволяет реализовать какие угодно алгоритмы. Мощность языка определяется не этим, а тем, сколько времени потратит программист на реализацию. Чем в языке больше разнообразных конструкций, тем он мощнее.
> Быстрый язык — язык, минимально втыкающий палки в колёса при попытке написать небольшую программку
А подавляющее большинство языков не создают сложностей с небольшими программами :) Вопрос больше лежит в области наличия библиотек под типовые задачи.
Дык, любой Тьюринг-полный язык позволяет реализовать какие угодно алгоритмы. Мощность языка определяется не этим, а тем, сколько времени потратит программист на реализацию. Чем в языке больше разнообразных конструкций, тем он мощнее.
> Быстрый язык — язык, минимально втыкающий палки в колёса при попытке написать небольшую программку
А подавляющее большинство языков не создают сложностей с небольшими программами :) Вопрос больше лежит в области наличия библиотек под типовые задачи.
Мощность языка определяется не этим, а тем, сколько времени потратит программист на реализацию. Чем в языке больше разнообразных конструкций, тем он мощнее.
Не совпадающие определения. Если конструкций слишком много, и области их применения пересекаются, то можно потратить много времени в процессе выбора а какую же конструкцию использовать. Грубо, то ли от абстрактного класса наследоваться, то ли интерфейс реализовывать.
Серьезно, вы много тратите времени на дилемму, реализовывать интерфейс или наследоваться от абстрактного класса? :) Я думаю, не ошибусь, если скажу, что с тех пор, как вы это сделали несколько раз, вы перестали над этим задумываться. Если вы программируете, а не изучаете новый для вас язык, то вы имеете понимание, какую конструкцию где лучше применять. Вы имеете набор привычных для вас паттернов разработки, и таких ситуаций у вас просто не возникает.
А на кой ляд нужен «C++ на базовом уровне»? Если он «по сложности/эффективности будет мало отличаться от C».
Да не будут школьники программистами на Си только потому что его изучали на уроках. Большинство вообще не будут программистами, а те, кто будут, успеют изучить ещё немало новых языков и технологий прежде чем начать профессиональную карьеру. Зато понимание того, что такое «выстрелить себе в ногу» в массивах и указателях будет очень полезно. Более менее адекватное представление о том как вообще выполняется программа на компьютере, способность оценить более мощные языки.
Да не будут школьники программистами на Си только потому что его изучали на уроках. Большинство вообще не будут программистами, а те, кто будут, успеют изучить ещё немало новых языков и технологий прежде чем начать профессиональную карьеру. Зато понимание того, что такое «выстрелить себе в ногу» в массивах и указателях будет очень полезно. Более менее адекватное представление о том как вообще выполняется программа на компьютере, способность оценить более мощные языки.
Мне кажется, лучше начать изучение программирования с алгоритмов и объяснения того, что компьютер — это не крутой магический ящик, который все может, а наитупейшая коробка с феноминальными памятью и скоростью вычислений.
Помню свой первый урок в пятом классе на эту тему: учитель на себе продемонстрировал как «думает» машина — нам надо было давать ему команды, чтобы он встал, взял мелок и начертил на доске линию с одного края до другого. С его фразами «а это как?» или «я этого не знаю и пока не умею» мы поняли что такое инстукции, переменные, константы, циклы и условия. Следующим нашим шагом стало понимание алгоритма работы наипростейшего процессора, и только потом перенос его на QBasic (я ни коем образом не говорю, что сначала надо именно его изучать). Все было интересно, сразу понятно зачем оно нужно и уже легко выполнимо. А вот второй группе класса не повезло — их сразу посадили за компы рассказывая что такое монитор, клавиатура, мышка, как ими пользоваться, как рисовать в паинте, вводить текст в ворде. Когда их посадили рисовать в QBasic'е все встали в ступор и возник вопрос: «А зачем это делать в бейсике, когда можно проще и быстрее нарисовать в паинте?»
В итоге, повторюсь, как мне кажется, упор нужно делать на развитие алгоритмического мышления и выбирать язык опираясь на различные данные — количество выделенных часов, возраст школьников, их скорость восприятия информации, требования к программе обучения итд. Боюсь, если бы мы в пятом классе начали с Си, то программа обучения очень сильно растянулась и у нас запал потух. В итоге мы бы к концу года знали синтаксис Си, но не более. А так первый год обучения информатике нам рассказал о том, что разработка — это очень интересно и дальше у нас понеслась родимая: паскаль и в концовке Си. На сегодняшний день я бы тоже паскаль заменил питоном, но все равно не стал бы ставить его (питон) в качестве первого ЯП для изучения. Почему мы сразу не сели за паскаль — я не знаю. Может из-за «лишних» обязательных требований самого языка, которые будут отвлекать от алгоритмов, а может еще что-то. Честно на знаю, благо и не преподаю.
P.S. Возможно сегодня для вовлечения в процесс можно использовать роботехнику, но я сам даже не щупал нынешних роботов, так что это только предположение.
Помню свой первый урок в пятом классе на эту тему: учитель на себе продемонстрировал как «думает» машина — нам надо было давать ему команды, чтобы он встал, взял мелок и начертил на доске линию с одного края до другого. С его фразами «а это как?» или «я этого не знаю и пока не умею» мы поняли что такое инстукции, переменные, константы, циклы и условия. Следующим нашим шагом стало понимание алгоритма работы наипростейшего процессора, и только потом перенос его на QBasic (я ни коем образом не говорю, что сначала надо именно его изучать). Все было интересно, сразу понятно зачем оно нужно и уже легко выполнимо. А вот второй группе класса не повезло — их сразу посадили за компы рассказывая что такое монитор, клавиатура, мышка, как ими пользоваться, как рисовать в паинте, вводить текст в ворде. Когда их посадили рисовать в QBasic'е все встали в ступор и возник вопрос: «А зачем это делать в бейсике, когда можно проще и быстрее нарисовать в паинте?»
В итоге, повторюсь, как мне кажется, упор нужно делать на развитие алгоритмического мышления и выбирать язык опираясь на различные данные — количество выделенных часов, возраст школьников, их скорость восприятия информации, требования к программе обучения итд. Боюсь, если бы мы в пятом классе начали с Си, то программа обучения очень сильно растянулась и у нас запал потух. В итоге мы бы к концу года знали синтаксис Си, но не более. А так первый год обучения информатике нам рассказал о том, что разработка — это очень интересно и дальше у нас понеслась родимая: паскаль и в концовке Си. На сегодняшний день я бы тоже паскаль заменил питоном, но все равно не стал бы ставить его (питон) в качестве первого ЯП для изучения. Почему мы сразу не сели за паскаль — я не знаю. Может из-за «лишних» обязательных требований самого языка, которые будут отвлекать от алгоритмов, а может еще что-то. Честно на знаю, благо и не преподаю.
P.S. Возможно сегодня для вовлечения в процесс можно использовать роботехнику, но я сам даже не щупал нынешних роботов, так что это только предположение.
Мне кажется, лучше начать изучение программирования с алгоритмов и объяснения того, что компьютер — это не крутой магический ящик, который все может, а наитупейшая коробка с феноминальными памятью и скоростью вычислений.Проблема в том, что не все языки для этого подходят. Pascal, C, даже чёртов QBasic — подходят, а вот C# или Java — нет.
Потому что там — слишком много магии. Потому что если у вас что-то «рассыпается» — вы не понимаете что делать.
Это как если бы на уроках химии рассказывали не про ряд напряжений и электронные оболочки, а ограничивались бы тем, что показывали эффектные реакции и объясняли как производить дистилляцию и отжиг, но не объясняли — что там при этом происходит внутри.
Бред? Но почему тогда мы считаем что при обучении программированию можно обойтись формочками и крестиками-ноликами?
При обучении программированию учеников в школе вполне можно обойтись. На уроках программирования рассказывают, что происходит внутри на некотором уровне абстракции. Как и на уроках химии рассказывают о реакциях в терминах химии, а не квантовой физики.
Как и на уроках химии рассказывают о реакциях в терминах химии, а не квантовой физики.Всё-таки базовые вещи в программировании — это сложность вычислений и потребность в памяти, а не формочки. Так что «уровень химии» — это рассказ про разного рода КМП и Дейкстра.
А «формочки» — это уровень не химии, а алхимии. Слили два раствора вместе — хлопок и дым пошёл. Что там произошло внутри — нам неважно и неинтересно.
А уровень «квантовой физики» в программировании тоже есть — это разного рода эффекты, связанные с кешами процессора, MOESI протоколами и эффектами, которые из-за этого в программе возникают. Выделение/освобождение памяти — где-то на грани (все понимают, что malloc и free работают не константное время — но ситуации, где это важно и где нужно оптимизировал аллокатор — встречаются на практике не так уж часто). И тут я согласен — туда лезть по первости не нужно. Но если вы не понимаете, что работа со строками всегда чревата проблемами — то какой, нафиг, вы программист?
Я честно не понимаю, что именно вы хотели именно мне сказать и почему спрашиваете меня о бреде с «формочками и крестиками-ноликами». Если вы придрались к тому, что пятиклассникам надо рассказать о том, что компьютер — это не магия, а тупица с феноминальными памятью и скоростью вычислений, то смею вас заверить в том, что бессмысленно им первым делом объяснять про нехватку памяти и сложность вычислений. Они же сами видят, что машина хранит тонны информации которая у них в голове не поместится и работает с ней в мгновение ока.
Я не согласен, что базовые вещи для начала обучения программированию — это сложность вычислений и потребность в памяти. Важно правильно выбрать уровень абстракции и дальше работать в двух направлениях: повышение уровня абстракции и более глубокое погружение в нюансы.
Хотел привести пример на самом простом — математические науки, но раз уж началась физика, то пусть будет она.
Надеюсь, согласитесь, что программа по физике для школы составлена адекватно? На нее и будем опираться. Если мне не изменяет память, то изучение физики начинается с механики: взяли уровень абстракции — абсолютно упругое тело, идеальные закрытые системы… Считается легко, видно явно. Дальше в течении нескольких лет с одной стороны идет углубление чуть-ли не до кварков, но с другой стороны начинается и повышение уровня абстракции до гравитационного воздействия планет и это еще без каких-либо легких тонкостей в виде коэрцитивной силы магнитомягких материалов или силы воздействия солнечного излучения на тела в нашей системе. В ходе обучения постепенно происходит доосмысление предыдущего материала и это нормальный адекватный естественный процесс.
В итоге в самом начале обучения программированию/информатике у школьников надо развивать алгоритмическое мышление и способность масштабировать мысли.
Насчет первого ЯП, на мой взгляд, это точно не Си. Скорее всего, это как начать изучение физики с уровня атомов и начать двигаться к квантам с галактиками. Или математику начать рассказом о мнимой единице.
Мне кажется, что лучше всего первым использовать ЯП, который они больше нигде использовать не будут. Попробовать, посмотреть, освоиться и перейти к нормальному.
На самом деле мне даже стало интересно, что вы сможете предложить в качестве старта для изучения 10-ти летним детям.
Я не согласен, что базовые вещи для начала обучения программированию — это сложность вычислений и потребность в памяти. Важно правильно выбрать уровень абстракции и дальше работать в двух направлениях: повышение уровня абстракции и более глубокое погружение в нюансы.
Хотел привести пример на самом простом — математические науки, но раз уж началась физика, то пусть будет она.
Надеюсь, согласитесь, что программа по физике для школы составлена адекватно? На нее и будем опираться. Если мне не изменяет память, то изучение физики начинается с механики: взяли уровень абстракции — абсолютно упругое тело, идеальные закрытые системы… Считается легко, видно явно. Дальше в течении нескольких лет с одной стороны идет углубление чуть-ли не до кварков, но с другой стороны начинается и повышение уровня абстракции до гравитационного воздействия планет и это еще без каких-либо легких тонкостей в виде коэрцитивной силы магнитомягких материалов или силы воздействия солнечного излучения на тела в нашей системе. В ходе обучения постепенно происходит доосмысление предыдущего материала и это нормальный адекватный естественный процесс.
В итоге в самом начале обучения программированию/информатике у школьников надо развивать алгоритмическое мышление и способность масштабировать мысли.
Насчет первого ЯП, на мой взгляд, это точно не Си. Скорее всего, это как начать изучение физики с уровня атомов и начать двигаться к квантам с галактиками. Или математику начать рассказом о мнимой единице.
Мне кажется, что лучше всего первым использовать ЯП, который они больше нигде использовать не будут. Попробовать, посмотреть, освоиться и перейти к нормальному.
На самом деле мне даже стало интересно, что вы сможете предложить в качестве старта для изучения 10-ти летним детям.
Хотите «абсолютно упругие тела» — возьмите какие-нибудь математические абстракции типа тех, которые я описывал выше.
Сегодняшнее же обучение программированию пропускает кучу этапов и начинает с «магических заклинаний», так что с ограниченностью ресурсов человек сталкивается зачастую не в процессе обучению, а после нескольких лет работы. В результате — куча времени и сил уходит на то, чтобы отсеять этих горе-деятелей на собеседованиях и куча обид, когда студентку-разработчицу под iOS приходится отчислять за профнепригодность.
Мне кажется, что лучше всего первым использовать ЯП, который они больше нигде использовать не будут.Чем тот же Pascal не годится?
На самом деле мне даже стало интересно, что вы сможете предложить в качестве старта для изучения 10-ти летним детям.Я вот вообще не уверен, что 10-леним детям нужно программирование преподавать. Физику — тоже не с первого класса в школе преподают.
Они же сами видят, что машина хранит тонны информации которая у них в голове не поместится и работает с ней в мгновение ока.Вот это — и есть самая большая проблема современного, с позволения сказать, «обучения программированию». Когда для детей программируемые игрушки начинались с какого-нибудь Big Trakа, а програмиирование осваивалось на каком-нибудь Б3-34, то никаких иллюзий по поводу возможностей компьютеров не возникало. И было чётко понятно, что компьютер — это всего лишь «коробка с транзисторами». Пусть и побольше немного, чем калькулятор.
Сегодняшнее же обучение программированию пропускает кучу этапов и начинает с «магических заклинаний», так что с ограниченностью ресурсов человек сталкивается зачастую не в процессе обучению, а после нескольких лет работы. В результате — куча времени и сил уходит на то, чтобы отсеять этих горе-деятелей на собеседованиях и куча обид, когда студентку-разработчицу под iOS приходится отчислять за профнепригодность.
1. Вы честно не понимаете что описание .RL сложно для восприятия относительно Pascal'я? Там абсолютно другой слой восприятия. Простота и краткость описания не обязательно идут в ногу.
2. Где я утверждал, что Pascal не годится?
3. А я уверен, что в наш век уже нужно давать азы программирования для понимания самого направления наук. Самое позднее для старта — 8й класс. Мир вокруг нас слишком быстро меняется.
35 лет тому назад нас не окружали универсальные резво думающие машины. Да, надо дать понять, что компьютер — это буквально коробка с транзисторами, но дико резвая коробка, иначе это понимание ничего не даст — время уже не то. Работать напрямую с регистрами процессора и стеком памяти надо тому, кто выбрал для себя это направление. Вы же не удивляетесь, почему это на алгебре не рассказывают про функционал.
4. Может быть я вам открою тайну, но во всех областях деятельности:
А) Есть тонна нюансов познается в работе, а не на обучении. Вы собираетесь учить нюансам, которые с большой вероятностью не повстречаются людям? Лучше дать удочку с сачком, а не кормить ведром мальков.
Б) Есть люди, не способные осилить — они просто не способны думать в нужном направлении. Они просто пошли за розовыми мечтами или еще по какой причине оказались в области, но ошиблись.
Меня самого очень часто вводит в ступор отсутствия способности думать и всепоглощающая лень, но я не считаю, что нужно учить программировать на, грубо говоря, транзисторах — для этого более специализированное направление.
P.S. Насчет лени сразу вспоминается несколько моментов:
— Однажды разработчику JS на NodeJS надо было что-то написать на Си и он поинтересовался «а какой пакетный менеджер у Си?»
— Массовое поголовное использование парострочных (утрированно) готовых решений https://habrahabr.ru/post/280039/
— Использование внешней ссылки при импорте https://github.com/docker/docker/blob/master/cli/flagerrors.go
2. Где я утверждал, что Pascal не годится?
3. А я уверен, что в наш век уже нужно давать азы программирования для понимания самого направления наук. Самое позднее для старта — 8й класс. Мир вокруг нас слишком быстро меняется.
35 лет тому назад нас не окружали универсальные резво думающие машины. Да, надо дать понять, что компьютер — это буквально коробка с транзисторами, но дико резвая коробка, иначе это понимание ничего не даст — время уже не то. Работать напрямую с регистрами процессора и стеком памяти надо тому, кто выбрал для себя это направление. Вы же не удивляетесь, почему это на алгебре не рассказывают про функционал.
4. Может быть я вам открою тайну, но во всех областях деятельности:
А) Есть тонна нюансов познается в работе, а не на обучении. Вы собираетесь учить нюансам, которые с большой вероятностью не повстречаются людям? Лучше дать удочку с сачком, а не кормить ведром мальков.
Б) Есть люди, не способные осилить — они просто не способны думать в нужном направлении. Они просто пошли за розовыми мечтами или еще по какой причине оказались в области, но ошиблись.
Меня самого очень часто вводит в ступор отсутствия способности думать и всепоглощающая лень, но я не считаю, что нужно учить программировать на, грубо говоря, транзисторах — для этого более специализированное направление.
P.S. Насчет лени сразу вспоминается несколько моментов:
— Однажды разработчику JS на NodeJS надо было что-то написать на Си и он поинтересовался «а какой пакетный менеджер у Си?»
— Массовое поголовное использование парострочных (утрированно) готовых решений https://habrahabr.ru/post/280039/
— Использование внешней ссылки при импорте https://github.com/docker/docker/blob/master/cli/flagerrors.go
Вы честно не понимаете что описание .RL сложно для восприятия относительно Pascal'я?Понимаю. Знание Pascal'я скорее мешает, да. Потому RL обычно изучают до Pascal'я, а не после.
Там абсолютно другой слой восприятия.Там простые математические термины. С которыми человек (если он не в начальной школе это читает) должен был ознакомиться на уроках математики.
Вы же не удивляетесь, почему это на алгебре не рассказывают про функционал.Про функционал не рассказывают потому что это сложно сделать быстро. И про сапог Шварца не рассказывают примерно по той же причине. А вот про синусы-косинусы — рассказывают до сих пор. Потому что они учат работать с формулами.
Вот и RL — учит работать с функциями. Изучить его можно за пару уроков, написать простенькие программки (скажем расставляющие ферзей на доске 8x8) — ещё за пару (вначале нужно, конечно, числа реализовать, так как в RL их нету — но тут можно натуральными числами в единичной системе счисления ограничиться). А дальше — пишите хоть на JS, хоть на C++, это дело ваше.
Меня самого очень часто вводит в ступор отсутствия способности думать и всепоглощающая лень, но я не считаю, что нужно учить программировать на, грубо говоря, транзисторах — для этого более специализированное направление.Специализированное направление — это если вы практически хотите добраться от транзисторов до JS. Но для практического занятия программированием самое важное, что нужно понимать — это то, что абстрации текут — и, к большому сожалению, протечки начинаются с самого-самого низу. Уже обращение в память «течёт», так как считать 100 байт подряд можно в несколько раз быстрее, чем 100 случайных байт, потом кеши добавляются и так далее — к моменту, когда мы добрались до JS у нас уже десятки слоёв абстракций — и все они могут нам аукнуться.
Да, надо дать понять, что компьютер — это буквально коробка с транзисторами, но дико резвая коробка, иначе это понимание ничего не даст — время уже не то.А что случилось со временем? Какие принципиальные изменения произошли за последние 35 лет? Последнее поколение компьютеров — таки четвёртое. Всё, что произошло после — уже количественные изменения, не качественные.
А то, что коробка «дико быстрая» скорее усложняет процесс, чем упрощает его: в практических задачах она всё равно недостаточно быстрая зачастую, но если во времена когда калькулятор выполнял 10 операций в секунды вы осознавали это факт в первые пять минут общения с этой железякой, то сегодня вполне можно с этим столкнуться уже только став разработчиком… а в этот момент перестраивать своё мышление гораздо сложнее…
потом кеши добавляются и так далее — к моменту, когда мы добрались до JS у нас уже десятки слоёв абстракций — и все они могут нам аукнуться.
Самое неприятное то, что чем больше слоев абстракции, тем сильнее будут «протечки» и тем меньше у нас контроля над ними. Потому что, собственно, абстракция призвана нам его не дать. И протечка будет решаться либо силами самой абстракции — а значит, долго и плохо, либо с помощью использующего ее, и тогда абстракция перестает быть таковой.
Никто не мешает отказаться от абстракции, если она мешает. Или вы предлагаете для передачи данных из формы в браузере на сервер использовать прямое управление напряжением на контактах ethernet-порта?
Если бы абстракции мешали — их бы не использовали. И беда не в том, что они мешают и от них хочется отказаться, а в том, что когда у тебя 100500 уровней абстракции, и что-то работает не так, как ожидается, то заранее сказать на каком уровне — нельзя. Чем более глубокие абстракции, тем реже их «протечки» стреляют в реальном мире (они просто более оттестированы), но я реально сталкивался со случаем когда настройки памяти (вернее настройка prefetch'а) вытекали аж в JavaScript…
1. .RL сложен для понимание не из-за Pascal'a а из-за базы знаний начальной школы.
2. Простые математические термины .RL дают нужный уровень абстракции для учеников 10-11 классов, но не для средней школы.
3. Вы предлагаете ученикам изобрести не велосипед, а способ как дышать — их уже научили, что есть минимум натуральный ряд (1 класс) и нужно поддерживать взаимосвязанность предметов. Ваше предложение больше подходить для институтов где говорят «забудьте все, что вы учили в школе».
4. Для практических знаний нужна тонна информации, а не только протечка абстракций (я понимаю, что это только один из примеров). Результативные практические знания получают не в школе или университете, а непосредственно на боевом опыте. Иначе пришлось бы учиться до 40 лет, а потом понять, что ты никому не нужен из-за того, что отстал на 20 лет.
Кстати, вы так часто ссылаетесь на этот блог как буд-то сами его ведете. Раскрою одну тайну по приведенной вами статье — она желтая и рассчитана на тех, кто не работает с сетью.
5. Что случилось со временем? На самом деле случилось самое страшное — мир информационных технологий изменился полностью.
Раньше компьютеры были доступны единицам, теперь ты можешь не подозревать о том, что купил новый еще один компьютер. Людям приходится подстраиваться под новые уровни абстракций взаимодействия с железом (благо в этом смысле эти абстракции стремятся к очеловечиванию, хоть я и дико против этого). Ни в одном направлении естественных наук не было столь дикого количества изменений за последние N лет, сколько в сфере информационных технологий. В то время когда физики/химики/биологи/etc живут в ожидании новых идей и открытий, мы живем в процессе фильтрации этих идей и открытий, иначе это просто невозможно переварить.
Я предлагаю изучать нужные современные абстракции. Как дальше развиваться — это выбор конкретного человека и специализации. Конкретные узкие проблемы должны решаться на месте/проекте а не на стадии обучения.
«То сегодня вполне можно с этим столкнуться уже только став разработчиком» — это и нужно осознавать только став разроботчиком.
2. Простые математические термины .RL дают нужный уровень абстракции для учеников 10-11 классов, но не для средней школы.
3. Вы предлагаете ученикам изобрести не велосипед, а способ как дышать — их уже научили, что есть минимум натуральный ряд (1 класс) и нужно поддерживать взаимосвязанность предметов. Ваше предложение больше подходить для институтов где говорят «забудьте все, что вы учили в школе».
4. Для практических знаний нужна тонна информации, а не только протечка абстракций (я понимаю, что это только один из примеров). Результативные практические знания получают не в школе или университете, а непосредственно на боевом опыте. Иначе пришлось бы учиться до 40 лет, а потом понять, что ты никому не нужен из-за того, что отстал на 20 лет.
Кстати, вы так часто ссылаетесь на этот блог как буд-то сами его ведете. Раскрою одну тайну по приведенной вами статье — она желтая и рассчитана на тех, кто не работает с сетью.
5. Что случилось со временем? На самом деле случилось самое страшное — мир информационных технологий изменился полностью.
Раньше компьютеры были доступны единицам, теперь ты можешь не подозревать о том, что купил новый еще один компьютер. Людям приходится подстраиваться под новые уровни абстракций взаимодействия с железом (благо в этом смысле эти абстракции стремятся к очеловечиванию, хоть я и дико против этого). Ни в одном направлении естественных наук не было столь дикого количества изменений за последние N лет, сколько в сфере информационных технологий. В то время когда физики/химики/биологи/etc живут в ожидании новых идей и открытий, мы живем в процессе фильтрации этих идей и открытий, иначе это просто невозможно переварить.
Я предлагаю изучать нужные современные абстракции. Как дальше развиваться — это выбор конкретного человека и специализации. Конкретные узкие проблемы должны решаться на месте/проекте а не на стадии обучения.
«То сегодня вполне можно с этим столкнуться уже только став разработчиком» — это и нужно осознавать только став разроботчиком.
Вы знаете, по своему опыту скажу что очень важно не останавливаться и не делать больших перерывов в изучении языков.
В институте я изучал C,C++,ASM,HTML,JAVA,SQL,1С. Параллельно работал сисадмином, и к сожалению знания по программированию я почти не применял. А зря. Сейчас со скрипом ( спустя 8 лет после окончания учёбы) пытаюсь навёрстывать упущенное.
И да, Pascal как 1й язык для меня был очень хорош.
В институте я изучал C,C++,ASM,HTML,JAVA,SQL,1С. Параллельно работал сисадмином, и к сожалению знания по программированию я почти не применял. А зря. Сейчас со скрипом ( спустя 8 лет после окончания учёбы) пытаюсь навёрстывать упущенное.
И да, Pascal как 1й язык для меня был очень хорош.
Incredibly, Java never proposed study. Java is a language of industry No. 1 the last 10 years in the number of work projects and infrastructure. In addition, Java is very interesting both for its design language, such as Python and other languages openly borrowed the idea of libraries and fraymvorkov. From an academic point of view, the JVM is subject to the compulsory study of any programmer-theorist and / or performansnika. One JMM is worth something!You can visit our website for logo design,
www.logogoon.com
www.logogoon.com
Какой-то очень странный подбор языков, выбранный лишь потому что автор их учил. Некоторые вообще очень специфичные или нигде не используются. Нет функционального программирования опять же.
Спасибо, на удивление годная статья, даже несмотря на непривычный выбор языков. Правда, вот эта фраза неистово повеселила:
> Objective-C – второй язык. Он представляет собой очень тонкий слой поверх чистого Си.
Все бы ничего, но потом с этого джедайского синтаксиса слезать больновато.
> Objective-C – второй язык. Он представляет собой очень тонкий слой поверх чистого Си.
Все бы ничего, но потом с этого джедайского синтаксиса слезать больновато.
Но если вы хотите работать в индустрии, знать его нужно, так как альтернативы ему не предвидится.
Почему не предвидится? Например Rust. Очень лаконичный и выразительный, а главное быстрорастущий язык. Вполне вероятно, что в недалеком будущем сможет составить конкуренция C++.
Какой С, какой ASM? Паскаль? Первый язык должен быть с низким порогом входа, писать на нем должно быть просто и по возможности язык должен быть современным и востребованным, а так же кроссплатформенным.
На С хорошо работать с железом, но сколько вообще людей это делает? ASM? А для чего именно ASM? Для каких процессоров? Для х86 и DSP он различает как небо и земля. И главное зачем? Паскаль? Что вам начинающие сделали? Куда вы потом с ним?
В качестве первого языка я считаю практически идеальным Python. Начать писать на нем очень просто, учится можно на чем угодно включая телефоны, позволяет писать все от простых программок и автоматизирующих скриптов до мега проектов. Можно писать в любом стиле. От скриптов до функционального программирования. Остается добавить, что для Python есть такая IDE как PyCharm. Когда ты мало понимаешь что происходит даже выловить опечатки уже большое дело.
А уже потом станет понятно что именно хочется делать. И учить нужно будет то, что интересует, а не то, что учил кто-то. И учил замечу не потому, что в этом был хоть какой-то смысл, а потому, что так получилось.
PS: я понимаю, что кто-то советует начинать с функциональных языков. Например за это ратует Кнут. Но он преподаватель и рассматривает процесс с точки зрения первоначального обучения студентов.
На С хорошо работать с железом, но сколько вообще людей это делает? ASM? А для чего именно ASM? Для каких процессоров? Для х86 и DSP он различает как небо и земля. И главное зачем? Паскаль? Что вам начинающие сделали? Куда вы потом с ним?
В качестве первого языка я считаю практически идеальным Python. Начать писать на нем очень просто, учится можно на чем угодно включая телефоны, позволяет писать все от простых программок и автоматизирующих скриптов до мега проектов. Можно писать в любом стиле. От скриптов до функционального программирования. Остается добавить, что для Python есть такая IDE как PyCharm. Когда ты мало понимаешь что происходит даже выловить опечатки уже большое дело.
А уже потом станет понятно что именно хочется делать. И учить нужно будет то, что интересует, а не то, что учил кто-то. И учил замечу не потому, что в этом был хоть какой-то смысл, а потому, что так получилось.
PS: я понимаю, что кто-то советует начинать с функциональных языков. Например за это ратует Кнут. Но он преподаватель и рассматривает процесс с точки зрения первоначального обучения студентов.
В 90е в хороших школах на информатике детям давали два языка — сначала бейсик, потом паскаль. Сейчас, имхо, питон прочно занимает нишу бейсика. Но если ограничиваться только питоном, то на выходе получаются чистые прикладники. И мы видем тонны ужасных библиотек на питоне, статьи "питон как крутой язык для data science" и программистов, не знающих шестнадцатеричные системы счисления.
Имхо, хорошим стартом является питон (5-8 класс) + С (9-11). Паскаль хоть и по-прежнему хорош для обучения базовым алгоритмам и структурам данных, но очень уж устарел как язык.
но очень уж устарел как язык.
По большей части это вкусовщина. Серьезно — если мы говорим не о сложных проектах, а обучении, то все сводится к «а мне не нравится объявлять переменные в самом начале» или «не люблю блоки с begin/end, хочу фигурные скобки, я так привык».
Python и Java, увы, бичи современного научного программирования, учёные, мало понимающие в программной инженерии написали на них много полезных, но ужасно работающих программ.
В школе изучал Basic. В ВУЗе давали стандартно: Паскаль (предмет «Алгоритмизация и структурное программирование»), потом Си в рамках него же, потом ООП на основе Паскаля. Затем Ассемблер, ООП на основе С++ с углубление в шаблоны и прочую перегрузку, потом нестандартное — Лисп, Пролог, параллельно — Организация ЭВМ, от самого железа и до уровня машинных кодов.
По-моему, очень правильная линейка: сначала человек учится что-то конкретное делать (Паскаль), затем изучает более глубоко (Си). То же с Ассемблером — сначала программируем в мнемокоде, а потом уже в машинной и изучаем «электронную» часть. И с ООП — сначала простое — на основе Паскаля, потом углубление. Потуги идти всегда от простого к сложному приводят к тому, что обучение идет от тяжелого к легкому и вся охота отбивается еще на раннем этапе.
Сейчас вместо Паскаля ввели Java, заместив 2 курса (программирование на ЯВУ и ООП).
По-моему, очень правильная линейка: сначала человек учится что-то конкретное делать (Паскаль), затем изучает более глубоко (Си). То же с Ассемблером — сначала программируем в мнемокоде, а потом уже в машинной и изучаем «электронную» часть. И с ООП — сначала простое — на основе Паскаля, потом углубление. Потуги идти всегда от простого к сложному приводят к тому, что обучение идет от тяжелого к легкому и вся охота отбивается еще на раннем этапе.
Сейчас вместо Паскаля ввели Java, заместив 2 курса (программирование на ЯВУ и ООП).
Сперва лучше выучить Python потом ассемблер и уже дальше Cи и подобные языки. сам так учил. Питон проще понять для человека который не сталкивался с программированием, язык то не компилируемый хотя и медленный но для обучения самый лучший, написал код и тут же выполнил его, удобно наглядно, да и ООП проще на нем понять. Си после Питона учится легко да и сам язык тоже простой, легкий и программы на нем выходят небольшими по «весу» так что однозначно Python и Си знать обязательно нужно.
Читаю комментарии и становится страшно за свое будущее, в глаза не видел паскаля и VB, которые рьяно рекомендуют к изучению в первых рядах. Начинал изучение с C# и за года пол написал примитивные крестики-нолики. Изучал, правда, на специальных курсах и мы использовали visual, расставляли формочки и прочее. Сейчас, спустя много лет, до сих пор не сталкивался с чем-то непонятным в плане изучения, восприятия в программировании. Изучать надо с того, что показывает сразу результат (для меня было невообразимо, что можно так легко делать приложения под Win), а не в консоли текст наблюдать.
p.s.
Ничего против консоли не имею — обожаю.
p.s.
Ничего против консоли не имею — обожаю.
Читаю комментарии и становится страшно за свое будущее, в глаза не видел паскаля и VB
Дата рождения:
17 января 1994
Логично. Время, внезапно, идет, популярные технологии сменяются.
Изучать надо с того, что показывает сразу результат
Паскаль с упомянутым вами VB и в совсем древнем варианте, Бейсиком (Питоном сегодня) — и есть то, что «дает результат сразу», по сравнению с Си, например.
Я освоил Бейсик и Фортран по книжке — благо в школе были компьютеры — и пару раз что-то объяснил преподаватель информатики, дальше было понятно всё. Си — вечером за чашкой чая друг объяснил/написал основные операторы и дальше была классическая книга K&R. Ради ASM пошел на курсы.
Зачем нужен Паскаль? Я так понимаю, что преподаватели учат тому, чему учили их — вот нынешние студенты и страдают. На примере нашей лаборатории — все студенты которые появлялись моментально переходили на Си и о Паскале/Делфи больше никогда не вспоминали.
На Паскале тоже пришлось что-то написать — переделывал чужую программу.
punkkk — вот-вот — без VB и P можно неплохо жить.
Зачем нужен Паскаль? Я так понимаю, что преподаватели учат тому, чему учили их — вот нынешние студенты и страдают. На примере нашей лаборатории — все студенты которые появлялись моментально переходили на Си и о Паскале/Делфи больше никогда не вспоминали.
На Паскале тоже пришлось что-то написать — переделывал чужую программу.
punkkk — вот-вот — без VB и P можно неплохо жить.
Паскаль лучше С годится для обучения, это уже много раз проходили. Зачем нужна Delphi? Ну, сейчас её актуальность уже прошла, ИМХО. Но в годы своей «молодости» это был идеальный инструмент для создания Windows-приложений, и по производительности Delphi-программистам просто не было равных (ну, кроме VB-программистов, которые были сильно ограничены своей платформой).
Паскаль нужен, чтобы не тратить время на Бейсик. Т.е. идти по цепочке Паскаль -> C -> ASM -> языки высокого уровня.
А вот Delphi для обучения программированию не нужен. Он действительно был актуален 10-15 лет назад, но не за счёт языковых возможностей, а из-за библиотек. Сейчас для тех же целей гораздо актуальнее изучать C#/Java.
А вот Delphi для обучения программированию не нужен. Он действительно был актуален 10-15 лет назад, но не за счёт языковых возможностей, а из-за библиотек. Сейчас для тех же целей гораздо актуальнее изучать C#/Java.
Так я и говорю — сейчас пишут что лучше всего для начала изучать паскаль.
Я первый раз что-то написал в школе на бейсике, на дополнительном занятии по информатике, первым заданием было что-нибудь нарисовать на экране с его помощью. На компах был DOS и соответствующий редактор.
Это было довольно неплохо. Для школьников, по-моему, разницы не много.
Хотя конечно, чем «круче» выглядит результат, тем лучше.
Это было довольно неплохо. Для школьников, по-моему, разницы не много.
Хотя конечно, чем «круче» выглядит результат, тем лучше.
НЛО прилетело и опубликовало эту надпись здесь
Одно только не понял: что ты написал в итоге и на чём?
Я пользуюсь своими программами каждый день на протяжении лет. Дорабатываю их точно так же, периодически выделяя по несколько недель, чтобы не отвлекать мозги.
И мой путь был C -> Python -> Asm с самого начала, исходя только из практических задач. На рынок и рейтинг TIOBE мне абсолютно наплевать. Для меня важно взять хороший инструмент и сделать с его помощью то, что надо для работы.
Почему мне нравится C — потому что на нём очень коротко можно записать.
Почему мне нравится Python — потому что на нём очень быстро можно записать.
Asm — инструмент для ковыряния в уже готовых программах (когда нужно вклинить своё что-то).
Я пользуюсь своими программами каждый день на протяжении лет. Дорабатываю их точно так же, периодически выделяя по несколько недель, чтобы не отвлекать мозги.
И мой путь был C -> Python -> Asm с самого начала, исходя только из практических задач. На рынок и рейтинг TIOBE мне абсолютно наплевать. Для меня важно взять хороший инструмент и сделать с его помощью то, что надо для работы.
Почему мне нравится C — потому что на нём очень коротко можно записать.
Почему мне нравится Python — потому что на нём очень быстро можно записать.
Asm — инструмент для ковыряния в уже готовых программах (когда нужно вклинить своё что-то).
НЛО прилетело и опубликовало эту надпись здесь
Статья конечно спорная (изучение Objective-C и Smalltalk чего стоит, особенно учитывая что сама Apple «переводит» всех на Swift, ну да ладно, это личные вкусы автора, о которых не спорят).
Если по теме в целом, то язык для изучения программирования должен обладать следующими свойствами:
— Простота освоения. Язык должен иметь минимум лишнего синтаксического «мусора» ([привет ObjectiveС:[с его нагромождениями скобок]]), не требовать монструозных дорогих IDE на целый DVD-диск (привет Visual Studio). Отличная среда в этом плане кстати, это Arduino IDE, минимум контролов, и ей даже инсталлятор не нужен.
— Язык должен иметь реальную практическую применимость (поэтому Borland Pascacal тоже идет лесом вместе с древними симуляторами DosBox, так же как и «мертвые» языки типа Smalltalk-a). Суть в том, что ученик долженпочувствовать в себе силу иметь возможность сделать для себя (и показать друзьям, родственникам и пр) какую-то реально полезную программку (неважно что, качалка файлов, скрипт для домашней странички, или установщик плагинов для Майнкрафта). Т.е. нужен полезный «выхлоп» и разбор _прикладных_ задач, чтобы был интерес в первую очередь. Нет ничего скучнее того, когда ученик понимает что проходимое на уроке ему никогда не пригодится. Из этого следует следующие 2 пункта.
— Нужно с учениками писать код на _разные_ платформы. Ученик должен попробовать и виндовую программу из форм «сбацать», и консольное приложение написать, и светодиодом на контроллере помигать, и на смартфоне приложение запустить.
— Нужно разбирать практические задачи: работа с файлами, сетью, ввод-вывод и пр (а для этого язык должен быть простым и высокоуровневым). Теорию типа «какого размера бывают переменные» и «куда растет стек» можно рассматривать параллельно во время решения прикладной задачи.
В итоге, что остается? Наверное, «С с классами» для начала (отказываться от string например, ради pure C все же нецелесообразно), параллельно Python как скриптовый язык, параллельно что-то типа Visual Basic чтобы делать простые приложения под Windows.
А еще хорошо бы, чтоб зарплата учителя информатики в школе примерно соответствовала зарплате программиста. Тогда туда пойдут те, кто реально умеет и любит это делать, а не выпускники пед.вузов, обучавшиеся по программам 20-летней давности.
Если по теме в целом, то язык для изучения программирования должен обладать следующими свойствами:
— Простота освоения. Язык должен иметь минимум лишнего синтаксического «мусора» ([привет ObjectiveС:[с его нагромождениями скобок]]), не требовать монструозных дорогих IDE на целый DVD-диск (привет Visual Studio). Отличная среда в этом плане кстати, это Arduino IDE, минимум контролов, и ей даже инсталлятор не нужен.
— Язык должен иметь реальную практическую применимость (поэтому Borland Pascacal тоже идет лесом вместе с древними симуляторами DosBox, так же как и «мертвые» языки типа Smalltalk-a). Суть в том, что ученик должен
— Нужно с учениками писать код на _разные_ платформы. Ученик должен попробовать и виндовую программу из форм «сбацать», и консольное приложение написать, и светодиодом на контроллере помигать, и на смартфоне приложение запустить.
— Нужно разбирать практические задачи: работа с файлами, сетью, ввод-вывод и пр (а для этого язык должен быть простым и высокоуровневым). Теорию типа «какого размера бывают переменные» и «куда растет стек» можно рассматривать параллельно во время решения прикладной задачи.
В итоге, что остается? Наверное, «С с классами» для начала (отказываться от string например, ради pure C все же нецелесообразно), параллельно Python как скриптовый язык, параллельно что-то типа Visual Basic чтобы делать простые приложения под Windows.
А еще хорошо бы, чтоб зарплата учителя информатики в школе примерно соответствовала зарплате программиста. Тогда туда пойдут те, кто реально умеет и любит это делать, а не выпускники пед.вузов, обучавшиеся по программам 20-летней давности.
Однозначный + в карму за статью. Поставил бы второй за попытку объяснить продвинутым современным программистам зачем нужен «мертвый» Smalltalk — но нельзя. Да и результат как-то не добавляет оптимизма по поводу нашего будущего…
Существует мнение, что Smalltalk вообще первым языком должен быть… Интересно, существуют ли примеры?
Существует мнение, что Smalltalk вообще первым языком должен быть… Интересно, существуют ли примеры?
Спасибо!
Вчера как-то забыл написать замечание о том, что совсем не упоминается Pharo. А между тем, это один из ведущих «диалектов» Smalltalk-а. Пожалуй, возьму на себя смелость заявить, что уже наиболее продвинутый и наиболее перспективный как с точки зрения использования для «коммерческого», так и для «научного» использования.
Немало людей посещают подобные курсы (за приличные деньги), учатся писать screensaver, радостно публикуют его в Сети и получает на выходе красивый сертификат с которым бегут устраиваться в фирмы.
Конечно, если нужно стать настоящим программистом, то стоит такой путь выбрать: авторитетные книги, стандарт, пробовать алгоритмы реализовавывать и др. А те разрекламированные курсы, легкие книги и т.п., видимо, подходят для знакомства, вовлечения не связанных с программированием людей. Такие упрощенные версии позволяют хоть как-то прикоснуться к программированию. Тем оно становиться понятнее. Действительно, стоит понимать зачем идешь на такой курс или зачем читаюшь такие книги. Ведь, такой дилетант выглядил бы смешно, если бы ему нужно было бы сделать screensaver, а он пошел бы Кормена читать. И наоборот, как у вас.
В обучении, не важно чему, важна быстрая обратная связь, хорошо ученик что-то сделал или плохо. В языке C такая связь может быть отложена надолго. Ну не освободил память память, программа работает, ну обратился по освобожденному указателю и ни чего не упало.
У скриптовых языков проблема аналогична.
Я считаю что начинать надо с языков с развитой статической типизацией — Elm, SML, Haskell, Purescript, F#, Rust (в порядке увеличения сложности изучения).
У скриптовых языков проблема аналогична.
Я считаю что начинать надо с языков с развитой статической типизацией — Elm, SML, Haskell, Purescript, F#, Rust (в порядке увеличения сложности изучения).
Как изучать языки программирования