psilogic | Страшная тайна ;)

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

From:

ГГГ

И вы никогда не наблюдали сценку, когда опытный программер решает задачки этого типа методом тыка, не? ;)

From:

Не доводилось. :)
Вроде это всё-тки совсем азы.

From:

Ну вот а мне доводилось. Так что, хоть и не откровение, но пущай лежит - вдруг да пригодицца.

From:

Когда возникает такой товраищ на горизонте, который задачи уровня грамматики языка решает методом тыка, его сразу надо посылать читать не такие вот отдельные тексты, а стандарт языка. В данном случае, Керниган-Ричи, второе издание, 1988 год, 272 страниц. Это два вечера вдумчивого чтения. И глупых вопросов больше не будет, вместо них будет нормальное понимание, как устроен язык.

From:

И при чем тут стандарт изыка? Это конкретная задачка, которая может в простых случаях решаться по аналогии/интуитивно, а в сложных - тыком или механически.

From:

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

Например если немного понимаешь мысли, стоявшие за Си, никогда не перепутаешь int *f() и int (*f)().
Понимать нужно всего лишь две вещи:
- Операция () как и [] имеет более высокий приоритет, чем *. Проверочная конструкция:
int *f() = int* f().
(Из чего немедленно ясно, что в первом случае у нас функция, возвращающая указатели на целые числа.)

- Принцип подстановки: если а определено как int *a, то *а должно иметь тип int. Если f определено как int f(), то f() должно иметь тип int. Соответственно *f во втором случае должно иметь тот же тип, что и x в int x(). (Из чего немедленно ясно, что во втором случае у нас указатель на функцию, возвращающую целые числа.)

From:

И о чем мы спорим? Ты предложил еще один механический способ... imho более медленный.

From:

Думать головой и понимать, почему всё устроенно именно так как устроено — это механический способ? :-)

http://www.trizway.com/art/article/210.html (Классическая “Он чинит приёмники, думая” Р. Фейнмана.)

From:

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

From:

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

From:

Может, работают именно так, как описано выше - просто ты делаеьш это на автомате.

From:

Наверное да.

From:

О! Кстати, вспомнил, что тебя можно поднапрячь, ибо алгоритмист. А скажи почто cтруктуры данных не в почёте? Ну, ясно, что ООП превозмогло, но это же совершенно другое, в пределе, представление инфы. Не нуждающееся в данных. Т.е. сама структура, представленная адресами, и есть данные.

From:

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

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

From:

Не... Не в тему. До ООП было структурное программирование. Структвра служила для организации данных. Она и посейчас этому предназначена. Но было ответвление - способпрограммирования, где структуры ибыли самипо себе данными. СТруктуры,заданные адресами, данных не содержали, а представляли сосбой множества. Вот что с ними стало?

From:

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

Первое - это "значение" или "экземпляр", второе - тип значения, оба они обзываются словом "структура".

From:

Тыменя совершенно не понимаешь! Нет данных в структуре, есть только структура - связанный адресами список и ВСЁ! Никаких данных внутри! Узел списка и есть данные! Куда делся способ? Где надыбать? Первичная классификация разрулиалась на списковом представлении множемств. Начало 70-х.
--------------------
Кстати, возник личнный вопрос. Кинь мне на почту, чтобы ответить. Твою не нашёл.

From:

Ты часом не про LISP и лямбда-исчисление?
--------
xoxox(САБАКА)list.ru

From:

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

From:

ru_lambda

From:

pascendi.livejournal.com

А потом надо подробно объяснить человеку, почему НЕ НАДО пользоваться такими штучками в реальной жизни :-)

From: