Чему и как учить ребенка...

Код (Text):

1. А у Дельфии
2.    срезало брюхо винтом
3. Выстрела в си-и-и-и
4.    не ожидает никто
5. Ну а на форте
6.    больше не пишут ваще
7. Нету в коробке
8.    болванок уже-э-э-э-э-э-э-э
9.  
10. Фаргус! Спаси нас, Фаргус!
11.    Во что играть уже не знаем мы совсем!
12.  
13. ПА-БА-БА-БАМ!

 

The Svin

Извини, под этими словами понимается лишь одно - алгоритмический язык, то есть язык описания алгоритма программы!

А это блок-схема алгоритма, то есть графическое представление алгоритма программы.

Бесспорно! Под словом "мышление" я подразумевал логика работы компьютера.



Логика работы компьютера не соответствует логике мышления человека - в этом главный недостаток компьютера(на данном этапе развития).



Чтобы увидеть это "разногласие", достаточно посмотреть за человеком, которые осваивает интерфейс виндос



Чтобы компьютер выполнил приказ человека, нужно чтобы человек сформулировал приказ в форме, понимаемой компьютером.



Обучить начинающего человека "формулировке приказов" и есть основная цель алгоритмического языка.



Чтобы человек-не программист мог отдавать приказы компьютеру разрабатываются интерфейсы.



Теперь пойдем "ниже":

Набор команд процессора - это и есть конструктор для формирования приказа компьютеру.



Именно набор команд определяет логику работы компьютера.

Все компоненты принципиальной схемы имеют алгоритм работы.



Логику работы любой приниципальной схемы любого устройства можно описать алгоритмическим языком.

 

Ох ужжж нафлеймели.



Давайте по делу.



Цель: попробывать привить ребёнку азы программирования.



Вариант 1: Опкоды.



ребёнку надо рассказать о машине.



Кстати я например (как грится личный прикол) начинаю это в виде нелепых историю о "муже".



Они теперь тут так и называются причём реальный факт - ученики их пересказывают, потому что им кажется что я рассказываю им анекдот.



Чтобы было понятно о чём я говорю... приведу это произведение здесь.

 

Ну если вы знаете. Есть такая классическая проблема в психологии о привыкании. Называется она проблемма с мусорным ведром.



Вот недавно поженились молодые люди. Любят друг друга и всё такое. Вообщем.



Муж попался не пьющий, такой пушистый, и ласковый. Но немного несколько ленивый. Жена наоборот - такая энергичная женщина.



Каждую суботу жена рано уходит из дома по своим делам.

И оставляет мужу список.



1. Умойся.

2. Позавтракай.

3. Полей цветы.

4. Пойди на базар, купи продукты.



Муж выполняет этот список.



Может быть кто-то ещё не понял. Где тут процессор, а где программа?

 

Этот простой пример со списком - достаточно нагляден, чтобы думать о том, как процессор выполняет команды. Что такое команда, и что такое программа.

 

Как всегда вечером муж сидит смотрит телевизор, получает удовольствие. А тут жена:

- Выниси мусор!

Муж думает: "Да, конечно надо! Моя очередь. Вот только фильм досмотрю..."

Через почаса жена:

- Вынеси мусор!

Муж думает: "Эх надо! Но хочется футбол"



жена уже устала повторять...



Поэтому она решила использовать ... циклы )))

 

как правило я пользуюсь этими историями - чтобы настроить аудиторию.

Тогда можно погрузится глубже. Но аналогия с женой мужем, и бабушками на скамейке (есть такая фича) - это уже вошло в обиход



Детям вообще очень НУ ОЧЕНЬ интересны рассказы о строении ПАМЯТИ - который ассоциируются со строением памяти у человека.



Их если честно прёт.



А именно это "прёт" и помогает в обучении.

 

Согласен со словами "логика работы", с утверждением несогласен.

Набор команд может быть одинаковым, логика работы разной.

Логику, не алгоритм. Алогоритм - шаги, последовательность,

там в основном шаги только импульсы синхронизации.

В основном замкнутые логические выражения.



