Какой ЯП выбрать?

ООП вне языков. ООП учить надо независимо отнизкоуровневой чуши.

А почему ты промолчал про лисп?

А почему ты промолчал про лисп?

LISP он очень высокоуровневый. Совсем не в тему.

Питон не испортит, MIT гарантирует это.

Дык, насколько понимаю, на питоне там преподают как раз не-программистам (типа робототехников), а что касается тех, у кого computer science - основная тема, то их мучают по-прежнему лиспом и sicp.

Питон не испортит, MIT гарантирует это.

Дык, насколько понимаю, на питоне там преподают как раз не-программистам (типа робототехников)

Это неважно.

Это неважно.

Наш автор пишет: «[...] я хотел бы вообще выучить алгоритмы и т.д, т.к хочу стать программистом, а не тупым кодером.»

В MIT преподают Python тупым кодерам или что?

если уж рекомендовать Кнута то

Конкретная Математика

Математические методы анализа алгоритмов

зря??? значит ты не курил Алгоритмы + структуры данных == программы

на сколько баллов было самое бальное задание которое сам решил?

Это слишком далеко от программирования, чтоб с этого начинать. Хотя книга годная, да.

нельзя в буквы до половой зрелости.

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

есть оптимизаторы - книжка(бетонная) для вторых.

по факту это не должности - а навыки и специализации

если уж рекомендовать Кнута то Конкретная Математика

ТС писал, что для него математика - не проблема. Пусть изучает, одно другому не мешает.

ты лично почитай послушай Степанова.

на сколько баллов было самое бальное задание которое сам решил?

40+, хотя не совсем честно - до того читал о решении похожих проблем. Много простых(по рейтингу Кнута) не смог осилить потому, что слабо знаю математику. За то осилил много средних, где матан не сложный, или мне знакомый.

Вообще, матана у Кнута конечно много, ну что поделать… Его и в жизни не мало, только у web-говнокодеров матана нет.

ты лично почитай послушай Степанова.

это который STL?

Сначала следует подучить английский - без него никак. Стартовать лучше с Free Pascal. Если чувствуешь в себе силы - с Python.

ага. родовое

если совсем не прогал. и компитентен в матане то можно сразу питон

MIT предлагает python не программистам.

а как же https://www.edx.org/courses/MITx/6.00x/2013_Spring/about

Ок, в чем он плохой и какой учебник лучше SICP?

сначала SICP(он сейчас вроде как Python использует для кода кстати), потом PAIP.

А почему ты промолчал про лисп?

Почему не предлагаю дифференциальное исчисление человеку, который читать и писать не умеет?

Special for you :) Python - язык слишком высокого уровня. Вначале нужно разобраться с низкоуровневым. Запутаться в указателях там, поймать не одну утечку памяти, споткнуться о то, что твоя локальная переменная уже тю-тю из-за того, что стек находится совсем в другом состоянии, ну и куча всего другого (кстати, точно такую же ошибку с локальной переменной я не так давно поймал в common lisp в чужом коде, но быстро раскусил - вот там дикая смесь очень высокоуровневых и довольно низкоуровневых вещей, на выбор).

Тут добрые люди советуют начать со Scala. Ну что же, на ЛОРе и не такое бывает. Почему бы и нет? А чем питон тогда лучше? Но я считаю, что плох тот программист на Scala, который не представляет себе, как она может быть скомпилирована на Java, а потом, как Java может быть скомпилирована на Си, и наконец, как код на Си может быть переведен в машинные коды (эх зря, отдал одному товарищу такую классную голубенькую книжечку с компилятором довольно большого подмножества Си - чертовски теперь жалею). Хотя, быть может, я требую слишком многого :)

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

Почему именно в начале?

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

Что-то не припомню, чтобы такие проблемы были в Scheme (ага, тот самый SICP, с которого начинают обучение Ъ-прогеров в MIT).

Тут добрые люди советуют начать со Scala. Ну что же, на ЛОРе и не такое бывает. Почему бы и нет? А чем питон тогда лучше?

Потому что Scala идет с двойным грузом - JVM и очень нетривиальной системой типов.

плох тот программист на Scala, который не представляет себе, как она может быть скомпилирована на Java, а потом, как Java может быть скомпилирована на Си, и наконец, как код на Си может быть переведен в машинные коды

Не понимаю, почему ты остановился. Давай спустимся вниз до микроархитектуры, потом до триггеров и вентилей (кстати, всё это реально полезно). Но мы говорим о первом языке или об университетском курсе CS/SE?

P.S. ИМХО, прогеру на Scala нафиг не нужно знать, какой машкод получится из его программы.

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

