Комментарии 237
Вот чем вам не нравится советский подход к информатике? Сначала играться с бейсиком, потом писать на паскале поиски-сортировки-деревья.
Сначала играться с бейсиком, потом писать на паскале
Я уж молчу про обучение нормальным языкам, а не динозаврами
Раньше по сети гулял мем о том, что "паскаль для образования", хотя вокруг были Delphi, freepascal и прочие, даже реально учебные Pascal ABC, потом было затишье, а теперь новый мем "паскаль не для образования"?
А что же для образования и чем надо измерять дляобразованиевость? У паскаля, бейсика и прочих кумиров отличный KPI, почти все кто их успешно изучал 10 лет назад — сегодня пишут на хабр умные статьи и получают килобаксы денег.
Scala, Scala, Lisp, Haskell, SML — для образования!!!:) Головоломные концепции отлично подойдут для развития мозга...:) а потом и к С++ можно в вузе будет приступать — он лёгоньким покажется.
Плюсанул, хотя со Scala не согласен, там слишком много разнородных концепций намешано в кучу. А для обучения лучше подходят чистые концепции аля Haskell, Scheme(всё-таки для обучения лучше Racket, чем Common Lisp), Smalltalk. Про SML ничего сказать не могу, я с ним не знаком )
Вы, наверное, шутите, ув. Vjatcheslav3345… Но, допустим, вы правы. Мой вопрос остаётся открытым, чем надо измерять пригодность языка для образования, чтобы потом сравнить, какой пригоден, а какой не очень?
Computer Science — это ведь не про языки программирования… они лишь одно из следствий и инструментов.
Какие есть фундаментальные вещи, которые можно изучать в классическом курсе? К примеру, архитектура фон Неймана, простые алгоритмы, алгебраические типы данных, лямбда-исчисление, абстрактное синтаксическое дерево и т.д. и т.п. Языки можно использовать разные, но чем чище в языке выражена та или иная концепция, тем лучше он годится для её объяснения. Т.е. отвечая на Ваш вопрос, для образования непригодны языки, в которых намешаны разнородные концепции.
В каждой шутке есть доля шутки, вот я и пошутил немного, но… — я имел в виду, что программирование можно было бы изучать в школе на протяжении 10-11 лет и продолжать в профобразовании и даже в аспирантуре (итого, получится, что грамотный человек будет иметь лет 17 изучения дисциплины — и нельзя это ценное время тратить на изучение всяческих тонкостей промышленного программирования, которые недолговечнее чем подёнки).
Но, — изучать так как советуют корифеи программирования и педагогики — не спеша, вникая в теорию. Чтобы легче давалось погружение в теорию и нужны вот такие вот специфические языки а потом уже, ближе к вступлению в "большую жизнь" — можно пройтись по практическим инструментом.
И не факт, что приведённые мной языки-примеры окажутся в школе наилучшими — языки стремительно устаревают (например, сейчас появились языки для вероятностного и квантового программирования) в современный период их развития, к тому же, если, скажем начать искать место дисциплины "Программирование" в образовании, то окажется, что, скажем, математики, информатики захотят разрабатывать ещё более абстрактные языки для нужд образования, но, подходя к ним с ещё и с позиций психологии и педагогики и даже медицины и здравоохранения учащихся и их педагогов. И они будут правы — ведь в образовании мы не повторяем вульгарно и в точности путь человека, скажем, в математике — учась считать сначала камешками, потом изобретая всевозможные системы счисления, изобретая нуль и т. д. а повторяем скорее развитие идей, не пытаясь проверить каждый тупиковый путь.
Самое главное, чтобы языки разрабатывали и применяли в программах "на опережение", так, чтобы к окончанию 10-15-летнего учения человек мог начинать пользоваться идеями, изучаемыми ранее, уже в практических языках и целях.
А по поводу метрики эффективности языков в образовании — открытая, независимая, от системы образования статистика качества информ-образования (т. е. более широкая, чем статистика эффективности языков в образовании — этого и другого иного инструментария) (скажем, организованная работодателями, профильными СМИ, иными заинтересованными лицами), нацеленная на определение — знает ли человек концепции или просто "макакит" ручками по клавиатуре.
Самое главное, чтобы языки разрабатывали и применяли в программах «на опережение», так, чтобы к окончанию 10-15-летнего учения человек мог начинать пользоваться идеями, изучаемыми ранее, уже в практических языках и целях.
Хорошо бы, но это уже невозможно. Времена такой презсказуемости давно прошли (почему — гуглить/ютубить «Закон Времени»).
Потому, остаётся единственный правильный путь дать нетленные знания: это знания о том, как познавать что-либо новое вообще, и творить что-либо новое. Т.е. управлять — в самом широком смысле слова.
А ещё в разработке языков для учебного программирования имеет смысл использовать принцип семейства микроязыков — т. е. разрабатывать каждый язык этого семейства так, чтобы каждый содержал только одну идею, но доводил её до безумно отшлифованного идеала в смысле понятности и чёткости.
Кроме того, следует учесть и то, что учитывают в преподавании давно (и чего нет в промкомпиляторах) — разделение изучаемых идей и концепций в соответствии с возрастным и индивидуальным развитием, интересами. Встроить прямо в учебный компилятор продвинутую аналитику и статистику для объективного определения — что плохо знает ученик (заодно — и для генерации автоотчетов для серверов Минобра что нибудь предусмотреть:)), генератор задач, учитывающий индивидуальные проблемы и трудности ученика и т. д. и т. п.
Кроме того, работать на опережение тоже вполне можно — например, сейчас на повестке будущего дня стоят квантовые компьютеры и нейрокомпьютеры, искусственный интеллект — при этом симуляторы тех же квантовых компьютеров появились давно и вполне можно было бы на перспективу учить в них тому, к чему промпрограммирование ещё не успело прийти, причём, в связи и с другими науками, например, в этом смысле было бы информатикам интересно и полезно замутить, совместно с физиками, при изучении термодинамики, лабораторки по консервативной логике.
языков для учебного программирования
Мне кажется, что за деревьями становится плохо видно сам лес.
Какова цель системы образования?
* Чтобы удобно провести 10 лет жизни?
* Или чтобы подготовиться ко взрослости?
Было бы довольно внезапно, неск лет в школе изучая специальные какие-то языки, выйдя во взрослую жизнь, обнаружить, что они в принципе никому не нужны…
Причём, это как раз и происходит, и не только с информатикой. Взрослые люди задаются вопросом: зачем было тратить 10 лет на школу, которая учила тому, что потом оказалось не нужно?
Про учить на перспективу — всё ж загуглите про «Закон Времени» — там есть ролик, наглядно показывающий почему единственная перспектива — это теория управления.
Ну а логика да, она нужна, и она часть этой самой теории управления.
Было бы довольно внезапно, неск лет в школе изучая специальные какие-то языки, выйдя во взрослую жизнь, обнаружить, что они в принципе никому не нужны…Так именно поэтому и не надо учить в школе Java/Python… Они подвержены моде, как любой мейнстрим.
Концепции по большей части моде не подвержены, поэтому всё что останется для перехода к production — это изучить синтаксис модного к тому моменту языка. Что как мы знаем занимает 2-3 недели, включая основную часть стандартной библиотеки.
А теперь подумайте сколько лет понадобится чтобы переключиться на что-то типа Haskell после 10 лет изучения Java.
Так именно поэтому и не надо учить в школе Java/Python… Они подвержены моде, как любой мейнстрим.
Именно!
Таких теоретиков-ни-о-чём школа плодит каждый год, и они потом пополняют статистику безработных.
На абстрактных концепциях не попрактикуешься (хоть знать их и нужно). Вот он конкретный комп, как руками почуствовать, что его таки реально заставить что-то делать? — только попробовав самому.
И чем плох так Вами названный мейнстрим в этом? Вон через дорогу от школы программеры сидят и кодят на этом мейнстриме, т.е. это реально востребовано и работает. Почему бы на нём не практиковаться?
Ну и пусть раз в 5 лет мейнстрим меняется — ну так обновлять программу обучения всё равно нужно. То, что счас продолжают учить уже давно неадекватному (во всех отраслях) — это ж ненормально.
Ну и пусть раз в 5 лет мейнстрим меняется — ну так обновлять программу обучения всё равно нужно.Ахах, Вы слишком хорошего мнения о минобре, новую программу лет 5 только согласовывать будут.
Да и потом, с чего Вы взяли, что предложенные языки неадекватны?.. за исключением Паскаля, остальные вполне себе используются в production, хоть и во втором эшелоне по популярности, а С так вообще — в первом, просто он уже достаточно стабилен, чтобы не дёргаться каждый год в новые фичи.
P.S. Если отвлечься от школы и переключиться на действующих программистов… Перечислите, если не трудно, список языков, которые Вы считаете перспективными с горизонтом 10 лет?
Так что, минобр может быть сколь угодно тормозным, но то, что нужно делать — можно определиться и не дожидаясь пока чиновники раздуплятся (ибо если не определиться — они вообще никогда не раздуплятся, будут просто бюджеты и дале пилить)
хоть и во втором эшелоне по популярности
Если есть возможность давать более востребованные знания новым поколениям… но нет, мы будет давать чуть похуже… Пусть те же индийские детки выглядять чуть лучше на фоне наших.
WAT???
список языков, которые Вы считаете перспективными с горизонтом 10 лет?
Первый эшелон: из семейства скриптовых: жабоскрипт (ну понятно) и всё, из низкоуровневых: Go (ибо с-подобный и асинхронный) и С.
Все остальные питоны, джавы, пхп, руби и т.д. — уже второй эшелон.
Да что тут считать. Берём статистику по языкам на гитхабе и всё видно (столбик слева):
https://github.com/search?o=desc&q=stars%3A%3E1&s=stars&type=Repositories
Впрочем, после выхода и стабилизации WebAssembly — монополия жабоскрипта пошатнётся (синтаксис у него всё-таки с-шный), рынок откусят более удобные синтаксисы, типа питоно-, рубе- или кофескриптово- подобные (хотя на кофях уже и счас можно писать).
Вобщем, основной тренд: асинхронность. Если она есть в самом языке (без необходимости сторонних либ) — то за ним будет и своя часть рынка.
Если есть возможность давать более востребованные знания новым поколениям…
Так я и предлагаю давать более востребованные знания, а не плодить кодеров-индусов из русских )))
Да что тут считать. Берём статистику по языкам на гитхабе и всё видно
Вы делаете прогноз на 10 лет, просто по текущему кол-ву открытых репозиториев на github? Ваше право, конечно, но имхо слабоватая метрика для прогнозов.
JavaScript сейчас колбасит только так. Учить его сейчас, чтобы найти работу в 2017 году — можно. С горизонтом 10 лет — бессмысленно.
А более удобных синтаксисов и так уже навалом.
Вы делаете прогноз на 10 лет, просто по текущему кол-ву открытых репозиториев на github? Ваше право, конечно, но имхо слабоватая метрика для прогнозов.
Метрика была написана: «Вобщем, основной тренд: асинхронность.» И указанные перед отсылом к гитхабу языки были выбраны именно по этому критерию.
JavaScript сейчас колбасит только так.
Ну если бурное развитие это «колбасит» — то пусть колбасит :)
С горизонтом 10 лет — бессмысленно.
Вышими же словами: «но имхо слабоватая метрика для прогнозов.». Это бессмысленно потому, что «колбасит»? Или почему бессмысленно?
А более удобных синтаксисов и так уже навалом.
Да, coffeescript рулит.
На мой взгляд, развитие — это когда что-то новое появляется (заимствования не в счёт) или хотя бы плохое старое отбрасывается… И это явно не про JavaScript.
Это бессмысленно потому, что «колбасит»? Или почему бессмысленно?
Да, если он и останется, то через 10 лет это будет совсем другой язык.
Но вообще в JavaScript далеко не самая удачная модель асинхронности — всё упирается в центральный однопоточный event-loop. Сравните с Erlang/Elixir, где центральный event-loop отсутствует как класс, а акторы масштабируются на сколько угодно ядер или даже на кластер машин.
И это явно не про JavaScript.
Т.е. свежие ES6 и ES7, введшие множество фич и синтаксического сахара (движение к питон-стилю синтаксиса) — Вы не рассматриваете как развитие?
Просто хочу либо какой-то конкретики про JS (почему он так уж плох), либо простое «да пофиг на него просто».
через 10 лет это будет совсем другой язык.
Ну и на здоровье. Не улучшать что-то только для того, чтобы не менять… эээ? :)
Ну либо Вы в состоянии показать заведомо идеальный и давно неизменный ЯП?
всё упирается в центральный однопоточный event-loop.
Да, счас этого может уже быть и маловато. Но в той же ноде есть искаробки модуль для распараллеливания вширь. Нормальный такой костыль, пока ядро однопоточное (но всё же меняется… ;)
Сравните с Erlang/Elixir
Вполне возможно, оно там как-то лучше завёрнуто (изначально в ТЗ на язык, видать, было так), но где тогда их распространённость?
На ерланге я знаю целую софтину (ejabberd) и либу распределённого хранения (кажись) mnesia…
Понятно, что маркетинг круче технического совершенства, но нода появилась не из-за маркетинга. Жабоскрипт сумел выйти из браузера в переполненную и чрезвычайно конкурентную среду серверного программирования (в виде ноды). В 2009. А сколько лет обозначенным языкам? Почему у них так негуст рынок при такой то архитектуре?
Вобщем, как я вижу: может по отдельным «концепциям» вполне возможно найти какие-то более удачные варианты, но суммарно по всем возможностям и экосистеме, которая на сегодня есть у жабоскрипта — вопрос о скриптовых языках закрыт надолго.
На каком ещё языке можно:
* писать асинхронно из коробки (без доп. либ)
* писать на всех (всех) мыслимых платформах: сервер, браузер, десктоп, мобил и даже всякие «малинки»
* иметь такую громадину готовых сторонних либ (более 200к либ только на npmjs, пусть даже не всё там для js, это с 2009; для сравнения: у синхронного питона на pypi около 70к либ, но с 1992 года(!!!)), и все эти либы — автоматически асинхронны, вопрос уместить в одном процессе разные сервера в принципе не стоит
Если можно — то, прошу, больше конкретики, без туманных терминов, типа «колбасит».
Если же просто неприятие жабосрипта (ещё год назад я плевался, примерно, как Вы счас) — то это тоже принимается. Никого к стенке прижимать я цели не имею, просто хочу узнать всякую конструктивную критику жабоскрипта и производных кофей (мне ж это в массы нести).
Т.е. свежие ES6 и ES7, введшие множество фич и синтаксического сахара (движение к питон-стилю синтаксиса) — Вы не рассматриваете как развитие?
Я рассматриваю это как неизбежное заимствование фич и решений под давлением других языков.
Просто хочу либо какой-то конкретики про JS (почему он так уж плох)
В первую очередь слабой динамической типизацией он плох, такую типизацию можно простить только Си для low-level оптимизаций, ни один язык высокого уровня не должен себе такую хрень позволять. Ну и архитектурными просчётами, которые начали потихоньку фиксить, начиная с ES6, но на это ещё хз сколько лет уйдёт.
Ну либо Вы в состоянии показать заведомо идеальный и давно неизменный ЯП?
Нет конечно, на это только Пайк способен, но мало кто с ним согласен )))
Тем не менее, очень немногие языки "развиваются" по сценарию "%lang_name% — говно, давайте его целиком переделаем". Обычно люди как-то более вдумчиво подходят к дизайну языка и не переделывают его кардинально после версии 1.0.
изначально в ТЗ на язык, видать, было так
Да, Вы угадали… изначально идея была в создании языка, который позволил бы писать ПО для управления тысячами устройств, без даунтайма, чтобы при звонках на телефон АТС не отвечала "извините, у нас тут ПО зависло". По совпадению, теперь для обычной разработки нужен именно такой язык. Кто ещё может похвастаться аналогом OTP? Особенно учитывая, что она уже 25 лет в бою под такими нагрузками, которые 99.999% проектов даже не снились, и 20 лет в OpenSource.
На ерланге я знаю целую софтину (ejabberd)
А про Riak или RabbitMQ не слышали? Ну или хотя бы про WhatsApp?
Почему у них так негуст рынок при такой то архитектуре?
Потому что раньше не были востребованы такие навороты в широких кругах. Всего 10 лет назад можно было прямо в php-файл вёрстку закинуть и збс, сайтец готов :-)
На самом деле люди с фундаментальным образованием работают сейчас там, где есть возможность зарабатывать, например в финансах (туда ещё очень часто физики и математики идут). Поэтому, действительно спецязыки и нужны на своём месте а вот люди со знаниями в жизни нужны всегда и за настоящие, "золотые" фундаментальные знания, готовы платить.
Но спецязыки, которые не выходят за рамки школы — вот где проблема. Т.е. выходит такой себе микромир: ковыряется что-то для самого же микромира, а не для реального, куда выпускники таки выйдут в итоге.
Спецязыки — это не большая проблема, чем сборка электросхем из учебных комплектов на уроках физики электрических цепей — никто же не ворчит: "Хватит дурью маяться, идите, и, как настоящие пионеры/комсомольцы, лучше бсплатно свет в подвале моей многоэтажки проведите".
Но люди, потом избравшие электротехнику своей профессией, благодаря знанию фундаментальных принципов проектируют и успешно реализуют трансконтинентальные системы связи и континентальные системы генерации и передачи энергии, не говоря уже о всём остальном.
Главный практический выхлоп спецязыков — твёрдые знания и умения в головах учеников и учителей (их тоже надо учить — посмотрите на их текущий уровень знаний и умений).
Я уж молчу про обучение нормальным языкам, а не динозаврами, но даже не в этом суть
А какие языки нормальны для обучения? На мой взгляд, язык для обучения должен быть достаточно фундаментален, чтобы на его примере можно было показывать основные концепции, не подверженные быстрому устареванию. Т.е. получается, что для обучения можно применять C, Pascal, Smalltalk (есть в варианте для самых маленьких — Scratch), Haskell, Racket.
Советовать учить PHP, Ruby, Python, Java, C# в школе, я бы не стал… это всё либо станет неактуальным к моменту, когда они закончат школу и универ, либо 100 раз ещё изменится. Да и не все же должны прикладными программистами становиться… Подумайте о других предметах, везде даётся классический базис. С чего бы именно программу по Computer Science надо переписывать каждый год и учить тому, что заведомо будет неактуально лет через 20?
Цитируя:
Every pupil should have repeated opportunities to design, write, run, and debug, executable programs. What an “executable program” means can vary widely, depending on the level of the pupil and the amount of time available. For example, all of the following are included in “programming”:
— Small domain-specific languages, such as instructions to a simple robot, or Logo-style
turtle.
— Visual languages such as Scratch BYOB or Kodu.
— Text-based languages, such as C#, C++, Haskell, Java, Pascal, PHP, Python, Visual
Basic, and so on.
— Spreadsheet formulae
Both interpreted and compiled languages are “executable”. In every case the underlying concepts are more important than the particular programming language or environment. The ability to understand and explain a program is much more important than the ability to produce working but incomprehensible code. Depending on level, pupils should be able to:
Design and write programs that include
o Sequencing: doing one step after another.
o Selection (if-then-else): doing either one thing or another.
o Repetition (Iterative loops or recursion).
o Language constructs that support abstraction: wrapping up a computation in
a named abstraction, so that it can be re-used. (The most common form of
abstraction is the notion of a “procedure” or “function” with parameters.)
o Some form of interaction with the program’s environment, such as
input/output, or event-based programming.
Find and correct errors in their code
Reflect thoughtfully on their program, including assessing its correctness and fitness
for purpose; understanding its efficiency; and describing the system to others.
Вот, скажем, тот же Pascal. Как к языку к нему претензий, пожалуй, особых и нет. Вопрос в том, что ребенок, который реально «перерос» школьную программу и уже не получает кайфа от чисто «тренировочных» задач, кроме этих самых сортировок ничего написать не сможет. Ну вот нереально на Паскале что-то действительно интересное написать для прикладных задач. Захотел ребенок для себя «ежедневник» написать и… и все… пошел учить что-то другое.
Из примеров, впрочем, на памяти строго обратное. Сначала Python внедрили в качестве образовательного в куче ВУЗов, а уже потом Гугл тот же вложился в прикладную «обвязку» для языка. На выходе получился вполне неплохой язык для изучения CS (не без оговорок, конечно, но получился) с достаточно широким прикладным применением. С Бейсиком и Паскалем так не получается.
Так что я лично (впрочем, мое мнение не особо авторитетно) только «за» переход преподавания в школах на тот же Python. В конце концов ребенок и портал для себя написать сможет, и десктопное что-то, и пару-тройку консольных тулз, и с «малинками» поиграться сможет для дальнейшего саморазвития.
(holywar_mode on)
Но в последнее время таким универсальным языком является жабоскрипт. Кроме вышеописанных тулзей с малинками, дитё сможет и дл мобилы попысывать, и для веба что-то покрутить. Т.е. закрывается вообще все направления программинга, да ещё и реально востребованным языком.
(PS мне много лет нравился именно питон, пока не узнал про ноду)
(holywar_mode off)
Не нужно будет переучиваться с учебного на рабочий (вопрос учебного языка, как по мне, так это вообще издевательство над детьми: научить какой-то учебной фигне, а потом плыви как хошь. Учёба ради учёбы? — вполне в русле школьной философии...)
PS мне много лет нравился именно питон, пока не узнал про ноду
Как Вы чётко в одном предложении выразили, почему не надо ни Python, ни JavaScript использовать в обучении основам :-)
Потому что они на уровне вкусовщины… Можете представить фразу типа "мне много лет нравилась механика, пока не узнал про термодинамику"?
Учебная программа — серьёзная вещь, в ней нет места личным пристрастиям. И ещё раз подчеркну, что языки программирования — это не объект изучения для школьной информатики. Это лишь форма записи для демонстрации концепций.
Учебная программа — серьёзная вещь, в ней нет места личным пристрастиям.
Перечитайте каменты — у всех в школе на всех уроках (включая информатику) была своя ситуация и своя конкретика. Откуда это? — просто все люди (включая учителей) — разные. Плохо ли это? — ну если б все, учащиеся в одно время, получали бы одно и то же знание — то счас бы не о чем было бы говорить. Все бы думали и действовали бы одинаково (включая одинаковые ошибки). Было бы это лучше, чем сейчас? (риторический вопрос)
языки программирования — это не объект изучения для школьной информатики. Это лишь форма записи для демонстрации концепций.
А в школе не время/не место изучать такие формы для демонстрации? Почему? Во «взрослом» мире такие формы очень даже востребованы. Почему бы нужным и востребованным вещам не учить в школе? (а чему, тогда, учить, если не нужному и важному? — впрочем, понятно чему… тому, чему счас повально учат, производя массы темени...)
Вкусами (приоритетами целей), конечно, можно меряться. Но если сойтись на том, что самые главные параметры языка программирования — это 1) затратность на работу с ним (время и силы) и 2) функционал, то по этим параметрам названные языки не равны.
(holywar mode on)
Думаю, холивар любят многие :), но разница меж питоном и нодой/js — в одном слове: асинхронность. Это значит выигрыш по параметру «функционал», а, следовательно, и по первому, главному — «затратность». (справедливости ради отмечу, что с 3.5 питона у него тоже есть асинхронность «из коробки» и нет нужды вручную перенатягивать синхронные либы на асинхронный Twisted, но поезд ушёл (объём сторонних библиотек уже в пользу жабы (можно посмотреть на pypi и npm — объём отличается в 3 раза, хотя да, в npm есть и не только нодо/жабо либы)) и питон-в-вебе пока только маячит в виде WebAssembly.
Много слов не буду писать почему так. Дам слово одному бывшему питонщику в статье про ноду, где он привёл пример, когда в одной проге на питоне нужно было совместить функционал двух синхронных библиотек…
(инглиш):
https://blog.nelhage.com/2012/03/why-node-js-is-cool/
просто все люди (включая учителей) — разные
Кто ж спорит… но мы тут вроде обсуждаем, что хорошо было бы включить в школьную программу, а вот она едина для всех. Вопрос её подачи — это уже другой вопрос.
А в школе не время/не место изучать такие формы для демонстрации?
Дело в акцентах. Вы гнёте линию, что надо выбрать какой-то один ЯП и учить ему. А я говорю о том, что информатика не об этом и надо учить концепциям с использованием 5-6 языков, не углубляясь в stdlib и прочее. Практически у каждой дисциплины есть 2 стороны — фундаментальная и прикладная. Фундаментальную учат в школе и в ВУЗах, прикладную — преимущественно в ПТУ или на работе. Так устроено изучения абсолютно всех наук, и я не вижу причин почему информатика должна тут быть не такой как все.
в одном слове: асинхронность
Вот хотя бы этот пример. Зачем нужна асинхронность? Чем она отличается от многопоточности? Чем параллельность отличается от конкурентности? Какие существуют модели конкурентности? В чём недостатки модели конкурентности в Node.JS и для каких задач она не подходит?
Вот на какие вопросы должно отвечать образование, а не выбирать что-то одно подо всё. "No Silver Bullet" ©
Я, например, говорил о том, что всем упомянутым вами вещам вполне можно учить на языках, имеющих прикладное применение.
Учить чему-то на том же Паскале или Бейсике, как мне кажется, форменное издевательство. Да, у них очень невысокий порог вхождения, что есть, безусловно, плюс. С другой стороны, дальше чем «пописать сортировку в учебных целях» на них не уедешь. В конечном итоге, мы удовлетворяем «средних» учеников, «работающих на оценку», но не даем никаких возможностей для роста будущим «рок-звездам» в программировании.
Собственно, откуда такая проблема — тоже вполне понятно. Проблема, собственно, начинается в учителях. Где ж их набрать-то столько, чтобы «в теме» были. Средний уровень школьного учителя информатики (могу и ошибаться в целом, говорю только по своему опыту) у нас невысокий.
На определенный момент мы упускаем другую проблему.
Допустим, у нас есть ученик Василий. Очень заинтересовался программированием, пишет, не покладая рук. Захотел написать что-то реально прикладное, даже язык новый, как мог, изучил. Допустим, ту же Java.
Проблема не в том даже, что бедному ребенку пришлось еще один язык выучить — впитывают-то они, как губки. Проблема начинается на том месте, где этот условный ученик Василий «затыкается» на каком-то месте своего pet-проджекта и идет искать помощи. У кого он ее ищет? Правильно, у ближайшего «авторитетного специалиста», у своего учителя. А учитель смотрит на Василия, как на дурака, и спрашивает, что за хрень тут написана…
Учить чему-то на том же Паскале или Бейсике, как мне кажется, форменное издевательство. Да, у них очень невысокий порог вхождения, что есть, безусловно, плюс. С другой стороны, дальше чем «пописать сортировку в учебных целях» на них не уедешь.Откуда такое пренебрежение к Паскалю и Бейсику? Есть же Component Pascal, Object Pascal (он же Delphi), Visual Basic .NET. Что такого на них нельзя написать, будучи школьником?
И Вы совершенно верно написали, что есть огромное количество преподавателей, которые их уже знают хоть в какой-то мере.
но не даем никаких возможностей для роста будущим «рок-звездам» в программировании.Да ладно, для таких достаточно предоставить доступ к компьютеру :-D
С прикладным применением всё равно не угадать… Вспомните, когда Вы в школу поступили, какие из сегодняшних мейнстрим-языков хотя бы существовали?
Ну вот, следуя вашей же логике, от таких вещей, как циклы, в преподавании надо отказываться. Вот конкретно на Component Pascal, Object Pascal и Visual BASIC отказываться? А как?
А вменяемые UI-библиотеки для этих языков?
Не говоря уже о том, что все 3 — достаточно нишевые и вендорозависимые вещи.
Собственно, назовите мне хоть одно реальное преимущество хотя бы одного из 3-х названных вами языков над той же многострадальной Java.
>> Что такого на них нельзя написать, будучи школьником?
Домашний сайт?
>> С прикладным применением всё равно не угадать…
Ну, собственно, тут трудно, да. Но те же BASIC и Pascal (как бы ни прискорбно оно звучало в отношении второго) вполне можно в разряд эзотерических языков относить. Экосистема вокруг них мертва.
Ну вот, следуя вашей же логике, от таких вещей, как циклы, в преподавании надо отказываться.На примере Pascal о них как раз можно рассказать. А в VB.NET, я так подозреваю, давно уже LINQ заправляет работой с Enumerable.
А вменяемые UI-библиотеки для этих языков?Есть. Для паскаля есть VCL и LCL. Биндинги к wxWidgets есть практически подо всё.
Домашний сайт?С VB.NET можно использовать ASP.NET MVC. Smalltalk, Haskell, Racket тоже отлично справятся с этой задачей. Хотя, честно говоря, в эту сторону я не думал. Считаете веб-программирование стоит тоже в учебный план включить?
назовите мне хоть одно реальное преимущество хотя бы одного из 3-х названных вами языков над той же многострадальной Java.Вы про паскали и бейсик? Они проще.
Ну, собственно, о них можно рассказать на примере почти любого другого языка. Изучать Паскаль, чтобы на нем продемонстрировать работу циклов?
>> А в VB.NET, я так подозреваю, давно уже LINQ заправляет работой с Enumerable.
В деталях — дьявол. LINQ — вполне себе достаточно нишевое вендорозависимое решение. К тому же скрывающее детали реализации. В образовательных целях предпочел бы какой-нибудь другой ORM.
>> Для паскаля есть VCL и LCL.
Мне вот кажется логичной мысль не завязывать образовательный процесс на проприетарное относительно дорогое решение, поддерживаемое одним единственным едва живым вендором…
>> Биндинги к wxWidgets есть практически подо всё.
Поэтому мне и кажется, что смысла завязываться на продукты Embracadero смысла нет.
>> Считаете веб-программирование стоит тоже в учебный план включить?
Собственно, сетевое программирование на уровне сервисов/служб/клиентов, КМК, стоит.
>> С VB.NET можно использовать ASP.NET MVC.
Вы же чуть выше говорили, что изучать нужно сами основы, а не конкретный продукт конкретной конторы, который неизвестно еще, будет ли жив через пару-тройку пятилеток.
>> Smalltalk, Haskell, Racket тоже отлично справятся с этой задачей.
К стыду своему признаю, что тут я вообще не авторитет.
>> Вы про паскали и бейсик? Они проще.
Хм, тут вы правы. А Python, Go? Не сложнее паскаля и бейсика, имхо. Впрочем, Go достаточно нишевой и таки гугловый, хотя комьюнити у него конское. Но если уж выбирать в качестве языка для обучения между Python и Basic (а их ниши вполне себе пересекаются), не вижу аргументов в пользу Basic'а.
Изучать Паскаль, чтобы на нем продемонстрировать работу циклов?Вы передёргиваете… Структурное программирование не ограничивается циклами. Какие ещё языки Вы бы выбрали для демонстрации именно этой концепции в чистом виде?
В образовательных целях предпочел бы какой-нибудь другой ORM.Вот Вы считаете, что LINQ — это ORM и вендорозависимое решение. А по факту, это не ORM и такой же подход можно реализовать во многих языках, где есть ФВП.
Мне вот кажется логичной мысль не завязывать образовательный процесс на проприетарное относительно дорогое решениеНу что Вы привязались к Паскалю, он ведь 1 из списка, образовательный процесс на него не будет завязан, он будет его синтаксис использовать для демонстрации структурного программирования. Я уж молчу про то, что LCL — это OpenSource (Lazarus).
Вы же чуть выше говорили, что изучать нужно сами основы, а не конкретный продукт конкретной конторы, который неизвестно еще, будет ли жив через пару-тройку пятилеток.Правильно. В школе и не нужно изучать ASP.NET MVC и т.п. Это был ответ на Ваш вопрос по поводу внеклассной программы для тех, кто очень увлёкся программированием. И смысл в том, что они найдут чем заняться вне школы для любого ЯП.
К стыду своему признаю, что тут я вообще не авторитет.Так это не стыдно. Их слабая известность — это недостаток текущей системы образования. Поизучайте их на досуге и поймёте почему те, кто уже ознакомился, хотели бы чтобы этим концепциям учили сразу… вместо того, чтобы пробиваться к ним годами через пот и слёзы промышленного программирования.
А Python, Go? Не сложнее паскаля и бейсика, имхо.Python гораздо сложнее, как любой мультипарадигмальный язык. Go — на мой взгляд не простой, а урезанный… Чуть в сторону и уже приходится извращаться.
Учить чему-то на том же Паскале или Бейсике, как мне кажется, форменное издевательство. Да, у них очень невысокий порог вхождения, что есть, безусловно, плюс. С другой стороны, дальше чем «пописать сортировку в учебных целях» на них не уедешь.
Да ну?! У меня был тёплый ламповый Бейсик на терминале. Но мы на нём такое писали… используя командные ASCII коды. В самом Бейсике не было никаких команд для перемещения курсора, но ASCII коды — позволяли такое делать. Так что на Бейсике мы делали то, что на прямую он делать не позволял.
PS сколько Вам лет, молодой человек?
Не уверен, что это существенно… 35
>> У меня был тёплый ламповый Бейсик на терминале. Но мы на нём такое писали… используя командные ASCII коды. В самом Бейсике не было никаких команд для перемещения курсора, но ASCII коды — позволяли такое делать.
Не сомневаюсь, было очень весело и вдохновляюще. Но вы же понимаете, что делали вы это не от хорошей жизни. Современный ученик с имеющимся инструментарием за сравнимое время Super Mario Bros. написать может. Только не на Бейсике…
В данный момент Бейсик может оказаться полезным для… хм… Для написания макросов в MS-Оффисе. Честно говоря, не знаю сфер применения, где у него не было бы лучшей альтернативы.
>> Так что на Бейсике мы делали то, что на прямую он делать не позволял.
Что-то мне кажется, это не в пользу языка говорит…
мы тут вроде обсуждаем, что хорошо было бы включить в школьную программу, а вот она едина для всех.
Да, программу нужно продумывать для всех…
… Ээ… нет, нельзя :( оказывается, что
Учебная программа — серьёзная вещь, в ней нет места личным пристрастиям.
Не можем мы с Вами тут, поэтому, вольно рассуждать об учебной программе. (законодатели, выходит, тоже не могут — у них ведь тоже есть личные пристрастия, которым не место).
Выходит, остаются дети без программы вообще… Ну или остаётся ждать непосредственно факс от Бога — может хоть у него пристрастия не личные…
Вы гнёте линию, что надо выбрать какой-то один ЯП и учить ему
Не говорил я такого, уж извините.
Разве, если один язык лучше другого, то это значит, что он лучше всех вообще?
Ну и я не говорил, что вся информатика — строго внутри компьютеров естьмъ.
языки программирования — это не объект изучения для школьной информатики. Это лишь форма записи для демонстрации концепций.
И Вы способы показать такие концепции детям, не используя ни одного языка?
Всё равно ж придётся на каком-то языке (русском, инглише, машинном и т.д.) рассказывать.
Фундаментальную учат в школе и в ВУЗах, прикладную — преимущественно в ПТУ или на работе. Так устроено...
А потом это приводит к тому, что выпускники не могут найти работу, потому что не в состоянии применить заученную теорию на практике, ну а работодели жалуются, что некому работать.
Даже если так сейчас и устроено — то не факт, что это всех устраивает и нет лучшего пути.
Почему школьников кумарит (самое ёмкое и культурное слово в данном случае) школа? — Она 10 лет вещает, что учит жутко нужному, но практически не даёт попрактиковаться в получнных знаниях, тем более в общественно полезных делах (к примеру, реальное производство чего-то нужного людям).
Зачем нужна асинхронность?
Для лучшей управляемости множеством объектов.
Если система быстрее отвечает на меньший запрос и больше на больший вне зависимости от того чем занята (т.е. способна менять приоритеты выполнения) — то это лучше (при достаточных ресурсах), чем если неспособна (синхронность).
Чем она отличается от многопоточности?
Многопоточность — частный случай асинхронности, основанный на множестве потоков управления.
Чем параллельность отличается от конкурентности?
Одно и то же на разных языках: по-русски и по-англицки, (записаное русскими буквами concurrency). Примерно то же и с parallelnost'yu.
Какие существуют модели конкурентности?
В педивикии расписано.
В чём недостатки модели конкурентности в Node.JS
В избыточной монопольности других :) (шутка)
и для каких задач она не подходит?
Можно сказать, что для много- и долго-мыслительных задач (CPU-bound), но, подумав, окажется, что подходит: на такой же модели можно написать процепрожорливую прогу.
Так что, выходит, что для всех подходит. (а лучше или хуже — Вы вопрос не ставили)
И касательно фундаментальных основ — то я крепко за них в школе. Нужно давать самую самую основу всего, всякой деятельности людей. В самом обобщённом виде — это управление.
Вот и нужно давать обобщённая теория для всех отраслей знаний людей. Чтоб в ней был расписын процесс управления как таковой (у человека он протекает в психике): из каких категорий состоит и какие взаимосвязи между ними есть. Т.е. это именно нетленные во времени знания. Изучив такую теорию, любой человек затем всю жизнь будет уметь самостоятельно учиться (впрочем, школа сейчас забивает детей ненужной ерундой, в итоге убивая практически любую тягу к знанию) и так же самостоятельно входить в любую отрасль деятельности (включая программирование: хоть на перфокартах, хоть на название_языка_программирования_популярного_на_ннный_год по желанию) в кратчайшие сроки.
И вместе с искусством Диалектики (искусство познания истины путём постановки наводящих вопросов) — это и есть та самая «Silver Bullet».
И Вы способы показать такие концепции детям, не используя ни одного языка?Само собой рассказывать придётся на русском. Но способ краткой записи всё равно нужен, так же как в математике.
В педивикии расписано.Ахах, давайте вообще школу отменим, можно же википедию почитать… Только вот не читают, включая Вас, судя по ответам на предыдущие вопросы :-)
В самом обобщённом виде — это управление.Что за управление? Менеджеров хотите готовить?
Но способ краткой записи всё равно нужен, так же как в математике.
А ещё, может, захочется дать детям посчупать комп на практике, и тут таки придётся пользоваться каким-то реальным ЯП. И выбор прост: брать что-то промышленное на данный момент (пусть оно и изменится через 5 лет) или брать то, что массово не востребовано в ромышленности?
давайте вообще школу отменим, можно же википедию почитать…
Вообще-то, дистанционные формы образования всё популярнее.
Или обязательно ходить в здание школы, чтоб там услышать унылую пестню педагога-пенсионера? (потому, что учителей-молодёжи за такую ЗП — негусто)
Только вот не читают, включая Вас,
Что будут читать школьники — вопрос организации и их мотивации.
А насчёт меня — я что, должен был Вам скопипастить оттуда сюда, чтобы показать, что я умею найти нужную мне в каждый момент времени информацию? :) самому не смешно?
судя по ответам на предыдущие вопросы :-)
Но что-то к моим ответам у Вас не появилось комментариев. Вы нигде не прокомментировали, если где что было неправильно.
Либо лень разбираться по сути, а не по копипасте из учебника, либо просто лень :) Впрочем, дело хозяйское.
Что за управление? Менеджеров хотите готовить?
Все люди всегда занимаются управлением. Кто-то управляет химическими реакциями (химики), кто-то физическими, кто-то предприятиями, кто-то общественными процессами и т.д.
И у управления как такового есть свои категории и закономерности. И если их знать — то войти в любую отрасль затем, после школы, в режиме самообразования, не составит большого труда. И именно это знание, знание теории управления, принадлежит к числу нетленных, не устаревающих со временем, что мегаважно в наш век перемен.
И выбор прост: брать что-то промышленное на данный момент (пусть оно и изменится через 5 лет) или брать то, что массово не востребовано в ромышленности?Хм, откуда взялся такой критерий? По-моему выбор: брать то, на чём удобно демонстрировать чистые концепции, или то, где куча разнородных концепций перемешаны в дикую кашу. Вы за какой пункт из этих двух?
Вообще-то, дистанционные формы образования всё популярнее.Есть обучение, а есть самообучение… Почитать вики — это про самообучение. В целом оно даже эффективнее, так как движется интересом, но без соответствующих навыков или менторства может быть слишком сложно.
А насчёт меня — я что, должен был Вам скопипастить оттуда сюда, чтобы показать, что я умею найти нужную мне в каждый момент времени информацию? :) самому не смешно?Да нет, конечно. Вопросы вообще были для примера… Просто некоторые ответы неправильные, некоторые неточные. Если Вам интересно восполнить этот пробел в знаниях, рекомендую книжку «Семь моделей конкуренции и параллелизма». В комментариях на мой взгляд не лучшее место расписывать, т.к. правильные ответы с пояснениями потянут на отдельную статью.
И именно это знание, знание теории управления, принадлежит к числу нетленных, не устаревающих со временем, что мегаважно в наш век перемен.Ладно, надо будет глянуть «Закон Времени», раз рекомендуете. А то всё равно пока слишком размыто выглядит.
Хм, откуда взялся такой критерий?
(очевидность mode) Да, вобщем, всё просто: время, отведённое виду хомо-сапиенс для детства — отведено не просто так, оно дано для подготовки ко взрослой жизни. (/очевидность mode) Следовательно, нужно давать самые актуальные вещи, которые востребованы во взрослой жизни.
Самые правильные фундаментальные знания, которые есть у человечества (хотя и заблуждения прошлого должны быть представлены в программе, но куда менее детально)
и самые востребованные технологии современности (но все былые технологии пересмотреть в программе — это вообще малореально), пусть они и изменятся к выпуску. К примеру, сейчас изучать работу компакт-дисков (в рамках курса технологий, а не фундамента) — всё-ж более адекватно, чем даже 3.5" дискеты.
то, на чём удобно демонстрировать чистые концепции, или то, где куча разнородных концепций перемешаны в дикую кашу. Вы за какой пункт из этих двух?
Я не могу назвать «кашей» мультипарадигмальный язык. Если на основе одного синтаксиса возможно показать больше концепций — то это явный выигрыш.
Про самообучение — да, дети ещё не умеют самообразовываться. Но если Вы таки доберётесь до «Закона Времени» — то поймёте, что если школа не научит самостоятельно учиться (а это нужно и показать, и рассказать, и активно практиковать, а затем и опираться на это в старших классах) — то это (вот, для наших дней и далее) будет самой большой ошибкой школы. И пока что, эта ошибка всё так же продолжается…
«Семь моделей конкуренции и параллелизма».
Спасибо за рекомендацию.
Я не могу назвать «кашей» мультипарадигмальный язык.
Смотрите в чём фишка: мультипарадигмальный язык не позволяет вам по факту использовать ни одну парадигму в чистом виде. Для обучения — это, на мой взгляд, самое ужасное. У школьника ещё не выкристаллизовалось понимание концепции, а его заставляют её применять на языке, который эту концепцию не поддерживает даже на 80%.
Для промышленного применения это катит, т.к. можно применять фичи какой-то концепции даже не понимая её… такой "херак-херак и в продакшн". Но тут надо понимать какой вы хотите результат — заложить основу для становления кодеров за еду, в стиле Индии и Китая, или основу для становления профессиональных программистов.
мультипарадигмальный язык не позволяет вам по факту использовать ни одну парадигму в чистом виде.
Ну конечно же позволяет.
В своё время, изучая питон, я спокойно писал функционально и, грубо говоря, знать не знал оператор «class» и конструктор __init__. Через какое-то время дошёл до ООП и начал всё это применять.
Счас, на жабоскрипте, всё это возможно точно так же: кому не надо ООП — спокойно пишет ф-ции.
Ну, разве что, Вы сможете продемонстрировать случаи, где возможность писать в одной парадигме мешала бы пользовать другую.
В своё время, изучая питон, я спокойно писал функционально и, грубо говоря, знать не знал оператор «class» и конструктор init.
Вы, видимо, путаете "процедурно" и "функционально". Невольно подтверждая мой тезис о том, что концептуального образования дико не хватает. Даже профессиональные программисты частенько путаются в элементарных вещах.
К примеру, в питоне есть мутабельные данные, этого уже достаточно для невозможности писать в чисто функциональном стиле и использовать стандартную библиотеку одновременно.
Ну или вот яркий пример. Скажите, чему с точки зрения ФП равно
random.random() == random.random()?
random.random() == random.random()
Заведомо — неопределённо.
Равно равности двух случайных чисел.
Два разных вызова дадут разные случайные числа — потому в общем виде более точного ответа не дать.
Вы, видимо, путаете «процедурно» и «функционально»
Возможно. Но если из результата работы процедуры взять и получить результат — то это уже прям меняет парадигму программирования? Даже если — то что? :)
Вот я думаю, что ровно ничего. Наличие у подпрограммы входных и выходных параметров — это более общий случай отсутствия первых или вторых. Как бы это ни называлось.
Невольно подтверждая мой тезис о том, что концептуального образования дико не хватает.
Кому? %)
Даже профессиональные программисты частенько путаются в элементарных вещах.
Получил значение выходного параметра — нужно записать в дневную отчётность: «воспользовался функциональной парадигмой»?
Вам шашечки или ехать?
в питоне есть мутабельные данные, этого уже достаточно для невозможности писать в чисто функциональном стиле и использовать стандартную библиотеку одновременно.
Разогрет и буду благодарен за реальный пример.
Сам бы может и накопал чего, но «мутабельные данные» — это же просто переменные данные, ну а в память записать значение можно на очень многих языках. И ну не вижу почему это может мешать функциональному программированию.
Заведомо — неопределённо.
Нет, с точки зрения ФП это равно true, т.к. функция оба раза вызывается с одинаковыми аргументами, точнее вообще без них. Вот и как с таким косяком в stdlib объяснять ФП?
Но если из результата работы процедуры взять и получить результат — то это уже прям меняет парадигму программирования?
:facepalm:
Вы думаете, что процедурном программировании подпрограмма не может вернуть результат? Прочитайте хоть статью на вики, а то ведь реально путаете.
И ну не вижу почему это может мешать функциональному программированию.
В ФП все данные неизменны. Собственно, что данные, что функции трактуются в математическом понимании. Т.е. что однажды попало в память, то так и будет там лежать, пока GC до него не доберётся. Изменить значение в памяти нельзя.
При этом переменные можно переназначать (rebinding), но данные от этого не меняются, просто становятся доступны для GC, если ни одна переменная с ними не связана.
А функция в математическом понимании обязана быть строго определена в зависимости от аргументов. Например, f(x, y) == f(x, y) вне зависимости от того, что такое f и какие значения связаны с x, y.
Вы забываете цели обучения в школе. Главная — знакомство с разнообразными предметами, по каждому из которых рассказывается классическая теория, т.е. то что общепринято и значительно уже не изменится. У школы нет задачи подготовить специалиста по конкретному предмету.
Захотел ребенок для себя «ежедневник» написать
Вы же понимаете, что учебный вариант можно написать абсолютно на чём угодно. А для реального понадобится не только бэкенд, но и 3 клиента под разные мобильные платформы, 1 — под веб и от 1 до 3 под десктопы. И это в реальности делает большая команда, а Вы хотите одного бедного школьника нагрузить задачей, которой ни один профессионал в одиночку не занимается?
ребенок, который реально «перерос» школьную программу и уже не получает кайфа от чисто «тренировочных» задач, кроме этих самых сортировок ничего написать не сможет.
К чему эта ложная дихотомия? Тренировочных задач гораздо интереснее сортировок целое море. Ну а если действительно перерос основы 5 языков, которые я перечислил, у него будет свобода выбора перейти к практическому применению одного из них уже вне школы.
>> C, Pascal, Smalltalk (есть в варианте для самых маленьких — Scratch), Haskell, Racket.
Вы про эти 5 языков? Серьезно?
>> Вы же понимаете, что учебный вариант можно написать абсолютно на чём угодно.
Я понимаю, что:
а) не на чем угодно возможно
б) не на чем угодно возможно в разумные сроки
в) не на чем угодно стОит
Ну и, собственно, из 5-ки «C, Pascal, Smalltalk, Haskell, Racket» не стОит ни на одном.
>> а Вы хотите одного бедного школьника нагрузить задачей, которой ни один профессионал в одиночку не занимается?
Вы что-то в дебри подались. Наколеночный ежедневник я, собственно, писал. Тысячи полторы строчек вышло. Не знаю, зачем там 100500 серьезных специалистов.
В общем и целом, не совсем понимаю вашу позицию. С одной стороны вы пытаетесь привить ребенку правила серьезной разработки, рассказать, чем фронтенд от бекэнда отличается, предъявить ему требования по качеству, допустимые для серьезной команды. С другой утверждаете, что все это он должен сделать на Pascal'е…
Вы про эти 5 языков? Серьезно?Вполне. Разве что насчёт C сомневаюсь, слишком низкоуровнево для непрограммистов.
А в остальном я за те языки, которые учат думать. Нравится или нет, но Java и Python учат разве что искать готовые решения на SO.
Pascal — структурное программирование, классические структуры данных и алгоритмы
Smalltalk — обмен сообщениями, ООП, программирование через отладку, интроспекция
Haskell — алгебраические типы данных, изоляция побочных эффектов, ФП
Racket — гомоиконность, метапрограммирование, DSL
Наколеночный ежедневник я, собственно, писал. Тысячи полторы строчек вышло.Я не про кол-во строчек, а про то, что в современном мире ежедневник без мобильных клиентов — это чисто учебный проект, делайте хоть с программным интерфейсом, хоть с консольным, хоть с GUI, никому кроме автора он не нужен будет.
Но следующим вопросом встаёт: зачему учить тому, на чём невозможно написать востребованного другими людьми чего-то?
А на чём их практически пробывать во время учёбы?
На том, что реально нужно и работает, вот сейчас, или на том, что вышло из массового употребления лет 20 назад?
Haskell с относительно недавнего времени стремительно набирает популярность. TIOBE его хэдлайнером ноября обозвали xD
Racket — это современный диалект Scheme, который в свою очередь используется в классической книге по Computer Science — «Structure and Interpretation of Computer Programs». Плюс на нём идет довольно крутая движуха разнообразных DSL, что весьма интересно, особенно при обучении.
это ж наркомания %))))
#lang racket
(require 2htdp/image)
(let sierpinski ([n 8])
(if (zero? n)
(triangle 2 'solid 'red)
(let ([t (sierpinski (- n 1))])
(freeze (above t (beside t t))))))
Это Lisp. По факту самый простой синтаксис для освоения. Но зашоренность сознания привычным С-like синтаксисом может мешать восприятию, это да.
К тому же Вы ж сами писали, что получать результат быстро — это круто.
Тут в 5 строках алгоритм отрисовки треугольника Серпинского. А фракталы — это интересно и весело. Теперь прикиньте сколько кода писать на JS пришлось бы для того же результата :-D
К тому же есть, например, проект языка програмирования Factor наследующего и принципы функциональной парадигмы.
P.S. Logo ещё не обсудили :)
По факту самый простой синтаксис для освоения.
Вот это самый простой синтаксис??
))))))
это не смайлик, а 6 (ШЕСТЬ!!!) закрывающих скобочек.
Но зашоренность сознания привычным С-like синтаксисом
C тут непричём. Копаем глубже. Где в жизни люди впервые применяют операторы сравнения меньше, больше и т.д.? — в школе.
И как они там выглядят? функциями «zero?» или «positive?»? — нет, математическим языком оно записывается знаками. Вполне логично и компьютеру писать программу такими же знаками (привычнее) и даже короче:
positive? n
11 символов
vs
N > 0
5 символов
И «zero? n» vs «n == 0» — 7 и 6 символов соотв.
Больше букв, к тому же нематематического синтаксиса.
Фракталы — это, конечно, просто отлично. Но рекурсия для этого есть не только в лиспах (впрочем, в ракете интересный подход, когда можно объявить ф-цию и тем же самым её вызвать: по сути, это скрытый оператор goto). Но синтаксис… просто жуть. Столько лишних (скобочек (в [самых] разных (местах)) ('просто?) кошмар)
Теперь прикиньте сколько кода писать на JS пришлось бы для того же результата :-D
Давайте прикинем. Кофескрипт. И для чистоты эксперимента буду пользовать либу с тем же именем и теми же ф-циями:
require '2htdp/image'
sierpinski = (n) ->
if n == 0
triangle 2, solid, red
else
t = sierpinski n-1
freeze above t, beside t, t
sierpinski 8
Ракетная прога (без учёта "#lang racket") — короче на одну строку благодаря фиче вызова ф-ции вместе с определением. Размером же её код: 168 символов. Кофескриптовый код — 156.
Читабельность — разница налицо.
К слову, ракет — тоже мультипарадигмальный: «объектно-ориентированный, процедурный,
рефлективный, функциональный, логический, мета» (с педивикии).
Ну это всё мерянья одним место.
А главное: почему, если лисповые так уж хороши, то на них так… кхм… негусто софта?
это не смайлик, а 6 (ШЕСТЬ!!!) закрывающих скобочек.
И что? Скобки редактор прекрасно расставляет, когда пишешь на лиспе, на них вообще внимание не обращаешь.
И как они там выглядят? функциями «zero?» или «positive?»? — нет, математическим языком оно записывается знаками
Наличие вспомогательных функций не запрещает Вам написать (> n 0). Что читабельнее вопрос спорный.
Читабельность — разница налицо.
Имхо, не в пользу CoffeeScript… freeze above t, beside t, t — вообще нечитаемо. Но вопрос даже не в этом… для JavaScript я не видел библиотек, похожих на стандартную поставку Racket. Там придётся собирать учебный дистрибутив из г**на и палок, ой т.е. из npm-пакетов неизвестного качества.
К слову, ракет — тоже мультипарадигмальный: «объектно-ориентированный, процедурный, рефлективный, функциональный, логический, мета»
Есть такое… Хотя правильнее сказать, что он метаориентированный, а библиотеки для других парадигм — уже как следствие. Это даёт чуть большую чистоту. См. директиву в первой строке. Её можно заменить на другую и получить язык с другим набором концепций, т.е. они не навалены все в одну кучу. Например "#lang typed/racket"
написать (> n 0). Что читабельнее вопрос спорный.
Читабельность задаётся стереотипами, которые внедряются через образование. А это школа. А в школе — математика. И там оператор — между операндами.
Имхо, не в пользу CoffeeScript…
Конечно же, это дело привычки. Но чем меньше информации нужно получить (и обработать) для понимания смысла — тем читабельность лучше.
Если не согласны — можем сравнить текст на С со скомпиленным бинарём в HEX'е ;)
Алгоритм один и тот же, но букаф — очень разное к-во.
freeze above t, beside t, t — вообще нечитаемо.
Можно добавлять скобочек поначалу, пока появится привычка:
freeze above t, beside(t, t)
или
freeze above(t, beside(t, t))
или
freeze(above(t, beside(t, t)))
(последний вариант Вам должен понравиться ;) скобочек так, поболе)
Снова же дело привычки. Но есть потенциал роста скорости набора программы путём уменьшения объёма вводимой инфы (символов) при неизменной окончательной логике.
Собсно, это и есть смысл синтактического сахара как такового. Ну и, понятно, не все исторические языки затачивались под это.
для JavaScript я не видел библиотек, похожих на стандартную поставку Racket
Ну это вообще в стиле холивара «какой линух дистр лучше: с опенофисом по умолчанию или без». Так можно и какое-нить руби взять и померять пиписк*ми с ракетой или ещё чем.
Благо, на дворе не оффлайн 90-хх и дистр с языком друг принёс на компакте. Что надо — берётся и ставится.
И нужно сравнивать экосистемы языков. Ибо вот писать с нуля какую-нить либу — это вот уже боль.
npm-пакетов неизвестного качества.
Как я понимаю, каждую строчку исходников и качество кода ракет дистрибутива Вы лично проверяете перед использованием…
Тогда молчу :)
Её можно заменить на другую и получить язык с другим набором концепций, т.е. они не навалены все в одну кучу. Например "#lang typed/racket"
Ну, если у скрипта поменять шабанг — то тоже можно получить очень даже другой язык :)
#!/usr/bin/python
#!/bin/bash
#!/usr/bin/coffee
#!/usr/bin/node
#!/usr....
Читабельность задаётся стереотипами, которые внедряются через образование. А это школа. А в школе — математика.
У, Вы сами себя в угол загнали… см. выше коммент про ФП.
Где императивное программирование, а где математика — это ж 2 диаметрально противоположных мира )))
Вообще, про читабельность я сравнивал (positive? n) и (> n 0)…
(n > 0) и (> n 0) на мой взгляд эквивалентны по читаемости, просто второй вариант непривычен, зато единообразен — функция всегда на первом месте.
Алгоритм один и тот же, но букаф — очень разное к-во.
Ладно, я следаю вид, что не заметил Ваш чит с подменой JS на кофе, т.к. очевидно, что в JS скобок было бы ничуть не меньше, чем в Racket.
И нужно сравнивать экосистемы языков. Ибо вот писать с нуля какую-нить либу — это вот уже боль.
У экосистемы Node.JS leftpad-синдром. При этом даже Вы преподносите число пакетов в N раз превышающее кол-во пакетов под Python как плюс. Вы даже не задумываетесь насколько это жирный минус. Задумайтесь, откуда берётся эта разница? Думаете JS решает в N раз больше задач, как бы не так...
Ну, если у скрипта поменять шабанг — то тоже можно получить очень даже другой язык :)
Да, только тут то язык остался тот же. Так можно сочетать разные концепции в рамках одного языка, не нарушая чистоту концепции. Имхо, для обучения — это прекрасный вариант.
программирование, а где математика — это ж 2 диаметрально противоположных мира )))
Ну, вообще-то, это один из разделов математики :)
Информатика (см: https://ru.wikipedia.org/wiki/Математическая_предметная_классификация )
Ладно, я следаю вид, что не заметил Ваш чит с подменой JS на кофе
Да какой чит? Конечно же кофескрипт. Чистый ЖС синтаксис — довольно уныл (те же сишные операторные скобки надо лепить — печаль).
Но все плюсы всех отраслей, где живёт чистый JS — сохраняются. За сим, вполне допустимо говорить о жабоскрипте с более вменяемым синтаксисом (с сайта CS: The golden rule of CoffeeScript is: «It's just JavaScript»)
Вы преподносите число пакетов в N раз превышающее кол-во пакетов под Python как плюс.
Хорошо, может там не все пакеты тянут на серъёзные либы, а на pypi пусть все. Но сути это не меняет.
Думаете JS решает в N раз больше задач, как бы не так...
Речь об удобстве решения задач, гибкости (2 и больше синхронных либы в одном питон-процессе = боль) и куче мест применения.
А с учётом того, что JS бегает в браузерах почти монопольно, то вполне можно попробовать и поутверждать, что таки больше. И даже если на серваке это пока не так, то тенденция — вполне позволяет делать такую ставку.
Математическая_предметная_классификация
Там по ссылке какая-то жесть… история, биология, геофизика и т.д. — это тоже разделы математики?
ФП — это раздел дискретной математики, там всё понятно.
Императивное программирование же искажает базовые математические понятия — функция, значение, etc.
Да какой чит? Конечно же кофескрипт.
С чего вдруг "конечно же"? Вы недавно про ES6/7 писали… А какая вам вообще печаль, что там в ES творится, если Вы по факту другой язык используете? Да и почему "конечно же кофескрипт"? Почему не TypeScript или не PureScript или не ClojureScript или ещё пара десятков вариантов? Вы свой личный выбор выдаёте за что-то дефолтное.
Но сути это не меняет.
Суть в том, что при выборе каждого пакета, Вам придётся сталкиваться с буридановым выбором.
история, биология, геофизика и т.д. — это тоже разделы математики?
хм… педивикия явно загнула.
Императивное программирование же искажает базовые математические понятия — функция, значение, etc.
Я несколько иначе смотрю на это.
В моей вселенной математика — это язык описания общевселенской Меры (предельно обобщённой категории, широкоизвестной в пока узких кругах, гуглимо). Мера — это числа, которые определяют назначение всего для всего. Для материи мера — это матрица возможных устойчивых состояний (в частности таблица Менделеева, 5 агрегатных состояний вещества) и путей перехода между ними (типа, чтоб расплавить 1кг льда нужно N джоулей энергии и т.д.). Для информации мера — это система кодирования. Если есть информация, но нет её декодировщика — то «смотрю в книгу, вижу… буквы». Для запуска бинаря — нужен драйвер его формата, для чтения с ФС — нужен драйвер, который знает где там что, на один и тот же иероглиф если будет смотреть русский — то мало чего поймёт, а вот японец — куда больше (у него есть соотв. система кодирования в знаниях) ну и т.д.
Потому, алгоритмы (программы) как таковые — это пути перехода между какими-то состояниями, а соответственно — часть Меры, для описания которой люди понапридумали язык «математика».
С чего вдруг «конечно же»?
Потому, что там вкусный синтакс сахар.
Вы недавно про ES6/7 писали…
Если сильно нужны фичи из них — то пока CoffeeScript2 допиливают до их использования, отдельные модули можно писать на чистом JS — всё будет работать в одном процессе.
Почему не TypeScript
Это оно же, тока в профиль (+статик типы и ООП, которое уже и так есть в ES6)
не PureScript
Вижу, там сахар не такой сладкий.
не ClojureScript
«You must have Java 8 installed to proceed.»
={ }
Вы свой личный выбор выдаёте за что-то дефолтное.
Грусть, если был так понят.
Конечно же, это всё мои предпочтения. И всё, что я пытаюсь — это вызвать здравый огонь критики в адрес этого выбора.
придётся сталкиваться с буридановым выбором.
Да ну, тоже мне проблема :)
Уже отсеиваю их за считанные минуты. Зато есть выбор.
Было куда хуже, когда программел асинхронность на питоновском твистеде и хотелось один в принципе обычный сетевой протокол поверх TCP, но его попросту не было на твистеде (обычно питон либы — синхронны, структура же либы для твистеда — кардинально иная, и переписывание == боль*боль).
алгоритмы (программы) как таковые — это пути перехода между какими-то состояниями
О, Вы мне напомнили ещё одно отличие между императивным и декларативным подходами. Императивный описывает процесс изменения состояния, а декларативный — процесс перехода между состояниями.
Конечно же, это всё мои предпочтения. И всё, что я пытаюсь — это вызвать здравый огонь критики в адрес этого выбора.
Ну как же я могу критиковать CoffeeScript, он же вдохновлён примером Ruby. А на Ruby я программировал аж 8 лет :-)
Разве что злоупотребляете poetry mode..
Уже отсеиваю их за считанные минуты. Зато есть выбор.
Зашёл ради интереса на npmjs поискать клиент для redis и "193 results for ‘redis client’" и при этом даже сортировки по кол-ву звёзд нет… Уже начинаю завидовать Вашей скорости анализа сторонних библиотек.
Было куда хуже, когда программел асинхронность на питоновском твистеде
Да я за питон нигде не агитировал. И даже согласен, что GIL в текущих реалиях уже тоже шоустопер. Впрочем, эвент-луп JS от блокирующих операций пока не защищен и это тоже проблема.
Императивный описывает процесс изменения состояния, а декларативный — процесс перехода между состояниями.
Мой вариант:
императивный — это сами переходы между состояниями (типа жд-рельсы между станциями),
а декларативный — это сами состояния (станции).
как же я могу критиковать CoffeeScript, он же вдохновлён примером Ruby. А на Ruby я программировал аж 8 лет :-)
Ну так тогда должно быть проще критиковать ;)
Кроме того, он и питоном вдохновлён (в частности, отступы == операторные скобки)
клиент для redis и «193 results for ‘redis client’» и при этом даже сортировки по кол-ву звёзд нет…
:D да, поисковик там тот ещё. Причём, звёзды — это, как я понял, вторичный параметр. Сортировка выдачи поиска идёт, похоже, по к-ву скачиваний за период.
Уже начинаю завидовать Вашей скорости анализа сторонних библиотек.
Да, собсно, ничё хитрого.
Выдача отсортирована по к-ву скачиваний в сутки/неделю/месяц. На каждой странице либы справа её скачивания расписаны — и лидер очевиден (из первых трёх: «redis», «ioredis» и «redis-then» популярность в таком порядке и ниспадает). Ну на крайняк можно ещё кликнуть на ссылочку на github'е репы либы — там к-во наблюдающих, звёзд и форков тоже красноречиво говорит о популярности.
GIL в текущих реалиях уже тоже шоустопер.
Чессгря, в своё время был неприятно удивлён этим GIL'ом в питоне…
эвент-луп JS от блокирующих операций пока не защищен и это тоже проблема.
Это, скорее, фича :) опция выбора концепции скрипта, чем проблема.
Если нужно простой консольный рукопускаемый скрипт (т.е. асинхронность в таком случае — часто просто помеха лишними буквами в реализации) — то для доступа к файлам можно пользовать синхронные версии операций и получить более наглядный алгоритм (как читается — так и выполняется), такой себе, «async/await».
Мой вариант:Не, оба определения не подходят, т.к. императивный стиль подразумевает именно изменение состояния, будь то состояние объекта или глобальные переменные. Предыдущее состояние затирается мгновенно.
императивный — это сами переходы между состояниями (типа жд-рельсы между станциями),
а декларативный — это сами состояния (станции).
Ну а по второму, если бы мы могли сразу указать состояния, то достаточно было бы указать финальное и не писать программу вообще. Вместо этого приходится описывать функции в математическом смысле, т.е. соответствие между множеством аргументов и множеством результатов, другими словами переходы между точками множеств (состояниями). С точки зрения математики, это называется морфизм.
да, поисковик там тот ещё.Да нормальный поисковик, ну да, может половина выдачи там не является redis клиентами, но другая половина ведь реально является. Т.е., грубо говоря, есть 93 варианта, из которых Вы рассматриваете только 3. Но при этом говорите, что это мегапреимущество, что есть ещё 90 вариантов. Вам не кажется, что соотношение 1 к 30 выглядит как серьёзная проблема в экосистеме, в частности ведущая к сильному распылению усилий сообщества?
Это, скорее, фича :) опция выбора концепции скрипта, чем проблема.Это была бы фича, если можно было одновременно несколько эвент-лупов запустить, какие-то для блокирующего кода, какие-то для неблокирующего.
Но при этом говорите, что это мегапреимущество, что есть ещё 90 вариантов.
Мега — не мега, но берётся самая популярная либа и юзается. Если всё хорошо — значит хорошо.
Но если насчупываются грабли? — то прежде чем упираться в её дебаг — можно посмотреть на другие либы. Вполне возможно будут беспроблемные. Именно вот это вот — реальный плюс.
в частности ведущая к сильному распылению усилий сообщества?
Ну, демократия — это когда каждый сам имеет своё мнение. Не нравится кому-то всё существующее — он пишет своё. И что, кто-то может сказать, что он не имеет права? Что он непременно обязан начать сотрудничать с авторами других либ? С чего бы это?
А если те авторы зашли в реальный тупик и не хотят из него выходить? Тут поможет только альтернатива.
А усилия любого сообщества — в способности договариваться. Если же люди не умеют этого — то всегда будет рознь. Это психология, невзирая на ЯП.
несколько эвент-лупов запустить, какие-то для блокирующего кода, какие-то для неблокирующего.
эээ… но у блокирующего кода нет ивент-лупа… А если есть — то это уже асинхронный код.
Но если насчупываются грабли? — то прежде чем упираться в её дебаг — можно посмотреть на другие либы.
OMFG, т.е. мы выбрали самое популярное и подходящее нам решение, но оно оказалось настолько бажным, что проще поискать что-то другое?.. Если бы я ещё не знал JavaScript, Вы меня такими аргументами убедили бы держаться от него как можно дальше :-)
Ну, демократия — это когда каждый сам имеет своё мнение. Не нравится кому-то всё существующее — он пишет своё.
Извините, но это не демократия, это детский сад на уровне "у кого куличик лучше вышел". Зачем тратить время на отдельный проект, когда можно за гораздо меньшее время добавить фичи/исправления в существующий? NIH-синдром или не в меру раздутое ЧСВ?
А если те авторы зашли в реальный тупик и не хотят из него выходить?
Да, такое бывает, но редко. Если авторы существующего решения не ответили в течении месяца на ваш pull request, то это действительно повод задуматься о создании отдельного проекта или форка. Но не убеждайте меня, что авторы всех популярных npm-пакетов забили на поддержку и месяцами на github не заглядывают. Я всё равно в эту версию не поверю :-)
А усилия любого сообщества — в способности договариваться. Если же люди не умеют этого — то всегда будет рознь. Это психология, невзирая на ЯП.
Все люди умеют договариваться и почти все умеют здраво мыслить. Мешает этому, как правило, юношеский максимализм или околорелигиозные предубеждения. От ЯП это не зависит, но способность договариваться характеризует его сообщество.
эээ… но у блокирующего кода нет ивент-лупа…
да, корректнее было сказать несколько потоков, часть из которых под эвент-лупы, а часть — под блокирующий код.
т.е. мы выбрали самое популярное и подходящее нам решение, но оно оказалось настолько бажным, что проще поискать что-то другое?
Почему оказалось? Вы не видите слово «если» в моём предложении? Или почему условие всегда должно быть истинным?
Нет проблем в самой популярной либе — хорошо. А что делать, если есть? Или самый популярный код — это значит не содержит ошибок? Или может это не касается каких-то других языков?
И если расписан сценарий что делать в случае наличия багов — то это всё, лапки кверху и «держаться от него как можно дальше»? Ну хорошо, можете не планировать что делать, когда нужная софтина начнёт глючить. Придётся планировать уже по факту.
А с Вашей логикой — выходит — нужно держаться подальше от языков, у которых есть хоть где-то альтернативные реализации чего-либо %)))
Т.е. если я напишу что-нить дублирующее на том же ракете и опубликую — Вам придётся держаться и от него подальше :D
Зачем тратить время на отдельный проект, когда можно за гораздо меньшее время добавить
С тем же успехом можно распросить зачем кто-то пишет линух, если есть *BSD? Зачем убунта, если есть дебиан и редхаты и прочее.
Это уже не ко мне вопросы. Это психология реальных людей, которые есть.
Все люди умеют договариваться
:)
Если б это было так — то ситуация, когда все квартиры в подъезде годами платят кучи денег за еле-тёплые трубы вместо того, чтоб послать лесом центральную теплосеть из неэффективных дармоедов, скинуться, поставить котёл на подъезд и получить экономию с теплом в достатке — была бы невозможна.
Но угадайте: что происходит в реальности…
Или та же свеженькая тема поборов на «капитальный ремонт»: большинство будет платить в фонды капремонта десятилетиями, не видя никакого реального ремонта их дома. А пойти предусмотренным законом путём самостоятельно скинуться домом, отремонтировать самим (или нанять бригаду) и не платить непонятно куда — это сделают доли процентов.
и почти все умеют здраво мыслить
Вы сегодня щедры на похвалы населению :)
Но почему-то якобы здравомыслящие живут так, будто для наших детей и внуков есть запасная планета, а эту можно гадить и обжирать пока на ней не останется места виду хомо-сапиенс.
Экологичекий, политичекий, экономический кризисы — это всё из-за здравомыслия?
Нет проблем в самой популярной либе — хорошо. А что делать, если есть?
Очевидно же, исправить и послать pull request. Почему надо сразу писать свою альтернативу?
А с Вашей логикой — выходит — нужно держаться подальше от языков, у которых есть хоть где-то альтернативные реализации чего-либо %)))
Нет, Вы передёргиваете… альтернативы — это хорошо, но ещё лучше когда альтернатив немного. Ну сколько есть способов написать клиент для redis (обычный, с поддержкой full-duplex, с поддержкой cluster, ну и парочку с учётом особенностей ЯП). В идеале хотелось бы иметь все варианты в одном пакете, но даже если будет 5 альтернатив — это ok.
Но что толку от большого кол-ва альтернатив, если 95% из них похожи как под копирку в техническом плане или никому не нужны?
Зачем убунта, если есть дебиан и редхаты и прочее.
Между прочим, это один из основных факторов, который сдерживает популяризацию Linux уже десятки лет. Если бы было меньше 10 дистрибутивов + узкоспециализированные, дело бы шло гораздо быстрее. Сравните с тем же Linux под мобилки… Есть Android и он вполне популярен. Да, там тоже лезут Firefox OS, Ubuntu Touch, MeeGo, etc. Но это уже чисто бизнес, все хотят кусок рынка.
Вы сегодня щедры на похвалы населению :)
Ну, я не утверждал, что все люди ежечасно пользуются своими способностями договариваться и здраво мыслить. Но если отрицать их наличие в принципе, то это ж дурдом получится )))
исправить и послать pull request. Почему надо сразу писать свою альтернативу?
А если pull-request размером больше, чем изначальная либа? %)))))
Кроме того, что делать, пока ждёшь приёмки пулл-запроса в мейн-стрим и нового релиза?
руками за собой по своим проектам таскать свои патчи? — зачем, если есть NPM? — опубликовал себе тихоньку то, что тебе надо и пользуешь.
Ан нет, набежали спорящие, нашли поиском то, что нечто «для себя» и давай дальше спорить %)
Но что толку от большого кол-ва альтернатив, если 95% из них похожи как под копирку в техническом плане или никому не нужны?
А вот, выше, у меня заранее и получился неплохой вариант ответа на этот вопрос.
Примерно то же происходит и на гитхабе. Куча практически копий. Спроста ли? — но для того, чтоб послать свой пулл-реквест на 2 строки, всё равно нужно сделать копию начальной репы, и предлагать изменения уже там. Ну а со стороны кажется, что маньяки, просто дублируют без толку.
это один из основных факторов, который сдерживает популяризацию Linux уже десятки лет
ему всего-то 25 %)
дело бы шло гораздо быстрее
А кому это было нужно, это быстрее? Кто субъект управления этим процессом? — никто?
Ну так какие тогда вопросы :)
Люди хотят свой дистр, чтоб всё там было, как хочется — вот берут и делают. А то, как это там отразится на общем продвижении линуха в общество — вопрос уже, как минимум, не первый. Результат — налицо.
Коммерческие всякие винды с огрызками — их понятно кто продвигает и зачем. И форк сделать крайне сложно. Ессьно, этого всего будет не много веток.
Есть Android и он вполне популярен
Ну, помилуйте, он не просто «есть». Он чуть ли не монополист на просторах вариантов железа (огрызки же никаких вариантов никому не предлагают) и очень настойчиво продвигается. И кто его продвигает — тоже субъекта видно.
Но если отрицать их наличие в принципе, то это ж дурдом получится )))
Ну так оглянитесь вокруг :) Так оно и есть: дурдом.
Добро пожаловать на Землю…
руками за собой по своим проектам таскать свои патчи? — зачем, если есть NPM? — опубликовал себе тихоньку то, что тебе надо и пользуешь.
А что npm разве не позволяет подключить репозиторий без создания пакета?
Примерно то же происходит и на гитхабе. Куча практически копий.
Гитхаб не считает форки за отдельные проекты. Так что там всё ok. В принципе, мне без разницы хотят публиковать каждый чих в npm — пусть публикуют. Я просто Вам намекаю, что засорение репозитория пакетов — это минус, а не плюс.
Я, кстати, посмотрел про "закон времени". Собственно, там основная мысль про нарастание информационного шума. Будь то СМИ, соц.сети или npm. Объём знаний не увеличивается так быстро, как они хотят показать. Увеличивается объём мусора. Научить выкапывать из под этого мусора неизменные концепции — это и есть задача современного образования. Если мы поддерживаем у самих себя и у детей иллюзию постоянной гонки — ничего хорошего из этого не выйдет.
Условно говоря, я Вам говорю:
Посмотри, какие классные концепции люди сформулировали в 50-x — 80-x годах прошлого века. Вот языки, в которых можно их пощупать на практике. Если их изучить, то ты качественно вырастешь как профессионал.
А Вы отвечаете:
Отстань, у меня тут ES7 вышел…
Мне надо срочно заменить Math.pow(x, y) на x**y.
Утрировано, конечно. Но смысл именно такой.
В итоге для Вас мейнстрим выглядит как бесконечное развитие, а для меня как вялотекущая имплементация концепций 30-50-летней давности.
Которые, блин, неизменны, как ассоциативность сложения.
Иногда смотришь на мейнстрим-языки и думаешь "ребята, а вы ну хоть что-то новое придумали за предыдущие 20 лет?".
Кто субъект управления этим процессом? — никто?
Коммерческие дистры Linux тоже есть, но это уже сильное отвлечение от темы.
А что npm разве не позволяет подключить репозиторий без создания пакета?
А действительно… умеет. И забыл как-то. Вполне возможно, что не я один такой :)
засорение репозитория пакетов — это минус, а не плюс
Засорение — да. А отсутствие фильтарции (цензуры) — не всегда. Тут уж зависит от типа психики посетителя репозитория: если человек предпочитает сам определять для себя параметры и потребность — то ему лучше, чтоб был выбор шире и как можно менее искуственно ограничен, если же человек предпочитает опираться на заготовленное за него мнение/решение/софт — то он будет рад, если выбирать особо не придётся.
Объём знаний не увеличивается так быстро, как они хотят показать.
Т.е. тысячу лет назад, когда дед, отец, сын, внук и правнук пахали землю одними и теми же технологиями на фоне сегодняшних только и успевай следить за новинками в области с/х — это не рост объёма знаний? Всё мусор? А главное — скорости обновления этих знаний.
Почему так случилось, что полученный всего-лишь в 70-80-х годах диплом ныне без обновлённых знаний не значит актуальности? (или у кого-то в офисе стоит комп на перфокартах?) Т.е. всё, что появилось с 80-ых — это всё мусор???
В 70-х не было понятия об интернетах всяких, о компах мало кто слышал. прошло каких-то 40 лет (всего-то 2 поколения вступили в жизнь) — и технологическая сфера обновилось до неузнаваемости. Никогда до этого прежде никакие 40 лет не приносили таких громадных перемен. И всё мусор?
Вообще-то, мы тут с Вами счас обсуждаем какую часть из этого «мусора», выдуманного за последние 40 лет, стоит преподавать новым поколениям.
На западе тоже есть некое понимание об этом (ролик «Знаете ли вы?» https://www.youtube.com/watch?v=xOsL9GIROLg)
Объём мусора без кавычек, конечно же, тоже растёт (объём инета удваивается счас каждые 2 года, или где-то так). Конечно же, далеко не всё там полезные знания :) неск процентов только. Но когда в истории людей были такие скоростя роста объёмов информации?
Научить выкапывать из под этого мусора неизменные концепции — это и есть задача современного образования.
Это да. И самой неизмнной концепцией является достаточно общая (в смысле универсальности применения) теория управления.
Все компы и парадигмы программирования — они уже весьма переменны.
Если мы поддерживаем у самих себя и у детей иллюзию постоянной гонки — ничего хорошего из этого не выйдет.
Иллюзия? Т.е. экспоненциального роста объёмов инфы нет?
И какой гонки?
Рост скорости обновления информации — явление объективное. Т.е. хочешь — не хочешь, а оно имеет место.
И вопрос стоит лишь: как себя вести и что делать, чтоб не оказаться на обочине истории, не сумев совладать с этим явлением?
Думаете, не стоит детям рассказывать об этой доминанте сегодняшнего дня? Плюс о том, как со всем этим совладать.
Если их изучить, то ты качественно вырастешь как профессионал.
Вижу, Вы имеете дело с образованием, и далеко не только со стороны студента.
Ну так должны знать, что мотивация «вам это в будущем понадобится» — крайне неэффективна, даже если давать реально полезные вещи (кстати, почему так?)
А Вы отвечаете: Отстань, у меня тут ES7 вышел…
Ну понятно, сам написал, сам закритиковал :) (я то такого не говорил)
Да и не очень понятно как у Вас получается пытаться противопоставлять разнокачественности: парадигмы программирования с конкретными языками… Причём, мне отводится роль строго конкретно-языкового :) Будто слова ООП я не слышал, принципов не знаю и рассказать о них не могу…
В итоге для Вас мейнстрим выглядит как бесконечное развитие, а для меня как вялотекущая имплементация концепций 30-50-летней давности.
Т.е. Вы способны на одних лишь концепциях, без практической реализации в ЯП творить софт?
Или на тех же языках 50 летней давности возможно удовлетворить запросы рынка?
А если нет — то почему Вы критикуете улучшения? Или принцип async/await был расписан 50 лет назад?
Или какой-то асинхронный язык существует с тех пор, идеальный и неизменный? (как классика АвтоВАЗа :)
Почему тогда Вы противопоставляете концепции их реализации? Или не нужно изучать реализации? Пусть дети сами себе языки пишут с нуля?
Вполне логично, что индустрия всё больше и больше понимает какие нужны концепции и как их лучше всего записать, каким синтаксисом. И языки меняются в эту сторону. Что здесь плохого? — мне непонятно…
«ребята, а вы ну хоть что-то новое придумали за предыдущие 20 лет?»
Подразумевается, что Вы бы хотели от них новых именно концепций. Технологии на их основе — не в счёт?
Но с Вами никто спорить не собирается, что в 2+2=4 выдумать чего-то нового — сложно.
О чём Вы тогда вообще?
Мне думается, Ваши претензии как раз в том, что кто-то посмел внедрить какую-то концепцию в какой-то «не тот» язык и имел смелость сказать об этом (нахал, буквально!). «Ведь это наша концепция», «мы её приватизировали!», «не сметь её использовать!», «придумывайте свою алгебру! а мы посмотрим как у вас это выйдет».
Не думаю, что это конструктивная позиция.
Люди ищут и будут искать всё более и более удобные формы использования лучших принципов-концепций. И с этим ничего не поделать.
Стараться держаться за однажды освоенные синтаксисы и критикуя всё новое только потому, что оно новое (а равно восхвалять старое потому, что оно было раньше) — значит терять адекватность реалиям…
«ребята, а вы ну хоть что-то новое придумали за предыдущие 20 лет?»
«Интел выпустил новую линейу процов?? — Пффф!!! Дети! Машина Тьюринга была выпущена полвека назад!»
Т.е. тысячу лет назад...
Любите Вы передёргивать… Я имею в виду, что после научного прорыва XX века сейчас идёт своеобразный этап стагнации… Человечество сейчас занимается техническим совершенствованием того что есть… помощнее, покомпактнее и т.д., это уже не качественный рост, а плавное усовершенствование существующих технологий.
Но когда в истории людей были такие скоростя роста объёмов информации?
И что? Скорость роста объёмов информации не равна скорости роста знаний и даже не пропорциональна. Вы же понимаете, что более 95% объёма современной информации — это фотки и видосики, из которых 99% даже не учебные, не говоря уж о том, чтобы они несли какие-то новые знания. А оставшиеся 5% почти полностью заняты сектором BigData, который собирает информацию о действиях пользователей на сайтах и т.п.
Стоит ли рассказывать детям, что сейчас модно фоткать еду, снимать котиков, собирать статистику и для этого надо дофига HDD? Да можно, только причём тут обучение познанию?
Вижу, Вы имеете дело с образованием, и далеко не только со стороны студента.
Ну, я скорее имею дело с менторством, как раз как 1000 лет назад xD
мотивация «вам это в будущем понадобится» — крайне неэффективна
Мотивация — это довольно индивидуальная штука, нельзя сказать что «вам это в будущем понадобится» неэффективна, но она не всем подходит, это да. При индивидуальном подходе можно вплетать полезные знания в процесс делания чего-то интересного для конкретного обучаемого. Но опять же у каждого свои интересы, поэтому как универсально это сделать — хз.
Будто слова ООП я не слышал, принципов не знаю и рассказать о них не могу…
Я ж написал, что это утрировано. Тем не менее, про ФП Вы если и слышали, то реально не сможете рассказать, потому что только позавчера путали его с ПП. Про ООП вопрос вообще спорный… Есть целые баталии на тему существует ли оно в мейнстриме вообще или мы наблюдаем лишь слегка модифицированный структурный подход.
Т.е. Вы способны на одних лишь концепциях, без практической реализации в ЯП творить софт?
ЯП в данном вопросе — это просто синтаксис для выражения концепций, синтаксис учится на 3-7 дней, это не проблема. Концепции же надо учить лет 7. И я сам ещё в них не гуру, т.к. года 3 назад ещё считал аналогично Вам, что всё развивается бешенными темпами. И я рад, что пришло осознание того, что это совсем не так. Конечно было бы круто если бы это ещё в школе объясняли, можно было бы сэкономить прилично времени, не изучая ненужное.
Или принцип async/await был расписан 50 лет назад?
Если точно, то в 1976 году. А что?
Мне думается, Ваши претензии как раз в том, что кто-то посмел внедрить какую-то концепцию в какой-то «не тот» язык и имел смелость сказать об этом
У меня вообще претензий к языкам нет. Меня даже вполне устраивает, что новых концепций не появляется… Не придётся постоянно изучать что-то концептуально новое, достаточно один раз изучить существующие наработки. Объём немаленький, но вполне посильный и существенно меньше, чем в других науках. А потом можно и самому о чём-то концептуально новом подумать xD
Люди ищут и будут искать всё более и более удобные формы использования лучших принципов-концепций.
Те, кто реально ищет, не ленится знакомиться с разными вариантами. А большинство просто ждёт пока в их дефолтном ЯП реализуют интересную концепцию хоть в каком-то виде. Даже если косячно реализуют, восторгам не будет предела, см. для примера анонсы pattern matching в C#. Мне в принципе параллельно, пусть радуются. Просто я вижу пути развития получше, чем текущий. Но для этого не надо циклиться на одном ЯП или на одной парадигме, не надо надевать шор.
«Интел выпустил новую линейу процов?? — Пффф!!! Дети! Машина Тьюринга была выпущена полвека назад!»
Предыдущие десятилетия шёл процесс технологического усовершенствования в плане кол-ва транзисторов на единицу площади. Сейчас они упёрлись в физическое ограничение и как бы всё на этом. Т.е. уловите разницу, развитие текущих процессоров — количественное (быстрее/компактнее/etc.). Качественным развитием будут квантовые компьютеры или что-то подобное. Да и это уже про физику, а не про Computer Science.
после научного прорыва XX века сейчас идёт своеобразный этап стагнации
Всё верно. Развития сейчас нет. Капитализм его не предполагает.
И что?
То, что это новое состояние общества, в котором оно никогда ещё не пребывало. А потому стоит громадный вопрос: как лучше всего себя вести в таком состоянии? «Всего»-то.
Скорость роста объёмов информации не равна скорости роста знаний и даже не пропорциональна.
Одна лишь необходимость управлять этим валом информации порождает отрасль, растущую объёмами технологий, как на дрожжах.
Стоит ли рассказывать детям, что сейчас модно
Похоже, Вы не поняли сути. Мода — явление субъективное (кто-то придумал, другие ведутся). А рост объёмов информации — объективен, от него никуда не деться. И придётся детей учить как теперь жить в таком мире. В том числе уметь выявить в этом потоке где полезное, а где мусор (никакие 5-95% этого не опишут).
Но опять же у каждого свои интересы, поэтому как универсально это сделать — хз.
Универсально — это начинать развивать детей с дошкольного возраста, а не забивать их, как это имеет место сейчас. Все от рождения — потенциальные гении, но именно школа оставляет этот потенциал невостребованным. Потому, что преподаватели «самые умные» и «уже всё знают»… (но почему-то при таком «умище» имеют далеко не лучший уровень жизни) — есть ли им дело до изучения потенциалов и талантов новых поколений? — а с какой тогда радости эти самые новые поколения будут хотеть вникать в «бу-бу» этих самых «уже всё знающих»?.. так и живём…
про ФП Вы если и слышали, то реально не сможете рассказать, потому что только позавчера путали его с ПП
Практика — критерий истины. Если я мог столько лет обходиться без этих терминов, то это ведь что-то да значит? Я делал и так, и сяк, но да, не знал, что оно как-то ещё и называется. И что? От этого программы стали хуже?
Езжу на машине и тут узнаю, что — внезапно — работа ногами по нажиманию на педали называется педалированием. Ну ничёсе… И как я жал на педали до этого? Ну а пересказать «нажать на левую — это сцепление, а на правую — это газ», якобы вообще невозможно, не зная, что где-то в академических кругах это называется педалированием…
Я вижу цель учёбы — в практике, а не в учёбе.
Концепции же надо учить лет 7
={ }
А потом — клац, и квантовые компьютеры закрывают их часть и открывают другие — и снова учиться.
Если точно, то в 1976 году. А что?
Вертолёт тоже был описан задолго до того, как техника доросла до практической реализации. Но почему-то никто не тычет пальцем на разработчиков вертолётов, обвиняя их в отсутствии новых «концепций».
У меня вообще претензий к языкам нет.
И к одним даже больше нет, чем к другим ;)
Просто я вижу пути развития получше, чем текущий. Но для этого не надо циклиться на одном ЯП или на одной парадигме, не надо надевать шор.
И что ж это за путь?
А потому стоит громадный вопрос: как лучше всего себя вести в таком состоянии?
Лучше всего игнорировать информационный шум. Это само по себе непросто в крупном городе, но я не понимаю вашего драматизма. Общество всегда пребывает в состоянии, в котором оно никогда до этого не пребывало. Но при этом всегда можно и что-то общее с прошлым найти (спираль истории).
В том числе уметь выявить в этом потоке где полезное, а где мусор
Я об этом с самого начала топика пишу. Что надо обучать полезному (концептуальному и неизменному), чтобы фильтры с детства настраивались… А Вы изначально за мейнстрим/моду/мусор агитировали.
Практика — критерий истины.
С чего вдруг? Исходя из практики можно сделать вывод, что Солнце крутится вокруг Земли и вполне спокойно с этим жить и много лет обходиться без гелиоцентрической системы.
Так же и PHP-программист, клепающий сайты визитки, вполне может, опираясь на свою личную практику, делать вывод, что другие языки в вебе вообще не нужны. Точно так же и Ваша практика ограничивает ваши представления об истине.
И что? От этого программы стали хуже?
Даже не сомневайтесь. Дело не в том, чтобы знать названия, а в том, чтобы понимать концепции, стоящие за этими названиями. Будет ошибкой полагать, что Вы неосознанно использовали концепции ФП, и единственная проблема — незнание названий… Проблема в том, что в силу своего незнания Вы не можете оценить практическую пользу знаний, которыми пока не обладаете. Людям вообще свойственно отстаивать именно свой круг знаний, т.к. нам обычно неприятно признаваться в незнании. Но тут ещё больший парадокс, чем больше знаешь, тем больше осознаёшь масштабы неизвестного. И тут я говорю именно о знаниях, а не об информации.
А потом — клац, и квантовые компьютеры закрывают их часть и открывают другие — и снова учиться.
Такие повороты не исключены. Но тем интереснее, хоть какая-то движуха по существу, а не по синтаксису.
Вертолёт тоже был описан задолго до того, как техника доросла до практической реализации.
OMFG, Вы всерьёз считаете, что event loop и promises впервые появились в JavaScript?
И что ж это за путь?
Осознать, что мейнстрим крайне медлительно заимствует концепции, которые давным давно сформулированы и реализованы в чуть менее популярных языках. Изучить эти концепции и спокойно наслаждаться конкурентным преимуществом в ближайшие 50 лет :-)
Лучше всего игнорировать информационный шум.
Хорошо. Но как понять: где шум, а где полезная информация?
Ведь просто закрываясь от всего нового — так ведёт себя старое (даже не старшее) поколение, для которых мобильный телефон — это «да ну, унучек! ты чаво это?»
Общество всегда пребывает в состоянии, в котором оно никогда до этого не пребывало.
Да, но не всякая смена состояния столь кардинальна. Потоянно учиться всю жизнь, чтоб быть просто актуальным специалистом — такой необходимости не было ещё до средины 20-го века.
Но при этом всегда можно и что-то общее с прошлым найти (спираль истории).
Конечно. Нет речи о том, чтобы поменялось вот прямо всё совсем. «Всего лишь» частота обновления социально значимых технологий теперь стала выше частоты обновления поколений.
А так, как говорил Ключевский «Закономерность исторических явлений — обратно пропорциональная их духовности». Т.е. пока люди не растут нравственно — круги ада всё повторяются и повторяются…
Что надо обучать полезному (концептуальному и неизменному). А Вы изначально за мейнстрим/моду/мусор агитировали.
Ну это Вы так поняли, раз считаете всё новое мусором (может, тогда и мобильник свой выбросите? их ведь масово не было во времена формулировки всего «великого и нерушимого»)
Я пишу, что жизненноважные технологии обновляются теперь по нескольку раз за период активной жизни. И как прикажете научить тому, что будет изобретено только через несколько лет?
Вот где главный вопрос, а не в информатике, компах или ЯП.
" Практика — критерий истины.
С чего вдруг?
:)
Нет, ну конечно же можно изучать какие из драконов не существуют более интересным образом: мнимые или отрицательные. Только вот во рту от этого слаще может стать только у учёных (и то, если им поверят и будут кормить во время таких изучений).
Людям нужно работать, изменять каким-либо образом Объективную реальность под свои цели. А законы, по которым она меняется — это и есть практика. Это — универсальный критерий истины.
Исходя из практики можно сделать вывод, что Солнце крутится вокруг Земли
А что, разве не крутится? — зависит от выбора точки отсчёта. И для каких-то задач лучше так, а для каких-то лучше центр Млечного пути, а не Солнце, выбирать точкой отсчёта.
Учителя то как детей учат? — Фразы «солнце взошло» и «солнце село» — вполне нормально воспринимаются. Хотя с точки зрения самого Солнца никуда оно не садится и не встаёт.
Точно так же и Ваша практика ограничивает ваши представления об истине.
Но Ваша то, видимо, сама объективность? ;)
Люди — все субъективны, и в состоянии познать лишь какую-то конечную часть безконечной Вселенной. Так что, все люди всегда ограничены.
Не ограничен — только Надмирная Реальность (Создатель).
И тут я говорю именно о знаниях, а не об информации.
А в чём разница?
Вы всерьёз считаете, что event loop и promises впервые появились в JavaScript?
Это — Ваши слова, не мои.
(что это Вам жабоскрипт покоя не даёт?)
Изучить эти концепции и спокойно наслаждаться конкурентным преимуществом в ближайшие 50 лет :-)
Ну, тут уж я вправе задать Вам похожий вопрос: Вы думаете, что первым придумали, что если изучить что-то самое лучшее — это это будет лучше всего?
А если ж нет — то что, все эти тонны курсов по программированию в мире (включая учебные заведения) либо не хотят денег, либо прям вот никто не знает всех тех условно незыблемых основ, либо почему-то целенаправленно не хотят воспитывать таких абсолютно-актуальных кадров? Или они все сговорились?
Хорошо. Но как понять: где шум, а где полезная информация?
Критическое мышление + знание существующих концепций и фундаментальных законов.
Более детально ответ зависит от конкретики: на какую тему информация, какого она характера и т.д.
Потоянно учиться всю жизнь, чтоб быть просто актуальным специалистом — такой необходимости не было ещё до средины 20-го века.
В том то и фишка, что такой необходимости и сейчас нет.
Сейчас просто модно стало хватать по верхам, ничего толком не изучив, от этого складывается иллюзия постоянных изменений, хотя по факту они носят чисто косметический характер в абсолютном большинстве случаев.
«Всего лишь» частота обновления социально значимых технологий теперь стала выше частоты обновления поколений.
Предлагаю на примере квантовых компьютеров и помониторить насколько увеличился темп… Сейчас они находятся примерно на той стадии развития, на которой современные компьютеры были в 1950-х годах. Они большие, очень дорогие и пока не особо мощные. Потенциал ускорения — 10^300 раз.
Какие Ваши прогнозы, сколько лет займёт переход к всеобщей доступности? У обычных компьютеров он занял в районе 50 лет.
Вы утверждаете, что частота обновления технологий увеличилась… Но на сколько процентов или во сколько раз по сравнению с серединой XX века?
Критическое мышление + знание существующих концепций и фундаментальных законов.
Т.е. правильный ответ — всё же ф-ция и от собственной интеллектуальной деятельности (критическое мышление), и от ранее созданных знаний.
Т.е. само знание «существующих концепций и фундаментальных законов» — не гарант актуальности как специалиста. Но это противоречит многому, что Вы говорите о новом (что оно почти всё мусор). но почему-то, в этом «мусоре» придётся копаться. Т.е. либо это всё не однозначно мусор, либо критическое мышление таки не нужно и можно попробовать разбить голову о жизнь, игнорируя всё новое.
такой необходимости и сейчас нет
Вашу точку зрения понял. Вам, как преподавателю, конечно же, вобщем, всё равно чему учить: всё равно что ученики-студенты, что их родители пока что знают куда меньше Вашего и Вы всё равно эксперт и заслуживаете своего вознагражения за обучение. Тут вопросов нет.
Но мир не ограничен учёбой. И вот тут уже начинается интересное…
Сейчас просто модно стало хватать по верхам
Меня учили технологиям (радиотехника), которые были актуальны лет 20 назад. Но уже на момент обучения нужно было знать не это, чтоб зарабатывать в проектировании радиоэлектроники, а какая китайская микруха что может, сколько стоит, где и в каких объёмах её можно достать. Попытки заменить эту копеечную микруху своими «тёплыми ламповыми» схемами — мгновенно выбрасывает с рынка, т.к. затраты конкурентов, которые пользуют китайские достижения, на порядки меньше.
Если не нравятся китайцы и радиотехника — то и в вычислительной технике в СССР были свои разработки, а западный 8086 — не феншуй. И как далеко придётся отложить зубы, попытавшись выйти на рынок с тем, что было изобретено на Родине в этой отрасли?
Какие Ваши прогнозы, сколько лет займёт переход к всеобщей доступности?
Научный прогресс — очень плохо прогнозируется (прогноз строится на существующих знаниях, но в том то и дело, что будущих технологий ещё нет в знаниях).
И дело не в том когда будет это нечто_новое через 5 лет или 50. А в том, что будут делать наши выпускники, когда им начальник скажет «Ну что, Саня, клиенты уже требуют <нечто_новое>» — увольняться и искать начальника со старыми взглядами или таки изучать?
У обычных компьютеров он занял в районе 50 лет. Вы утверждаете, что частота обновления технологий увеличилась… Но на сколько процентов или во сколько раз по сравнению с серединой XX века?
Прямо зацитирую ролик «Знаете ли Вы»:
«Сколько лет понадобилось, чтобы набрать аудиторию в 50 млн:
* радио — 38 лет
* телевидение — 13 лет
* интернет — 4 года
* ipod — 3 года
* лицорука (facebook) — 2 года.
К-во инет устройств:
в 1984 году — 1000
в 1992 — 1000000
в 2008 — 1000000000
...»
Но это противоречит многому, что Вы говорите о новом (что оно почти всё мусор).
В чём противоречие то? Очевидно, что "Почти всё" != "Всё".
Конечно есть развитие, есть новые знания и концепции. К сожалению, их концентрация в общем потоке информации снижается, тут не поспоришь.
Вам, как преподавателю, конечно же, вобщем, всё равно чему учить
С чего Вы взяли, что я преподаватель? Я же уже выше даже явно писал, что это так. Я занимаюсь вполне себе production разработкой веб-проектов.
Но уже на момент обучения нужно было знать не это, чтоб зарабатывать в проектировании радиоэлектроники, а какая китайская микруха что может, сколько стоит, где и в каких объёмах её можно достать.
Надеюсь, закон Ома и правила Кирхгофа от этого не пострадали? )))
Научный прогресс — очень плохо прогнозируется
Ну, так не интересно… Т.е. не ждать мне квантовый компьютер за $1000 через 5 лет, исходя из закона времени? :-D
Сколько лет понадобилось, чтобы набрать аудиторию в 50 млн
И дальше сравнение абсолютно разных технологий в разные эпохи. Даже без поправки на общее население планеты в тот период. К примеру, на момент изобретения телевидения людей в принципе на Земле было в 3 раза меньше, чем на момент изобретения интернета. Вот уж точно рукалицо. Где же Ваше критическое мышление?
К-во инет устройств
И что? Если Вы намекаете на экспоненциальный рост, то его там нет. Кол-во устройств на Земле в принципе весьма конечно и скоро уже нечего будет подключать к интернету )))
Я пишу, что жизненноважные технологии обновляются теперь по нескольку раз за период активной жизни.
Ok. Я вижу, что Вы это пишете. Но я не вижу, чтобы это по факту происходило. Возможно, дело в том, что я физик по образованию, поэтому там где Вы видете бешенный технологический прогресс, я вижу просто шлифовку тех.процессов. Это круто само по себе и заметно в повседневной жизни, но это не сильно влияет на объём знаний по физике, вот даже не то, что не удвоился за предыдущие 20 лет… он даже на 10% не прирос.
И как прикажете научить тому, что будет изобретено только через несколько лет?
Тут есть 2 варианта: либо человек знает концепции, тогда новые изобретения будут для него долгожданным воплощением ожидаемого;
либо не знает и тогда они будут для него своеобразным шоком. В-первом случае даже учить не придётся, во-втором человек скорее всего будет отвергать новые технологии насколько хватит упорства.
Но Ваша то, видимо, сама объективность? ;)
Нет конечно. Именно поэтому практика не является и не может являться критерием истины.
Люди — все субъективны, и в состоянии познать лишь какую-то конечную часть безконечной Вселенной. Так что, все люди всегда ограничены. Не ограничен — только Надмирная Реальность (Создатель).
Ох, куда Вас занесло… Во-первых, исходя из наблюдаемых явлений, Вселенная не бесконечна. А её расширение происходит подобно тому, как расширяется поверхность воздушного шарика при надувании.
Во-вторых, рекомендую почитать про теорию голографической Вселенной. Пополните свой арсенал физических концепций ;-)
И тут я говорю именно о знаниях, а не об информации.А в чём разница?
Информация может вообще не нести знания или нести мимолётное знание (аля как там дела у Питта с Джоли). Т.е. информация может быть пустой с точки зрения профессионального, духовного и вообще какого-либо развития.
Вы думаете, что первым придумали, что если изучить что-то самое лучшее — это это будет лучше всего?Нет конечно. Я вроде на новаторство в этом вопросе и не претендовал.
то что, все эти тонны курсов по программированию в мире (включая учебные заведения) либо не хотят денег, либоЯ где-то выше по комментам давал оценку этого объёма знаний — 7 лет. Так и представляю рекламу "приходите на наши 7-летние курсы".
Что касается ВУЗов, то некоторые всё-таки стараются обучать именно концепциям, но там свои сложности… Нужно чтобы преподаватели и хорошо владели материалом и имели желание донести его до широких масс, при этом практически без финансовой компенсации. Ну и студентов надо суметь заинтересовать, они то падки на сиюминутные тренды и зачастую только спустя много лет осознают, что вот те лекции надо было внимательно слушать.
Но я не вижу, чтобы это по факту происходило.
Ну, выражать в процентах рост актуальных знаний не буду. Но отмечу: в конце 90-хх я откуда-то притащил древний, в меру ржавый арефмометр, и он даже работал. Но использовать его в промышленном счёте, когда простой калькулятор умел на порядок больше (не говоря уже о компах), смысла не было. Хотя ещё лет 20 до того времени, арифмометр был очень даже почему же замена счётам.
Так вот такого, чтоб за 50 лет произошло несколько замен социально важных технологий, не было никогда до этого.
Ну а видеть это или нет — дело хозяйское.
В-первом случае даже учить не придётся
«Всё ваше новое состоит из всё той же старой таблицы Менделеева! Ничего учить не надо! Пойду я и дальше предлагать бухгалтерский учёт с арефмометром» — долго ль сможет ходить?
во-втором человек скорее всего будет отвергать новые технологии насколько хватит упорства.
Да, можно часто менять работу в поисках директоров-консерваторов. Но как долго будет нужен на рынке настройщик ламповых вычислительных машин? И как скоро он двинет ноги с голоду, когда последний консерватор таки купит себе комп на транзисторах или (ойойой!!) на микропроцессоре?
практика не является и не может являться критерием истины.
Ну это если считать, что всякая деятельность протекает только в своей собственной Вселенной, где законы выдуманы своими руками. Если это Ваш случай — то у меня нет вопросов.
В моей же Вселенной на планете Земля живёт 8 ярдов населения и они взаимодействуют и с окружающим миром и друг с другом по так называемым законам природы (которые не люди выдумали). И если закон Гука гласит, что сила пропорциональна коэффициенту упругости и реальные эксперименты (та самая практика) происходят в русле этой закономерности — то это истина (если вести деятельность в общей всем Вселенной, а не в своей собсной, не привлекая внимания санитаров).
Вселенная не бесконечна
Для Бога — да. А люди, будучи частью Вселенной — не могут ни выйти за её пределы, ни достоверно узнать что находится вне неё.
А потому, все сказки о раздувающемся «шарике» Вселенной — это увеселение для толпы, не более. Так же, как и большой взрыв. По нему особенно улыбают рассуждения о состоянии молодой Вселенной в тот или иной момент в долях секунды, хотя секунда тогда не могла существовать :) Вспомним через что определяли люди секунду: то часть от периода вращения Земли, то время, за которое луч света в вакууме проходит расстояние… — но всего этого в рассматриваемый момент попросту ещё не было :) Вобщем, потешно слушать про эти раздувающиеся шарики.
теорию голографической Вселенной
Спасибо, да. Я вкурсе, что Мера — голографична. В частности, торсионная связь основана на этом свойстве.
Информация может вообще не нести знания или нести мимолётное знание (аля как там дела у Питта с Джоли). Т.е. информация может быть пустой с точки зрения профессионального,… развития.
Смотрите не ляпните этого жёлто-прессовым журналистам, профессиональная работа и рост которых как раз и основана на разжёвывании Питов и Джоулей этих :)
Выходит, где «просто информация», а где «знания» — чисто субъективное отличие. Кому-то одного, кому-то другое. Т.е. объективная разница не в этом?
Так и представляю рекламу «приходите на наши 7-летние курсы».
Т.е. либо денег нет у людей, либо терпения столько лет только слушать, либо… а действитеьлно: зачем так долго изучать вот всё-всё-всё подробненько, если для достижения своих целей хватает куда меньшего объёма инфы?
Ну и студентов надо суметь заинтересовать, они то падки на сиюминутные тренды и зачастую только спустя много лет осознают, что вот те лекции надо было внимательно слушать.
Кстати, не удивительно ли, что преподаватели, зная важность того знания, что они несут, почему-то оказываются неспособными показать эту важность студентам?
Выходит, по факту ситуация для студента выглядит как: не смог понять, что этот вот дяденька несёт что-то очень важное — ну и сам себе буратино, придётся набивать шишки… А что ж взрослые? Как же так получилось, что знали, но не предупредили? (по факту)
Пойду я и дальше предлагать бухгалтерский учёт с арефмометром
Я имел в виду, что не придётся учить, потому что человек сам без труда освоит то, появление чего он давно ожидал. Хоть Вы и пишете про стремительную смену технологий, она не столь стремительна как человеческие ожидания.
И если закон Гука гласит, что сила пропорциональна коэффициенту упругости и реальные эксперименты (та самая практика) происходят в русле этой закономерности — то это истина
Вы уже в демагогию перешли… Экспериментальная проверка и практика какой-то промышленной деятельности — это совершенно разные вещи.
Т.е. это не та самая практика (если я программирую на X и много вакансий на Х, то X — это самая идеальная технология), о которой Вы изначально говорили.
жёлто-прессовым журналистам, профессиональная работа и рост которых как раз и основана на разжёвывании Питов и Джоулей этих :)
Даже они эту информацию всего лишь используют как объект для применения своих проф.навыков. А сами их навыки от кол-ва и содержания этой информации никак не зависят.
зачем так долго изучать вот всё-всё-всё подробненько, если для достижения своих целей хватает куда меньшего объёма инфы?
Вот! Теперь Вы гораздо больше похожи на маркетолога типичных курсов. Разумеется у них нет и не может быть цели подготовить профессионалов. У них цель — как можно больше учеников зазвать на волне интереса к программированию. А для этого придётся активно ездить по ушам. "каждый сможет научиться всего за 2 месяца/недели/дня ..."
Как же так получилось, что знали, но не предупредили?
Хз. Не могу тут по существу ничего сказать. Возможно, текущим ВУЗам в программе как раз не хватает "мостика" между концепциями и их практическим применением в мейнстриме.
человек сам без труда освоит то, появление чего он давно ожидал
Не думаю, что можно считать, что большинство тех, кому приходится работать с какой-то технологией, ожидали её появления. Даже наоборот: не ждали и не хотели, но пришлось (см. луддисты), т.к. кто-то другой работал над этим, искал, нашёл и получил денег, а людям теперь всё бросать и начинать это всё осваивать просто для того, чтобы остаться на работе.
Освоение — большой труд, потому как это непременно нужно делать самому, никакими деньгами тут не откупиться, только упорной работой по смене стереотипов (а это — самая сложная работа на Земле).
Экспериментальная проверка и практика какой-то промышленной деятельности — это совершенно разные вещи.
А что, лаборатории находятся в одной Вселенной, а промышленные цехи в другой??? с другими законами мироздания? :)))))))
И после этого я демагогию развожу???
Промышленность просто использует те истины, которые были найдены в лабораторных условиях. И то, только потому, что и цех, и лаборатория — в одной Вселенной.
если я программирую на X и много вакансий на Х, то X — это самая идеальная технология
Такого я не говорил.
Эта популярная технология идеальна для заработка денег (почувствуйте разницу).
Другое дело, что абстрактные бегемоты в плазме, супер ровные и стройные, но не приносящие должной нормо-прибыли, остаются пылиться на академических полках.
И тут либо заговор большого бизнеса (есть история, когда громадная нефтяная западная компания прикупила за сотню лямов технологию, в разы улучшающую качества нефте-продуктов, но за 15 лет её так и не применила), что он упорото не желает ещё больше прибылей, либо таки применение этих идеальных бегемотов на практике (да, снова она!), включая учёбу и прочее, оказывается менее выгодным.
Что тут поделать? — у банков, рулящих экономикой, свои цели. (но о рулящей роли банков, в таком случае можно было бы предупредить студентов?)
А вообще идеальные технологии ещё только предстоит изобрести. Потому как с тем, что есть на Земле — у нас Тихий океан стал уже пластиковым супом (причём, за каких-то полвека).
Вот! Теперь Вы гораздо больше похожи на маркетолога типичных курсов.
А на студента не похож? Который с радостью и рвением готов на пару лет дольше изучать и сдавать то, без чего и так можно найти работу.
Или на его родителей? Которым предстоит на пару лет дольше кормить своего студента и ждать когда ж он выйдет на свои хлеба.
Это жизнь такая. Да, представляете?
Ну так, напоминаю, на случай если Вам из высоких кабинетов не видно этого.
текущим ВУЗам в программе как раз не хватает «мостика» между концепциями и их практическим применением
Ну что ж, спасибо за откровенное признание.
Так и есть: учат одному (причём, высокомерно, с моноклем в глазу), а на практике будет нужно другое.
Не думаю, что можно считать, что большинство тех, кому приходится работать с какой-то технологией, ожидали её появления.
Это уже вторая категория… Процитирую себя же:
Тут есть 2 варианта: либо человек знает концепции, тогда новые изобретения будут для него долгожданным воплощением ожидаемого;
либо не знает и тогда они будут для него своеобразным шоком. В-первом случае даже учить не придётся, во-втором человек скорее всего будет отвергать новые технологии насколько хватит упорства.
Я поэтому и ратую за обучение концепциям… Что во времена промышленной революции, что в современном мире этого не хватает в массовом образовании.
Промышленность просто использует те истины, которые были найдены в лабораторных условиях.
У меня ощущение, что Вы меня не слышите… Я об этом тоже уже писал: "мейнстрим (промышленность) крайне медлительно заимствует концепции, которые давным давно сформулированы и реализованы в чуть менее популярных языках (лабораториях)". Вы же утверждали, что истина рождается из практики промышленного применения, когда по факту всё наоборот, и промышленность лишь использует готовые концепции. Поэтому такая практика и не является критерием истины, она просто адаптирует готовые результаты. Обратное утверждение как раз приводит нас к луддизму, когда мы опираясь на мейнстрим пытаемся апеллировать к истине.
Который с радостью и рвением готов на пару лет дольше изучать и сдавать то, без чего и так можно найти работу.
Ну, тут вопрос приоритетов, цель "побыстрее найти работу" — это одно. Цель "стать профессионалом" — уже другое. Это похоже на типичный выбор школьника: учиться ради оценок или ради получения знаний.
Одно другому не мешает. Но первая мотивация приводит к недальновидным решениям, а вторая — удовлетворяет первую в полуавтоматическом режиме.
Ну что ж, спасибо за откровенное признание.
Пожалуйста, только это не признание, а лишь мои догадки… Т.к. я по образованию физик и вообще слабо представляю чему там на IT-специальностях учат… Но, судя по текущему состоянии IT, явно не тому, чему я тут с начала темы предлагал учить :-)
что мейнстрим крайне медлительно заимствует концепции, которые давным давно сформулированы и реализованы в чуть менее популярных языках. Изучить эти концепции и спокойно наслаждаться конкурентным преимуществом в ближайшие 50 лет :-)
Изучил Ваш студент эти основы и соотв. эталонные «чуть менее популярные» ЯП — и воодушевлённый Вашими словами о расслабухе на «ближайшие 50 лет» пошёл устраиваться в контору программистом… На все вопросы о его познаниях в таких-то и таких-то актуальных ЯП — он (мысленно с моноклем на носу и котелком на голове) будет вещать о том, что всё это переделки уже давно всего придуманного и писать на этом не стоит. — почему? — да потому, что на этих ЯП базовые парадигмы не так выразительны/оптимальны/нужное_подчеркнуть, а все заказчики, кто хотят проги на них — странные и… и ваще.
Вопрос: что Вам пожелает на день учителя этот Ваш бывший студент, когда будет разослан в известном направлении всеми конторами города, куда он сходил в попытках устроиться с такими речЯми?
(работу он, конечно же, нашёл; но после изучения того, что уже Ннадцатая контора рекомендовала ему изучить)
Я ещё раз отмечу, что у меня нет студентов. Но я не вижу тут проблемы, мы ведь изначально школу обсуждали… Т.е. не предполагалось, что люди поголовно будут программистами и после изучения концепций сразу пойдут трудоустраиваться. А на уровне ВУЗов и ПТУ вполне можно рассмотреть как изученные в школе концепции выражены в популярных на текущий момент языках. Со знанием концепций можно влёгкую учить по языку за семестр без напряга и достаточно глубоко для трудоустройства и даже параллельно с какими-нибудь сложными концепциями, которые на уровень школы не прошли.
Конечно, должен даваться наилучший фундамент, который есть у взрослых в каждый момент времени.
И если всё будет сделано правильно — то так и будет, как Вы сказали: что нужные знания для работы будут осваиваться самостоятельно в реальном времени.
Спасибо за науку общения с представителями образовательного цеха. Хотя мне тут ещё учиться и учиться…
Ну, собственно, никому больше и не должен быть нужен. Ну, возможно, одноклассникам. Возможно, ученика за это симпатичная одноклассница поцелует. Почему бы и нет?
Давайте отвлечемся от чисто теоретической составляющей.
Представим все того же Василия, в меру одаренного ученика средней школы, среднестатистической не особо выделяющейся внешности, тайно влюбленного в одноклассницу Катю. Приходит он домой после уроков (крайним как раз оказался урок информатики) с твердым желанием творить. Ставит себе ту же IDE, что в школе (бесплатную, без смс), и, применяя полученные там же знания, пишет интерактивное-приложение открытку-признание в любви. Прикольно же?
Но тут мы выясняем, что учат его на Pascal. «Окей, нам нужна Delphi!» — решает предприимчивый Василий. Идет он, значится, на сайт Embracadero, сразу жмет «Купить» (мальчик у нас честный, воровать не привык) и… охреневает. Первая попавшаяся ему на глаза цифра: 331 999,00 руб. Можете сами сходить на сайт, проверить.
Не, ребят, вы серьезно? Мне почему-то кажется, что есть просто mast have условия для преподаваемой вещи, как то:
1. Возможность поставить/использовать то же самое дома, без лишних заморочек, без рекламы и без смс.
2. Непривязанность к единственному вендору, способному превратить светлые позывы ученика в тыкву единственным волевым экономически-обоснованным решением.
3. Наличие экосистемы вокруг. Важно, чтобы материалы по языку/среде/экосистемы были доступны, по возможности бесплатны, вменяемы, полны. Да и спросить чтобы было у кого.
Только вот Ваше предложение идёт вразрез с интересами конторы _название_конторы_, ибо планы на прибыль и т.д.
Потому то её лоббисты и пообсели образовательные министерства и ведомства.
Ну и, как _следствие_ — уже выращены поколения на закрытых платных программках… И это — проблема.
Когда сегодняшние дети закончат школу действительно есть вероятность, что Python растеряет свою популярность, а Java умрет, как ей пророчат с 90-х годов прошлого века. Но лично я в это не верю. Слишком уж хорош Python для своей ниши, а в смерть Java может верить только фанатик. Но вот что можно сказать наверняка, что когда дети закончат школу, паскаль точно будет мертвым потому, что он уже мертв много лет.
По моему Python куда более подходит как первый язык, чем Паскаль, как и многие другие в общем-то. Он работает на всем включая мобильные телефоны. А ведь учится писать программы нужно на чем-то. Он очень емкий. Откройте примеры реализации любого алгоритма с примерами на разных языках. Программа на Паскале и Питоне будет различаться раз в 10. А для того, кто только начинает количество вводимых символов все-таки важно. И кроме всего прочего в Python есть все, что только душа пожелает. От словарей и объектов до замыканий, лямбд и функционального программирования вообще.
Вы правы. Не все должны быть программистами, но знать, что рутину можно легко автоматизировать написав просто несколько строчек- важно. Даже для того, что бы попросить об этом кого-то более осведомленного. Но то, что Паскаль для этого подходит лично я сильно сомневаюсь.
Не все должны быть программистами, но знать, что рутину можно легко автоматизировать написав просто несколько строчек- важно
Правильно. Уметь программить — это не опция, а насущная потребность сегодняшнего дня. Даже если зарабатывать на жизнь чем-то другим.
Уметь программить — это не опция, а насущная потребность сегодняшнего дня.
Ну ё-моё, зачем всех под себя подстраивать? Я тоже могу сказать, что умение объяснить почему небо голубое — это насущная потребность сегодняшнего дня. Все люди разные, для кого-то элементарная арифметика в уме уже за гранью понимания...
Только вот программирование — это не только про компы. Алгоритмы — это куда более широкое понятие, и работает везде и в обществе, в людях. Поэтому критически важно знать их, понимать и уметь составлять.
А уметь составлять алгоритмы — это ли не умение программировать?
Вы путаете тёплое с мягким… Все алгоритмы бытового/общественного плана построены на нечёткой логике. И это весьма сложная тема в формализованном виде, явно не под силу школьникам. Однако люди оперируют нечёткой логикой на интуитивном уровне и им для этого школа вообще не нужна.
Компьютерные же алгоритмы, за редким исключением, построены на булевой логике, которая за пределами компьютеров относительно редко встречается. Попробуйте для прикола осознанно использовать булеву логику при общении, все окружающие мигом заметят, что Вы странно себя ведёте :-)
Рад видеть, что Вы знакомы с нечёткой логикой (хотя я ни о ней, ни о булевой не говорил). Алгоритмы то всё равно работают, нужны и Вы то этого не отрицаете.
Все алгоритмы бытового/общественного плана построены на нечёткой логике.
Но от этого они же не исчезают и не перестают работать…
А значит, знать их важно и нужно.
Уровень развития интеллекта старшеклассников уже достаточен для некоторых видов работы. А если вспомнить Великую Отечественную, то дети в партизанах показывают возможности генетики нашего вида даже в раннем возрасте. Так что, «недалёкость» большинства нынешних школьников — не их вина. Что им будет под силу, а что нет — зависит от того, чему и как их учат. Если учить алгоритмизации и логике — они будут в состоянии ими оперировать. Если ж не учить — то можно сетовать, что для них это недостижимо.
Компьютерные же алгоритмы, за редким исключением, построены на булевой логике, которая за пределами компьютеров относительно редко встречается.
Если б это было так — то компьютеры бы максимум, могли песенки и кино крутить. Больше их применить было бы некуда.
Однако, всё обстоит несколько иначе.
Почему? — просто нечёткая логика очень даже хорошо реализуется через булевую. И это не заслуга компов как таковых. Во Вселенной всё квантуется, т.е. чётко разделимо на нечто одно и на нечто другое. И если кажется, что что-то не квантуется — то нужно просто увеличить масштаб и приглядеться глубже.
Булевая логика не просто «за пределами компьютеров относительно редко встречается», на ней основано всё, в том числе и нечёткая логика.
Так что, для прикола или нет, но мы все и так используем булевую логику при общении, и выглядит это вполне обычно.
Причём тут это? Нечёткая логика — раздел высшей математики, который изучается уже поверх знания теории вероятностей, классической логики и теории множеств. Предлагаете всё это в школьную программу затолкать? o_O
> нечёткая логика очень даже хорошо реализуется через булевую.
Реализуйте для начала через булеву логику такие понятия как «может быть» и «да нет, наверное».
Hо вдруг не пришел, день нет, второй, народ заволновался, приходят к нему домой, стучат… нет ответа, ломают дверь, находят его синим в ванной. А в руках флакон шампуня с инструкцией на обороте:
1. Hанести шампунь на голову
2. Помассировать
3. Через 5 минут повторить…
Жена посылает программиста в магазин:
— Купи батон колбасы, а если будут яйца, купи десяток!
Приходит программист в магазин.
— У вас яйца есть?
— Есть!
— Дайте мне 10 батонов колбасы!
Помнится, в начале/середине 90х годов в Компьютерре была статья Маслова(?) (из МГУ ВМК?), где он научно-популярно рассказывал про нечеткую логику. И, если не путаю, именно там и говорилось, что система управления на нечеткой логике может быть разработана старшеклассниками. Вероятно, вы смотрите на FL через призму Высшей Математики, тогда как знание теории дифуравнений не нужно для использования методов системной динамики. Так же и с FL.
Давайте по-честному, этими темами от силы 0.1% профессиональных программистов владеет.Это не аргумент, чтобы не изучать. Нечеткая логика это совсем не нейронные сети. Область пересечения этих областей незначительная.
Нечеткая логика пригодится в школьной робототехнике для описания регуляторов/котроллеров к механизмам, которые, кстати говоря, можно описать системной динамикой. Точность не высокая, да она и не нужна на этом этапе, т.к. сами механизмы дают большую ошибку. Но результат будет более продвинутый, т.к. объяснять школьникам ПИД регуляторы без ДУ непродуктивно, а вот в комплекте с системной динамикой вполне возможно. И школьные роботы-тележки будут быстрее и точнее бегать.
Кстати, был приятно удивлен, когда увидел в современной школьной информатике объяснение «отрицательной обратной связи».
Это не аргумент, чтобы не изучать.Если речь о курсе информатики, то вполне аргумент. Хотя Вы и тут скажете, что всё взаимосвязано :-)
Нечеткая логика пригодится в школьной робототехнике для описания регуляторов/котроллеров к механизмам,
Ну да. И вообще, выходит, что эта нечёткая логика — это суть для компа: работа с вещественными переменными нужной точности.
Кстати, был приятно удивлен, когда увидел в современной школьной информатике объяснение «отрицательной обратной связи».
Да, неплохо.
Но давать отдельные категории из теории управления — это такое же издевательство, как делить математику на «высшую»/«низшую», до тошноты заучивая вторую, ни слова не говоря о первой. На выходе: вроде и математику ученик знает… до тех пор, пока не посмотрит на олимпиадные или вступительные задачи…
Встаёт вопрос: кого и зачем готовит такая школа?
Ну и теорию управления тоже нужно давать полностью. Её там немного, зато всё остальное в жизни будет ложиться стройно, связно и быстро.
упростить и в каком-то объёме рассказать можно почти всё, что угодно.
Во, минуту назад я был именно об этом.
Потому то и нужно быть человеком, а не роботом, чётко исполняющим любые инструкции (впрочем, школа как раз и требует бездумно чёткого выполнения)
раздел высшей математики, который изучается уже поверх знания теории вероятностей, классической логики и теории множеств. Предлагаете всё это в школьную программу затолкать? o_O
«Всё это» можно дать в разной детальности. И да, я считаю, что школа — это то место, где нужно дать представляния обо всех отраслях деятельности людей. Ну а кому уж что понравится — дальше пойдёт изучать узконаправленно.
И математика не должна быть исключеним тут. Нужно рассказать: обо всех разделах математики и вкратце их суть. Чтоб было представление. Потому, разделять математику на некую «высшую» и некую «низшую» — это глупость.
«Теория вероятностей» и матстатистика — весьма плотно используются в бизнесе. Это инструменты для изучения общества и поиска ЦА.
И если выпускник школы не имеет даже представления об этих разделах — то он заведомо в заложниках (ищет работу) у тех, кто знает.
Реализуйте для начала через булеву логику такие понятия как «может быть» и «да нет, наверное».
«Может быть» == вероятность самореализации строго больше нуля.
«да нет, наверное» == вероятность самореализации строго меньше 0,5
Потому то и нужно быть человеком, а не роботом, чётко исполняющим любые инструкцииАнекдоты показывают как раз чёткую логику. Как записан алгоритм, так и исполнять. Компьютер так и делает (за редким исключением), человек так не делает почти никогда.
«Может быть» == вероятность самореализации строго больше нуля.В булевой логике нет понятия «вероятность».
«да нет, наверное» == вероятность самореализации строго меньше 0,5
Человек, к слову, тоже всегда работает по алгоритмам. Другое дело откуда они взялись у него в голове.
В булевой логике нет понятия «вероятность».
Это просто вещественная переменная нужной точности.
А уж работать с переменными булевая логика может.
Это просто вещественная переменная нужной точности.Поясните… Вероятность — это не просто вещественная переменная. Допустим для 0.5 она означает, что обе ветки и if и else исполняются равновероятно. Булева же логика может исполнить только одну ветку.
Обычно вероятность пытаются эмулировать через random, но это ничего общего с человеческой логикой. Её эмулируют нейросети, но пока на очень-очень базовом уровне.
Допустим для 0.5 она означает, что обе ветки и if и else исполняются равновероятно.
Ну да. А боле никаких данных то и нет. Только вот такое вот высказывание и возможно выжать.
Булева же логика может исполнить только одну ветку.
Строго говоря, булевая логика ничего не выполняет, она не описывает алгоритмы (но алгоритмами возможно описать последовательность вычисления состояния выражений булевой логики). Она описывает состояния.
Алгоритмы же — это пути перехода между состояниями.
И вот для условного алгоритма в точке развилки используется булевая логика для выяснения состояния условия и направления дальнейшего потока исполнения.
Если я Вас правильно понял, то
эмуляция вероятности через random — это введение новых искусственных данных в задачу. Но это, скорее, тестирование алгоритма, в котором участвует некая вероятность: правильно ли будет отрабатывать алгоритм при разных входных вероятностях (обычное unit-тестирование).
Вы предлагаете Haskell как один из подходящих? Хорошо. Расскажите мне как на нем писать циклы. Или циклы не нужны? ;)
1) Чтобы прояснить, я предлагаю использовать несколько языков, каждый для демонстрации отдельных концепций в чистом виде. Вы знаете язык, который лучше Haskell подходит для демонстрации алгебраических типов данных и отделения побочных эффектов? Это концепции, которые полезны сами по себе и даже если человек станет программистом они пригодятся в любом языке. Сейчас большая проблема в том, что программисты не хотят развивать мышление… Многие пару месяцев поучившись на курсах сайтики делать, с горем пополам трудоустроившись после этого, считают что дело в шляпе, забывая что они находятся на уровне первого семестра ПТУ.
2) Теперь про циклы… Циклы — это абстракция, которая была удобна на определённом этапе развития индустрии. Сейчас её спокойно можно считать устаревшей. Все мейнстрим языки переползли сначала на итераторы, а потом на функции высшего порядка, генераторы списков и рекурсию, которые в Haskell изначально. Я не исключаю рассказ про циклы в рамках рассмотрения С, но в целом — да, они не нужны уже сейчас в 99% случаев.
Слишком уж хорош Python для своей ниши
То же самое про Perl говорили 20 лет назад. Когда дети закончат школу, выйдет какой-нибудь Python 4, на который ещё 10 лет переходить будут… Спасибо, но ну нафиг )))
Java умрет, как ей пророчат с 90-х годов прошлого века
C самого рождения или даже чуть раньше? o_O
Если серьёзно, то Java как виртуальная машина разумеется протянет ещё 10 лет точно, но как язык — разве что для поддержки legacy. Я стараюсь в этот стек вообще по минимуму заглядывать, но очевидно ведь, что попытки сделать лучшую Java в виде Scala, Groovy, Clojure, Ceylon, Kotlin, etc. рано или поздно увенчаются успехом.
А для того, кто только начинает количество вводимых символов все-таки важно.
Это Вы решили аргументов в пользу Haskell накидать? :-)
Поймите меня правильно, я за изучение концепций, а не конкретного языка программирования. Ни один из них не стоит на месте, поэтому изучение с упором на язык — это пустая трата времени, особенно для тех, кто не собирается завтра искать работу программистом.
Да, про Perl говорили. И он был великолепен в свое время. Но всему нужно развитие и поддержка индустрии. Perl, к моему большому сожалению, заглох и его место занял Python. В нашем мире возможно все, но сейчас работая в связи я могу сказать, что многие производители железа переходят на Python или добавляют его поддержку. Ericsson перешел с Perl на Python, а это настоящие консерваторы, Huawei дружит с Pytnon, ZTE вообще использует его как основной язык автоматизации. Как вы сами понимаете на продукцию этих фирм завязаны миллиарды и что-то менять просто так они не будут.
Java ведь 94 года рождения. Вот как появилась, так на нее и бухтят. В то время компы были еле-еле живыми. Мой первый комп mp3 не успевал расшифровывать. А жаба памяти жрала немерянно, тормозила и еще и глючила.
Так в том-то и дело, что на Java написано уже столько, что переписать уже точно не получится. Поэтому специалисты нужны будут всегда. И не где-нибудь, а в корпоративном секторе. А это деньги. 10 лет это вообще для Java не срок. А с учетом того, что Java уже очень даже прилично допилили что бы ее кто-то заменил из новичков? Он должен быть не просто хорош, а божественен. И самое главное он должен давать неоспоримые преимущества для корпоративного сектора что бы он на него переполз. Думаете это возможно?
А смысл в концепциях без языка? Знание принципов не позволяет открыть IDE и написать по этим принципам простейшую программу. Нужен банальный опыт. И тем более он нужен тем, кто не собирается работать программистом. Ну кто будет учить язык программирования будучи не программистом?
Я бы в школе учил как решать обычные задачи автоматизации и обработки.
Задумка интересная. Но как быть с тем, что не существует типовых задач автоматизации и обработки, для которых ещё нет готового решения?
Perl, к моему большому сожалению, заглох
Так вон же, Perl 6 вышел, только я почему ты сомневаюсь, что Вы забросите Python и вернётесь обратно.
А смысл в концепциях без языка?
Развитие мышления. Это гораздо полезнее, чем любой конкретный язык.
Как вы сами понимаете на продукцию этих фирм завязаны миллиарды и что-то менять просто так они не будут.
Не понимаю, Вы ж сами написали, что они переходят на Python… Значит ничто им не помешает и перейти с Python на что-то другое. Это всё лишь вопрос времени. Пока в индустрии консенсусом на тему языков программирования даже не пахнет. А значит всё ещё не раз поменяется.
Так в том-то и дело, что на Java написано уже столько, что переписать уже точно не получится.
С одной стороны написано много, с другой стороны всё переписывать и не нужно, многое устаревает само собой. К тому же я перечислял языки под JVM в предыдущем комментарии, именно они пока теснят Java как язык. С каждым годом причин выбрать именно Java, а не другой JVM-язык для нового проекта всё меньше, поэтому всё возможно.
В общем-то тут 2 варианта: либо всё стабилизируется как есть, либо текущие мейнстрим-языки уйдут в узкие ниши вместе со всем legacy… В первый вариант мне лично слабо верится. А если какие-нибудь квантовые компьютеры вытеснят обычные, то вообще прощайте все популярные ЯП, привет Quipper )))
В сугубо концептуальном смысле я с вами склонен согласиться. Только мы тут про преподавание в школах говорим. Мотивация у вас как-то выпала. «Развитие мышления», «Потом будет легче», «В жизни пригодится» — очень слабые мотиваторы. Для детей/подростков профит должен быть «здесь и сейчас». «Пропыхтеть» полтора часа за каким-то алгоритмом и через секунду после запуска программы увидеть ожидаемый вывод — это какой-никакой мотиватор. Убить полтора часа над схематической записью в тетради без возможности проверки «выхлопа» алгоритма — на мотивацию не похоже.
>> Но как быть с тем, что не существует типовых задач автоматизации и обработки, для которых ещё нет готового решения?
А вот тут прелесть как раз в том, что перед нами, предположительно, дети. Они не знают, что «все уже сделано до них». Поэтому, мне кажется, потренироваться на «велосипедах» — неплохая идея. По крайней мере, дети будут понимать, как работают чужие велосипеды, признанные «готовыми решениями для автоматизации типовых задач».
Убить полтора часа над схематической записью в тетради без возможности проверки «выхлопа» алгоритма — на мотивацию не похоже.Так я и не предлагал в тетрадке программировать, хотя мы в школе именно этим занимались первые полгода в 10-м классе, а потом нас к Агатам допустили, вот такая веселуха была в начале 00-х.
По крайней мере, дети будут понимать, как работают чужие велосипеды, признанные «готовыми решениями для автоматизации типовых задач».Опыт мне подсказывает, что признанные решения редко совпадают с первым, что в голову пришло. Но здравое зерно тут тоже есть, хотя бы иллюзия понимания будет, которая придаёт некоторую уверенность в своих силах.
хотя бы иллюзия понимания будет
Лучшее признание в том, что сегодняшая школа готовит к жизни в каком-то другом обществе, но не в том, которое есть.
А потом вышел в жизнь после такой школы, с кучей иллюзий, что умный и т.д. — и давай дрова ломать…
Вероятно, я более везучий. У нас в 90-х каким-то образом появились уже «прогрессивные» «последней модели» 386-е. Дома у меня тогда AMD K6 стоял, правда…
>> Опыт мне подсказывает, что признанные решения редко совпадают с первым, что в голову пришло.
Мне вот кажется, что попытка решить самостоятельно «до» может дать нехилое понимание не только того, что мы используем, но и ответить на извечные вопросы «зачем» и «почему». Знаете, когда-то я узнал, что такое РСУБД. И вот решил я это свежеприобретенное знание где-то непременно задействовать. SQL мне в руки и поехало. Прямо в коде запрос, потом еще один, потом добавляем табличку, переписываем запросы, потом переделываем тут и там. Да, на любом языке можно писать на PHP.
На определенный момент я самостоятельно пришел к таким вещам, как «соглашение об именованиях», причесал базу. Стало легче. Дальше следующий шаг — конктруктор запросов. Потом приведение структуры классов в соответствие со структурой базы… А потом я узнал, что такое ORM. Вы знаете, я почему-то сразу уловил суть нового инструмента и я заранее знал ответы, почему оно именно так, и зачем эта штука существует…
Мне вот кажется, что попытка решить самостоятельно «до» может дать нехилое понимание не только того, что мы используем, но и ответить на извечные вопросы «зачем» и «почему».Да, это так. Но всё-таки это надо как-то дозировать в образовательном процессе… ведь одна из его целей — в сокращении количества набитых шишек.
Для детей/подростков профит должен быть «здесь и сейчас»
Плюсую!
Причём, это справедливо и вообще для всех. Просто «здесь и сейчас» на разном уровне развития — разное. Для кого-то и 5 минут поработать на результат боль, а для кого-то и на результат в поколениях не вопрос (где-то в каких-то тибетах серъёзные решения принимаются с учётом интересов 7 (семи!) поколений на будущее).
Так что, да, получить на практике результат от изученного — это, видать, хороший мотиватор (увы, в школе с этим, похоже, целенаправленная беда).
Циклы — это абстракция, которая была удобна на определённом этапе развития индустрии. Сейчас её спокойно можно считать устаревшей
А как тогда работать с упорядоченными массивами? Просто кастовать «примени ф-цию чтотонужное() к массиву девайсы»? Но компу всё равно придётся элементы перебирать по очереди, даже если высокоуровневый язык позволяет об этом не знать. И что, низкоуровневое программирование канет в лету? Нового железа уже не будет и всё можно будет писать на высокоуровневых языках?
я за изучение концепций, а не конкретного языка программирования.
А вот это вот правильно.
Только вот циклы — как раз одна из таких концепций, о которой не рассказать, выходит, нельзя.
А как тогда работать с упорядоченными массивами? Просто кастовать «примени ф-цию чтотонужное() к массиву девайсы»?В том же комментарии, который Вы процитировали есть ответ: функции высшего порядка (map, filter, reduce), генераторы списков и рекурсия. Да, некоторые низкоуровневые алгоритмы останутся как есть, но это уж точно только профессиональных программистов должно интересовать, а не школьников.
Но компу всё равно придётся элементы перебирать по очереди, даже если высокоуровневый язык позволяет об этом не знать.И что? Причём тут циклы?
На уровне ассемблера есть только goto (jmp, loop) и goto по условию (jpe, jnz, ...). Ну, реально нет циклов в архитектуре современных компьютеров, что тут поделать…
Нового железа уже не будет и всё можно будет писать на высокоуровневых языках?Я уже чуть выше писал, что новое железо вообще может принести новую архитектуру и будет вам Quipper вместо C. Только опять же причём тут циклы?
Только вот циклы — как раз одна из таких концепций, о которой не рассказать, выходит, нельзя.Да можно, так же как на уроках физики про теорию эфира рассказывают… Исторический фактор никто не отменял.
Как «функции высшего порядка (map, filter, reduce), генераторы списков и рекурсия» сочетается с «C, Pascal, Smalltalk, Haskell, Racket»
Да, некоторые низкоуровневые алгоритмы останутся как есть, но это уж точно только профессиональных программистов должно интересовать, а не школьников.
Что заинтересует школьников — зависит от взрослых (учителей и родителей). И если их не заинтересовывать фундаментальными вещами, а лишь частными их производными, созданные кем-то [за окияном], то не придётся жаловаться на то, что наша страна плетётся в хвосте у других, и сама чего-то новенького придумать не может.
Почти как про капусту детям рассказывать. Извращать их мировоззрение.
А когда они где-то на улице услышат, что всё было на самом деле неколько не так и перестанут с родителями обсуждать интересующие их вопросы (а заинтересовать их может ой как много чего, иногда нехорошего...) — то кому выставлять претензии?
На уровне ассемблера есть только goto
А когда это одно и то же goto почему-то срабатывает постоянно и бесконечно (особенно в обработчике прерываний со всем замаскированным) — то сие явление люди зовут как угодно (завис, повис...), а грамотные ИТшники над ними потешаются в своём фольклоре.
А всего-лишь это цикл без условия об окончании.
(+анекдот про программиста, шампунь и «при необходимости — повторить»)
Цикл — это тип блока алгоритма. А алгоритмы работают и вне компьютеров. И когда лучше всего рассказать об этом, если не в школьной программе?
Цикл — это тип блока алгоритма. А алгоритмы работают и вне компьютеров. И когда лучше всего рассказать об этом, если не в школьной программе?Я ж включил Паскаль для объяснения структурного программирования. Не нравится Паскаль, объясняйте на РАЯ, без разницы.
Вы та боитесь конкуренции со стороны молодёжи, что предпочитаете их учить неактуальным вещам?
Неужели нельзя на чём-то реально и массово востребованном на рынке нельзя объяснять?Учить надо на том, что проще понять.
Конкуренция со стороны Java и Python-программистов мне параллельна, пусть поддерживают legacy хоть ещё 100 лет )))
Я вижу, что они уже неактуальны для многих новых проектов, поэтому для меня эти 2 языка выглядят как захламлённый Паскаль :-)
Если цель обучать под JVM, то любой из Kotlin, Scala, Clojure будет лучше Java.
А Python по моему прогнозу лет через 5 останется только как инструмент для сисадминов… всякие сценарии автоматизировать. Конечно, я могу ошибаться, но это мы узнаем только в 2021 году :-)
Ну а лет через 10 актуальными будут только те языки, которые позволят эффективно использовать сотни ядер и квантовые компьютеры, т.е. чисто декларативные. Все мои рекомендации исходят из этого убеждения.
А сотни ядер — это уже актуально, и 10 лет ждать незачем :)
Ну и если квантовые компутеры (это те, которые, якобы, не тратят время на вычисления?) шагнут в реальную жизнь — то всё равно у людей есть алгоритмы, которые будет нужно выполнять. Даже без затрат времени алгоритм не перестаёт быть алгоритмом. Чистая декларативность, как я понимаю, этого не обеспечивает?
А сотни ядер — это уже актуально, и 10 лет ждать незачем :)
Ну я пока на практике видел серваки только с 12 ядрами… Но тем не менее, этот тренд уже действительно очевиден.
Вот и смотрите, как эффективно занять 100 ядер вычислениями и не попасть на race condition? Нужны иммутабельные данные. В каких языках они есть? Erlang, Lisp, Haskell и тому подобное.
Да можно и по-другому, но достаточно сравнить привычную для Java модель с потоками/ мьютексами и модель акторов… и становится очевидно, что Java пора на пенсию. Она конечно сопротивляется, но генерирует больше аргументов в пользу Scala и Clojure, чем за саму себя.
это те, которые, якобы, не тратят время на вычисления?
В смысле? Время всё равно тратиться будет, только меньше :-)
Чистая декларативность, как я понимаю, этого не обеспечивает?
Отчего же… λ-исчисление обладает свойством полноты по Тьюрингу. Т.е. на любом функциональном языке можно написать любую программу.
Вопрос удобства, конечно, остаётся. Пока (с текущей архитектурой компов) у них в этом плане паритет… Для каких-то задач удобнее декларативный подход, для каких-то — императивный. Для квантовых, насколько мне известно, пока только декларативный применяют.
Вот и смотрите, как эффективно занять 100 ядер вычислениями и не попасть на race condition? Нужны иммутабельные данные.
Ну и для эффективного использования 100 ядер нужно просто обеспечить беспроблемность в их совместной работе. Если имеют место общие данные — то нужна синхронизация (кстати неизменные переменные — это частный случай, когда запись в переменную вообще запрещена всегда; кстати, оператор const в других языках никто не отменял).
Так что только из-за иммутабельности выбирать для проекта (в том числе обучение) язык 3-го эшелона — неразумно. Объём сторонних библиотек и прочей инфы — всё это списать со счетов популярных языков только из-за одной фичи — не вариант. В том числе изучать редкий язык только из-за одной фичи для демонстрации одной из концепций — тоже не вариант. У учеников сложится впечатление, что «за ООП — это идти к ЯП1, функциональное — это к ЯП2, а эффективно использовать проц — это к ЯП3». Т.е. концепция демонстируется не сама со себе в таком случае, а вместе со всё новым языком. Наглядность улетучивается.
кстати, оператор const в других языках никто не отменял
по-моему Вы не очень понимаете, что такое иммутабельность данных, если сравниваете её с const (который вообще к идентификатору относится, а не к данным)
Объём сторонних библиотек и прочей инфы — всё это списать со счетов популярных языков только из-за одной фичи — не вариант.
Вы просто не представляете объём сторонних библиотек и прочей инфы, по языкам, с которыми не знакомы… и их популярность тоже недооцениваете )
У учеников сложится впечатление, что «за ООП — это идти к ЯП1, функциональное — это к ЯП2, а эффективно использовать проц — это к ЯП3»
Ничего страшного. По факту всё так и есть, по-крайней мере на данном этапе развития IT. В мультипарадигмальных языках есть возможность использовать несколько разнородных концепций одновременно, но это в реальности достигается путём уступок и жёстких компромиссов.
А как Вы предлагаете выбирать язык, наиболее подходящий под задачу, если человек освоил только "молоток" и все задачи ему кажутся "гвоздями" xD
по-моему Вы не очень понимаете, что такое иммутабельность данных
Ну да это уже детали. Брать и просто не менять единожды созданное, или как-то самоограничиться с помощью средств языка. В итоге разницы практически нет.
Вы просто не представляете объём сторонних библиотек и прочей инфы, по языкам, с которыми не знакомы…
Знал бы — зачем бы тогда спрашивал?
Потому и говорю, что нужно сравнивать экосистемы языков.
Ничего страшного.
Наложить кучу… кхм… в голову людям, которые через 15-20 лет возьмут бразды правления страной в руки — сущие пустяки!
По факту всё так и есть,
"- Так Вам нужна программа с применением ООП?
— Для тупых повторяю: рация сломалась на танке"
Но по факту мы не наблюдаем монополии какого-либо языка на всякую концепцию. Формирование обратного представления у детей — это гадить им в жизнь, своим детям и внукам, ну и себе в старости.
но это в реальности достигается путём уступок и жёстких компромиссов.
«Эх… на чём же писать-то?? ООП на сях или ООП на питоне??.. железа много — можно на питоне»
Примеры?
Где, кроме суровых железных ограничений, придётся пойти на «жёсткий компромисс» и выбрать моно-язык какой, без того же ООП, а оно в проекте нужно?
Почти все популярные языки нонче — мульти. Т.е. языка — это уже ф-ция от желания заказчика и наличия специалистов и даже немного :) от специфики задачи.
А как Вы предлагаете выбирать язык, наиболее подходящий под задачу
Если существующий проект — то боль и вопрос языка закрыт (разве что речь о «всё по-новой»).
Если проект новый/перепись — то выбор начинается.
Окинуть взором веб на предмет возможных вариантов/новинок/тенденций в ЯП (кстати, отдельными языками можно и нужно считать даже сторонние библиотеки, ибо это отдельный набор терминов и функционал).
Если долгосрочный — то важны затраты на поддержку: внесение изменений должно быть простым (быстрым и дешёвым) — нечто достаточно популярное и/ли с растущей популярностью (чтоб спецы на нём были по безоблачным ценам).
На этапе реализации основные затраты — это время людей. И они его не должны тратить на специфику специфичного чего-то без надобности. Т.е. приоритет тому, что уже знают (а знают, вероятнее всего — нечто популярное; а популярность в ЯП не падает с неба), либо то, что есть смысл изучить ввиду растущей популяpрности (проект то не последний).
Ну а дальше всё просто:
сервак/PC — где железа поболе — скриптовый ЯП высокого уровня (JS — фактически, уже без вариантов),
если железа мало/критичная скорость — то компилируемый язык: Go или С (ну максимум с асм вставками).
Если веб — ну совсем понятно (флеш или жаба-аплеты — уже всё).
Мобила — как и на десктопе (с поправкой, что низким уровнем может быть и андроидная жаба).
Ну а если какие ардуины многоногие — то там выбор не так широк.
Если ж нормальную ОСь там можно пустить («малинки» и ко) и по скорости/мозгам некритично — то можно сохранить время людей, взяв привычный ЯП высокого уровня (нода крутится на таком без вопросов).
Думаю, ни одному «гвоздю» мало не покажется.
Как в вашу императивную картину мира вписываются такие факты:
Twitter выбрал Scala, WhatsApp — Erlang, Facebook — написал свой язык.
Сложность проектов и требования к ним растут, текущий мейнстрим — это временное явление, впрочем как всегда.
По-моему Вы боитесь, что люди после школы будут знать больше полезного, чем большинство текущих программистов. Поэтому хотите их учить тому, что наверняка уж устареет и как можно быстрее :-)
Где, кроме суровых железных ограничений, придётся пойти на «жёсткий компромисс» и выбрать моно-язык какой, без того же ООП, а оно в проекте нужно?
Вы не поняли… на компромиссы приходится идти дизайнерам языка, чтобы вписать в него несколько взаимоисключающих парадигм. В итоге ни одна не реализована толком, но какие-то отдельные фичи можно юзать.
Twitter выбрал Scala
Имеющаяся кодовая база и куча спецов на жаве, но захотелось чего-то освежить? (когда — не знаю)
Вполне.
WhatsApp — Erlang
Пишут, что по 2 ляма коннектов ерланг-софтина держит на сервер. Но это новость за 2012. А перед этим они хвастались результатами за 2011 год в 1лям коннектов. А когда решение принималось — вообще вопрос.
Нода же только в 2009 появилась на свет… Тогда и речи быть не могло о продакшне на ней.
Но 7 лет то уже позади…
(кстати! на ерланге ещё RabbitMQ писан — хорошая софтина)
Facebook — написал свой язык.
Их Hack язык — это пропатченый пых (я тоже пых патчил в своё время) под статическую типизацию. Т.е. снова же: груз имеющегося кода + системные проблемы с ним = конечно легче подпатчить язык, а не менять всю кодовую базу.
Ещё есть примеры? — было интересно покопать.
текущий мейнстрим — это временное явление, впрочем как всегда.
Текущий мейнстрим — в асинхронности (уже писал). И у кого его нет — тот счас уходит со сцены. Медленно, но уходит.
Вы боитесь, что люди после школы будут знать больше полезного, чем большинство текущих программистов.
Ну я ж уже просил пример другого какого языка, на котором можно было бы программить почти на всём мыслимом железе (кроме низкоуровневых контроллеров). Нет примера, но есть пустые обвинения, что такой реально существующий язык с какого-то рожна уйдёт в небытиё в обозримом будущем…
на компромиссы приходится идти дизайнерам языка,
да уж, внезапно… таки не понял этого.
В итоге ни одна не реализована толком
Ну и по доброй традиции — ноль примеров. Дескать, всё что есть из популярного — всё чисто недопиленные позёрские поделия…
Имеющаяся кодовая база и куча спецов на жаве
Мимо, имелась кодовая база и куча спецов на Ruby.
Их Hack язык — это пропатченый пых
А помните как переводили кодовую базу? https://github.com/facebookarchive/lex-pass/tree/master
я ж уже просил пример другого какого языка, на котором можно было бы программить почти на всём мыслимом железе
А на каком языке сейчас нельзя? Упомянутые Вами малинки потянут что угодно из компилируемых ЯП, они даже интерпретируемые типа JavaScript тянут. Вообще идея для всего использовать один язык — это как раз та история про плотника с молотком. Ну можно на JS писать под десктоп (Electron), но это ж тихий ужас… Приложение весит 100+ Mb, и память жрёт не хуже, чем браузер. Не у всех на десктопе по 16 Gb оперативы… тот же C# на десктопе JS уделывает как тузик грелку.
Поэтому чем тут мериться? Тем что "для галочки" везде можно использовать?
Дескать, всё что есть из популярного — всё чисто недопиленные позёрские поделия…
Причём тут позёрство? К примеру, чисто технически невозможно сделать одновременно функциональноориентированный и объектноориентированный язык. Хотя бы потому что в для первого — необходимо передавать состояние функциям, а для второго слать сообщения "состоянию"(объектам).
Можно частично использовать ООП и ФП совместно, но нельзя ориентировать один язык сразу на 2 парадигмы. Всё равно одна будет ведущей, а другие — частично поддерживаемы.
как переводили кодовую базу? https://github.com/facebookarchive/lex-pass/tree/master
Полистал сей хаскеловский код… не увидел ничего прям суперского по поводу парсинга. Как-то показалось, что когда-то видел что-то получше для парсинга. Просто какой-то фанат хаскела смог продавить проект.
(ЗЫ прочёл у них в каментах, что хаскел таки имеет какие-то чудные средства для парсинга)
но нельзя ориентировать один язык сразу на 2 парадигмы
Звучит как «нельзя сделать автомобиль, который мог бы поворачивать в разные стороны: ведь если Вы повернёте руль влево — то он не может быть повёрнут в то же время направо»…
нельзя сделать автомобиль, который мог бы поворачивать в разные стороны
Скорее автомобиль, который приезжал бы в два (далёких друг от друга) пункта назначения одновременно.
Если не фен-шуй, когда разноконцептуальный код размещён в рамках одного файла исходника, то чуть абстрагировавшись и поднявшись в иерархии мироздания на уровень всего компа — тоже можно заявить:
«на одном компе не фен-шуй наличие разноконцептуальных языков программирования, нужны отдельные компы для разных языков» :) «На этом мы программим функционально, а на этом вот — ООПим.»
Так что, так уж много ль разницы,
* если несколько концепций находятся внутри одного бинаря интерпретатора языка (и могут парсить разные концепции внутри одного файла-исходника)
* или же если несколько концепций находятся внутри одного винта и могут парсить разные концепции внутри одной ФС этого же винта? :)
Фен-шуй тут ни причём, смотрите простой пример:
Если ЯП позволяет написать функцию, модифицирующую свой аргумент, то это процедурный ЯП.
Если эту функцию необходимо убрать в объект, и модифицировать она будет состояние объекта, то это объектный ЯП.
Если эту функцию в принципе нельзя написать, т.к. данные неизменяемы, то это функциональный ЯП.
Т.к. невозможно выполнить все 3 "если" одновременно, язык должен определиться со своей главной парадигмой.
А теперь код:
function modify(a){ a[0] = 0; }
x = [1, 2, 3];
modify(x);
x == [0, 2, 3]; // => truedef modify(a):
a[0] = 0
x = [1, 2, 3]
modify(x)
x == [0, 2, 3] # => trueКак видно, и JavaScript и Python являются процедурными языками. Да с поддержкой и эмуляцией некоторых фич ООП и ФП, но без ориентации на них. То что разные концепции частично сочетаются в одном языке — это хорошо и удобно для практики, но ужасно для обучения. Сейчас мало кто из программистов понимает, что такое ПП, ООП, ФП… потому что не понимают концепции, а используют какие-то неадекватные критерии, типа "есть классы — значит поддерживает ООП", "есть функции высшего порядка — значит поддерживает ФП". А маркетологи языков на этих мифах успешно ездят.
Т.к. невозможно выполнить все 3 «если» одновременно, язык должен определиться со своей главной парадигмой.
Зачем???
И почему невозможно? Берёшь, не трогаешь переменные — получается ФП. Трогаешь — ПП. Какие проблемы? Или шашечки так уже нужны?
И почему невозможно? Берёшь, не трогаешь переменные — получается ФП. Трогаешь — ПП. Какие проблемы?Экосистема, начиная со стандартной библиотеки.
И даже если полностью отказаться от стороннего кода, то всё равно будут проблемы с самим языком, т.к. на его уровне нет поддержки важных фич конкретной парадигмы… Попробуйте какую-нибудь парадигму помимо ПП с классами, чтобы понять масштаб проблемы в мейнстрим-языках. К примеру, Smalltalk (ООП) или Haskell (ФП).
А теперь код:
…
хорошо и удобно для практики, но ужасно для обучения.
Если учёба логически не заканчивается практикой — то это имитация, а не учёба.
Ну а если для практики порядок — то учёба это всего-лишь подготовка к этому удобству.
Тяжело то должно быть в ученьи, а не в бою. Если в ученьи прям легко — то на практике будет грусть и печаль, либо изучение уже совершенно других, практических инструментов.
Но зачем тогда было терять время на непрактичные?
Както выходит, что учёба — это учёба, а практика — это практика. И, дескать, их ничто не объединяет. Я такое встречал в универе, где преподы уже давно сами ничего практичеки не делали, а потому и не умели толком. Зато умели учить… чему-то…
Как там в народе: «кто не умеет работать — идёт учить. А кто не умеет учить — идёт учить тому, как учить»
Но это именно тот тупик, из которого нам предстоит выбираться…
Ну а если для практики порядок — то учёба это всего-лишь подготовка к этому удобству.
Текущая практика исходит из того, что надо при низкой квалификации программистов сделать побыстрее что-то работающее и не упереться колом в кадровый дефицит, поэтому для неё удобна процедурная парадигма в винегрете с классами и ФВП.
Я бы хотел, чтобы через 20 лет средний уровень программистов был на порядок выше, чем сейчас. А вы (к сожалению не только Вы) по факту хотите чтобы он стал ещё ниже, т.к. даже текущее образование готовы упразднить в пользу сиюминутной моды. В итоге спрос на программистов растёт, а качество обучения постоянно падает. Вот в чём настоящий тупик!
Тяжело то должно быть в ученьи, а не в бою. Если в ученьи прям легко
Легко по моему плану будет вряд ли, зато будет чётко и понятно что к чему.
Текущая практика исходит из того, что надо при низкой квалификации программистов сделать побыстрее что-то работающее и не упереться колом в кадровый дефицит
Совершенно верно. И что, это неадекватное желание? Или вложить в проект побольше, писать академической чистоты код 5 лет, выверяя каждую запятую и ведя по ней документацию по всем гостам об использованных в ней парадигмам? И закрыться потом бесславно, т.к бизнесу нужно, что работало, а не академическая красота.
А вот почему бизнес не хочет вкладываться в неё и почему-то всегда ограничен в деньгах и страстно жаждет прибыли — это уже вопрос к тем самым «практически всем здравомыслящим», которые допустили банковскую процентно-ростовщическую гонку за наличностью.
Так что, писать код ради красоты, а не ради работающего результата — это пока не в этой реальности.
даже текущее образование готовы упразднить в пользу сиюминутной моды
Во такую «сиюминутную моду» я хочу в образование:
мой камент повыше
В итоге спрос на программистов растёт, а качество обучения постоянно падает. Вот в чём настоящий тупик!
Можете полюбопытствовать как дела обстоят в других направлениях науки. К примеру, в 15-ом году наша команда школьников на олимпиаде по математике в Тайланде «впервые за всё время участия в подобных соревнованиях не получила ни одной золотой медали» (http://d-russia.ru/mezhdunarodnaya-olimpiada-po-matematike-rossiya-vpervye-bez-zolota.html)
Здравомыслие, говорите?
(справедливости ради: в этом году у наших было уже 4 золота)
Т.е тупик есть — но в чём его первопрочина, корень?
ато будет чётко и понятно что к чему.
Ну дай то Бог, чтоб в гонке за академической чистотой не прозевать недовольство заказчика.
Совершенно верно. И что, это неадекватное желание? Или вложить в проект побольше, писать академической чистоты код 5 лет,
Вы пропустили "при низкой квалификации программистов"… Дело не в академической чистоте, а в том, что текущие программисты в среднем могут пользоваться напильником, но не в состоянии освоить токарный станок. Надо ли объяснять чем было бы быстрее детальки выпиливать?
Но Вы правы, у бизнеса нет свободных ресурсов, чтобы существенно повысить среднюю квалификацию программистов, именно поэтому этим должно образование заниматься.
мой камент повыше
Ну вот, Вы пишете "Самую высокую ценность обретает методология познания нового". Я согласен, но как это сочетается с желанием занять всю школьную программу мейнстримовым примитивом? Если люди с детства будут познавать только смазанные упрощенные концепции, как они научатся познавать новое?
Т.е тупик есть — но в чём его первопрочина, корень?
Имхо, как раз в упрощении программы, насколько мне известно, сейчас в некоторых школах обучение в старших классах свелось к подготовке к ЕГЭ o_O
токарный станок. Надо ли объяснять чем было бы быстрее детальки выпиливать?
Но станок и стоит куда дороже напильника…
Это вечная диллема «автоматизация — затраты на неё»
именно поэтому этим должно образование заниматься.
Может и не вполне очевидно, но в условиях дикого капитализма (счас практически на всей планете) государство во многом самоустраняется от рулевания макроэкономикой как единым целым, вынуждая отрасли заниматься вопросом выживания самостоятельно. И образование — не исключение.
Если образовательное заведение не умеет заработать — его купит (безотносительно формального права собственности) кому надо.
Отсюда и официально платная форма обучения.
И вопрос встаёт ровно тот же: если начать учить заказчика (студент и его родители — это заказчики) чему-то безмерно высокому, но не [очень] востребованному — то можно и без работы остаться… А чего хочет заказчик? — да ровно того же: суметь заработать на полученном знании и/или корочке. Т.е. тоже не склонен платить за лишние годы протирания штанов, если за меньшее время уже можно успешно выйти на рынок труда.
Вот так всё замыкается за рынок.
Ведь государство то самоустранилось от управления… Кому-то это нужно…
Но и да, правда в том, что выйти из этого порочного деньгоцентричного круга возможно только начиная с образования (потому то я и «мусолю» этот вопрос для себя).
но как это сочетается с желанием занять всю школьную программу мейнстримовым примитивом?
Ну я не соглашусь, что всю и что примитивом, но:
Пока в народе нет понимания и навыков об управлении (той самой методологии познания) — всё будет идти ровно как описал выше: всё во имя денек. Это счас — массовая идеология. Звучит: «выгодно продай». Кто что продаёт: кто китайские товары, кто своё время, кто какие-то понты, кто какието секреты, кто ближних своих… главное, хотят повыгоднее.
Ну и вот встаёт вопрос: и как эту махину перевести в другой режим? — Нужно как-то привлекать внимание этих людей. И на уме у них понятно что в первую очередь.
Т.е. нужно привлекать чем-то, что реально поможет им на пути к их целям (деньгам), и уже параллельно с этим давать разумное-доброе-вечное (всем что-либо человечное не чуждо).
А тем более, если это разумное-доброе-вечное — это теория управления чем угодно, в любой отрасли. То если это знание будет двигаться в массы вместе с актуальными технологиями заработка (ну а зачем ещё молодёжь идёт в программинг? красоту кода созерцать?) и навыками самообразования — то я думаю, что это весьма и весьма.
Если люди с детства будут познавать только смазанные упрощенные концепции, как они научатся познавать новое?
Какое же «только», если в первую очередь речь идёт о теории познания?
программинг со всеми компами и языками программирования — это уже частности. Кто умеет познавать новое — научится чему пожелает даже сам.
как раз в упрощении программы
Да… и, увы, сей процесс начался на 2 и не 3 десятилетия назад. В средине 20-го века в СССР в программе была и логика, и более вменяемая математика и т.д. В космос наш спутник вышел первым (после такой то разрушительной войны!) — неспроста…
сейчас в некоторых школах обучение в старших классах свелось к подготовке к ЕГЭ
Всего лишь в примерно 99% школ…
Да, болванский этот процесс — это очередная стадия разрушения нашего общества вообще. Благо, новая министр образования завела рЭчь, что с этим пора подвязывать. Впрочем, возврат к программам СССР — это тоже уже не выход. Считать, что мир остался таким, как был тогда — кхм… неразумно.
Да и теории познания тогда такой стройной не было.
Счас же, та страна, которая первой введёт в массовое обязательное образование вышеобозначенную достаточно общую теорию управления — станет безальтернативным мировым лидером. Но это отодвинет «элиту» этой страны от «корыта»… а она этого не хочет… потому, ждать таких перемен «сверху» — не приходится.
нужно привлекать чем-то, что реально поможет им на пути к их целям (деньгам)
Ну не знаю. Я верю в человечество, и хочется думать что повёрнутые на деньгах люди — это маргинальное меньшинство. Из таких не получатся ни профессионалы, ни богачи. Потому что деньги — это побочный эффект деятельности, а не её цель.
Да и теории познания тогда такой стройной не было.
Это Вы загнули… Гносеология то чем изменилась за последние пару десятилетий?
Я верю в человечество
Ну, без веры в человечество не было бы и смысла думать о каких-то переменах!
и хочется думать что повёрнутые на деньгах люди — это маргинальное меньшинство
Ну, тут уж наблюдения могут показать сколько у нас таких «маргиналов»…
Просто у этого явления есть вполне конкретная причина (я уже писал — глобальное банковское ростовщичество), а потому денег всем везде не хватает, а долгов хоть отбавляй. Вот люди и живут мыслею о том, где бы урвать, чтоб оттянуть свой конец…
Потому что деньги — это побочный эффект деятельности, а не её цель.
Но почему-то, именно прибыль — главная цель любой коммерческой деятельности. Не будет прибыли — деятельность свернётся и/или будет изменена.
Гносеология то чем изменилась за последние пару десятилетий?
Может и ничем. Но от этого не стала адекватнее насущным задачам людей.
Каков практически полезный главный вопрос философии? «Что первичнее: материя или сознание?»? (или курица с яйцом? :)
В педивикии читаю в статье о гносеологии: «Основной вопрос — познаваем ли мир в принципе?»
Ну, допустим, материя первична — и что? Или сознание — тогда что? Какова от этого польза?
Ну или вопрос о познаваемости мира. Ну если непознаваем? — отлично, и что? сесть и лапки сложить? А если познаваем — то кэп подсказывает, что нужно его исследовать. Офигенный совет! Спасибо, кэп!
Удивительно ли, что такая философия осталась в высоких кабинетах и не востребована в массах? Есть ли смысл после этого говорить о её стройности? — я уже не вижу смысла.
А что же тогда людям надобно? для пользы то.
А людей всегда, всю дорогу интересовали вопросы прогнозируемости последствий от деятельности или бездействия в тех или иных ситуациях. Всегда хотелось знать или видеть будущее. К этим вопросам никогда интерес не охладевал. Но где же, тогда философия, которая бы ставила его во главу угла?..
А вот о ней я речь теперь и веду…
Но почему-то, именно прибыль — главная цель любой коммерческой деятельности
Если почитать биографии известных миллионеров, то окажется, что это не совсем так.
А людей всегда, всю дорогу интересовали вопросы прогнозируемости последствий от деятельности или бездействия в тех или иных ситуациях.
Это да, поэтому астрология и хиромантия гораздо популярнее любой теории познания..
Если почитать биографии известных миллионеров, то окажется, что это не совсем так.
Не без исключений, конечно (тот же Форд — да, имел некоммерчекие цели).
А вот публичные биографии известных людей — это отдельная статья доходов писателей таких биографий… ;)
поэтому астрология и хиромантия гораздо популярнее любой теории познания..
Ну если только первые предлагали людям то, что их интересовало, а кабинетные науки — нет, то никаких претензий быть не может.
Трудовому то народу нужны вполне практичные прогнозы.
А как насчёт TDD?
Вы «за» или «против»? Что думаете?
Трудовому то народу нужны вполне практичные прогнозы.
"Ну что сказать… Устроены так люди… желают знать что будет"
Только если кабинетные науки хоть какие-то вероятностные прогнозы позволяют делать, то точные прогнозы от гадалок — это совсем другая история. Вообще, это косяк… вместо того, чтобы взять на себя ответственность за будущее, люди постоянно пытаются её на кого-то переложить.
А как насчёт TDD?
Вы «за» или «против»? Что думаете?
TDD vs TLD — это чисто субъективный вопрос. Как писал сам Кент Бек — ему удобно TDD, но это не значит, что все обязаны делать именно так.
На начальном этапе TDD полезнее, т.к. насильно помогает продумывать внутренний API, но для опытных программистов эта часть пользы уходит в ноль. Поэтому если кому-то нравится писать тесты постфактум — я нисколько не возражаю.
вместо того, чтобы взять на себя ответственность за будущее, люди постоянно пытаются её на кого-то переложить.
Желание знать будущее — это как раз и есть попытка какой ни на есть самостоятельности (а вот уповать «придёт хороший дядя и всё сделает» — вот что плохо).
Только если кабинетные науки хоть какие-то вероятностные прогнозы позволяют делать
Были бы такие точные науки — люди б уже давно их на воорудение взяли бы, что сделало бы их не кабинетными. Так что, пока в кабинетах — значит выше лабораторных предсказаний не поднялись. Людям же нужны прогнозы в общественной, политической, экономической и личной областях.
TDD vs TLD — это чисто субъективный вопрос
Я не упоминал TLD. Речь была именно о первом.
Желание знать будущее — это как раз и есть попытка какой ни на есть самостоятельности
Ну как сказать… Верить в то, что твоё будущее не зависит от тебя (т.е. теоретически предсказуемо извне) — это скорее фатализм.
Я не упоминал TLD. Речь была именно о первом.
Тогда возможно я не понял суть вопроса. Уточните, пожалуйста.
В целом я за то, чтобы внутренний API имел низкую связность (и как следствие был тестопригоден) и хотя бы 20% наиболее частых/важных функций были покрыты тестами.
Верить в то, что твоё будущее не зависит от тебя (т.е. теоретически предсказуемо извне) — это скорее фатализм.
Как это не зависит?
Бабушка говорит внучку: «не суй пальцы в розетку — будет бобо». Внучёк ещё не понимает данной закономерности, но она есть. И очень хорошо, что есть рядом бабушка, которая его предупредит. Но это уже дело внучка: совать пальцы в розетку или нет.
Знать закономерности и быть способным на их основе строить прогнозы — это не то же, что верить, что всё предрешено заранее (зачем тогда законы знать хоть какие-то вообще?)
В целом я за то, чтобы… низкую связность и...
Ну, собственно, да, это полезно.
Однако, TDD — это несколько не о том.
Это именно новый подход в программировании (кажись, его в 90-хх изобрели), который решает множество проблем.
20% наиболее частых/важных функций были покрыты тестами
А остальной код может глючить безбожно %)
А если нет — то как узнать что он вообще делает? Читать? Каждый раз? Все мегабайты кода?
Ну тут я уж лезу в большую тему TDD… можем не трогать. А TLD — это, по сути, та же TDD с чуть ухудшенной техникой.
Бабушка говорит внучку: «не суй пальцы в розетку — будет бобо».
Не думаю, что люди жаждат прогнозов такого уровня )))
Наоборот, они хотят точных прогнозов там, где нет чётких закономерностей.
Это именно новый подход в программировании (кажись, его в 90-хх изобрели), который решает множество проблем.
Ах, вот Вы куда вели… Безусловно, TDD — концепция, которая достойна ознакомления с ней. Но идеализировать её я бы не стал, проблем она тоже привносит немало, особенно когда применяется формально, что тоже не редкость.
А остальной код может глючить безбожно %)
Вы верны себе в манере передёргивать. Во-первых, есть принцип Парето, который в реальной разработке просто замечательно применяется, позволяя не сливать усилия, куда не надо. Во-вторых, отсутствие тестов не означает автоматическое наличие глюков. В-третьих, юнит-тесты не являются заменой ни приёмочному тестированию (которое впрочем можно частично автоматизировать, но это уже к TDD никаким боком не относится), ни документации. В-четвёртых, Вы с таким презрением пишете про "читать код", как-будто тесты это не код и как-будто в них самих не бывает багов )))
Строго говоря, 100% покрытие может нанести самый внушительный удар по проекту, если у разработчиков возникнет иллюзия, что если тесты проходят — то всё гарантировано работает как надо. По факту, так бывает только в книжках и в волшебных мирах, где единороги бегают по радугам.
А TLD — это, по сути, та же TDD с чуть ухудшенной техникой.
Не согласен. Подход совершенно иной. Ухудшенным он будет только для начинающих программистов. Впрочем да, это уже оффтопик.
Не думаю, что люди жаждат прогнозов такого уровня )))
Ну, конечно же люди любят положительные прогнозы (т.е «ничё делать не надо, всё будет хорошо») и редко когда на негативные прогнозы реагируют адекватно (в частности, не любят тех, кто давал им такой прогноз-предупреждение со стороны, особенно, когда он, увы, сбывается...)
Наоборот, они хотят точных прогнозов там, где нет чётких закономерностей.
Только вот они есть везде (просто имеют вероятностный характер).
Хотя да, далеко не везде и известны (в частности, что закономерности — вещественно-вероятны, а не булево-бинарные), и приемлемы людям. Потому и хотят чёткости даже там, где всё ещё есть некая неопределённость.
Но это уже проблемы людей…
Но идеализировать её я бы не стал, проблем она тоже привносит немало
Интересно, какие бы Вы назвали, хоть пару.
особенно когда применяется формально, что тоже не редкость.
Если формализм настолько формален, что привёл к какому-то другому методу — то обсуждать уже нужно его, а не TDD.
В прочих случаях, если соблюдается цикл тест-код-рефакторинг — то это TDD и качество такой разработки на голову выше любых прочих (при прочих равных, есьно).
Вы верны себе в манере передёргивать.
Ничуть. Что не контролируется — то неизвестно существует или нет, и в каком оно состоянии. А если неизвестно работает ли код как надо, то вполне закономерно вести речь о глюках (включая безбожные :)
А как иначе проверить работает ли код как надо, кроме как проверить его? — я других путей не знаю. И если это проверка умозрительно во время чтения кода — хорошо, это тоже проверка, хоть такая. Ну и выполнение на компе — понятно.
А дальше встаёт вопрос производительности труда программиста: есть ли возможность в любой момент в течении секунд-минут получить тот единственный достоверный бит «работает ли код так, как надо?»
Если «нет» — на нет и кода нет :)
А вот «есть» — вот этот вариант возможен только при TDD. Если тестов нет или тесты когда-то будут написаны потом (читай «никогда») — то за секунды-минуты вот прям здесь и сейчас невозможно получить этот бит.
Во-первых, есть принцип Парето, который в реальной разработке просто замечательно применяется
Ну я понял. 20% кода работает, а остальные 80% — глючат (Божно или нет — уже функция от верований программиста :)
Во-вторых, отсутствие тестов не означает автоматическое наличие глюков.
Даже присутствие не означает отсутствие.
Но проверить ни то, ни другое за секунды-минуты — некак.
ни документации
Перед программером новая либа, её нужно заюзать.
Есть простыня документации и дира tests с реальными и работающими примерами кода. Куда он заглянет, когда понадобится уже вот прям брать и писать код?
Вот и вся цена громким словам о документации…
как-будто тесты это не код и как-будто в них самих не бывает багов )))
Бывает. Но их есть кому проверить — самому коду.
100% покрытие
Это не значит, что разработка по TDD. Вообще.
100% покрытие может нанести самый внушительный удар по проекту
соответственно, и это не аргумент в минус TDD, а в минус методу «смотреть качество кода по % покрытия».
если тесты проходят — то всё гарантировано работает как надо
На своём уровне — как раз значит. И как было надо — программеры записали однозначно, кодом. Это может не совпадать с приёмочными тестами (т.е. логическая ошибка программеров), но это всплывёт на соотв. этапе.
По факту, так бывает только в книжках и в волшебных мирах, где единороги бегают по радугам.
«Изучать всякое там, чтоб писать хороший код — это всё в волшебных мирах, где пони круглые и кони в эфире».
Вопрос то в другом: улучшает ли TDD качество кода или нет? А не «делает ли его идеальным?»
А раз улучшает — значит его использование оправдано.
TLD… Подход совершенно иной.
В процессе управления цель ставится всегда перед её достижением. Цель — это тест (в терминах TDD). Концепция достижения цели — это код для удовлетворения теста.
Если пишется хоть какой-то код — значит цель уже была поставлена (пусть и только в голове программера).
И чуть менее важно когда тест будет записан в синтаксисе ЯП. Не такое значимое падение качества кода TLD в сравнении с TDD имеет место лишь потому, что даже такой пост-тест всё равно будет запущен, пусть и в следующую итерацию код-тест-рефакторинг.
Интересно, какие бы Вы назвали, хоть пару.
Смещение цели (Вы это ниже описали). Цель разработки — код проекта, а цель TDD — тесты.
При разработке прототипа проекта выполняется двойной объём работы: нужно постоянно менять не только код, но и тесты, что при хорошем покрытии весьма неприятно. Программистам свойственно забывать, что на уровне маркетинга тоже идёт своё проектирование и переделать поведение половины методов из-за изменившихся требований — это вполне рабочая ситуация.
Про ложное ощущение надежности я уже писал. Но стоит повторить, т.к. если, понадеявшись на TDD, сократить отдел тестирования, то можно нехило проблем огрести.
Тесты сами по себе не гарантируют хороший код. Я такие тесты видел, которые в рамках TDD писались, что охренеть можно… На них на самих тесты надо было бы писать.
Вопрос то в другом: улучшает ли TDD качество кода или нет?
Сама по себе — не улучшает. TDD может способствовать улучшению кода, если пришлась по душе конкретному программисту. В противном случае — будет соблюдаться формально, что в целом негативно скажется на проекте.
есть ли возможность в любой момент в течении секунд-минут получить тот единственный достоверный бит «работает ли код так, как надо?»
TDD тут ничем не поможет, на этот вопрос только приёмочное тестирование отвечает. И я ни разу не видел, чтобы это было в виде бита. Хорошие тестировщики всегда, как минимум, минорные недочёты находят. QA — это Вам не TDD, там реальный хардкор )))
А как иначе проверить работает ли код как надо, кроме как проверить его?
Только приёмочное тестирование согласно спецификации. К сожалению, TDD тут ничем не поможет, т.к. юнит-тесты пишет тот же человек, что и код и если он что-то неверно понял, то ошибка будет и в коде и в тестах.
Перед программером новая либа, её нужно заюзать.
В документации по-хорошему тоже есть примеры кода, которые можно тоже автоматически тестировать, чтобы гарантировать актуальность.
Так что я лично за то, чтобы смотреть в нормальную документацию. И только в запущенных случаях — в тесты/код.
Цель — это тест (в терминах TDD).
В терминах TDD — да, в терминах TLD — нет. Этим они и отличаются :-)
Ну я понял. 20% кода работает, а остальные 80% — глючат
С какой стати Вы отождествляете покрытие тестами и надёжность кода? При том, что это очевидно несвязанные вещи. О том, какая часть кода глючит Вам сообщит багтрекинг, а не тесты. Причём он Вам об этом сообщит даже если тестов написать в 10 раз больше, чем основного кода. Потому что тесты всегда будут врать, говоря что всё супер. И с другой стороны, даже если не написать ни одного теста, 80% кода глючить не будут даже если автор — зелёный джуниор.
Смещение цели (Вы это ниже описали). Цель разработки — код проекта, а цель TDD — тесты.
Мда… прочитать одно, и смешать всё в совершенно неудобоваримую кашу…
Проскочили слова «TDD», «цель» и «тест» в одном предложении — и, невзирая на их последовательность и роль в предложении, делается вывод, что у TDD целью являются тесты… (лицорука...)
Ладно, вижу, у Вас сложности с пониманием сути TDD. Новая методология разработки. Ну понятно, свои 7 лет Вы уже отучились и вроде студенты не жалуются (им чтоб жаловаться именно знаний то и не хватает) — зачем ещё время тратить и мозг перестраивать? если и так всё в шоколаде…
Но это дело хозяйское, чего учить, а чего нет.
С какой стати Вы отождествляете покрытие тестами и надёжность кода?
Потому как если есть контроль за каждым элементом — то качество лучше, чем если такого контроля нет. Тогда, конечно, начинается тяжёлая работа тестировщиков и проклацивание всех вариантов работы программы вручную.
О том, какая часть кода глючит Вам сообщит багтрекинг, а не тесты.
={ }
Даже комментировать такое больно…
Багтрекер ведь пополняется людьми (тестировщиками (а им ещё и ЗП надо платить) и бета-тестерами (пользователями)) в таком случае. Т.е. ошибки программистов выходят из-под их пера и ложатся бременем на других.
TDD позволяет писать код так, чтоб отдел QA находил 0 (НОЛЬ) ошибок. И его и нужно писать именно так. Что без TDD (или его подмножества TLD) — невозможно.
Проскочили слова «TDD», «цель» и «тест» в одном предложении
Да ладно, не стесняйтесь себя процитировать: "Цель — это тест (в терминах TDD)."
На самом деле суть TDD не в тестах, суть в том, чтобы упрощать дизайн кода при помощи обкатки применения методов в тестах. И, как можно догадаться из названия, тесты — это далеко не единственный из возможных driver'ов разработки.
А вообще забавно как Вы завелись… чувствуете прилив религиозных чувств, встав на "защиту" любимой концепции? Это верный признак, что Вы её не понимаете, но верите в неё. Нет ничего универсального и идеально подходящего для любых задач. И TDD тут, само собой, не исключение.
Вспомните, чем научный подход отличается от религиозного… Первый ищет границы применимости и варианты опровержения.
Багтрекер ведь пополняется людьми
OMFG, откройте для себя Airbrake и аналогичные сервисы.
От тех репортов, которые пишут люди вас никакие тесты не защитят, потому что они все либо на тему изменения требований к коду, либо косметического характера (типа вёрстка неожиданно себя повела в Safari, хочу посмотреть как Вы это при помощи TDD решаете, чтобы не больно было))).
TDD позволяет писать код так, чтоб отдел QA находил 0 (НОЛЬ) ошибок.
Пару пруфов не затруднит предоставить? В вырожденных случаях это теоретически возможно, но на практике Вы скорее найдёте сотни статей разочарованных в TDD, которые когда-то, как и Вы, поверили в это ложное утверждение. А ведь проблема не в TDD, а в неадекватных ожиданиях… Люди, которые понимают что TDD это про дизайн кода, а не про контроль качества, прекрасно его применяют по назначению.
Цель — это тест (в терминах TDD)
Всё верно.
Но, похоже, я не изложил многого в надежде…
Приходится расписывать счас.
У программы есть множество всякого функционала, который разбивается на мелкие цели и реализуется поочерёдно. Каждая отдельная цель записывается в форме теста. Он сначала не работает. Потом пишется код, достаточный для работы теста (концепция достижения этой цели). Рефакторинг — и к следующей цели.
А вообще забавно как Вы завелись…
Не люблю, когда мои слова понимают превратно, особенно диаметрально противоположно.
Это верный признак, что Вы её не понимаете, но верите в неё
Из пункта А в пункт Б, поэтому у Маши на 4 яблока больше.
Нет ничего универсального и идеально подходящего для любых задач.
Есть. См. полную функцию управления (ПФУ) в ДОТУ.
И TDD тут, само собой, не исключение.
TDD подняло планку индустрии до более автоматизированного следования ПФУ. Но сами авторы TDD об этом пока ещё даже не догадываются. Всё встаёт на свои места если знать и то, и другое.
Вспомните, чем научный подход отличается от религиозного…
Кроме того, что Вы путаете религию (religio — на латыни: связь; с кем? — в Богом) и вероучение (набор писаных людьми алгоритмов мышления/поведения), так ещё и противопоставляете науку вероучению, хотя были времена, когда они весьма мирно сосуществовали и богословы занимались наукой.
откройте для себя Airbrake и аналогичные сервисы.
Такого добра уже хватает. Но приравнивать багтрекеры к ним — это не очень.
Safari, хочу посмотреть как Вы это при помощи TDD решаете
Смотрите.
Если есть код — значит его возможно тестировать.
Для веба есть selenium и Ко.
Пару пруфов не затруднит предоставить?
Я не говорил, что TDD это гарантирует. Это именно идеал разработки, чтоб тестеры ничего не находили. И TDD этому крепко способствует. Или Вы считаете иначе? И код допустимо писать с глюками?
В остальном по TDD cм. книги или видео Дяди Боба.
Но приравнивать багтрекеры к ним — это не очень.
И как же Вы предлагаете их называть, если их самоопределение Вас не устраивает?
Если есть код — значит его возможно тестировать.
Кто спорит… его возможно тестировать и без TDD :-)
Для веба есть selenium и Ко.
Вы лично используете selenium для TDD?
И TDD этому крепко способствует. Или Вы считаете иначе?
Да, я считаю иначе. TDD является одним из методов написания качественного кода, но преимущество от его применения доказать не смогли, хотя исследования проводили… Оказалось, что качество кода зависит от уровня программиста, а не от применяемых им методик.
Из всего этого можно сделать вывод, с которого я и начал, TDD подходит тем, кому нравится конкретно эта методика. Остальным она будет скорее во вред. Другими словами, это всё чисто субъективизм.
В остальном по TDD cм. книги или видео Дяди Боба.
Спасибо. Вы лучше Бека почитайте, про XP в целом много интересного узнаете ;-)
так ещё и противопоставляете науку вероучению
Где это? Вы слово "подход" видимо пропустили )
Хорошая смена темы, но границы применимости TDD Вы по-прежнему не хотите формулировать… а значит для Вас это остаётся вопросом веры.
Приходится расписывать счас.
От того, что Вы расписали, ничего не поменялось… Вы по-прежнему путаете цели разработки и средства их достижения. Цель Вы хоть частично можете выразить в виде интеграционного теста, но никак не в виде юнит-теста.
И как же Вы предлагаете их называть, если их самоопределение Вас не устраивает?
Да, нормально. Всё-таки они отслеживают баги.
Вы лично используете selenium для TDD?
Нет. У меня просто не та область.
Оказалось, что качество кода зависит от уровня программиста, а не от применяемых им методик.
Ну высококлассный специалист делает и работу высококлассно. Кэр тут не обманывает.
Только вот кто такой высококлассный специалист, если не тот, кто владеет и пременяет качественные методики? (при прочих равных IQ и прочих сугубо личных качествах)
но границы применимости TDD Вы по-прежнему не хотите формулировать
Да вроде уже сформулировал: если возможно автоматически проверить результаты работы кода — там применим ТДД.
Цель Вы хоть частично можете выразить в виде интеграционного теста, но никак не в виде юнит-теста.
Почему же.
Нужна ф-ция, которая что-то делает. К ней выдвигается ряд формальных требований, которые возможно записать на ЯП. Эти требования — и являются целями (впрочем, это уже термин из теории управления, что, видимо, Вас и вводит в заблуждение). А код самой функции, который удовлетворит всем требованиям — и будет концепцией (тоже термин не из ТДД, а из теории управления) достижения потавленных целей.
Вобщем, я неправ, что смешал термины разных теорий, чем… ну Вы поняли.
Ладно, я не вижу смысла продолжать прения… А то может сложиться впечатление, что я имею что-то против TDD )))
Единственное с чем я не согласен, что это серебряная пуля, которая подходит абсолютно всем.
Что касается Selenium, его можно использовать при BDD, но при TDD. Лично я считаю, что BDD лучше подходит для бизнес-целей. Но навязывать не буду :-)
Вот такой у нас хреновый бизнес? Это ведь поэтому наш бизнес не в состоянии конкурировать с общемировым?
>> именно поэтому этим должно образование заниматься.
Похоже на перекладывание с больной головы на здоровую. Почему проблема у бизнеса, а решать ее должно образование?
Это ведь поэтому наш бизнес не в состоянии конкурировать с общемировым?
Почему именно наш? Это по всему миру так, за редким исключением.
Даже Google решила, что им проще урезанный ЯП разработать, чем в квалификацию программистов вкладываться.
Почему проблема у бизнеса, а решать ее должно образование?
Так забота о населении — это вроде как задача государства, а для бизнеса эта задача в десятом ряду. Поэтому бизнес в среднем исходит из сиюминутных реалий.
Это ведь поэтому наш бизнес не в состоянии конкурировать с общемировым?
Нет, не поэтому. Причина — в макроэкономике. Она так настроена: так называемые «развивающиеся» страны работают в угоду так называемым «развитым» странам.
Крышуется всё фрсом, ЦБ и академией наук вместе с высшей школой экономики.
Почему проблема у бизнеса, а решать ее должно образование?
Порождена она неадекватной наукой — потому и решена может быть только там же.
К примеру, если всех детей учить только телят пасти — то через 2-3 поколения будет стоять вопрос «а что это за железные кареты стоят посредь дорог и больше не двигаются? хотя деды рассказывали, что на этом раньше все ещё и ездили как-то!!!»
Вы серьезно в школе учились писать поиски, сортировки…?Представьте себе, Да.
Обычная школа в захолустье. Плотность населения 2чел/км2. 1989г. Без компьютеров. Доска и АЯ. Алгоритмы на деревьях не помню, но помню дерево арифметического выражения на доске.
Я вам больше скажу, я по ходу своей олимпиадой деятельности таких индивидуумов встречал! На последней олимпиаде по вебу я объяснял члену жюри (их из учителей набирают) что такое форматирование гиперссылок, так она мне не верила, говорит:«ты подчеркивание убрал, это теперь не гиперссылки».
Или чего уж там далеко ходить, в параллельной группе учительница, как она дает html… Это фейспалмом еще стену за собой пробить! Шел 2016 год, а она все оборачивала div с align=«center» в тег
<center>
Зачем она это делала, она сама не может обьяснить, про то, что в современных стандартах такого вообще нет, я молчу. Ей говорил я, говорили другие ученики, говорила моя учительница, все говорили ей, что так делать нельзя — не помогло.
Важно, чтобы не просто: дали набор операторов и крутись как хочешь (как оно часто и бывает), а чтобы была общая теория: как оно работает, как правильно строить программу, какие есть подходы к обработке данных, какие есть парадигмы программирования и так далее. А потом уже теорию применять на практике на компьютере. Тогда новому языку обучиться, новой парадигме программирования, освоить новую предметную область в объеме, нужном для понимания при написании программы — никаких проблем.
В частности, в порядке освоения школьной программы мой класс на информатике программировал на абстрактном языке с русскоязычными операторами. А в качестве бонуса (вне программы) еще программировали на фортране.
Другие классы, которые учились после нас, программировали на бейсике и паскале.
При этом, в зависимости от преподавателя и школы, обучение могло быть как чисто теоретическим, с программированием на бумаге, так и чисто практическим, с выполнением задач исключительно на ЭВМ и игнорированием общей теории. Могли давать только программу, могли и ее не давать в полном объеме, а могли значительно выходить за ее границы.
Кодирование для дошкольного возраста: 'Черепашка Лого ' в Forth
By Assad Ebrahim, on October 30th, 2016
http://mathscitech.org/articles/turtle-logo-forth
ЗадачаComputer Science — не сделать из вас программиста, а научить думать.
Фраза «научить думать» — это антипаттерн текстов про образование. Примеры:
«Цель высшего образования — научить думать», «Цель школы — научить думать», «Цель хорошего педагога — научить думать». Все пытаются «учить думать», вместо того того чтобы учить предмету / специальности.
По сабжу — учить computer sciense вместо word-а — это правильный подход.
С практикой уже сложнее. И часто курсы тоже ни о чем, как и базовое образование.
Причем, в школе (и даже до школы) надо бы дать некое мета мышление, базовые «наборы мышлем», «накатанные рельсы», на которые уже позже могут мапиться алгебра, геометрия, физика, Java, Haskell, и т.п.
Классическое образование предполагает изучение множества курсов, которые сформируют (или нет) некое неформализуемое мышление. И слишком часто продуктом такого обучения являются кодеры копипастеры…
Поток то новой инфы никого не обходит стороной, включая учителей (почему так — см. «Закон Времени» — гуглимо). А потому найти учтеля по какому-то новому и актуальному знания — так сложно: ведь кто-то должен найти это знание, освоить его самостоятельно, и заявить остальным себя в роли учителя. Но пока он учится — другим то что делать? Им то нужно это новое знание. Они тоже будут пытаться его изучать.
Т.е. сразу все стоят перед необходимостью самостоятельно осваивать что-то новое. Т.е. сама эта новая фактология и нужна резко, но и теряет актуальность так же быстро (технологии счас обновляться — только успевай следить). А что постоянно нужно? — то самое умение учиться. Самую высокую ценность обретает методология познания нового.
И она уже много лет как расписана и лежит свободно в нете. Достаточно общая теория управления (ДОТУ), гуглимо. В ней дан набор категорий, их названий и взаимосвязей, которые имеют место в любом процессе управления. Т.е. не устаревают в принципе. Именно методологию познания и нужно давать в школе, причём как можно ближе к началу. Тогда и в школе любые частные науки будут ложиться в голову легко и просто, и саообразование будет само собой разумеющимся.
Как подметила Черниговская очевидную банальность: мозг нужен нам для обучения. Любопытство у всех с рождения сильное и с возрастом угасает. Если в моем дестве были минуты и даже часы, когда не знаешь чем себя занять (не было у меня тогда под рукой много хорошей фантастики), когда умираешь от скуки (тв всего два канала), то сегодня такой проблемы у детей нет. Полно жвачки для мозгов. Нажал на кнопку и ушел в транс. В итоге, ресурсы любопытства быстро иссякают и ребенка уже все достает. Проблем целый букет. Так что пока не скажу, какие рельсы самые прямые.
Любопытство у всех с рождения сильное и с возрастом угасает.
Просто так, без причин?
Насилие в образовании, причём десятилетнее — отбивает напрочь желание даже самостоятельно что-то изучать новое.
А врубить ящик дураков и не напрагая извилин втыкать — это уже ближе к деградации, чем развитию, где вовсю должен быть задействован интеллект (как процесс выработки новой информации на основе имеющейся).
Далее есть стратегии «рационального мышления», и ТРИЗ здесь лишь наиболее известный.
На самом деле, если внимательно присмотреться к людям эффективным в своих областях, можно выявить конкретные стратегии поведения, а потом, например в игровой форме перенести их на детей\взрослых.
Казалось бы это всё психотехнологии, причём здесь computer sciense, но ИМХО именно паттерны computer sciense эту технологию делают. Мне всё чаще попадаются люди, шикарно наводящие трансовые состояния, освоившие самогипноз, но не способных сделать не фига полезного, кроме сценических фокусов, и это как раз таки следствие ограниченного набора паттернов мышления!
Или ещё пример понятный более-менее каждому, приходилось ли вам читать юридические документы или участвовать в судебных разбирательствах, для большинства это редкостная бредятина, НО в ней есть своя логика в которой юристы как рыбы в воде плавают не напрягаясь.
1) https://code.org/curriculum/unplugged
2) http://csunplugged.org/books/ (тут книжка в pdf)
3) https://www.kidscodecs.com/cs-unplugged-projects/
Вот только сдаётся мне, что пару раз погоняв вперёд-назад, вправо-влево, ребёнку это станет совсем не интересно, потому как нет цели или (непереводимое слово) challenge. Чего-то тут не хватает. :))
Для детей постарше есть такого плана: https://www.youtube.com/watch?v=XnDvebuc0tw
Заинтересованные лица есть. Полагаю ссылки можно прямо к статье прицепить или сделать этакую вторую часть, в которой будут ссылки и комментарии к ним.
Подскажите, что именно вам интересно? Материалов на самом деле очень много.
… обучение computational thinking — это прежде всего обучение принципам мышления и только во вторую очередь — за компьютером. Больше всего наработок в этом направлении, как ни странно, у Австралии с Новой Зеландией — именно они занимались разработкой такого направления, как CS unplugged — упражнений на развитие навыков по предмету, которые выполняются без компьютера.
Алгоритмы как таковые — это часть управления вообще.
У нас в России есть разработанная теория, однообразно описывающая в принципе любой процесс управления (от езды ребёнка на 3-колёсном велосипеде до реализации международного проекта). Обучение этой теории детей поможет им с лёгкостью освоить вообще любое частное знание (математику, физику, информатику с компами и программированием, производство, госуправление) и найти общий язык между любыми узкими отраслями деятельности людей. Просто потому, что все везде и так занимаются управлением, просто оздали узкозаточенный терминологический аппарат для каждой отрасли. Обобщив процессы, происходящие в частных формах управления — мы и получим дотаточно общую теорию управления (ДОТУ, гуглимо).
1) https://code.org/curriculum/unplugged
2) http://csunplugged.org/books/ (тут книжка в pdf)
3) https://www.kidscodecs.com/cs-unplugged-projects/
По международному опыту — считаю, что UK — один из самых классных примеров для копирования. Можно посмотреть много всего в их CAS Community.
+ http://www.computingatschool.org.uk/data/uploads/CASPrimaryComputing.pdf
+ https://www.computingatschool.org.uk/data/uploads/ComputingCurric.pdf
+ http://www.computingatschool.org.uk/data/uploads/internationalcomparisons-v5.pdf
+ https://www.acm.org/education/curric_vols/k12final1022.pdf
+ https://www.euractiv.com/section/digital/infographic/infographic-coding-at-school-how-do-eu-countries-compare/
такой же предмет как физика и химия и должен изучаться детьми с начала школы и вплоть до ее окончания.
Физика начинается с 6-го класса, а химия — с 7-го, или сейчас что-то поменялось?
Пропедевтика — введение в какую-либо науку или искусство, сокращенное систематическое изложение науки или искусства в элементарной форме, подготовительный (предварительный, вводный) курс, предшествующий более глубокому изучению предмета.В начальной школе изучают физические понятия: расстояние, время, скорость. Окружающий мир — включает элементы химии.
Ну, так можно далеко зайти… Если мама объясняет ребёнку, что не надо хвататься за включенную лампу накаливания, потому что когда её включают — она горячая, можно ли это считать вводной формулировкой закона Джоуля-Ленца? :-)
Границы вовсе не искусственны, они исторически сложились, просто потому что невозможно быть специалистом по всему одновременно. Да, сейчас уже есть много прикладных дисциплин на стыке разных наук, но перемешать всё в одну — это Вы явно загнули.
Ну, STEM — это даже не половина школьных предметов )))
STM (scientific, technical, and mathematics;[4] or science, technology, and medicine; or scientific, technical, and medical)
eSTEM (environmental STEM) [5][6]
iSTEM (Invigorating Science, Technology, Engineering and Mathematics); adds Invigorating: Recognises that STEM is not new. This program identifies new ways to teach STEM related fields.
METALS (STEAM + Logic), introduced by Su Su at Teachers College, Columbia University.[7]
MINT (mathematics, information sciences, natural sciences, and technology); a less common term with a similar meaning. MINT is used more often in Germany.[8]
STREM (Science, Technology, Robotics, Engineering and Mathematics); adds robotics as a field.
STREM (Science, Technology, Robotics, Engineering and Multimedia); adds Media as a field.
STREAM (science, technology, Robotics, engineering, art, and mathematics); adds the arts and robotics field.
STEAM (science, technology, engineering and applied mathematics); more focus on applied mathematics[9]
GEMS (Girls in Engineering, Math, and Science); used for programs to encourage females into these science fields.[10]
STEMM (science, technology, engineering, mathematics, and medicine)
AMSEE (Applied math, science, engineering, and entrepreneurship)
Как отметили выше, разделение предметов дает более простую управляемость системой образования. Но целостная картина мира будет формироваться (у ученика), если все предметы сильно связать, когда, например, производная в концептах физики дается совместно с производной в концептах математики, чтобы сразу было понятно «зачем оно нужно». И так по всем предметам.
Да я в общих чертах представляю что такое STEM. Просто Вы забыли, что в школе есть ещё и куча гуманитарных предметов. Или предлагаете литературу тоже в концептах математики разбирать? А вместо изучения правил русского языка заняться частотным анализом?
Физика с математикой и так всегда связаны были, в том числе и в школьной программе. Химия тоже с ними переплеталась. Ну добавили биологию и информатику к ним ещё. Это всего 5-6 школьных предметов. А всего предметов, емнип, раза в 4 больше.
С остальным я, в принципе, и не спорю… Хотя всё это разнообразие аббревиатур наводит на мысли о горе-маркетологах. Особенно доставляет GEMS с дискриминацией по половому признаку… как они такое название в США зарегистрировать то смогли )))
А вот с литературой все очень сложно, потому как это воспитательный компонент. Изучение литературы ведет к снижению коммуникативных издержек между людьми. Люди друг друга проще понимают, в итоге больше взаимопонимания, быстрее договариваются, выше пропускная способность социальной системы.
Думаю, что если удастся сформулировать идеальный результат воспитания (желаемый образ личности, может несколько разных образов), тогда алгоритмически можно было бы подобрать нужный список литературы к изучению. А сегодня большая часть произведений изучаемого списка обосновывается аргументом «так сложилось» или «так считает авторитет», т.е. антинаучно.
Я учился в школе с лингвистическим уклоном, и информатика у нас была 1 раз в неделю (если не ошибаюсь, это было более 10 лет назад), на которой нас ни разу не учили офисным программам, а мы проходили алгоритмы, изучали как вообще функционирует компьютер и все такое.
Недавно помогал племяннице, с информатикой, и там тоже алгоритмы, объекты, абстракции. Где вы взяли что детей учат пользоваться вордом? Да учебники сейчас так себе, и подача материала хромает (Так племянницу заставили учить расширения файлов не объясняя почему так и переводить байты в мегабайты, не объясняя что такое возведение в степень)
В Москве есть около 3-4 групп разных учебников по информатике и, соответственно, учебных программ. Есть и такие, где с 3го дается алгоритмика и все отлично. Но так пока не везде.
Excel — замечательная среда для моделирования почти чего угодно.
В школе сейчас популярна проектная методика. Как представить результаты работы? В PP! А это значит, отобрать главное, структурировать, правила дизайна не нарушить и т.п.
У каждого из этих приложений множество очень полезных возможностей, о которых большинство не догадывается. Или все перечисленные умения от рождения даны? А ведь они пригодятся практически каждому.
Хотя, конечно, все можно сделать «на коленке»: буквы, цифры, пробел, enter — на любом языке код можно написать. А что еще человеку нужно?
Для начала — научите людей использовать поисковики. In my honest opinion, это один из наиболее критичных скиллов на данном этапе развития общества, но, при этом, что в вузе, что в школе, что на работе, я постоянно встречаю людей, которые просто не умеют работать с тем объемом информации, который находится у них под рукой и не могут быстро ее найти и применить.
Полугодичный курс в университете в первом семестре, с названием «Гуглим правильно» и аналогичный предмет для школьников был бы очень полезен.
ЗадачаComputer Science — не сделать из вас программиста, а научить думать.я думаю, что научить думать это и есть самая главная задача образования, любого образования.
Во-вторых, есть тенденция к внедрению возможностей программирования в бытовую технику. Некоторые, польстившись на «крутизну» современной техники, но не обладая навыками программирования уже имеют с этим проблему. Им бы кнопочку, чтоб нажал и заработало, а там надо целый алгоритм работы строить.
Взчть тот же «умный» (на самом деле тупой автоматизированный) дом.
(Тут, кстати, в полный рост встает вопрос о том, что учить надо не конкретному языку, будь то паскаль, бейсик или даже хаскель, а программированию вообще).
… перечитали большое количество талмудов.
А не можете ли вы перечислить три наиболее полезных из них с вашей точки зрения?
Как проходят уроки информатики в разных странах мира: 5 основных выводов