Ну и если уж речь о принципиальной схеме, то как раз содержит кое-что что из набора команд не понять а вот на работу компьютера влияет.

 

Edmond

Апплодисменты!



Но далеко не каждый также как ты может преподносить "нудный" материал.



Не знаю, обладает ли таким даром DirectOr - именно по этой причине всё-таки лучше делать упор на последовательность изложения материала.



Собственно, об этом и данный топик - "с чего начинать".



The Svin

Не-а

Именно логика работы устройства определяет набор команд для управления этим устройством.

1. Под словом "логика" я не подразумевал "логические схемы", так как ты применил "устройство" в общем понимании этого термина, а не применительно только к цифровым устройствам. Из-за этого произошла небольшая путаница в терминологии. :\



Простейший утюг имеет логику работы:

Если пользователю нужно гладить синтетику, тогда температура нагрева полотна такая-то.

Если пользователю нужно гладить хлопок, тогда температура нагрева полотна такая-то.



Это и есть логика работы = алгоритм работы устройства.



И как видишь алгоритм работы устройства я описал алгоритмическим языком(не строго, конечно же)



2. В разных областях науки используются разные способы представления алгоритм.



Опишу только для тех, которые были упомянуты:

а. Разработка аналоговых устройств - формулы зависимостей, графики, осциллофограммы, сверочные таблицы контрольных точек.

б. Разработка цифровых устройств - таблицы истинности, датаграммы.

в. Программирование устройств - алгоритмический язык, блок-схема алгоритма

г. Использование устройств - руководство пользователя.



Ты же смешал всё в кучу.



Программирование устройств развивается в сторону независимости от конструктивного решения самого устройства.

В DOS использовали int и порты, в Windows - драйвера устройств.



А задача языков высокого уровня окончательно устранить зависимость программ даже от операционных систем.

Пока, как мы видим, они с этой задачей не справляются.

Может это кому-то выгодно?



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



И если у парня "пойдет", то он начнет "копать глубже".



Вот тогда можно уже будет начать объяснять что команда print - это тоже процедура. К тому времени он будет знать "что такое процедура" и переход на ассемблер перейдет достаточно мягко.

 

Не могу сказать насчёт "заговоров", но то что я вижу в высокоуровневых языках как языках это сведение логики к тупейшей реализации импликации через .IF (сама импликация вообще присутсвуя в мат. логике напрочь отсутсвует к тому же в схемотехнике) и убого реализованных итерационных оператах, остальные идеи связанные с логикой могут быть интересны но обычно не проходят надлежащей проверки математикой в итоге мы имеем глючные реализации различных "технологий" которые работают в одних условиях и глючат в других. Про математику (в особенности арифметику влючая высшую) и говорить не хочу - она полностью этой же самой убогой импликацией подменена. Это всё одно что мы все множества будем записывать экстенсионально.

Т.е. языки на том уровне что есть не выдерживают критики с мат. точки зрения.

 

Да и насчёт "перехода на ассемблер"

У меня ребёнок "перешёл на ассемблер" с машинных кодов в 6 лет. При этом удивившись некоторым синтаксическим требованиям сказав "а на кой это нужно и без этого понятно".

У нас часто подменяют слова "От теории к практике" смыслово "От простого к сложному" и это вверх тупизма и античеловечности.

Обычно человек естественно, а в особенности ребёнок, идёт по пути "от частного к общему" и это почти для него "от простого к сложному". Высокий язык - это абстракия и обобщение, низкий уровень (я даже избегаю слово "язык") - частность - реальность (или близкая - изоморфная абстракция к реальности например 1 0 заменяют низкий и высокий уровень напряжения). Когда он сделает несколько частных циклов на машинных командах, он легче увидит общность между ними и обобщит её, может при этом скажет кто-то что это называется цикл, а далее он увидит это подобие в while, for и т.д.

А вот высокоуровневый программист лишён взгляда на реальность, но человек не может так и потому он начинает придумывать, додумывать и как то для себя обозначать эти "чёрные ящики", это происходит в ужасно искажённом виде, либо вообще не искажённом а прообраз ничего не имеет общего с реальным образом.