P.S. ИМХО, прогеру на Scala нафиг не нужно знать, какой машкод получится из его программы.

Ты утрируешь. Я писал о том, что желательно иметь представление, а не о том, что нужно знать. Не находишь, что смысл разный? Но точно желательно знать, как Scala транслируется в Java.

Тогда пусть товарищ пообещает нам после питона обязательно изучить си.

...параллельно с SML :)

Кстати, почему не посоветовали coursera?

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

если так подходит то нужно действительно начинать с языка(ов) в которых не зависит от контекста семантика имени перемереной.

например во всех алгол-языках различаетя «lvalue» VS «rvalue» семантика одного и того же терминала ( имя переменой )

реально затруднения плодятся когда оказывается что у части имён компилятор делает привычное разыменования , а у части (зная их тип - строки в одних языка, обьекты в других) не делает.

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

sml - если сильно не танцевать вокруг строгой типизации - а чисто как язык описания процедур - вполне хорош для научения алгоритмизации

Д. Хендрикс?

сначала SICP(он сейчас вроде как Python использует для кода кстати),

4.2

там схема.

Тогда пусть товарищ пообещает нам после питона обязательно изучить си.

...параллельно с SML :)

Да, тут без честного пионерского не обойтись.

Кстати, почему не посоветовали coursera?

Я про нее почти ничего не знаю. Заходил на сайт пару раз и все.

Си.

не знаю такого

Д.Хендрикс Компилятор языка Си для микроЭВМ

Алголовские языки хороши для обучения. Мне школьником очень нравились Modula-2 и Ada-83. Наверное, их тоже можно считать алголовскими.

А, понял. Я названия не помню, потому что это было 13 лет назад. Сейчас попробую пробить. Может быть, и она.

Да, там был Small C, но обложку не признаю. Может, и совсем забыл, как она выглядит, но по-моему обложка была другой.

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

лисп это реальный матан

никакой это не матан. Обычный ЯП, просто подход не естественный. Создатели машинных кодов тупо хотели сделать такие коды, на которых удобнее и быстрее было-бы программировать. Сделали. И не один набор, а МНОГО. Пришлось придумать C, что-бы можно было писать сразу на любой CPU, в т.ч. и тот, которого ещё или уже нет. Параллельно этим заинтересовались математики, и задумались о том, а что собственно нужно, что-бы написать «идеальный C». Нужны функции. Ну и всё. Всё остальное можно выкинуть нафиг. Так возник LISP. Один тип данных(список) + одна идиома(функция). Остальное пусть кодер додумывает, если оно ему надо. Как это не удивительно, для некоторых целей, такой подход оказался годен. Ибо избавлял от лишних сущностей, и давал возможность обдумать алгоритм. В этом смысле C получился более низкоуровневым, и более приземлённым.

Фишка в том, что как не крути, мысли в комп не запихаешь, и приходится придумывать какой-то костыль-ЯП. Не факт, что более близкий к мозгам костыль будет лучше, потому и получается так, что концептуально более сложные задачи проще решать на LISP'е, а более простые - на всяких C-диалектах.

можно конечно асемблерить и на лиспе

нельзя. Это УЖЕ ассемблер, только для очень простой придуманной машины. Но её «простота» похожа на простоту машины Тьюринга - IRL сделать невозможно.

Создатели машинных кодов тупо хотели сделать такие коды, на которых удобнее и быстрее было-бы программировать.

Машинные коды делаются для _машины_. То есть для того, чтобы процессору удобно было их исполнять. Удобство человека тут и рядом не пробегало.

http://www-inst.eecs.berkeley.edu/~cs61a/sp12/book/index.html

http://ru.wikibooks.org/wiki/Учебник_Python_2.6 - отличный учебник по пайтону.

Машинные коды делаются для _машины_. То есть для того, чтобы процессору удобно было их исполнять. Удобство человека тут и рядом не пробегало.

сам-то понял что сказал? А кто код писать будет? Если ты не понял, я про ситуацию 50 лет назад, задолго до твоей JVM.

Продолжаешь позориться, изрыгая отвратительную чушь?

http://www-inst.eecs.berkeley.edu/~cs61a/sp12/book/index.html

при желании можно и на BrainFuck'е написать. Что это доказывает? Говорю-же: язык вторичен. SICP изначально на схеме пейсалась. вот тебе пруф: http://mitpress.mit.edu/sicp/full-text/book/book.html

Продолжаешь позориться, изрыгая отвратительную чушь?

GTFO

для тупых - картинка: http://noobstore.com/prodimages/sign-gtfo-400.jpg

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