Здравствуйте, Сергей Губанов, Вы писали:
СГ>А я вот не понимаю в каком месте сложна Общая Теория Относительности, но встречал очень небольшое количество людей думающих также.
T>Это синтаксис. Фигня вобщем.
Какой нафиг синтаксис? Это определение и примеры использования. Понятие исчерпывающе определяется
в первых же преддложениях. И иллюстрируется на человекопонятном языке.
T>Почитай Джефа Эджера например. Такое могут осилить крайне малое количество программистов.
Читал, валяется где-то. Попытки Элджера сделать из си жабу мы рассматривать не будем — врядли
Спольски это имел ввиду.
Здравствуйте, Tanker, Вы писали:
T>Здравствуйте, dmz, Вы писали:
T>>>Ахтунг ! Джоэл — женщина ! dmz>>То, что Джоэл — ахтунг, факт широко известный. Думаете, это как-то связано с указателями?
T>Ахтунг ! Джоэл — ахтунг !
А указатель — это фаллический символ! И если программист любит играться с указателями, то ...
Здравствуйте, dmz, Вы писали:
dmz>А бывает вообще такое, что бы учили программировать без ознакомления с какой-нибудь (фон-неймановой) архитектурой?
Конечно, митовский MIT 6.001 (который упоминает Джоэль) так и устроен . Это вводный обязательный курс CS.
Сначала аппликативное функциональное программирование. Ближе к середине семестра вводится понятие присваивания , и заодно обясняют, как из замыкания за пять минут сделать ООП с множественным наследованием и.т.д. Потом ленивые списки потоки многозадачность и.т.д. Потом на лиспе пишут интерпретатор лиспа. Учатся в 5 строчек менять динамический скопинг на лексический, трансформировать AST и.т.п. Потом на лиспе пишут интерпретатор ленивого функионального языка. Потом недетерминистического. Потом пролога. И только после этого проектируют регистровую машину и пишут для нее компилятор.
На самом деле, современный вариант курса, который занимает один семестр, заканчивается на ленивом интерпретаторе.
Поинт был: показать, что можно двигаться от лямбда-исчисления к фон-неймановской архитектуре, и так даже проще.
Здравствуйте, Владек, Вы писали:
T>>Ахтунг ! Джоэл — ахтунг !
В>А указатель — это фаллический символ! И если программист любит играться с указателями, то ...
Видишь ли, тут все сложно. С одной стороны когда играется слишком много (чистый c/с++ник) это одно. А совсем другое — когда совсем не играется — C#.
На счет видео не знаю, но ссылка на перевод уже точно неоднократно проскакивала. Сейчас начал заниматься по этому курсу, стараюсь читать оригинал, но все же иногда заглядываю в перевод.
Mystic,
> СГ> А я вот не понимаю в каком месте сложна Общая Теория Относительности, но встречал очень небольшое количество людей думающих также.
> Бог с ней, ОТО... Вот квантовая механика...
Релятивистская
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, _prometey2005, Вы писали:
_>Есть люди которым они поддаються, есть те, кто никак не может понять их концепцию. Тут или дано, или не дано. _>Третьего не бывает.
_>На западе этот факт давно известен.
_>А вы уверены что сами понимаете их в полной мере?
Думается мне, что проблемы с указателями возникают у тех, кто пытается найти в них скрытый смысл и какую-то глубину. Идея-то соврешенно простая: указатель — это просто адресс в пямяти.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Думается мне, что проблемы с указателями возникают у тех, кто пытается найти в них скрытый смысл и какую-то глубину. Идея-то соврешенно простая: указатель — это просто адресс в пямяти.
А может переменная, хранящая адрес в памяти?
ЗЫ: Только не думайте, что я птыаюсь найти скрытый смысл .
It is always bad to give advices, but you will be never forgiven for a good one.
Oscar Wilde
Здравствуйте, _Obelisk_, Вы писали:
_O_>Думается мне, что проблемы с указателями возникают у тех, кто пытается найти в них скрытый смысл и какую-то глубину. Идея-то соврешенно простая: указатель — это просто адресс в пямяти.
Идея простая. Только использовать сложно. На самом деле указатели это не просто IPNode* pNode = NULL; Это ручное управление памнятью. И если с адресной арифметикой все в порядке у многих людей, то с ручным управлением памяти далеко не все в порядке.
Указатели надо
1. всегда инициализировать нулем
2. всегда ставить ассерт на !NULL при использование (как минимум)
3. всегда проверять что куда присваиваешь
4. всегда затирать нулем если объект разрушен
5. следить за
а. указателями на стек
б. хип
в. в секгмент данных
6. осторожно пользоваться адресной арифметикой
7. осторожно пользоваться приведением типа
Теперь про управление памятью
8. следить за тем
а. кто выделяет память
б. кто освобождает память
9. Проверять неявное выделение памяти
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Mystic,
>> СГ> А я вот не понимаю в каком месте сложна Общая Теория Относительности, но встречал очень небольшое количество людей думающих также.
>> Бог с ней, ОТО... Вот квантовая механика...
ПК>Релятивистская
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>А я вот не понимаю в каком месте сложна Общая Теория Относительности, но встречал очень небольшое количество людей думающих также.
M>Бог с ней, ОТО... Вот квантовая механика...
Она еще проще формулируется :)
"Теория унитарных операторов в гильбертовом пространстве" :)
Фиг его знает, конечно, может так оно и правильней...
Но я отношусь к таким людям, которые весьма психуют, если из того, что им преподают хотя бы малая толика является "черным ящиком по определению". Т.е. ни в математике, ни в физике ни в химии в меня инфа совершенно не хотела лезть, если я абсолютно ясно не представлял себе, как именно что-ли происходит или откуда выводится.
Когда к нам в 9-м классе завезли "Корветы" и он высветил мне строку приглашения бэйсика, как сейчас помню — это заставило меня мучаться примерно неделю. Мучаться очень сильно вопросами: "КАК" и "ПОЧЕМУ"?
Я уже неплохо владел электроникой к тому времени, но мне трудно было представить себе размер микросхемы, которая выполняла бы бэйсик аппаратно (не микропрограммно, а именно аппаратно, так мне казалось по-началу). Потом я купил себе книжку по микропроцессорам (уже даже не помню какую), где так же дано было немного от дискретки и проектировании автоматов. Проглотил ее за 3 дня и... хлоп!!! Картинка ожила, все встало на свои места. От моего прежнего понимания транзисторов до только что понятых вентилей, тактов, состояний, микро- и макро- программного управления цифровым автоматами.
Если бы не эта книжка, я бы просто продолжал нервничать, видя "разумное" поведение бейсик-консоли и не понимая "КАК ЭТО?"
А от изучения Схемы и лямбд без понимания того, на чем это все зиждется лично мне мало было бы толку. Мне был бы банально не интересен предмет, который построен на непонятных мне принципах. Какой смысл строить интерпретатор Лиспа на Лиспе, если студент понятия не имеет о формальных грамматиках? А после того как поимеет, то тем более, строить интерпретатор с этого языка будет бессмысленно, ибо не добавит навыков/образования.
Здравствуйте, vdimas, Вы писали:
V>Когда к нам в 9-м классе завезли "Корветы" и он высветил мне строку приглашения бэйсика, как сейчас помню — это заставило меня мучаться примерно неделю. Мучаться очень сильно вопросами: "КАК" и "ПОЧЕМУ"?
... V>Если бы не эта книжка, я бы просто продолжал нервничать, видя "разумное" поведение бейсик-консоли и не понимая "КАК ЭТО?"
... V>А от изучения Схемы и лямбд без понимания того, на чем это все зиждется лично мне мало было бы толку.
Я не согласен абсолютно. Хорошо рассуждать, когда добрый американский дядя уже изобрел для тебя этот "Корвет". Схема зиждется на лямбда-исчислении. Лямбда-вычислитель никому не обязан быть реализован как компьютер. И к нашему счастью, Черча и Тьюринга не остановило то, что книгу про микропроцессоры взять было негде
Схему на 6.001 не изучают — ее используют после 10-минутной инструкции по применению.
V> Мне был бы банально не интересен предмет, который построен на непонятных мне принципах. Какой смысл строить интерпретатор Лиспа на Лиспе, если студент понятия не имеет о формальных грамматиках? А после того как поимеет, то тем более, строить интерпретатор с этого языка будет бессмысленно, ибо не добавит навыков/образования.
Интерпретаторы строят не на принципах формальных грамматик. Их строят на основе вычислительных моделей. Задумайтесь, чем отличается интерпретатор Scheme от интерпретатора Haskell. Грамматикой?
А вто что сами авторы пишут о "какой смысл" — Chapter 4. Metalinguistic Abstraction
Если кому интересно попробовать — помимо SICP, есть еще, по крайней мере, 4 университетских курса (широко применяемых за пределами породивших их университетов) на которых "пишут интерпретаторы":
Здравствуйте, _Obelisk_, Вы писали:
T>>Слишком много правил, не правда ли ?
_O_>Нет. Все правила неплохо запоминаются и следовать им можно на автомате.
Запоминаются. Можно следовать. Вот только поработоав три года на шарпе и вернувшись в плюсы я вижу, что надо учиться заново.
Здравствуйте, Tanker, Вы писали:
T>Указатели надо T>1. всегда инициализировать нулем
Хм... зачем? Указатели надо инициализировать перед использованием, как и все прочие переменные.
P := nil; // Следуем непогрешимому правилу #1 и получаем хинт.
P := AllocMem(16);
T>2. всегда ставить ассерт на !NULL при использование (как минимум)
В зависимости от контекста. Если мы получили адрес локальной переменной, функции/процедуры, то зачем тут Assert?
P := @I;
P^ := 4; // А тут, имхо, Assert лишь загромоздит кода, коинтольное изнасилование в голову выходит...
Во-вторых, отлов нулевых указателей почти везде работает на ура и не несет большой проблемы. То ли свалится Assert, то ли свалится использующий оператор --- не вижу разницы. Б\'ольшая проблема --- использование поврежденных указателей.
T>3. всегда проверять что куда присваиваешь
Целиком и полностью за, но настаиваю на том, что данный пункт справедлив не только в отношении указателей Если в переменную, которая хранит напряжение в вольтах мы поместим силу тока в амперах, то последствия могут быть не менее катастрофическими! Такая уж работа программиста, что надо проверять написанный тобою код. Всем надо пользоваться осторожно. Ошибка с указателями стоит слетом программы, а вот если забыть поставить условие WHERE ID = @ID в операторе DELETE... Если писать тяп-ляп, то тут уже все равно, указатели это, БД или что еще.
T>4. всегда затирать нулем если объект разрушен
Возможны различные схемы. В некоторых случаях это бессмысленно. А когда ты не уверен в том, что указателем никто больше не воспользется, то совет разумен.
procedure Test;
var P: Pointer;
begin
GetMem(P, 30);
try
finally
FreeMem(P);
P := nil; // Объект разрушен, следуем правилу #4end;
end;
T>5. следить за T> а. указателями на стек T> б. хип T> в. в секгмент данных
Тут я совсем не понял. Что значит --- за ними следить? Их надо различать в ряде случаев. Но если метод принимает указатель, то в большинстве случаев безразлично, на что он указывает.
T>6. осторожно пользоваться адресной арифметикой
Чем отличается от п. 3?
T>7. осторожно пользоваться приведением типа
Тавтология с п. 3.
T>Теперь про управление памятью T>8. следить за тем T> а. кто выделяет память T> б. кто освобождает память
Иногда это проблема. Иногда это тривиально. К тому же указатели это не обязательно динамическая память.
T>9. Проверять неявное выделение памяти
В смысле, проверять? Вот в .NET вся динамическая память выделяется неявно, как мне ее прикажете проверять???
T>Слишком много правил, не правда ли ?
Все с легкостью выводимо из понимания архитектуры. К тому же приведенные правила не имеют догматичный характер...