Это даже не на низком уровне происходит - это с ассемблерщиками происходит, которые только ассемблер и знают, уже детские программки год как лежат на WASM а до сих пор вопросы про hexы машинных кодов. Т.е. даже у ассемблерщиков неправильное представление о машинных кодах. Они учились по книжкам тех кто сам не имеет чёткого представления о низком уровне.



Т.что

1. Без частного с абстракции начинать сложнее (единственное приемущество такого обучения - навыки работы с синтаксисом, машинному программисту вообще с ним работать не надо понятно - он пишет "как есть" - ему язык не нужен)

2. Абстракция отражает только часть, и "переход к ассемблеру" закончится тем, что обучающийся и в низком уровне будет искать только ту часть, которая отражена в его абстракциях

 

Позвольте,

Чем же вашему IF ... THEN отличается от CMP ... Jxx?



По-моему ничем



Я одно время в качестве "изучения" Си проводил такой эксперимент - добивался чтобы код получаемый от Си-транслятора соответствовал байт в байт коду от АСМ-транслятора.



Применительно к условным переходам, пересылкам данных, вызовам функций API - это получалось без проблем.



На Си можно писать "ассемблерные" программы.

Просто стандарт Си гораздо шире, чем набор команд процессора.

Ммм... Скажу немного по-другому, часто теорию с практикой "разделяют" и затем молодому уму тяжело совместить эти знания.



Я считаю что теория и практика должны идти параллельно.



Но азы - в частности алгоритмический язык - надо преподать перед началом программирования, так как это равносильно ознакомлением с руководством пользователя для нового устройства.



Помню, в техникуме, зная схемотехнику компьютера, а также ассемблер для этого компьютера - мне было тяжеловато проследить результат засылки числа в порт по электрической принципиальной схеме компьютера. Но я справился

 

Честно говоря я даже непонимаю с какого бока на такое отвечать и к чему относится подмигивание.

Даже тупой компилятор не всегда на месте IF ... THEN ставит CMP (не только потому что иногда он чуть соображает, но иногда ему CMP вовсе ничем не поможет)



А уж низкоуровник ему вообще до болды IF ... THEN, ну не нужны они ему, они поперёк вообще его логике, а CMP для него просто вычитание с установкой флагов без записи результата и использует он это зачем ему заблагороссудится и воовсе не обязательно в блоках управления. Так же не обязательно в блоках управления он будет использовать CMP.



Вопрос то выдаёт высокоуровневый подход.

Я уже тысячи таких примеров видел, появляется высокоуровневик и начинает типа дурью маетеся, вот компиляторы такие крутые - они вот как круто мою программку оптимизируют... ну и дальше идёт какой нить сишный исходник и результат действий компилятора, ну а ассемблерщики понятно давай кричать - да человек всегда машину победит - и давай сыпать результаты как они руками это делают.



Полный идиотизм на который я по началу поддавался.

Идиотизм в том что человек и компилятор соревнуются в чём?

В решении какой-то задачи?

Нифига!!!

В КОМПИЛЯЦИИ СИШНОГО ИСХОДНИКА.

Т.е. изначально программа уже написана (написано то что на Си написать можно т.е.) а потом что уже можно написать на C начинают компилировать, сишники - компилятором а ассемблерщики - руками

Ну сишник понятно - ему кажется что он дал ЗАДАЧУ, он дал ПРОГРАММУ, он из-за своей ограниченности отождествляет исходники на Си и спецификацию. Но ассемблерщики то какого поддаются )



А вообще твои слова про IF и cmp здесь ни к селу относительно приведённой цитаты. Я в ней не рассуждал о приемуществах ассемблера перед высокоуровневыми языками - ты сказал что непонятно почему абстрогироваться не мог полностью от машин и я в ответ на это рассуждал о том что эти самые высокоуровневые языки именно с точки абстракции - мат. логики ещё несовершенны. Т.е. они пока хуже даже, корявей, неполноценней обычной мат. логики, они даже до неё не доросли (слова про импликацию!!! были связанны с IF) а им нужно сложнее задачи решать тех что в мат. логике.

