Для игрушек точно Scratch и Project Spark. Там можно гораздо интереснее вещи создавать, чем сапёр и тетрис. Для фракталов — Logo и Racket. И там и там, первый вариант — для маленьких, второй — для тех, кто повзрослее и хочет покруче.
Racket я указал в том ряду как раз в качестве граф.планшета, уже не игрушечный, но всё ещё логичный и простой для понимания, с хорошей библиотекой, позволяющей детям не заскучать.
10 лет назад я начал изучать C++. В данный момент я пишу на C++. Думаю, что он никуда не денется еще лет 10.
Рад за Вас и даже могу допустить, что Вы всё на том же подмножестве C++ программируете, игнорируя вышедшие стандарты. Но если посмотреть на web, mobile, робототехнику, там произошли изменения гораздо масштабнее, чем в С++.
Точки для конкатенации мне тоже не нравятся, т.к. вызывают лишние ассоциации с другими вещами, но всяко лучше, чем +.
Ну а ++ или <> вообще идеально. К сожалению, исторически сложилось, что ++ в С-семействе языков зарезервирован под инкремент.
Там куда более занятно, что отсутствуют выделение операторов и синтаксических конструкций, управляющих потоком выполнения, в отдельные сущности. Тот же if является всего лишь сообщением для Boolean-объекта.
Использовать + для конкатенации строк или массивов — это само по себе глупость, правда зачастую от создателей языка. В данном случае мономорфность операторов — благо даже для сильной типизации, а для слабой типизации — сущая необходимость.
Да вроде наличие полноценного ООП никогда не было критерием популярности языка… Когда прочитаете "Pharo by example" поймёте, что ООП в полноценном виде ни в одном мейнстрим языке нет в наличии. Чаще всего мы имеем банальное процедурное программирование с классами, ну и, благодаря исторической роли C++, это принято ассоциировать с ООП.
Ну, если для Вас вся суть промышленного программирования сводится к "натыкивать буквами команды", тогда конечно )))
Во-первых, блоки только у Scratch. Во-вторых, это всяко веселее, чем блок-схемы на бумажке, которые мы в школе рисовали. В-третьих, вспомните, что было 10 лет назад, что есть сейчас и Вы поймёте, что никто не знает как будет выглядеть промышленное программирование ещё через 10 лет.
давая ему совершенно бесполезную технологию
Ох, я чувствую дай Вам волю, Вы и цветные карандаши у детей отберёте..
Я знаю что «программисты хорошо получают» и в целом «востребованы на рынке труда» и поэтому я хочу стать сферическим программистом в вакууме.
Что мне начать учить? И зачем?
Имхо, с такой мотивацией вообще бесполезно что-то учить.
Если уж программировать, то только тогда, когда не можешь не программировать :-)
JS явно не очень подходит как первый язык, как минимум потому, что нет строгой типизации, человеку после js будет сложновато, на мой взгляд, перейти на тот же С, а вот наоборот — запросто.
Скажу Вам по секрету, что в С тоже нет строгой типизации.
А по существу, я бы обобщил, что любой язык со слабой типизацией плохо подходит в качестве первого.
Поддержу! Stratch, Logo и Racket для начального обучения самое то.
Кстати, Stratch в том числе хорошо решает проблему "поделиться результатом с друзьями".
Ещё очень круто выглядит Project Spark.
лучше бы начинать с какого-то языка, где всё устроено именно так, как кажется на первый взгляд.
А знаете, тут вот шутят насчёт Haskell, и я тоже раньше думал, что это очень сложный язык. Но когда начал изучать, оказалось, что он весьма простой (основной косяк, что про него любят писать заумно, но это не вина языка). После освоения нескольких базовых концепций, всё остальное выстраивается на их основе, настолько естественно, что иногда диву даёшься… Чуть ли не любую библиотечную функцию можно переписать в пару строк, потом открыть код GHC и с удивлением обнаружить, что именно так она и реализована. Я более-менее знаю больше 10 языков, но ощущение "всё устроено именно так, как кажется на первый взгляд" у меня возникло впервые именно при изучении Haskell.
Не берусь пока его советовать в качестве первого языка, но в качестве одного из первых 5 ЯП однозначно рекомендую.
Вот результат опроса, который проводился на Stack Overflow в 2016-м году. В нём участвовало 49397 разработчиков. Более половины из них используют JavaScript.
В результате множество компаний нанимают JavaScript-разработчиков, но разработчиков этих не так уж и много.
Это 5. Я понимаю, что Вы всё подгоняете, чтобы каждый пункт был в пользу JavaScript, но можно же хоть как-то согласовано это было сделать.
P.S. Если по существу, то с JavaScript имеет смысл начинать тем, кто хочет заниматься разработкой фронтенда для веб-проектов в ближайшие 5 лет. Для остальных это не лучший выбор первого языка.
Проскочили слова «TDD», «цель» и «тест» в одном предложении
Да ладно, не стесняйтесь себя процитировать: "Цель — это тест (в терминах TDD)."
На самом деле суть TDD не в тестах, суть в том, чтобы упрощать дизайн кода при помощи обкатки применения методов в тестах. И, как можно догадаться из названия, тесты — это далеко не единственный из возможных driver'ов разработки.
А вообще забавно как Вы завелись… чувствуете прилив религиозных чувств, встав на "защиту" любимой концепции? Это верный признак, что Вы её не понимаете, но верите в неё. Нет ничего универсального и идеально подходящего для любых задач. И TDD тут, само собой, не исключение.
Вспомните, чем научный подход отличается от религиозного… Первый ищет границы применимости и варианты опровержения.
Багтрекер ведь пополняется людьми
OMFG, откройте для себя Airbrake и аналогичные сервисы.
От тех репортов, которые пишут люди вас никакие тесты не защитят, потому что они все либо на тему изменения требований к коду, либо косметического характера (типа вёрстка неожиданно себя повела в Safari, хочу посмотреть как Вы это при помощи TDD решаете, чтобы не больно было))).
TDD позволяет писать код так, чтоб отдел QA находил 0 (НОЛЬ) ошибок.
Пару пруфов не затруднит предоставить? В вырожденных случаях это теоретически возможно, но на практике Вы скорее найдёте сотни статей разочарованных в TDD, которые когда-то, как и Вы, поверили в это ложное утверждение. А ведь проблема не в TDD, а в неадекватных ожиданиях… Люди, которые понимают что TDD это про дизайн кода, а не про контроль качества, прекрасно его применяют по назначению.
Не думаю, что можно считать, что большинство тех, кому приходится работать с какой-то технологией, ожидали её появления.
Это уже вторая категория… Процитирую себя же:
Тут есть 2 варианта: либо человек знает концепции, тогда новые изобретения будут для него долгожданным воплощением ожидаемого;
либо не знает и тогда они будут для него своеобразным шоком. В-первом случае даже учить не придётся, во-втором человек скорее всего будет отвергать новые технологии насколько хватит упорства.
Я поэтому и ратую за обучение концепциям… Что во времена промышленной революции, что в современном мире этого не хватает в массовом образовании.
Промышленность просто использует те истины, которые были найдены в лабораторных условиях.
У меня ощущение, что Вы меня не слышите… Я об этом тоже уже писал: "мейнстрим (промышленность) крайне медлительно заимствует концепции, которые давным давно сформулированы и реализованы в чуть менее популярных языках (лабораториях)". Вы же утверждали, что истина рождается из практики промышленного применения, когда по факту всё наоборот, и промышленность лишь использует готовые концепции. Поэтому такая практика и не является критерием истины, она просто адаптирует готовые результаты. Обратное утверждение как раз приводит нас к луддизму, когда мы опираясь на мейнстрим пытаемся апеллировать к истине.
Который с радостью и рвением готов на пару лет дольше изучать и сдавать то, без чего и так можно найти работу.
Ну, тут вопрос приоритетов, цель "побыстрее найти работу" — это одно. Цель "стать профессионалом" — уже другое. Это похоже на типичный выбор школьника: учиться ради оценок или ради получения знаний.
Одно другому не мешает. Но первая мотивация приводит к недальновидным решениям, а вторая — удовлетворяет первую в полуавтоматическом режиме.
Ну что ж, спасибо за откровенное признание.
Пожалуйста, только это не признание, а лишь мои догадки… Т.к. я по образованию физик и вообще слабо представляю чему там на IT-специальностях учат… Но, судя по текущему состоянии IT, явно не тому, чему я тут с начала темы предлагал учить :-)
Смещение цели (Вы это ниже описали). Цель разработки — код проекта, а цель TDD — тесты.
При разработке прототипа проекта выполняется двойной объём работы: нужно постоянно менять не только код, но и тесты, что при хорошем покрытии весьма неприятно. Программистам свойственно забывать, что на уровне маркетинга тоже идёт своё проектирование и переделать поведение половины методов из-за изменившихся требований — это вполне рабочая ситуация.
Про ложное ощущение надежности я уже писал. Но стоит повторить, т.к. если, понадеявшись на TDD, сократить отдел тестирования, то можно нехило проблем огрести.
Тесты сами по себе не гарантируют хороший код. Я такие тесты видел, которые в рамках TDD писались, что охренеть можно… На них на самих тесты надо было бы писать.
Вопрос то в другом: улучшает ли TDD качество кода или нет?
Сама по себе — не улучшает. TDD может способствовать улучшению кода, если пришлась по душе конкретному программисту. В противном случае — будет соблюдаться формально, что в целом негативно скажется на проекте.
есть ли возможность в любой момент в течении секунд-минут получить тот единственный достоверный бит «работает ли код так, как надо?»
TDD тут ничем не поможет, на этот вопрос только приёмочное тестирование отвечает. И я ни разу не видел, чтобы это было в виде бита. Хорошие тестировщики всегда, как минимум, минорные недочёты находят. QA — это Вам не TDD, там реальный хардкор )))
А как иначе проверить работает ли код как надо, кроме как проверить его?
Только приёмочное тестирование согласно спецификации. К сожалению, TDD тут ничем не поможет, т.к. юнит-тесты пишет тот же человек, что и код и если он что-то неверно понял, то ошибка будет и в коде и в тестах.
Перед программером новая либа, её нужно заюзать.
В документации по-хорошему тоже есть примеры кода, которые можно тоже автоматически тестировать, чтобы гарантировать актуальность.
Так что я лично за то, чтобы смотреть в нормальную документацию. И только в запущенных случаях — в тесты/код.
Цель — это тест (в терминах TDD).
В терминах TDD — да, в терминах TLD — нет. Этим они и отличаются :-)
Ну я понял. 20% кода работает, а остальные 80% — глючат
С какой стати Вы отождествляете покрытие тестами и надёжность кода? При том, что это очевидно несвязанные вещи. О том, какая часть кода глючит Вам сообщит багтрекинг, а не тесты. Причём он Вам об этом сообщит даже если тестов написать в 10 раз больше, чем основного кода. Потому что тесты всегда будут врать, говоря что всё супер. И с другой стороны, даже если не написать ни одного теста, 80% кода глючить не будут даже если автор — зелёный джуниор.
А что ж Вы ссылку не добавили на сопоставление? Нужна скорость — нужен компилятор, тут без вариантов.
Ну да, а потом 20 лет джуниором работаешь, мечтая о средней зарплате xD
Для игрушек точно Scratch и Project Spark. Там можно гораздо интереснее вещи создавать, чем сапёр и тетрис. Для фракталов — Logo и Racket. И там и там, первый вариант — для маленьких, второй — для тех, кто повзрослее и хочет покруче.
Racket я указал в том ряду как раз в качестве граф.планшета, уже не игрушечный, но всё ещё логичный и простой для понимания, с хорошей библиотекой, позволяющей детям не заскучать.
Рад за Вас и даже могу допустить, что Вы всё на том же подмножестве C++ программируете, игнорируя вышедшие стандарты. Но если посмотреть на web, mobile, робототехнику, там произошли изменения гораздо масштабнее, чем в С++.
Мейнстрим-решения не всегда лучшие, зачастую что-то исторически сложилось, а потом все годами жуют кактус во имя обратной совместимости..
Есть вполне себе хорошие варианты:
"++" — Haskell, Erlang
"<>" — Elixir
".." — Lua
"." — Perl, PHP
Точки для конкатенации мне тоже не нравятся, т.к. вызывают лишние ассоциации с другими вещами, но всяко лучше, чем +.
Ну а
++или<>вообще идеально. К сожалению, исторически сложилось, что++в С-семействе языков зарезервирован под инкремент.Там куда более занятно, что отсутствуют выделение операторов и синтаксических конструкций, управляющих потоком выполнения, в отдельные сущности. Тот же
ifявляется всего лишь сообщением для Boolean-объекта.В JavaScript действительно не самая плохая поддержка ООП, но есть существенные минусы:
Так же его нельзя назвать объектно-ориентированным языком, т.к.
Использовать
+для конкатенации строк или массивов — это само по себе глупость, правда зачастую от создателей языка. В данном случае мономорфность операторов — благо даже для сильной типизации, а для слабой типизации — сущая необходимость.Да вроде наличие полноценного ООП никогда не было критерием популярности языка… Когда прочитаете "Pharo by example" поймёте, что ООП в полноценном виде ни в одном мейнстрим языке нет в наличии. Чаще всего мы имеем банальное процедурное программирование с классами, ну и, благодаря исторической роли C++, это принято ассоциировать с ООП.
Ну, если для Вас вся суть промышленного программирования сводится к "натыкивать буквами команды", тогда конечно )))
Во-первых, блоки только у Scratch. Во-вторых, это всяко веселее, чем блок-схемы на бумажке, которые мы в школе рисовали. В-третьих, вспомните, что было 10 лет назад, что есть сейчас и Вы поймёте, что никто не знает как будет выглядеть промышленное программирование ещё через 10 лет.
Ох, я чувствую дай Вам волю, Вы и цветные карандаши у детей отберёте..
Если Вы хотите ознакомиться с полноценным ООП, посмотрите Smalltalk/Pharo.
Имхо, с такой мотивацией вообще бесполезно что-то учить.
Если уж программировать, то только тогда, когда не можешь не программировать :-)
Скажу Вам по секрету, что в С тоже нет строгой типизации.
А по существу, я бы обобщил, что любой язык со слабой типизацией плохо подходит в качестве первого.
Поддержу! Stratch, Logo и Racket для начального обучения самое то.
Кстати, Stratch в том числе хорошо решает проблему "поделиться результатом с друзьями".
Ещё очень круто выглядит Project Spark.
А знаете, тут вот шутят насчёт Haskell, и я тоже раньше думал, что это очень сложный язык. Но когда начал изучать, оказалось, что он весьма простой (основной косяк, что про него любят писать заумно, но это не вина языка). После освоения нескольких базовых концепций, всё остальное выстраивается на их основе, настолько естественно, что иногда диву даёшься… Чуть ли не любую библиотечную функцию можно переписать в пару строк, потом открыть код GHC и с удивлением обнаружить, что именно так она и реализована. Я более-менее знаю больше 10 языков, но ощущение "всё устроено именно так, как кажется на первый взгляд" у меня возникло впервые именно при изучении Haskell.
Не берусь пока его советовать в качестве первого языка, но в качестве одного из первых 5 ЯП однозначно рекомендую.
Это 5. Я понимаю, что Вы всё подгоняете, чтобы каждый пункт был в пользу JavaScript, но можно же хоть как-то согласовано это было сделать.
P.S. Если по существу, то с JavaScript имеет смысл начинать тем, кто хочет заниматься разработкой фронтенда для веб-проектов в ближайшие 5 лет. Для остальных это не лучший выбор первого языка.
Да ладно, не стесняйтесь себя процитировать: "Цель — это тест (в терминах TDD)."
На самом деле суть TDD не в тестах, суть в том, чтобы упрощать дизайн кода при помощи обкатки применения методов в тестах. И, как можно догадаться из названия, тесты — это далеко не единственный из возможных driver'ов разработки.
А вообще забавно как Вы завелись… чувствуете прилив религиозных чувств, встав на "защиту" любимой концепции? Это верный признак, что Вы её не понимаете, но верите в неё. Нет ничего универсального и идеально подходящего для любых задач. И TDD тут, само собой, не исключение.
Вспомните, чем научный подход отличается от религиозного… Первый ищет границы применимости и варианты опровержения.
OMFG, откройте для себя Airbrake и аналогичные сервисы.
От тех репортов, которые пишут люди вас никакие тесты не защитят, потому что они все либо на тему изменения требований к коду, либо косметического характера (типа вёрстка неожиданно себя повела в Safari, хочу посмотреть как Вы это при помощи TDD решаете, чтобы не больно было))).
Пару пруфов не затруднит предоставить? В вырожденных случаях это теоретически возможно, но на практике Вы скорее найдёте сотни статей разочарованных в TDD, которые когда-то, как и Вы, поверили в это ложное утверждение. А ведь проблема не в TDD, а в неадекватных ожиданиях… Люди, которые понимают что TDD это про дизайн кода, а не про контроль качества, прекрасно его применяют по назначению.
Это уже вторая категория… Процитирую себя же:
Я поэтому и ратую за обучение концепциям… Что во времена промышленной революции, что в современном мире этого не хватает в массовом образовании.
У меня ощущение, что Вы меня не слышите… Я об этом тоже уже писал: "мейнстрим (промышленность) крайне медлительно заимствует концепции, которые давным давно сформулированы и реализованы в чуть менее популярных языках (лабораториях)". Вы же утверждали, что истина рождается из практики промышленного применения, когда по факту всё наоборот, и промышленность лишь использует готовые концепции. Поэтому такая практика и не является критерием истины, она просто адаптирует готовые результаты. Обратное утверждение как раз приводит нас к луддизму, когда мы опираясь на мейнстрим пытаемся апеллировать к истине.
Ну, тут вопрос приоритетов, цель "побыстрее найти работу" — это одно. Цель "стать профессионалом" — уже другое. Это похоже на типичный выбор школьника: учиться ради оценок или ради получения знаний.
Одно другому не мешает. Но первая мотивация приводит к недальновидным решениям, а вторая — удовлетворяет первую в полуавтоматическом режиме.
Пожалуйста, только это не признание, а лишь мои догадки… Т.к. я по образованию физик и вообще слабо представляю чему там на IT-специальностях учат… Но, судя по текущему состоянии IT, явно не тому, чему я тут с начала темы предлагал учить :-)
Смещение цели (Вы это ниже описали). Цель разработки — код проекта, а цель TDD — тесты.
При разработке прототипа проекта выполняется двойной объём работы: нужно постоянно менять не только код, но и тесты, что при хорошем покрытии весьма неприятно. Программистам свойственно забывать, что на уровне маркетинга тоже идёт своё проектирование и переделать поведение половины методов из-за изменившихся требований — это вполне рабочая ситуация.
Про ложное ощущение надежности я уже писал. Но стоит повторить, т.к. если, понадеявшись на TDD, сократить отдел тестирования, то можно нехило проблем огрести.
Тесты сами по себе не гарантируют хороший код. Я такие тесты видел, которые в рамках TDD писались, что охренеть можно… На них на самих тесты надо было бы писать.
Сама по себе — не улучшает. TDD может способствовать улучшению кода, если пришлась по душе конкретному программисту. В противном случае — будет соблюдаться формально, что в целом негативно скажется на проекте.
TDD тут ничем не поможет, на этот вопрос только приёмочное тестирование отвечает. И я ни разу не видел, чтобы это было в виде бита. Хорошие тестировщики всегда, как минимум, минорные недочёты находят. QA — это Вам не TDD, там реальный хардкор )))
Только приёмочное тестирование согласно спецификации. К сожалению, TDD тут ничем не поможет, т.к. юнит-тесты пишет тот же человек, что и код и если он что-то неверно понял, то ошибка будет и в коде и в тестах.
В документации по-хорошему тоже есть примеры кода, которые можно тоже автоматически тестировать, чтобы гарантировать актуальность.
Так что я лично за то, чтобы смотреть в нормальную документацию. И только в запущенных случаях — в тесты/код.
В терминах TDD — да, в терминах TLD — нет. Этим они и отличаются :-)
С какой стати Вы отождествляете покрытие тестами и надёжность кода? При том, что это очевидно несвязанные вещи. О том, какая часть кода глючит Вам сообщит багтрекинг, а не тесты. Причём он Вам об этом сообщит даже если тестов написать в 10 раз больше, чем основного кода. Потому что тесты всегда будут врать, говоря что всё супер. И с другой стороны, даже если не написать ни одного теста, 80% кода глючить не будут даже если автор — зелёный джуниор.