А потом в середине листа встречается объявление функции и становится очень непонятно, почему ее операторы не исполняются, ведь мы уже привыкли, что программа это лист.
Во-первых, понятно — это отдельная поименованная область. Как текст/статья в рамке/блок в блок-схеме.
Во-вторых, при обучении элементарщине user defined функции не используются, они описываются позже.
В-третьих, отдельный модуль.
Я о том, что если есть простая причина почему надо делать какие-то действия, то это более понятно
А если нет никаких причин делать что-то ради того чтобы делать, еще лучше.
Мне кажется, это не лишнее, это и есть та суть, которую нужно понять — как работает программа.
Мы о разных стадиях говорим. Я имел дело с людьми, которые не знали совсем ничего. Такому ты объясняешь императивный принцип: вот твои действия: первое, второе, третье. Выполняются одно за одним, именно в таком порядке, никак иначе. Вот ветвление, вот цикл.
Потом, потом, уже идет «вот это повторяется, мы выделим это, назовем и вызовем. Это функция/подпрограмма».
Вот представьте, что вы объясняете по блок-схеме: здесь действия в чистом виде, никаких побочных объявлений, описаний, включений и пр. Чем лучше блок-схема отражается на язык, тем лучше для новичка.
Или тот же непопулярный нынче алгоритмический язык/мнемокод — описывает чисто алгоритм, используя базовые конструкции и никакой побочки.
Читаю комментарии и становится страшно за свое будущее, в глаза не видел паскаля и VB
Дата рождения:
17 января 1994
Логично. Время, внезапно, идет, популярные технологии сменяются.
Изучать надо с того, что показывает сразу результат
Паскаль с упомянутым вами VB и в совсем древнем варианте, Бейсиком (Питоном сегодня) — и есть то, что «дает результат сразу», по сравнению с Си, например.
до этого я знал только Visual Basic на очень базовом уровне
То-есть та самая начальная подготовка уже была, о чем я и написал.
но после объяснения тоже все понятно — курсор в начало / курсор вниз
Я не говорил, что «перевод строки» — непонятная хрень, я говорил о другом.
Писали void main(), главная функция — точка начала программы
А почему у программы должна быть точка начала, почему начало в виде функции?
Вот в примере на Бейсике все понятно: начался лист — началась программа. И так далее.
Вы идете все по тому же полю: "это можно понять, если приложить немного усилий". Я не говорю о том, что это дико непонятная вещь; я говорю о том, что это лишнее и мешает понять суть.
но раньше Linux использовал BIOS только для загрузки
Ага. Всего-то.
«Загрузка» это длиннющий и сложный процесс, за которым скрывается… всё — вся инициализация оборудования. Сервис для чтения, которым пользуется загрузчик — это по сути уже драйвер жесткого диска. А если он на PCI шине, если это SATA…
Не знаю как вам, а мне 1 строчку читать проще, чем 10
Если в 1 строчке фарш — то нет, спасибо. А пустые return и присвоения — это фарш. Субъективно, конечно же.
Куча бойлерплейт-кода для совершенно тривиальных вещей — это хорошо?
Так маппирование свойства на переменную 1 в 1 одной строчкой вместо строчных геттера/сеттера — это и есть «нет кучи бойлерплейт-кода».
Смысл в том, что если действие примитивно — просто map на внутреннюю переменную, то мы используем 1 строку. А если нам нужен сеттер с валидацией, то уже функция, как минимум 2 строки (простейший if), уже в строчку не уложишь — здесь вынесено отдельно.
Проще.
Труднее, но проще, а не сложнее. Вы видите свою программу целиком, можете использовать нестандартное размещение данных в регистрах. Компилятор же обязан придерживаться конвенции вызова.
Я бы сказал, что это отнсительно: если ты ставишь себе положительную цель, то работать заставит не возможность ее достигнуть, а риск наоборот, не получить желаемого. Т.е. непосредственная мотивация все же отрицательная.
Хотя, допускаю, что это вопрос субъективного восприятия.
По большей части это вкусовщина. Серьезно — если мы говорим не о сложных проектах, а обучении, то все сводится к «а мне не нравится объявлять переменные в самом начале» или «не люблю блоки с begin/end, хочу фигурные скобки, я так привык».
В школе изучал Basic. В ВУЗе давали стандартно: Паскаль (предмет «Алгоритмизация и структурное программирование»), потом Си в рамках него же, потом ООП на основе Паскаля. Затем Ассемблер, ООП на основе С++ с углубление в шаблоны и прочую перегрузку, потом нестандартное — Лисп, Пролог, параллельно — Организация ЭВМ, от самого железа и до уровня машинных кодов.
По-моему, очень правильная линейка: сначала человек учится что-то конкретное делать (Паскаль), затем изучает более глубоко (Си). То же с Ассемблером — сначала программируем в мнемокоде, а потом уже в машинной и изучаем «электронную» часть. И с ООП — сначала простое — на основе Паскаля, потом углубление. Потуги идти всегда от простого к сложному приводят к тому, что обучение идет от тяжелого к легкому и вся охота отбивается еще на раннем этапе.
Сейчас вместо Паскаля ввели Java, заместив 2 курса (программирование на ЯВУ и ООП).
Так на любом языке для «Hello, World!» нужно программный код писать
Не, человек сказал «кучу неочевидных вещей», а не «код».
Например, чтобы написать HW на Quick Basic, нужно ввести ровно одну строку:
PRINT «Hello world!»
И все. И объяснить начинающему, что это, несложно: вот оператор вывода, вот текст, который мы выводим.
Возьмем Си:
#include <stdio.h>
int main(){
printf('Hello world!\r\n');
return 0;
};
Здесь уже сложнее: это потом, когда ты продвинулся, ты понимаешь, что инклюд позволяет тебе связать твой код с библиотекой, но изначально, для новичка — это ненужное, вспомогательное действие. Лишнее на этом этапе обучения.
Потом — зачем нам нужна «главная» функция, почему и кому она возвращает результат, почему вывод сделан вот так, и почему перевод строки выглядит вот так…
В общем — много мишуры, которая при росте размера и сложности программы станет просто «погрешностью округления», но для новичка оно совсем лишнее и только путает.
Это я не к холивору, просто пытаюсь на пальцах показать разницу для новичков (ну, раз уж о HW речь зашла).
Это не то что бы ВМКашная последовательность, это каноничная. У нас единственно Ассемблер изучали после С++, до Лиспа с Прологом, как раз перед изучением «Организации ЭВМ».
Т.е. сначала нужно просто понять, что такое алгоритм. А потом идти от самых глубин
Золотые слова: последовательность «сначала машинная арифметика, потом Ассемблер, а уж потом что-нибудь еще» не работает. Человеку надо сначала влезть на ступеньку, с любым языком — будь то хоть Паскаль, хоть, прости господи, Бейсик. Почувствовать, попробовать программирование на вкус, а уж потом нырять.
Серьезно? Можно мне другой глобус, пожалуйста?
Это слишком индивидуально, такому не научишь.
Не только учат, но и непосредственно развивают: внезапно, физкультура.
Частично это делает литература, но она изрядно устарела, поэтому эффект мал.
У нас учили разным приемам в рамках уроков психологии.
Во-первых, понятно — это отдельная поименованная область. Как текст/статья в рамке/блок в блок-схеме.
Во-вторых, при обучении элементарщине user defined функции не используются, они описываются позже.
В-третьих, отдельный модуль.
А если нет никаких причин делать что-то ради того чтобы делать, еще лучше.
Мы о разных стадиях говорим. Я имел дело с людьми, которые не знали совсем ничего. Такому ты объясняешь императивный принцип: вот твои действия: первое, второе, третье. Выполняются одно за одним, именно в таком порядке, никак иначе. Вот ветвление, вот цикл.
Потом, потом, уже идет «вот это повторяется, мы выделим это, назовем и вызовем. Это функция/подпрограмма».
Вот представьте, что вы объясняете по блок-схеме: здесь действия в чистом виде, никаких побочных объявлений, описаний, включений и пр. Чем лучше блок-схема отражается на язык, тем лучше для новичка.
Или тот же непопулярный нынче алгоритмический язык/мнемокод — описывает чисто алгоритм, используя базовые конструкции и никакой побочки.
Логично. Время, внезапно, идет, популярные технологии сменяются.
Паскаль с упомянутым вами VB и в совсем древнем варианте, Бейсиком (Питоном сегодня) — и есть то, что «дает результат сразу», по сравнению с Си, например.
То-есть та самая начальная подготовка уже была, о чем я и написал.
Я не говорил, что «перевод строки» — непонятная хрень, я говорил о другом.
А почему у программы должна быть точка начала, почему начало в виде функции?
Вот в примере на Бейсике все понятно: начался лист — началась программа. И так далее.
Вы идете все по тому же полю: "это можно понять, если приложить немного усилий". Я не говорю о том, что это дико непонятная вещь; я говорю о том, что это лишнее и мешает понять суть.
Надеюсь, что это шуточный пункт. Просто не верится, что есть такая степень… странности пожеланий.
Ага. Всего-то.
«Загрузка» это длиннющий и сложный процесс, за которым скрывается… всё — вся инициализация оборудования. Сервис для чтения, которым пользуется загрузчик — это по сути уже драйвер жесткого диска. А если он на PCI шине, если это SATA…
Если в 1 строчке фарш — то нет, спасибо. А пустые return и присвоения — это фарш. Субъективно, конечно же.
Так маппирование свойства на переменную 1 в 1 одной строчкой вместо строчных геттера/сеттера — это и есть «нет кучи бойлерплейт-кода».
Смысл в том, что если действие примитивно — просто map на внутреннюю переменную, то мы используем 1 строку. А если нам нужен сеттер с валидацией, то уже функция, как минимум 2 строки (простейший if), уже в строчку не уложишь — здесь вынесено отдельно.
Проще.
Труднее, но проще, а не сложнее. Вы видите свою программу целиком, можете использовать нестандартное размещение данных в регистрах. Компилятор же обязан придерживаться конвенции вызова.
Хотя, допускаю, что это вопрос субъективного восприятия.
Бейсик понятен. Всем. Поэтому и используется(овался).
Эммм… просто: нет. Блоки как блоки. Модули, функции, составные операторы (по сути, не синтаксически).
По большей части это вкусовщина. Серьезно — если мы говорим не о сложных проектах, а обучении, то все сводится к «а мне не нравится объявлять переменные в самом начале» или «не люблю блоки с begin/end, хочу фигурные скобки, я так привык».
По-моему, очень правильная линейка: сначала человек учится что-то конкретное делать (Паскаль), затем изучает более глубоко (Си). То же с Ассемблером — сначала программируем в мнемокоде, а потом уже в машинной и изучаем «электронную» часть. И с ООП — сначала простое — на основе Паскаля, потом углубление. Потуги идти всегда от простого к сложному приводят к тому, что обучение идет от тяжелого к легкому и вся охота отбивается еще на раннем этапе.
Сейчас вместо Паскаля ввели Java, заместив 2 курса (программирование на ЯВУ и ООП).
Не, человек сказал «кучу неочевидных вещей», а не «код».
Например, чтобы написать HW на Quick Basic, нужно ввести ровно одну строку:
PRINT «Hello world!»
И все. И объяснить начинающему, что это, несложно: вот оператор вывода, вот текст, который мы выводим.
Возьмем Си:
#include <stdio.h>
int main(){
printf('Hello world!\r\n');
return 0;
};
Здесь уже сложнее: это потом, когда ты продвинулся, ты понимаешь, что инклюд позволяет тебе связать твой код с библиотекой, но изначально, для новичка — это ненужное, вспомогательное действие. Лишнее на этом этапе обучения.
Потом — зачем нам нужна «главная» функция, почему и кому она возвращает результат, почему вывод сделан вот так, и почему перевод строки выглядит вот так…
В общем — много мишуры, которая при росте размера и сложности программы станет просто «погрешностью округления», но для новичка оно совсем лишнее и только путает.
Это я не к холивору, просто пытаюсь на пальцах показать разницу для новичков (ну, раз уж о HW речь зашла).
Золотые слова: последовательность «сначала машинная арифметика, потом Ассемблер, а уж потом что-нибудь еще» не работает. Человеку надо сначала влезть на ступеньку, с любым языком — будь то хоть Паскаль, хоть, прости господи, Бейсик. Почувствовать, попробовать программирование на вкус, а уж потом нырять.