Высокоуровневые языки просто в самом начале пути и проверки как формальный язык (с точки зрения математики), т.е. кроме сложностей маш. реализации, качественных компиляторов и т.п. из-за которых высокоуровневый программист не может абстрогироваться полностью от машины, существуют ещё и недостатки языка, которые не дадут этой полной абстракции даже если остальные проблемы будут решены, пока не будут исправлены с точки зрения математики.

Я ещё раз повторю - я не против высокого уровня, но считаю что обучившись высокому уровню опустится до низкого труднее чем наоборот.

 

Я хотел сказать что основные конструкции языка - будь-то Си, будь-то ассемблер - одинаковы.



Ты забываешь, что начинающий еще не знает, что каждой команде соответствует свой код, а буквы на экране - на самом деле просто числа.



Но в языках высокого уровня существуют дополнительные абстракции(в частности при работе с памятью), которые ты так люто ненавидишь...



...Тем не менее начитать изучение программирования надо с языка высокого уровня, так как начинающий еще не знает и не использует существующие абстракции языка высокого уровня.



Плюс языки высокого уровня Си/Бейсик/Паскаль ближе к по своему систаксису к алгоритмическому языку.



Именно поэтому преподают сначала язык высокого уровня - чтобы быстрее перейти к практическим занятиям на компьютере.



Идеальнее всего для этого подходит интерпретатор, так как он и редактор, и отладчик, и "исполнитель" одновременно.

Я прошел подобным путем(учили в техникуме).

Всё вроде прошло гладко и без каких-либо затруднений.

Но фишка в том, что мне "дали" ассемблер сразу же после Бейсика. То есть ничего серьезного я на Бейсике еще не написал - просто не успел



Как результат курсовая работа "Описание микропроцессорного набора КР580" был написан полностью на ассемблере. Дипломная работа "Постраничный вывод текста на печать с пользовательскими шрифтами" также был выполнен только на ассемблере.

 

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

 

The Svin

Я вот точно то же могу сказать об обратном - "на кой мне эти опкоды и знание того как они формируются?" Т.ч. все относительно.

Ага, а еще есть такие "тупейшие" компиляторы, которые вообще могут этот блок выкинуть за ненадобностью, которая будет очевидна компилятору, но не очевидна большинству программеров.

Это тебе оппоненты безграмотные попадались Мне иногда приходится "переводить" из Си в асм (намедни вот zlib переводил под свои нужды) и у меня почему-то даже мысли не было тупо "вести пальцем" по сишному коду и переводить все на асм. В результате (хотя это не было самоцелью) скорость работы выше на 35-40+%, размер в 3 раза меньше чем самый заоптимизированный сишный вариант.

Очень, очень субъективное мнение, зависящее от кучи факторов

 

Ребенку в копилку от ...

1441624752__math.zip

 

Угу я об этом и говорю, переводится должна задача.

Но сплошь и рядом в таких соревнованиях проводится именно компиляция ручная сишного кода.

 

Я тут немного в начале топика распинался о матрицах сознания.

А никто что-то не обратив внимания особо.



Не могу говорить о статистике касательно асма.



Сейчас у меня группа из 10 чел. 8 - постоянны.



Из них 1 ребёнок в 8 классе.



Последовательность задач - как я уже говорил.



1. Hello - пример я кидал

2. Пирамидка из звёздочек на экране вида:

Код (Text):

1.  
2. *
3. **
4. ***
5. ****
6. *****

Потом такая

Код (Text):

1.  
2.                         *
3.                        ***
4.                       *****
5.  

Потом вверх ногами.



Потом квадрат



потом....



Эти все задачи базируются на 2 вещах



1. Соединяют визульное представление с внутренним

2. Позволяют понять ребёнку - что на самом деле по сути программирование - всего лишь работа с данными.



Язык - можете выбрать любой. Но Асм - просто самый прозрачный - а значит понятный.



По статистике. 3 задачи - никто не понимает...

Но в процессе - 4 пишется сама.

 

эт вам мнение врача-педиатра для разнообразия: