>>168312
Ты неправильно ставишь задачу.
Неправильно - "Какой бы мне язык программирования изучить?"
Правильно - "У меня есть такая-то задача, на чем и как её лучше решать?"
Поставь правильно цель, чтобы в ответ услышать не "боку но питон" или "бэтлсидоадз++ зе анимеййщон".

>>168315
Вообще-то, ОП спросил, "с чего начинать", а не "какой язык программирования изучить".

Итак, ОП, в программировании есть два аспекта (ну, как минимум два, лол) — логическая часть, то есть программисткая наука, все эти алгоритмы, структуры данных, кампутир саенс и прочее, и материальная часть, логические элементы, (микро)архитектура и система команд, и прочее такое. Вообще, люди обычно втыкают плотно либо в одно, либо в другое в силу специфики работы и специализации.

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

>>168312
Начинай: "Структуры данных и алгоритмы"

>>168319

>ОП спросил, "с чего начинать"

С чего начинать для достижения какой цели?

>>168321
Изучать программирование, очевидно.

>>168322

Пусть тогда про BASIC почитает и закончит на этом.

>>168319

>Но начинать все равно следует с ассемблера целевой машины.

Откуда вы такие лезете?

https://www.jetbrains.com/pycharm-educational/

>>168374
Вообще, я хотел сказать, со схемотехники, лол, но подумал, что это слишком.
А вообще, what's wrong? Может, он разработчиком компилера хочет стать?

>>168377

>Может, он разработчиком компилера хочет стать?

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

>>168374
А я поддвачну этого ассемблерщика. В школе учили паскаль, в универе на младших курсах С++, но хоть что-то в программировании я начал понимать именно после ассемблера.

>>168378

>Но в остальных случаях, нахрена забивать этим голову?

Это называется "образование".

>Или ты думаешь, ты умнее компилятора, лучше что-то соптимизируешь?

Компиляторы писали люди. Возможно, я смогу улучшить компилятор. Или, может, я хочу свой ЯП?

>Сегодня знание команд и регистров конкретной (x86) архитектуры тебе не даст ровным счётом ничего

Офигительные новости.
Оно дает как минимум представление о том, как работает программа на низком уровне. До ассемблера понятие "стек" (имеется в виду не общее понятие структуры данных "стек") и как работают автоматические переменные в Си, например, были для меня лишь мантрами. После — это стало гораздо более понятным и логичным.

>с практической точки зрения - разве что если пишешь под какие-то очень специфические микроконтроллеры

ОП ничего не сказал по поводу своих задач. :p

>>168379 Кстати, да.
Я начинал с ассемблера (не считая BASIC'а на ZX Spectrum в детстве) и часто замечаю, что тем, кто начинал с языков более высокого уровня, бывает очень трудно понять элементарные вещи о функционировании их собственного кода.
Для них его работа является своего рода магией - набором произвольных абстракций без внутренней логики и предсказуемого поведения.

>>168312
python

>>168380

> представление о том, как работает программа на низком уровне

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

>>168383
Потому, что алгебру гораздо сподручнее учить, зная арифметику.
Если ты, конечно, действительно хочешь её выучить, а не просто подставлять значения в готовые формулы из книги.

>>168384
Некорректная ассоциация.

>>168383

>электроники

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

>И зачем оно мне?

Тут уже несколько раз прозвучало, зачем. Если ты себя комфортно чувствуешь и так, то тебе это, наверно, не нужно.

На нашем замкадском факультете/вузе/кафедре так: сперва базовый ассемблер, причем RISC-ассемблер с прилжениями на МК с изучением базовой (простой) архтектуры (в т.ч. гарвардской), потом лоу-левел C тоже на разных платформах (не х86, тоже там dsp, мк и прочее soc-добро), потом структуры данных и алгоритмы с практикумом на плюсах, потом есть что-то на сях под никсами, ах, да, потом ещё курс по базам данных, курс по МЭКовским языкам и платформам ПЛК, сетям, языки и системы для модерирования процессов и систем, потом для желающих - жаба или шарпы, или ещё что-то там, не знаю, не мой курс.
Правда, у нас готовят не кодиров, а спецов по управлению/автоматизации и системных аналитиков, но не суть важно, базовые знания на тему "как кодить коды" у них таки есть.

>>168383

> конечном итоге перейти на какую-нибудь квантовую физику

Неплохая идея.

>>168380

>Оно дает как минимум представление о том, как работает программа на низком уровне.

А какой же это низкий уровень? Ты манипулируешь такими же абстракциями, вот стек, регистры, команды, MOV, ADD, оп-коды какие-то. А как это устроено внутри, абстракция, и так ты дойдёшь до вопроса, как работает p-n переход.
Вообще всё знать невозможно, можно, конечно, в целях общего образования, но не нужно, а особенно - начинать с этого, только запутает и оттолкнёт.

Более важно, как написал >>168320, алгоритмы и структуры данных, дискретную математику, ибо если алгоритм работает за квадрат, хоть обоптимизируйся, логарифм быстрее отработает. И конечно, понимать принципы ООП, если пишешь что-то сложнее hello world

>>168396

> и так ты дойдёшь до вопроса, как работает p-n переход.

Хорошо, что я учился на радиотехническом. Плохо, что мне это вряд ли понадобится.

>>168396

>А какой же это низкий уровень?

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

>а особенно - начинать с этого, только запутает и оттолкнёт

Согласен с тем, что асм x86 — плохой старт. x86 просто ужасный ассемблер, меня от него тошнит.

>ибо если алгоритм работает за квадрат, хоть обоптимизируйся, логарифм быстрее отработает

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

>И конечно, понимать принципы ООП, если пишешь что-то сложнее hello world

nigga pls
gives u a link to linux source tree

>>168401

>Все программисты, от разработчика компилятора и ядра ОС до последней код-макаки видят именно команды процессора, закодированные в разные шаблоны.

Лол. Команды какого именно процессора (x86, x86_64, ARM, MIPS?), в твоём понимании, видит программист? Даже в рамках одной (x86) архитектуры, можно скомпилировать, например, с поддержкой MMX, SSE и т.д., а можно без них.
И это не говоря про интерпретаторы, вроде того же питона, и такие вещи, как jvm и дотнет, которые специально созданы, чтобы абстрагироваться от деталей реализации конкретной архитектуры.

>Но как только ты перестаешь программировать на бумажке, тебе следует начать с ассемблера

Ой, всё

>>168402

>Команды какого именно процессора

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

>интерпретаторы, вроде того же питона
>питон
>интерпретатор

Лол.

>Ой, всё

Что, все? Все твои язычки, джава-машины и доднеты подчиняются конкретной системе команд, когда исполняются. Не знаешь ее — не знаешь, как работает твой язык, уж извини.
Хотя, может, можно какие-то более общие академические книжки и про это прочесть, чем задрачивать каждый асм, тут можно согласиться.

>>168403

>Все. Сводится. К машинному. Коду.

Да кто спорит? А машинный код, в свою очередь, сводится к электронике.

>Все твои язычки, джава-машины и доднеты подчиняются конкретной системе команд, когда исполняются

Так в том и дело, что не java - это просто такой стандарт и абстракция. Можно сделать реализацию виртуальной машины, соответствующую стандарту, под x86, под arm, под sparc, под ia-64, под стиральную машинку, вот они, таки да, будут транслировать байт-код jvm в свой ассемблер. И ты этим хочешь сказать, чтобы знать жаву, нужно знать ассемблеры вообще всех-всех архитектур?

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

>что java

фикс >>168405

>>168405

>Да кто спорит? А машинный код, в свою очередь, сводится к электронике.

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

>И ты этим хочешь сказать, чтобы знать жаву

Да. Поэтому полностью никто джаву знать не может, и поэтому там черт ногу сломит.
Вообще, мне глубоко претит идея кода "один раз написал — всегда и везде работает". Код должен быть более гибким и подстраиваться под задачи и реалии, поскольку есть разумные пределы автоматизации же.
Так что про джаву я знаю мало. И работаит она медленно. :-(

>кроме того, что это привязка к архитектуре

Ну да, синдром утенка может проявиться потом, это плохо. Поэтому не рекомендую слишком углубляться.

>попробуй напиши какой-нибудь qsort на ассемблере (любом) и на си

Ну, если писать для только одного известного типа данных, предпочтительно числового (предпочтительно целочисленного :D) то это не очень тяжело для x86.
На си, конечно, будет заметно легче, но на то и язык высокого уровня, пардон. Вот эти "{" "}" штуки делают очень много. :D

>>168407

>программист дальше машинного кода не видит

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

Даже если ты точно знаешь, что будет работать, к примеру, только на x86, и пишешь код с расчетом, что компилятор скомпилирует именно в конкретные коды. А потом обновили gcc, или я в своей gentoo решил пересобрать с оптимизацией -O3 и всё, привет.

>Да. Поэтому полностью никто джаву знать не может, и поэтому там черт ногу сломит

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

>>168408
Не, я не рекомендовал изучать настолько, чтоб прям "писать с расчетом". Код на языках высокого уровня должен писаться, как должен на этих языках, ассемблерные вставки, если необходимы, идут отдельно.

>можно сконцентрироваться на решении задачи, на математике

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

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

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

>>168410

>Я не рекомендую становится гуру асма, если тебе это не надо. Я рекомендую побаловаться и бросить, это реально здорово.

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

>Ветвтвления и циклы довольно простые

Но вообще, если так посмотреть ассемблер - самый простой язык, каждая команда делает простое действие. Но чтобы что-то написать, приходится всё усложнять.
Например: if (a>0) -> две команды (допустим, a у нас в регистре), cmp (сравнение) и jg (условный переход).
Но если нужно что-то более сложное: if ((a+b)>=0 && !c) то на ассемблере это превратится в дохрена строчек, в которых с первого взгляда не понятно ничего

>>168413

>if ((a+b)>=0 && !c)

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

>>168413

>if (a>0)

А 0 у тебя в уме? Что такое больше? Что такое если?

>>168418

>здорово мимикрирует под "человеческую" запись арифметики и алгебры-логики

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

>>168389

>Правда, у нас готовят не кодиров

Ну а кодиры получают ударную дозу прикладной математики.

>>168428
Работа с "человеческой" записью приводит к расхлябанности.
Тебе для программы нужен конкретный инструмент-функция и конкретная переменая-область значений.
Ты делаешь этот инструмент на асме. Обзываешь как-то нехорошо и даешь лентяю поиграться. Приходит лентяй и создает свою специальную процедурку, включая туда твою и еще десяток других функций, к каждой из которых присобачивает объекты.
Это он обзывает процедурой на си и даетет дурачку поиграться. Тот из таких процедур ваяет модуль, прифигачивает новые имена вызова и утаптывает в монстров-универсалов, которым можно вбивать сотни различных вариаций параметров.
И вот уже приползает кто-то уровня кишечнополосных и собирает из таких модулей и объектов библиотеки.
Потом на их основе некие амебы ваяют какой-то скриптовый "язык".
А бульон коацерватных капель создает "среды разработки".
И вот уже из них создают "редакторы".

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

И вот с такой логикой разработки мы приходим к тому, например, что странички, которые выглядят практически так же, как в 2005-м, которые в том 2005-м летали на 2 мегабитах в секунду, в 2015-м тормозят на ресурсах, превышающих ресурсы средней машины 2005-го в разы, при скоростях в 50 мегабит.

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

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

>>168431
Так а ты сравни время (==стоимость) разработки и поддержки на каком-нибудь питоне в "среде разработки" и на ассемблере. И становится понятно, что целесообразнее таки докупить памяти и процессор на больше гигагерц.

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

>появляется поколение "специалистов", для которых логика и причины происходящих в "гудящем железном ящике" процессов остаются такой же непостижимой магической загадкой

Собственно, для тебя также остаётся загадкой, что делает "гудящий ящик", когда ты пишешь MOV или ADD. Intel тебе не расскажет, что там внутри. Разница между тобой и тем самым реднеком лишь в том, что ты углубился чуть дальше, в рамках одной архитектуры.

>странички, которые выглядят практически так же, как в 2005-м

Ошеломительная история! Тонны мультимедиа, AJAX в 2005 году.
Хотя частично соглашусь, веб сейчас слишком жирный, и делать всё средствами разных js и флешей в браузере неоптимально, что подтверждается тем, что все более-менее крупные порталы, вроде того же контактика и твиттера, делают отдельные клиенты под всякие iOS, где ресурсы более ограничены.

>>168437

>для тебя также остаётся загадкой, что делает "гудящий ящик", когда ты пишешь MOV или ADD

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

>>168438
Проприетарная микросхема у тебя - именно чёрный ящик